Programming with FSUIPC

[sri777]

I am trying to understand the basics of programming addon with fsuipc.

When you change a value of some offset by writing to FS, assume that change will impact and change the values of say 10 other offsets.

So, then is it the responsibility of the client program to know what those 10 other offsets that might get effected and read back only those variables following the original write?

What are the general guidelines for efficient reading/writing of multiple offsets?

Is it advisable that a program to spawn multiple threads for either reading or writing simultaneously for large number of variables processing?

Thanks

srini

[Pete Dowson]

When you change a value of some offset by writing to FS, assume that change will impact and change the values of say 10 other offsets.

So, then is it the responsibility of the client program to know what those 10 other offsets that might get effected and read back only those variables following the original write?

Why would it want to? What are you trying to do? What are these other values? I'm not really understanding your question.

What are the general guidelines for efficient reading/writing of multiple offsets?

All you have to realise is that the ONLY call which actually does anything is the FSUIPC_Process() call -- the others are simply manipulting data for you, to make life easier. The code for those is in your program (the sources are all provided as well, so you can do your own thing).

Since FSUIPC_Process actually calls FSUIPC, it will involve a process switch by Windows. In fact there will be at least two before your program gets control back -- one from your program to FS, and the other back again. Since each such switch can take many milliseconds, it is those which need to be kept to a minimum.

None of the others matter.

So, the technique would be to have a cycle in which you issue all the FSUIPC_Read and FSUIPC_Write calls you wish to do, in the order you want them executed, and then make on FSUIPC_Process() call to get them executed. Do all this once per cycle, keeping the cycle time to something reasonable so as not to detract noticeably from FS's performance. There's little point in trying to go faster than FS's frame rate, so a 55 mSec cycle (the typical Windows timer tick of 18.2 per sec) would be fine for that sort of performance. Of course you would do it much less often when you did not need anything domne.

Is it advisable that a program to spawn multiple threads for either reading or writing simultaneously for large number of variables processing?

Not really, but that's a program design thing, depending on what you want to do. Be aware that by having multiple threads accessing the same data (your program will only have one shared data block for the transfer of the data) you risk data corruption unless you use semaphores or something to ensure serial access. You would be makingl ife much more complex than it would need to be.

Regards,

Pete

[sri777]

Thanks Peter. That explained the most.

Why would it want to? What are you trying to do? What are these other values? I'm not really understanding your question.

It is hypothetical at this point, but i imagine changing one variables value will impact the internal simulation state and hence will inturn impact more than one offset's value. Basically, i am thinking about writing a program to handle my overhead logic something like mini pmsystems. I can't think of a perfect example, but say turning off an engine in flight may cause altitude to drop, some overhead annunciators light up etc., So, it is my program, that it should know what all these attributes that can be impacted and read them correct?

Also, in general, if a client program is interested in say 50 offsets, it is upto the client program to decide it's strategy about when and how to read these correct?

So, the technique would be to have a cycle in which you issue all the FSUIPC_Read and FSUIPC_Write calls you wish to do, in the order you want them executed, and then make on FSUIPC_Process() call to get them executed.

As these group of calls are stacked up on the client program before FSUIPC_Process() is called, what is the impact of first writing and then some reads (of variables impacted due to the write call before) following the write call within the same batch? Would client program be able to see the effect of write in the following read calls within the same batch executed through the FSUIPC_Process() call?

thanks and I appreciate.

regards

srini

[Pete Dowson]

It is hypothetical at this point, but i imagine changing one variables value will impact the internal simulation state and hence will inturn impact more than one offset's value.

Well, yes, of course. But this won't concern the program unless you have some sort of interdependent loop going on some place.

I can't think of a perfect example, but say turning off an engine in flight may cause altitude to drop, some overhead annunciators light up etc., So, it is my program, that it should know what all these attributes that can be impacted and read them correct?

Well, you seem to be looking at it the wrong way round. You build your panel and populate it with switches and indicators. The switches result in changes being sent to FS (well, some of them -- not all. see ** below). The indicators are there to indicate things, and for those (not all, again) you'd be reading from FS.

But just because you write something does not mean you have to read something. You implement whatever it is that is neded to perform the function -- change things in FS or display something.

** If you are thinking in terms of a full airliner type overhead you will find that FS doesn't, in itself, simulate much of it for you to influence or gain indications from. You'll need to work out your own logic and keep your own data for much of it. This is what pmSystems does for, for instance, the APU (not simulated at all in FS), and which Thomas Richter, for one, has been developing quite sophisticated pmSystems logics for.

If you are realy out to do all this yourself, separately, good luck.

Also, in general, if a client program is interested in say 50 offsets, it is upto the client program to decide it's strategy about when and how to read these correct?

I still don't really understand what you are asking here. It would read them when it wants them, but no more often than they are likely to be changing. Anyway, the individual reads don't do anything, as I said. Only the Process does anything anyway.

As these group of calls are stacked up on the client program before FSUIPC_Process() is called, what is the impact of first writing and then some reads (of variables impacted due to the write call before) following the write call within the same batch? Would client program be able to see the effect of write in the following read calls within the same batch executed through the FSUIPC_Process() call?

That's quite unlikely, but it depends. If you write to the transponder code and read it back it will normally be what you've just written. If you write a reduced throttle setting it won't influence the N1% or RPM readings until the simulator has simulated something. Whilst FSUIPC is processing the reads and writes nothing else is happening in FS -- luckily they are all done in a very short time.

There's always going to be a lag in any case in anything which is simulated -- things actually are like that in the real world too. If you reduce the throttle in a real aircraft, the effect may seem instantaneous but there's enough milliseconds in there to make it very much non-instantaneous. You should never expect anything instantaneous. Why would you?

If you ever intend the program to run on a Client PC over WideFS you've got the Network latency in between as well. That could be hundreds of milliseconds.

Regards

Pete

[Kye]

Hi there,

I would like to make a suggestion for the FSUIPC interface. I'll provide a bit of background info incase my thinking is flawed somewhere:

Previously I have been modding/hacking other (non-FS) games for several years. I have come to understand that FSUIPC is one of the main interfaces used for modding FS's internal data. I downloaded the SDK, took a look at the IPC interfaces for accessing FS memory, all was good. However, I wasn't interested in writing an external application to access and modify flight simulator's memory, I wanted to be inprocess like the main FS modules and gauges and avoid the shortcomings of internal latency generated by any form of IPC.

This left me with a question I could not answer. Why were gauges and other 3rd party FS modules making use of an IPC interface when they were already inprocess? The answer, which everybody knows, but I didn't at the time, is that FSUIPC provides a convenient and compatible interface to FS's data. Data that may otherwise require months to years of research to locate and document.

My suggestion is that FSUIPC carry a secondary interface (exported procedures) which bypasses the IPC and allows developers which are already inprocess to more or less access and modify FS's data in realtime. This should result in considerable framerate/update speed increases. Especially for those using ReadAndProcess or WriteAndProcess techniques.