Jump to content
The simFlight Network Forums

Recommended Posts

Posted

I am a big fan of the auto-save and previous flight save feature of FSUIPC. I have a question:

When is the "previous flight" saved? When the flight is ended and/or FSX is exited? I don't see it in the manual.

I also have some suggestions:

The auto-save filenames should include YYYYMMDDHHmmSS so that they're easily located (e.g. last one) and to make it convenient for archiving.

Lastly, I'd like to see a per-aircraft "previous flight" save option.

This would allow me to resume a flight where I left off on a per plane basis. Wherever I left my Scout Tundra is where I can resume from. Or, wherever I left the Islander is where I can resume it form. So in addition to the above, there would be like a "Previous Flight - Scout Tundra Blue+White Whatever" saved file.

Regards,

John

Posted

I am a big fan of the auto-save and previous flight save feature of FSUIPC.

"Previous Flight"? Neither FSUIPC3 nor AutoSave save such a flight. That's an automatic action by FS.

FSUIPC4 does do a "Previous Flight" because it seems FSX is not so considerate.

When is the "previous flight" saved? When the flight is ended and/or FSX is exited? I don't see it in the manual.

Since it is supposed to be simply a "fix" for what Microsoft omitted, it's on FSX exit, same as FS9 does.

The auto-save filenames should include YYYYMMDDHHmmSS so that they're easily located (e.g. last one) and to make it convenient for archiving.

The filenames already contain the day and time. This has been the same now for 12 years or more. I'm not about to change such a standard. If you want to see the date and year it is easy enough in Explorer.

Lastly, I'd like to see a per-aircraft "previous flight" save option.

This would allow me to resume a flight where I left off on a per plane basis. Wherever I left my Scout Tundra is where I can resume from. Or, wherever I left the Islander is where I can resume it form. So in addition to the above, there would be like a "Previous Flight - Scout Tundra Blue+White Whatever" saved file.

Hmm. Interesting idea, but more complicated than it sounds. The aircraft titles FSUIPC sees are not restricted in length and can contain characters not allowed in filenames. How would you suggest the filenames be formed given this problem? What if throwing out unwanted characters and abbreviating the names to sensible lengths made them less distinguishable? Consider those folks with 10 or 20 different paint jobs of the same aircraft.

Regards

Pete

Posted
What if throwing out unwanted characters and abbreviating the names to sensible lengths made them less distinguishable?

I think the way John and I want to use this functionality it doesn't really matter if the name of the saved flight is super easy to distinguish or not, we want FSUIPC to select the appropriate aircraft specific previous flight automatically for us the next time we load FSX and a particular plane. If there is no previous flight associated with an aircraft then just load the previous last location as things exist now. Maybe also an option to make the paint scheme irrelevant and just save the flight based on the model only.

Posted

I think the way John and I want to use this functionality it doesn't really matter if the name of the saved flight is super easy to distinguish or not, we want FSUIPC to select the appropriate aircraft specific previous flight automatically for us the next time we load FSX and a particular plane.

Er ... hold on, that's an entirely different matter! I've never ever done automatic flight loading, and I really don't like the sound of it. And, don't foget, loading a flight loads the plane it was saved with.

If there is no previous flight associated with an aircraft then just load the previous last location as things exist now.

But they don't. FSUIPC never loads flights.

It sounds like a good job for an external add-on, or maybe a Lua program. But I really don't want to do this in FSUIPC. Sorry.

Regards

Pete

Posted

Er ... hold on, that's an entirely different matter! I've never ever done automatic flight loading, and I really don't like the sound of it. And, don't foget, loading a flight loads the plane it was saved with.

But they don't. FSUIPC never loads flights.

It sounds like a good job for an external add-on, or maybe a Lua program. But I really don't want to do this in FSUIPC. Sorry.

Regards

Pete

