$Id: fsx-preserve-state.html 223 2012-01-10 12:40:52Z dave_infj $
$Id: fsx-preserve-state.html 223 2012-01-10 12:40:52Z dave_infj $
Each time you start a free flight, do you bother to check fuel quantity as a part of your preflight checks?
Probably not. For most simmers, your default flight has full tanks, however much you used last time. Your switches and radios etc are always in the same state, regardless of how you left them, and the battery is never flat. Not so realistic.
This package contains a pair of tools, fsx-save-on-event and fsx-update-flt.py, which make it possible to preserve as much or as little aircraft state (eg fuel, switches, etc) as you like between sessions.
Download 32-bit binaries; browse or download sources.
There are two parts to this package: capturing the very latest state of the aircraft before the simulation ends, and then later applying the desired changes to the default flight files.
First, a bit of background. Although FSX saves a flight in %APPDATA%\Microsoft\FSX\Previous Flight.FLT, it's unclear how frequently it does this, and anyway it deletes this flight file on exit. FSUIPC sometimes saves %USERPROFILE%\My Documents\Flight Simulator X Files\Previous Flight.FLT, but it doesn't seem to do so consistently.
The root problem is really that when the user ends the flight, it is often too late to record the state of the aircraft. The first tool in this package, fsx-save-on-event.exe, solves this by automatically saving the current state of the aircraft on certain events — with the hope that one of these events relates to the very last thing the user did to their aircraft. (Actually, it listens for changes in simulator variables, which are usually pretty closely linked with FSX events). When the nominated variable(s) change (eg electrical master battery), it sends a Save Flight event to the simulator and, optionally, runs a script that does something with the newly saved flight file.
This is the only reliable way I've found of capturing the last state the aircraft was left in. If you know of another way, I'd be interested in hearing about it.
usage: fsx-save-on-event <flight file> <var1> [...]
<flight file> (eg, last-state.FLT) by default will be put into your %USERPROFILE%\My Documents\Flight Simulator X Files folder.
The remaining arguments (use double quotes for variable names containing spaces) are a list of FSX simulator variables which should be monitored. Whenever any of these change, the current state will be saved.
In my simulator, the very last thing I do is turn off the battery master (variable electrical master battery). This seems to be enough for me. If I forget to turn the battery master off, the battery will be flat when I come back to it (see below), so the lack of saving of any other switches is the least of my troubles.
After saving the flight, fsx-save-on-event.exe invokes the script fsx-save-on-event.cmd, if present in the same directory as fsx-save-on-event.exe itself. NB: if you rename the EXE file, you'll need to rename the script so the base-names match.
Running the script is optional, but necessary if you want state to persist into the next session without quitting the simulator altogether. When the user ends the current flight, FSX automatically loads %APPDATA%\Microsoft\FSX\Previous Flight.FLT. If the script applies the desired settings to this flight file, they will be picked up after FSX has ended the session.
Important: For this feature to work, you must invoke fsx-save-on-event.exe with its full path, or it won't know where to look for the script. Also note that you may have problems if for any reason the environment variable %PATHEXT% has been altered from its default.
In order to guarantee that fuel state is preserved, I highly recommend that you turn on FSUIPC's "also save as" feature, giving it the same flight file name as fsx-save-on-event, with a period of, say, 30 seconds.
There should be no risk of a race condition between FSUIPC and fsx-save-on-event, because both only send an event to FSX, and it is the FSX process itself that serialises and performs the save operation.
There is no particular reason why you shouldn't have fsx-save-on-event.exe overwrite the default flight file directly, it which case absolutely everything will be preserved.
There are at least two possible reasons why you might not want to do this, however. The first is if you have manually tweaked the default flight file to position undocked panels in full-screen mode (eg, if you have multiple monitors and use the extras for flight instruments). Undocked panels in windowed mode are not affected, but FSX will clobber those settings when it saves in full-screen mode.
The second is that it makes little sense to preserve the positions of physical controls such as throttle levers etc. It is better to have all your engine levers set to 0% in the flight file, and to manually position them there before you start the flight.
Whatever your reasons, the Python script fsx-update-flt.py provides the solution — plus a few extras.
usage: fsx-update-flt.py <src_flt> <dst_file> [--today] [--battery=<MINS>] [--engines=<%pHR>] <+|->sect[.opt]...
where:
Paths are relative to %USERPROFILE%\My Documents\Flight Simulator X Files if not absolute. If <dst_flt> begins with a '=', it will be treated as a list of mappings for specific aircraft descriptions (eg Boeing 737-800 Paint1) to specific flight files. The format of this file, one line per mapping, is:
<regular_expression> = <flight_file>
where <regular_expression> is any valid, case-insensitive
regular
expression (eg Boeing 737.*)
and <flight_file> follows the same rules as
<src_file>.
NB: For safety, the Aircraft description string in [Sim.0] in <src_flt> must match this RE, or the string exactly if no mapping file is used. If it doesn't, fsx-update-flt.py will refuse to write the output file.
The remaining arguments are interpreted as a list of whole [sections] (or only specific options, in the form sect_name.opt_name) to include (+) or exclude (-) from copying. Wild card * is permitted. Nothing is copied unless explicitly included, and explicit excludes override explicit includes. Use double quotes for sections/options containing spaces. Case is sensitive.
Example invocation:
c:\python27\python fsx-update-flt.py last-state.flt my-default.flt --today --battery=120 --engines=2 +Avionics* +Fuel* +Systems* +Gauges* +Switches* +AutoPilot* "+Engine Parameters*" "-Engine Parameters*.*Lever*"
This will copy all the important aircraft state except engine levers (throttle, propeller and mixture), which for most people are mechanical devices that can't be set by the simulator.
At minimum, fsx-update-flt.py should be run before the simulator is started. See the example start-fsx.cmd script. I recommend that you also invoke fsx-update-flt.py from inside the fsx-save-on-event.cmd script twice: once on your default flight file, and once on %APPDATA%\Microsoft\FSX\Previous Flight.FLT. This flight file is reloaded by FSX after the current flight has ended. Any changes made by fsx-update-flt.py will then be fed back into the next free-flight session.
Unless you have FSX set to use the system time and date as the simulation time and date, you'll find that time never advances and all of your log book entries will say more or less the same day.
I prefer to fly during the day, but I don't have time to mess with my simulator until the evenings. Using this option means I can set the default time-of-day in the default flight file, but have the date updated for every flight.
In the example above, if you leave the battery on for more than two hours without at least one engine running with its alternator switched on, the battery will be flat when you come back.
FSX doesn't save battery charge level in flight files, so a flattened battery is emulated by failing outright the electrical system in the Failures menu. If you find your battery is flattened, reset the failure to 'recharge'.
NB: fsx-update-flt.py uses the current local time, as reported by Windows, and the timestamp on the last state flight file to determine how much time has elapsed. Simulation time is not used at all.
Of course, if you leave an engine running, there'll be less fuel in the plane when you come back. Leave it long enough, and your tanks will be completely empty.
The argument to --engines is the number of percentage points to subtract from each tank if any engine is left running. It's not particularly realistic, but given the variety of aircraft that may be used with FSX, it isn't really practical to subtract fuel only from the appropriate tank, so all tanks are adjusted in the same way.
The above example uses a figure of 2%/hr which, in a plane with two full tanks, means that plane will have idled away all fuel in 25 hours. This parameter is really only indicative, and you are free to use any value you like.
If all tanks are exhausted, the battery flattened logic really should kick in once the engines stop — but it doesn't. Maybe I'll write that one day if I can see a reasonable set of logic that would apply generally and without knowing anything about the aircraft in question.
Happy contrails!
David.
|
dave_infj at users.sourceforge.net $Id: fsx-preserve-state.html 223 2012-01-10 12:40:52Z dave_infj $ |
|