What is the best way to detect FS state with FSUIPC?

[GregG]

I'm sure this is just a frequently asked question but I couldn't find anything specific in the SDK about it, I tried many offsets that seemed related according to the docs, but found none that worked, and performed several searches in these forums. I suspect I'm just missing something obvious.

What is the best offset to poll to detect whether a flight is fully loaded? (By fully loaded I mean the point where it's now safe to start reading and writing in-flight variables.) Furthermore, can this method be used to detect if the player is viewing a screen that is not part of the flight experience (such as display settings, etc.)? I also need to make sure that I know if the player does an "End Flight". Most of the offsets I tried still showed the leftover settings from the previous flight after an end flight. The general note regarding offset 0x4D2 sounded relevant, but I still don't think it's what I'm looking for, as FSUIPC is initializing just fine.

Currently, I need to do this for FS2004, although ideally I'd like to be able to detect the same thing for FS2002. My application is a fully external .exe.

I'd appreciate any help regarding this issue.

Thank you,

Greg

[Raymond van Laake]

Hi Greg,

What I do is this: have the flight loaded, and then read the lat/lon of the aircraft. Once that readout matches what it should be I continue. It never gave any problems. Of course you need to know where the aircraft should be after loading the flight for this to work.

Ray

[GregG]

Raymond, thank you for your suggestion. Knowing the expected position is not a problem as my program launches the flight. However, I can think of some scenarios where that might not work. For example, my VA usually uses the exact same starting gate for all flights from the same hub. If someone loaded flight A and then flight B there would be no position shift to detect since the variables aren't cleared (as far as I can tell) between loadings.

Someone I contacted about this off the forums (whose name I omit simply because I dont like giving peoples names in public forums without their permission) had an interesting suggestion to use the FSUIPC "run program" feature which will launch a program when the flight is finished initializing. I could implement something based on this, and probably will, but I wonder that if FSUIPC knows when the init is complete in order to have that functionality, couldn't it feasibly maintain a variable that could be queried by programs? I'd be interested to hear from Pete on this when he's caught up from being away. This is far more important to detect reliably than the 2 other scenarios I mention, to me.

This gentleman also generously suggested a possible solution to detecting what window the user is looking at, by enumerating the process windows which is doable. As for the third scenario, detecting "End Flight" I don't think I really have a solution to that yet. I suppose I could watch that window for the appropriate message for the button being pushed, but I'd much rather know if there's a more direct route to detecting this.

Thank you,

Greg

[Pete Dowson]

an interesting suggestion to use the FSUIPC "run program" feature which will launch a program when the flight is finished initializing. I could implement something based on this, and probably will, but I wonder that if FSUIPC knows when the init is complete in order to have that functionality, couldn't it feasibly maintain a variable that could be queried by programs? I'd be interested to hear from Pete on this when he's caught up from being away.

Actually, the "run ready" facility doesn't work that well in FS2004. I have quite a lot of difficulty from inside FSUIPC knowing when it is safe to access aircraft paramters in SIM1.DLL simply because there's nothing clearly obvious to tell me when a previous flight is deleted nor when a new one is completely loaded and initialised. And it isn't only Flights, simply loading or reloading an aircraft is the same problem. All the data structures are deleted then re-built for the new aircraft in both cases. And different structures are built for each aircraft type -- prop, jet, turbo, helo, glider. It's a nightmare in fact.

In FSUIPC I take some precautions to simple avoid trying to access areas which are not valid at any time, but it isn't foolproof. I use pointers in other, more general structures, and before accessing those I check for validiiy by APIs like "IsBadReadPtr".

If I do ever find a foolproof way, I can certainly provide some sort of indication. It could be useful for my other modules. But it might help for me to actually understand why an application (rather than FSUIPC) would need to know. Can you explain?

Regards,

Pete

[GregG]

Thanks for the response, Pete. Let me outline what I'm currently implementing. I actually need to detect what I'm asking for other reasons, but this one is the most complex implementation that requires it and is the one I'm currently working on.

The application in question is very multi-purpose. Amongst many other things, this program launches flights after making customizations. The feature giving me trouble is called sim run-up and what it does is load the flight X minutes early and then time accelerates up to 4x until the original flight time is met and it sets time accel back to 1x and pauses. I have all the code in to do this, and can, indeed get it to work some of the time, but without a reliable way of detecting the flight init process, it can't seem to make it fully reliable. I could, for this feature, simply have the user push a button to start the process once the flight is loaded, but that's not a good solution for various reasons, including that I need this level of detection for other planned features.

I've tried basing the detection on shifts in the in-flight time, but this is not reliable (after putting 12 hours of trial and error into it). Shifts in position are even less reliable for the reason I give in and earlier post in this thread.

I'm utterly frustrated at this point. But I haven't given up. I really can't give up since I feel that this form of detection is crucial to my project.

I'll be happy to give any other information you need.

Thank you,

Greg

Edit: I'm investigating another option. According to Spy++, there seems to be an unnamed window open in the FS9 process when it's loading a flight. I'm going to look into this for a very undocumented way of detecting what I need. :) But if I could do it through FSUIPC somehow, it would be preferable, as this might be a red herring.

[Pete Dowson]

Amongst many other things, this program launches flights after making customizations. The feature giving me trouble is called sim run-up and what it does is load the flight X minutes early and then time accelerates up to 4x until the original flight time is met and it sets time accel back to 1x and pauses. I have all the code in to do this, and can, indeed get it to work some of the time, but without a reliable way of detecting the flight init process, it can't seem to make it fully reliable.

I'm not realy understanding all of this. Are you using the FSUIPC facility to load a flight? (i.e. offsets 3F00 ff). If so, I assume you then wait for the count in 3F02 to change. Is that right? There's also an AIR file change counter at 32FC which will also change.

The problem may derive from the fact that FSUIPC detects these events by intercepting calls to read the files (AIRCRAFT.CFG and *.FLT), I don't know any other ways. After the files are read I expect there is an unknown number of seconds whilst scenery, cockpit and weather data is read and set up. I don't know when that part has finished I'm afraid.

One thing you could check is the frame rate (0274). I suspect the frame rate might "freeze" for a period whilst this occurs. Maybe detecting when it starts changing again will help?

In fact I shall make some checks on the Chained calls I get from FS. Possibly the frame-rate determined ones will tell me. If I can detect it directly I will certainly provide a flag or something.

Let me know if you find something before me, please.

Regards,

Pete

[GregG]

I'm not realy understanding all of this. Are you using the FSUIPC facility to load a flight?

Actually, no. I started development on this a while before I decided to widen its scope and then started using FSUIPC. For launching the customized flights, plans and aircraft, I simply use the FS9 command-line parameter /FLT:. If a FS9 process is already running, it launches the flight in the existing process, if not, it launches a new process and loads the flight.

Let me know if you find something before me, please.

I will do so, Pete. I'm pretty determined to find an answer to this, and if I do so, you'll be the first to know. :) I did some very cursory looks at using the FPS to detect this, and after some initial setbacks I did not try further. Therefore, it's not been sufficiently tested to indicate it's usefulness. I'm going to investigate this unnamed FS9 window first, as it seems to hold the some promise. I just have to reacquiant myself with enumerating windows within a process before I can test anything.