1. For me, it would be enough to get a saved flight tagged with the plane, period. Stripping anything but numbers and letters, and trimming to some limit like 50, 64, or 100 characters should be good enough and work in most cases (for those cases where two names conflict, the user could always edit the aircraft title to fix the problem and get a title to their liking - life's a compromise). This would allow you to resume the flight from where you left the plane if you want, or just do whatever you normally do. No need to make things automatic. I start FSX, if I want to continue where I left my Scout, I just load the "Previous Flight ACAScoutTundra" or whatever the name of the plane would be. If I don't want to continue, I just set up the flight I want as I normally would. I may be wrong, but this seems like it would be rather trivial since it would require just another call to the flight saving code with a different file name.

2. Would it be possible to save flights any time a "new flight" is selected? That is, anytime a flight is ended, or before a new AC is selected, or a new scenery or world position is selected? This would allow for #1 above to be used in cases where you switch planes, sceneries, or just end a flight to start a new one, without having to exit FSX.

3. I understand the naming has been around for a while. Perhaps an option could be offered to use different format. Or, there could be a textfield that would allow the definition of the name using some simple markup, in the form of strftime() plus some FSUIPC built-ins like the AC title (the default markup would be the current format). This would provide two things: one, an near-automatic archiving capability without having to rename files after exiting FSX, and two, it could be used for #1/#2 above by making this the only change in FSUIPC. You could configure your auto-save options to save with something like "AutoSave $AC %Y%m%d%H%M%S" and to save on ground. Then your only requirement would be to wait long enough after shutdown for the auto-save interval to be triggered (e.g. arrive at airport, taxi to parking, shutdown, wait 1 minute). This would even provide a solution for having multiple plane locations for the same plane, since the you could pick the location for the given date. Does FSX provide the current airport? Perhaps that could be an expansion field as well, something like $LOC, if there's not airport then replace with something like "NOLOC" or "INFLIGHT".

In order of "wants", they are in order of importance. But #3 would provide the functionality of #1 and #2 so that would be perfectly welcome as well, and might be the most efficient use of your time. I would be even willing to write the file naming expansion code for you to insert wherever. So there's more than one way to do this, and whichever would be easier for you, I'm all for it. But, the more I read over my choices above and think about their use, the more it seems that #3 would solve a lot of these. :)

Or, perhaps even easier yet, the "Also save to a Flight called" option could be used for this feature. All it needs then is the macro/var expansion capability for date/time and AC/LOC or whatever might be possible; no GUI changes, just some extra code to strip/trim AC name, perhaps LOC if possible, substitute for $AC/$LOC or whatever, and then pass through strftime() and done. I get goosebumps just thinking about it: a history of pretty much all your flights, cataloged automatically by date/time and AC and/or LOC, that you can pick and reload (relive) at your leisure.

Posted

1. For me, it would be enough to get a saved flight tagged with the plane, period. Stripping anything but numbers and letters, and trimming to some limit like 50, 64, or 100 characters should be good enough and work in most cases (for those cases where two names conflict, the user could always edit the aircraft title to fix the problem). This would allow you to resume the flight from where you left the plane if you want, or just do whatever you normally do. No need to make things automatic.

That's certainly easier, assuming you are just talking about one flight saved when FS is closed, not the timed sequence of flights with automatic cleaning of files in a cycle. But I still really don't see the point -- at the end of a session it is almost just as quick to use FS's facilities, pressing ; and entering a title.

2. Would it be possible to save flights any time a "new flight" is selected? That is, anytime a flight is ended, or before a new AC is selected, or a new scenery or world position is selected? This would allow for #1 above to be used in cases where you switch planes, sceneries, or just end a flight to start a new one, without having to exit FSX.

No, not any of those except possibly ending a flight (via ESC-End flight), though I'd need to check even that. I've a feeling that, again, I don't see this occur until it is too late to save anything useful. Certainly by the time FSUIPC is informed that you are loading a new flight or changed positions, it's already too late.

3. I understand the naming has been around for a while. Perhaps an option could be offered to use different format ...

No, I don't like any of that. Sorry. The timed saving is simply for retrying after a crash (aircraft crash or FS crash), not for archiving autosaves. I honestly don't see the point of that. I can see the application of the end of flight facility, but even then I don't see why trying to make it automatic (when it can't really be, needing FS close or flight exit) saves you much effort over just pressing the ";" key and entering the name of your choice, as I have always done )e.g. "BA 737 at EGCC Gate 42". I have flights saved with my favourite aircraft at my favourite airports.

Regards

Pete

Posted

That's certainly easier, assuming you are just talking about one flight saved when FS is closed, not the timed sequence of flights with automatic cleaning of files in a cycle. But I still really don't see the point -- at the end of a session it is almost just as quick to use FS's facilities, pressing ; and entering a title.

