REVISED FLIGHT TIMER GAUGE

[Tom Goodrick]

I got a good suggestion today from Jean ROBERT d'ESHOUGUES concerning how to fix the FTime gauge to avoid premature resets to zero after landing. The logic of the gauge is such that it is not easy to implement his suggestion exactly. (It seemed all Greek to me after 4 years.) But the change I made is essentialy as good and may be better for flights like in this GAAR where we try to match Target Times.

The new gauge is posted now on my website (click on the first icon under my photo at left). Download FTimeV4.zip and install it per directions. You will not have to change installations in individual aircraft because the new file has the same name as the old file - just different dates. The other one was four years old.

The new gauge still measures time from 35 KIAS on takeoff to 35 KIAS on landing so there will NOT be any change in measured times. But with the new gauge you can slow to 26 KIAS and then get a gust to over 35 KIAS without losing the time. The time will simply be extended to count time while rolling. Only when you slow below 25 KIAS and then increase speed above 35 knots will the gauge reset and start timing a new flight.

This should allow you to extend a roll to get as much flight time as possible to match a target. I tested this gauge on several aircraft and landing conditions, including the condition at YCRG in this GAAR where the old gauge failed on me. The new version has worked in all cases so far. But consider it in the Beta stage of development. Please report any failures to me.

Thanks Jean!

Good luck, all.

[paulv]

Hi Tom

Thanks for the revised gauge. Looking forward to using it.

Regards




Paul

[Les Smith]

Hi Tom

I have encountered a problem with the new flight timer ver 4.

After setting up a flight I save it to disk in FSX. MAAM DC3.

When I am ready to fly I load the flight from disk and start the take-off run. The timer shows 0.00'. At about 35 kts the timer suddenly starts with a very high figure like 1006.56'. I abort the run. Reset the flight. Start the run again and all is well. The timer performs perfectly.

Any clues on what has happened?

Les

[Tom Goodrick]

Les, I am afraid I cannot help you much with this because it is, evidently, a feature only of FSX. It does not happen in FS9. I just checked that. I don't have FSX and cannot test anything I do against FSX. This is why I say I cannot vouch for the performance of anything I do in FSX.

Everyone using FSX should consider this as a potential problem.

But it probably occurs because of the process of saving the flight situation in FSX. This process must put some value into the variable I name and start for the gauge during a flight.

One thing you can try is to turn off the engine before you save the situation.

Another suggestion would be to stop saving the flight at that point. The situation is already saved with regard to position of the aircraft and setting the weather. Why save it a second time?

Another possible solution is to start a takeoff, cut power and brake after the timer starts with its bogus value, and taxi back for a second start. You might have to stop and restart the engine.

[paulv]

Les, just to check the basics, can you please send the portion of the panel.cfg, including the new gauge entry.

Secondly, can you confirm that this happens in another aircraft, e.g. default C172, or is it limited to the MAAM DC3?

Lastly, are you using any other add-on programs in conjunction? Specifically, external weather or local scenery?

Does it happen only with GAAR situation files, or another user-generated free-flight?

Regards




Paul

[Les Smith]

Hi Paul and Tom
The above is an image of the config.cfg file, showing the FTime gauge as Gauge 20. I suspect that there should be another value in the line to match the other gauges but I have inserted it as designed for FS9.

I have not been able to reproduce the fault in a Cessna 172, nor with the MAAM DC3 on 3 test further flights from Corryong YCRG trying to see the fault again.

I have experienced the problem of FTime starting at a high level (1000.00+) on at least three occasions over the six legs that I have completed. Resetting the flight seems to fix the problem.

The only add-on scenery I use is the ORBX FTX Australian Expansion Pack.

I also use FS Commander for flight planning which is linked to FSX.

Any clues for a fix would be helpful as I am wearing out the brake pads on the DC3.

Cheers,
Les

[paulv]

Hi Les, thanks for the quick answer. THe panel looks fine, and you don't need extra values. THe first two values describe the start position of a gauge, and the second set describe the size. If omitted, the default size is assumed.

No obvious clues jump out from what you have written. Murphy of course prevented you from recreating the fault (typical), and I hope you have a good pad supplier. I hear the DC3 pads are hard to get nowadays...

Regards




Paul

[Tom Goodrick]

I don't think anything in the new version of the gauge would have changed anything related to this problem. It has to do with initializing the variable space assigned by FS when loading an aircraft. When the aircraft is loaded into your sim as active, FS compiles all XML gauge file codes and performs variable initialization as needed. Evidently, something in FSX is messing up the variable space when you save the situation.

I looked at the code but did not see anything that could be changed to help this without possibly making the situation worse. With a file such as this, detecting the initial use is a bit difficult. Such a detection might trigger a reset at odd times.