Synchronizing FSUIPC and external program

[Alexey Morozov]

Dear Pete,

in one of posts of yours in this forum I have found the following "FSUIPC is synchronised to FS's frame rate -- it needs to be because aynchronous settings can upset things." So my question is, if it is not a secret of course, how does this thing work? Which of the internal chains of the simulator you use to do synchronisation? I believe that it should be the chain 0x13 that seems to be connected to the frame rate or chain 0x10 that is called quite often (I belive each (15mSec) and may be is connected to computation circle. If you do not use the chains may be you use simulator events? If so, could you tell what are the ID's of those events?

I really need this information to do the same synchronisation of my computation circles with FSUIPC and FS .

Best regards,

Alexey

[Pete Dowson]

Which of the internal chains of the simulator you use to do synchronisation? I believe that it should be the chain 0x13 that seems to be connected to the frame rate or chain 0x10 that is called quite often (I belive each (15mSec) and may be is connected to computation circle.

Hmm. I didn't know about chain x10. Is that reliably 15mSecs? I use chain x02 which appears to be a normal Windows "tick" counter (55 mSecs) for many timing purposes, rather than directly access a new Windows timer, but a 15 mSec one might well come in handy.

Chain x13 is the main one I use for synchronisation, yes. This was fine in FS2000 and before, but it appears to occur 4 times too often in FS2002 and FS2004 (compared to before) so for many purposes I only use every 4th call.

To make matters more complicated, it appears that in FS2004 (not FS2002) if the Slew mode display is on it goes 8 times faster instead of 4, so I take every other one again in that case. Weird.

Note that this is for the calling of procedures in SIM1.DLL and WEATHER.DLL elsewhere to set or obtain data I can't get any other way, and the tracing of pointers to privately owned data structures, all in order to keep a variety of values up to date. Where I can map directly I do, and in these cases there's no synchronicity imposed.

The calls from applications via the message queue are of course aynchronous and are dealt with as they arise. Some action requests are left to the next synchronous time, but not that many -- mostly those concerned with the weather which seems very precarious otherwise (probably code re-entry. Very bad).

So, really the synchronous nature applies to all those variables which I have to obtain by procedure call or convert from one form to another.

It's all got far too complicated over the years. If I was to start again now I'd do it differently. I'd design for FS2004 (or 6 or whatever) and leave older versions to older unsupported FSUIPC's. But it's all predicated by time. I don't seem to ever have any. :wink:

Regards,

Pete

[Alexey Morozov]

Pete,

thanks for quick answer.

First of all about the chains. May be I am wrong but it seems to me that the chain 0x13 is called each time something is drawn on the screen. So, for example, if we have only spot view on the screen the chain is executed only once per frame. If, additionaly, we display any text (flight display, slew mode indicator and so on) the chain will be called twice a frame but calls will be done practically at the same time moment. And it goes up, the more things are displayed (additional views and so on) the more often this chain is called. If we display cockpit view it seems that the chain is called twice (first for displaying scenery and second for gauges).

As about chain 0x10. I tested it on different computers and it seems that if the computer is fast enough it is called every 15 mSec and never goes down this value, but, as well as the 0x13 chain, it may be called twice or more practicallt at the same time. If FS is not able to perform the requested frame rate, this chain goes down.

Now about synchronization. For example, if I write two offsets at one Process call comparing to two different Process calls? Does it make any difference? Another words, do you wait for synchronization circle to pass all the calls that came or each call is passed immediately? Or it depends on the parameters that should be passed?

Alexey

[Pete Dowson]

First of all about the chains. May be I am wrong but it seems to me that the chain 0x13 is called each time something is drawn on the screen ...

Ah, that explains a lot, in FS2004 at any rate. But it wasn't the same in all releases. I have so much hooked into these chains that finding a working alternative is not easy without risks, and the risks are concerned with stability of FS.

Now about synchronization. For example, if I write two offsets at one Process call comparing to two different Process calls? Does it make any difference?

If the calls are from an external application, two of them involves 4 process switches, so that is obviously a lot less efficient. From an internal program it is almost negligible -- an extra message on the message queue. Who will notice amongst the millions? It always amazed me how much FS uses the messaging system internally. Most odd.

Another words, do you wait for synchronization circle to pass all the calls that came or each call is passed immediately? Or it depends on the parameters that should be passed?

If you are reading data then you read it there and then, in that call, either from memory in FSUIPC, or from FS memory directly mapped. If I need to call other parts of FS to read such data or maybe just to convert it from a mapping, then that is done in the Chained part, but the results go into the FSUIPC memory which is where you are reading them. Therefore, how "out of date" that data is varies according to how close your read comes to the most recent Chained update.

There again, to save processing time, FSUIPC classifies some data as lower priority than other data. Some of the lowest priority, like NAVAID names and positions, may only be updated infrequently, perhaps half-a-second at normal frame rates. And so on. Only the more important flight control values are updated every "frame" (chained call).

If you are writing something, then it very much depends. If it is something that can be written directly to FS and have the desired effect, then it is done there and then, in your process call. If it involves me posting a message to FS, or, in most cases, calling an Event handler directly in SIM1.DLL, then that is normally doable in the process call.

But some things aren't, because they are precarious. Changing the Traffic settings, for instance. If you change the percentage of AI traffic, I flag that and do it separately. The most important example is weather -- the calls I make to both read a specific weather station or set one are only ever done on the chained entries. I tried doing them immediately with horribly unpredictable results. I assume this is related to threading and non-reentrant code in some parts of FS.

Regards,

Pete