[/size][/font]

No, not any of those except possibly ending a flight (via ESC-End flight), though I'd need to check even that. I've a feeling that, again, I don't see this occur until it is too late to save anything useful. Certainly by the time FSUIPC is informed that you are loading a new flight or changed positions, it's already too late.

No, I don't like any of that. Sorry. The timed saving is simply for retrying after a crash (aircraft crash or FS crash), not for archiving autosaves. I honestly don't see the point of that. I can see the application of the end of flight facility, but even then I don't see why trying to make it automatic (when it can't really be, needing FS close or flight exit) saves you much effort over just pressing the ";" key and entering the name of your choice, as I have always done )e.g. "BA 737 at EGCC Gate 42". I have flights saved with my favourite aircraft at my favourite airports.

Regards

Pete

Sorry, I likely edited the above post after you read it...

So would adding a small variable expansion capability to "Also save to a Flight called" be too much work? In the end, after all this thinking, that's really all I would need to get the functionality I'm seeking, and then some. And I'm sure there would be other uses for it... Please?

Posted

I've just checked. FSUIPC can detect when an aircraft or flight is loaded, but there is no way to detect the previous one being unloaded. By the time FSUIPC gets any information it is too late. The only possibility is the closure, and that's only because FSUIPC is being told to close up shop. And that doesn't work much of the time because by the time FSUIPC is told to close, the SimConnect routines it needs to call are often already closed..

Are you actually seeing Previous Flight being regularly saved by FSUIPC? I just had a look at my Flight Simulator X Files folder and the last time it managed to happen here on my test PC was late last year. I think it probably depends on how many SimConnect clients you had running. External ones like ASX are more likely to be keeping SimConnect responsive long enough for FSUIPC to get the job done. On my cockpit PC where I have many SimConnect clients, including at least three external (ASX, UT2, EZCA), the Previous Flight seems to be saved relatively consistently. But, on the other hand, FSX usually hangs on termination (without Windows), in aiPlayer, unless I think to terminate UT2 first, so it has loads of time. (Termination is then a Task Manager process killing job).

This problem with not being able to do something on close was one I had on a list lodged with the SimConnect developer in ACES studio, and one promised to be fixed in some never-to-appear SimConnect update. I think it might have been done in ESP, though, as it is working in Prepar3D without any other SimConnect clients.

Regards

Pete

Posted

Sorry, I likely edited the above post after you read it...

If you mean this:

Or, perhaps even easier yet, the "Also save to a Flight called" option could be used for this feature. All it needs then is the macro/var expansion capability for date/time and AC/LOC or whatever might be possible; no GUI changes, just some extra code to strip/trim AC name, perhaps LOC if possible, substitute for $AC/$LOC or whatever, and then pass through strftime() and done. I get goosebumps just thinking about it: a history of pretty much all your flights, cataloged automatically by date/time and AC and/or LOC, that you can pick and reload (relive) at your leisure.

Yes, I hadn't seen that before.

So would adding a small variable expansion capability to "Also save to a Flight called" be too much work? In the end, after all this thinking, that's really all I would need to get the functionality I'm seeking, and then some. And I'm sure there would be other uses for it... Please?

I'll have a look. Next week. But only aircraft and date/time (FS or Real?). I'm afraid there's no way I know to get the current airport without a database look-up based on the Lat/Lon (There IS a SimConnect facility to get nearest airports etc, but it doesn't work properly. It gets lists of airports with random omissions, quite often including the one you are sitting on!).

Regards

Pete

Posted

If you mean this:

Yes, I hadn't seen that before.

I'll have a look. Next week. But only aircraft and date/time (FS or Real?). I'm afraid there's no way I know to get the current airport without a database look-up based on the Lat/Lon (There IS a SimConnect facility to get nearest airports etc, but it doesn't work properly. It gets lists of airports with random omissions, quite often including the one you are sitting on!).

Regards

Pete