Thanks,

Greg

[GregG]

Just to followup on the unnamed window idea. It seems to work on some initial testing for FS9. If you want to test it here's some simple code:

HWND CFSUIPCInterface::DetectUnnamedWindow(void)
{
	HWND hwndUnnamedWindow = NULL, hwndFS9TopLevelWindow = FindWindow("FS98MAIN", "Microsoft Flight Simulator 2004 - A Century of Flight");
	if (hwndFS9TopLevelWindow)
	{
		hwndUnnamedWindow = FindWindowEx(hwndFS9TopLevelWindow, NULL, "FS98CHILD", "");
	}
	return (hwndUnnamedWindow);
}

The only caveat I've found so far is that the unnamed window doesn't disappear if you have FS9 minimized.

Otherwise, this will obviously need some testing and see if that unnamed window appears under other circumstances, such as during a long flight. Therefore, I wrote up a little utility that watches for the window and beeps once per second when it finds it.

The executable:

http://www.bitspring.com/misc/FS9FlightInitAlarm.zip

The VS.NET 2003 project:

http://www.bitspring.com/misc/FS9Flightroject.zip

If you would, let me know if you find this works for you as well, Pete. I can probably get some of my beta testers to try it as well. Oh, and don't judge me on the code. I just build a basic Win32 project and added in the bits I needed. There's nothing elegant about it. :)