AC and real date/time only would be fine (I fly sim time mostly, and when the flight is loaded I'm back to sim time.) Real time will also allow me to pick the latest drop-off point. Thanks for considering it!

If you're not using something like strftime() for the date/time stuff, and you think it's useful, then maybe sim. time could be available as well (e.g. Y2/M2/D2) but that's not necessary for what I envision.

The only reason I thought location would be available is because I noticed that FSX keeps a pretty consistent log of my flight, including airports at which I've done only a touch-and-go, so I thought it might be some obvious thing it provides. If something's possible without too much fuss, great, if not, no worries.

Thanks, again!

John

Posted

I've just checked. FSUIPC can detect when an aircraft or flight is loaded, but there is no way to detect the previous one being unloaded. By the time FSUIPC gets any information it is too late. The only possibility is the closure, and that's only because FSUIPC is being told to close up shop. And that doesn't work much of the time because by the time FSUIPC is told to close, the SimConnect routines it needs to call are often already closed..

Are you actually seeing Previous Flight being regularly saved by FSUIPC? I just had a look at my Flight Simulator X Files folder and the last time it managed to happen here on my test PC was late last year. I think it probably depends on how many SimConnect clients you had running. External ones like ASX are more likely to be keeping SimConnect responsive long enough for FSUIPC to get the job done. On my cockpit PC where I have many SimConnect clients, including at least three external (ASX, UT2, EZCA), the Previous Flight seems to be saved relatively consistently. But, on the other hand, FSX usually hangs on termination (without Windows), in aiPlayer, unless I think to terminate UT2 first, so it has loads of time. (Termination is then a Task Manager process killing job).

This problem with not being able to do something on close was one I had on a list lodged with the SimConnect developer in ACES studio, and one promised to be fixed in some never-to-appear SimConnect update. I think it might have been done in ESP, though, as it is working in Prepar3D without any other SimConnect clients.

Regards

Pete

Odd... I also run UT2, but don't have the hang problem. I see a Previous Flight save pretty consistently, but on several occasions it failed to load, and once or twice crashed FSX in weather.dll. I guess which is all the more reason why the "also save flight as" option expansion is likely a better solution.

Posted

I've been using previous flight pretty much every time I load the sim up since 2007 and never had any problems loading. I like to start my session up from where I last left it. When I want a change in aircraft I just choose a more appropriate parking spot at the same airport for the different aircraft.

Posted

The only reason I thought location would be available is because I noticed that FSX keeps a pretty consistent log of my flight, including airports at which I've done only a touch-and-go, so I thought it might be some obvious thing it provides.

I've no idea where it gets that from internally. Obviously it knows where places are as you can see from the Map facility and using ATC or the GPS. If you can find out how to obtain it internally, fine. It's something I would have liked adding in FSUIPC's application interface, and did spend a lot of time trying to make it work with SimConnect's facilities data. In fact the code for a Nearest Airports list is still included and can be enabled by an INI file parameter. But, as I said, it doesn't work properly. The information it provides is full of holes.

Regards

Pete

Posted

I've no idea where it gets that from internally. Obviously it knows where places are as you can see from the Map facility and using ATC or the GPS. If you can find out how to obtain it internally, fine. It's something I would have liked adding in FSUIPC's application interface, and did spend a lot of time trying to make it work with SimConnect's facilities data. In fact the code for a Nearest Airports list is still included and can be enabled by an INI file parameter. But, as I said, it doesn't work properly. The information it provides is full of holes.

Regards

Pete

I'm assuming you've tried by using SIMCONNECT_DATA_FACILITY_AIRPORT and then calculating the closest one yourself? And that's the facility that doesn't get you all the airports, or may not get you the closest one... I wonder if this is fixed in Prepar3D.

Posted

I'm assuming you've tried by using SIMCONNECT_DATA_FACILITY_AIRPORT and then calculating the closest one yourself? And that's the facility that doesn't get you all the airports, or may not get you the closest one.

Yes, precisely.

I wonder if this is fixed in Prepar3D.

I don't know. Maybe I'll have a look. However, Prepar3D is a very low-use sim compared with FSX. I'm not currently using it because it seems no faster than FSX (slower with some of my sceneries), and doesn't work with some of my major add-ons --- mainly I think because they don't recognise the name. Maybe the performance wil change as they develop it, but I can't see many of my favourite add-ons getting updated to be compatible. UT2 and ASX work okay, but nowadays I can't live without Ezca! And I think Gary Summons must have taken advantage of some special quirks in FSX for his more recent UK scenery, because it doesn't work properly in P3D either.

Regards

Pete

Posted

Yes, precisely.

I don't know. Maybe I'll have a look. However, Prepar3D is a very low-use sim compared with FSX. I'm not currently using it because it seems no faster than FSX (slower with some of my sceneries), and doesn't work with some of my major add-ons --- mainly I think because they don't recognise the name. Maybe the performance wil change as they develop it, but I can't see many of my favourite add-ons getting updated to be compatible. UT2 and ASX work okay, but nowadays I can't live without Ezca! And I think Gary Summons must have taken advantage of some special quirks in FSX for his more recent UK scenery, because it doesn't work properly in P3D either.

Regards

Pete

I'm not on board with Prepar3D either, just wondering out loud... I agree FSX without EZCA is sterile. :)

I haven't done any development for FSX but read plenty. I've been wishing for a nice clean flight/landing judge add-on, so this and that might be the push needed for me to start up VC++.

Posted

AC and real date/time only would be fine (I fly sim time mostly, and when the flight is loaded I'm back to sim time.) Real time will also allow me to pick the latest drop-off point.

One thing worries me about this. The "AlsoSave" option is not a file management one. It simply replaces the last one of the same name each time it operates. So at present you don't get an accumulation of files filling the disk directory and slowing each access down bit by bit. Once you start adding data and time, you'll get an accumulation of files. If you have it set for 30 seconds you'll get 120 new files per hour.

Now I realise you might set the interval longer to avoid this, but if the main point is simply to choose that latest for this aircraft, then why have the date and time? If you wanted an easy way to archive I suppose Date would be okay, so you get one per aircraft per day.

In view of this I'd prefer to add just the two variables: %A for Aircraft, %D for date (YYYYMMDD). I can add %T for time, but I've a feeling this should be rejected unless the interval is set to at least 30 minutes, not seconds, in which can it would probably not be useful.

Comments?

Pete

Posted

One thing worries me about this. The "AlsoSave" option is not a file management one. It simply replaces the last one of the same name each time it operates. So at present you don't get an accumulation of files filling the disk directory and slowing each access down bit by bit. Once you start adding data and time, you'll get an accumulation of files. If you have it set for 30 seconds you'll get 120 new files per hour.

Now I realise you might set the interval longer to avoid this, but if the main point is simply to choose that latest for this aircraft, then why have the date and time? If you wanted an easy way to archive I suppose Date would be okay, so you get one per aircraft per day.

In view of this I'd prefer to add just the two variables: %A for Aircraft, %D for date (YYYYMMDD). I can add %T for time, but I've a feeling this should be rejected unless the interval is set to at least 30 minutes, not seconds, in which can it would probably not be useful.

Comments?

Pete

I think it's a good point, and now that I rethink my use, I would likely want to decrease granularity, but now quite to the day. I would probably use an hourly save, with a format like %Y%M%D%h%m, or maybe a 5-15 minute save. Those that won't read the manual won't know about the expansion capability anyway, and the feature will continue to provide the same facility as it has now. For those that don't care about the date, they can just use %A, but for those that want to be very granular, they have the option.

I think it's better to have the capability, with a short warning message in the manual about potential misuse, than to force a date-only option. And while I would normally use the hourly option, I can imagine scenarios where I would want the level granularity that minutes and seconds would provide (for example retrying some decision that was wrong, that might have happened 5 minutes ago, like flying up a box canyon, but it's a scenario where I won't know when the bad decision will be made and when it can be corrected, so the granular archive is needed). Having a more granular definition for date/time, would also allow users to mimic Auto-Save naming schemes without using YYYY or MM. Perhaps %d %h%m%s, with %d being an expansion for the name of the day of the week.

Lastly, it's pretty easy to trim the directory from excess files, even manually, if a misconfiguration occurs and many files are created. So while I whole heartedly agree with the concept of trying to save the user from him/herself, advanced users should be given the choice and option to kill their filesystem. Maybe there's a way to do both, with manually setting things in INI and limiting what can be "entered" in the text field in the GUI? But that seems like more work for you. :)

Posted

I think I'll settle for 4 optional inserts:

%A aircraft

%D date YYYYMMDD

%W day of week (MON, TUE etc)

%T time hhmm (no seconds)

Pete

If I do not choose one of those options will the current method still be in force so that my Autosaved "also's" get overwritten

on any given day?

I really do not want to have to go in and manually remove those files as I have a 7 minute save schedule.

Paul

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use. Guidelines Privacy Policy We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.