Edit: One of my beta-testers reported (and I've verified) that the unnamed window is present when first loading FS9 up until one creates or loads a flight and that flight starts loading. So it's presence alone is not in any way telling. However, the disappearance of the unnamed window seems to indicate that the flight is beginning loading. This may be enough for my needs, and hopefully useful to others, if this holds true after further testing.

[GregG]

Just an update. I've had pretty encouraging reports on this from my beta-testers. However, an unnamed window does appear momentarily when changing from internal to external views. I'm going to see if it has the same characteristics as the pre-flight-init window in the hopes it's a different window that can be differentiated programmatically by window characteristics/styles. If it's the same window, then it will make this a less effective method of detection, unfortunately, but not useless.

Edit: Unfortunately, it's the same window. It has the same characteristics, and, more importantly, has the same window handle. But, this isn't a complete waste. As a matter of fact I've implemented it in my original program and it seems to work pretty well. But it's not a panacea for the whole situation. I'll try to keep thinking about this and see if I can find something. I still haven't re-investigated polling the FPS offset. If you find anything or have any further suggestions, Pete, please let me know.

Edit2: I've double-checked using the FPS offset for this. It reports a > 0 value consistently (polling once per second) even if a flight is being loaded. Any other suggestions would be welcome. I'm happy to do the testing.

[Pete Dowson]

I've double-checked using the FPS offset for this. It reports a > 0 value consistently (polling once per second) even if a flight is being loaded.

It will do. I was not suggesting that it would report zero frames or anything. but normally I'd expect it to be changing all the time when the simulation is running, and frozen when it isn't. So you need to check for changes.

I'll look at other things tomorrow, not had time this weekend.

Regards,

Pete

[GregG]

I was not suggesting that it would report zero frames or anything. but normally I'd expect it to be changing all the time when the simulation is running, and frozen when it isn't. So you need to check for changes.

As I think back, I believe this indeed is what happened (it would maintain a single value when the 3d screen was not displayed.) I'll double check the specifics of this, however, the unnamed window method will probably be more useful, or, perhaps, a combination of the two.

I'll look at other things tomorrow, not had time this weekend.

Thanks, Pete. Hopefully, my research into this will be of use to you as well.

I'll report back when I have some new findings.

Thanks again,

Greg

[Pete Dowson]

I'll report back when I have some new findings.

I've done some more checking here.

I don't think your checking of that unnamed window is reliable enough. here it seems to be created right at the beginning and it exists unchanged throughout. I don't know what it is for, but it seems how it is treated may depend on some configuration option.

The frame rate is no good either. That starts change after you select a flight and continues changing whilst the scenery and aircraft are being loaded.

My idea of the frame rate chain calls being suspecnded doesn't work for the same reason.

But what I find most promising is simply checking the time count. The seconds value at offset 023A does not change at all initially, nor whilst things are being loaded.

When a new flight is being loaded, at some point the seconds value will possibly change to the value in the Flight file (depending on the file), but then it is again static til everything is running.

So, I'd propose monitoring the Seconds value for 2 changes within, say, 4 seconds.

The problem with this is that it won't work if the flight is paused, and is problematic if the sim rate is set low. You can of course check both of those things too. But so far it seems the most reliable indicator I've found.

Regards,

Pete

[Pete Dowson]

Further to my last message here, I traced FS to find out where it was updating the "Seconds" counter, and in the process I found a better way of determining when FS is actually "ready to fly". This involves adding more code to FSUIPC to check two locations in MAIN.DLL. I will also check FS2002 and FS2000 to see if I can apply it universally.

I'll then add a flag to the offset list someplace which you can check. I'll also use it to regulate my "Run READY" facilities in both FSUIPC and WideFS.

It actually provides me a safer way of telling when it is okay to access SIM1.DLL ariables too, so it was a worthwhile investigation. Thanks for prompting me to do it! :lol: :lol: :lol:

Regards,

Pete

[GregG]

Dear Pete,

Thank you for your further testing on this. Unfortunately, I have been unable to do anything over the past four days due to some severe problems with my server. I'm very glad to hear you've made progress on this although I'm sorry my ideas haven't panned out for you so far.

Just out of curiousity, you are saying the unnamed window, for you, does not disappear during the loading of the flight? If so, then obviously you are right. I was hoping more of my beta testers would check on it for me, but, unfortunately, only two did as far as I know. That's not quite enough folks to consider it a valid sampling. :)

I'm looking forward to the implementation of your new discovery and am glad that at least my interest in this feature has helped you solve it for yourself. :)

Thanks again,

Greg

[Pete Dowson]

Just out of curiousity, you are saying the unnamed window, for you, does not disappear during the loading of the flight?

It didn't appear to. I was watching the list of windows in ProcExp whilst I loaded a flight. Do you want me to double-check?

I'm looking forward to the implementation of your new discovery and am glad that at least my interest in this feature has helped you solve it for yourself. :)

I have it working now for FS2004, but unfortunately there's no such code in FS2002 (so it isn't worth me looking at FS2000 either).

So I've implemented it for FS2004 only. The BYTE at offset 0x3364 will be zero whilst things are loading, changing to 0xFF when the simulator is ready.

Regards,

Pete

[GregG]

It didn't appear to. I was watching the list of windows in ProcExp whilst I loaded a flight. Do you want me to double-check?

Only if you too are curious. Since you've found an alternate solution, there's certainly no need, but purely out of curiousity it might be interesting. It would be really easy if you feel secure running the little alarm program I provided. If you are concerned about it, you could build it from the project yourself. It should start to go off when FS2004 starts but should then stop once a flight starts loading. It should then only go off for a moment when loading a new flight or when changing views. At least that is how it functioned on my system and two of my beta-testers systems. Again, there's really no pressing reason to bother, though.

So I've implemented it for FS2004 only. The BYTE at offset 0x3364 will be zero whilst things are loading, changing to 0xFF when the simulator is ready.

Exceptional news! Thank you Pete. I'll be greatly looking forward to your next release.

Best wishes,

Greg

[Pete Dowson]

So I've implemented it for FS2004 only. The BYTE at offset 0x3364 will be zero whilst things are loading, changing to 0xFF when the simulator is ready.

Exceptional news! Thank you Pete. I'll be greatly looking forward to your next release.

Actually I've decided to reverse the indication: 00 = ready to fly, FF = not ready. That way programs which use it to hold off before doing something won't be held off forever on previous versions of FSUIPC or FS.

Regards,

Pete

[GregG]

That sounds good, too. :) This feature should get a thorough checkout once the next version of FSUIPC is released as I know at least several of my beta-testers plan to use the feature dependent on this addition.

Since the implementation of this feature is quite simple, I'll go ahead and add the code for it now, so it's ready when 3.12 is released. Actually, that's a point. Are new features like this added "right away" and released with the next version or do they tend to be one or two releases down the road (I'm not sure about your development/testing practices)?

[Pete Dowson]

Since the implementation of this feature is quite simple, I'll go ahead and add the code for it now, so it's ready when 3.12 is released. Actually, that's a point. Are new features like this added "right away" and released with the next version or do they tend to be one or two releases down the road (I'm not sure about your development/testing practices)?

Once I've done them, they're in, unless I'm suspecting problems, which in this case I'm not. However, I've no schedule for 3.12 at present. Would you like an interim Beta version to test with?

Regards,

Pete

[GregG]

If it's not too much trouble, then that would be quite helpful so I can more comfortably move forward. Would I have permission to let a few of my beta-testers use it as well? I would only send it to them directly and would not make it available otherwise. If not, no worries, it's still a help.

Either way, thank you again,

Greg

[Pete Dowson]

If it's not too much trouble, then that would be quite helpful so I can more comfortably move forward. Would I have permission to let a few of my beta-testers use it as well? I would only send it to them directly and would not make it available otherwise.

Yes. It will be a Beta version with a time limit anyway. Probably end November now. Just keep the numbers reasonably low please. Write to me at petedowson@btconnect.com and I'll send it by reply there. I'll have it ready over the weekend some time.

Regards,

Pete