How to access written data withing gauges

[ihr]

Hello Pete,

I've created an application that writes data info FSUIPC offset 5600. I coudn't found the way to read this data in a gauge.

I've tried several things:

a) Using the "Importable.PANELSEntry.fnptr + 0x5600"

b) adding the Global.dll to the Linkage area (don't do that. FS hangs)

c) Looking for a function that retrieves te Global.dll address.

None of them works.

¿How is it possible?

Pd: I've created a pretty cool application to "decompile" de gauges. You can see it at my web site. http://www.avsim.com/hangar/utils/nav

Regards,

IHR

[Pete Dowson]

I've created an application that writes data info FSUIPC offset 5600. I coudn't found the way to read this data in a gauge.

Take care. Location 0x5600 is used by Project Magenta. If you need a work area in FSUIPC offset space you need to get it reserved first so it doesn't conflict with anyone else. Work out how much you need (try to keep it reasonably small please), and ask me for the area and I will mark it for your use.

I've tried several things:

a) Using the "Importable.PANELSEntry.fnptr + 0x5600"

b) adding the Global.dll to the Linkage area (don't do that. FS hangs)

c) Looking for a function that retrieves te Global.dll address.

None of them works.

I am not surprised! The offset range 0000 to FFFF supported by FSUIPC is an illusion, not a coherent area of memory. Some is indeed in Globals.DLL, but not at those offsets. Some is in SIM1.DLL, some in FLIGHT.DLL, etc etc., but never at the same place - SIM1's structures for instance are completely reallocated and rebuilt each time you load an aircraft.

Some doesn't exist as such, but invoke procedure calls which supply the data. There are more and more like that. Indeed, many locations now do different things when written to than when read.

The only way to address FSUIPC offsets is through the interface provided by FSUIPC. That passes the request through the mapping procedures which get the access done, whatever it is.

From an external program you use the regular Library (or at least its methods) as supplied by the SDK. This uses memory file mapping and message passing to transfer the data.

From an internal FS module you use the internal module user's library, or equivalent code. This is also supplied in the SDK. The interface it provides is almost identical -- the only differences are in the FSUIPC_Open() call, now FSUIPC_Open2(), in which you also supply the transfer memory. There is no memory file as it isn't needed within the one process. There is still the message send by FSUIPC_Process.

Regards,

Pete

[ihr]

Take care. Location 0x5600 is used by Project Magenta. If you need a work area in FSUIPC offset space you need to get it reserved first so it doesn't conflict with anyone else. Work out how much you need (try to keep it reasonably small please), and ask me for the area and I will mark it for your use.

Peter,

The internal module library works fine. Many thanks!

I need a work area. Could you send me a Start location? I'm not sure how many bytes I need but if you give me a start location and a temporary size of about 512 bytes I can start working.

In case I need more I'll tell you. In case of the final buffer were smaler I'll tell you too.

Regards,

IHR

[Pete Dowson]

I need a work area. Could you send me a Start location? I'm not sure how many bytes I need but if you give me a start location and a temporary size of about 512 bytes I can start working.

Use 6420-661F for now. I'd prefer this to be smaller. Most applications (greedy Project Magenta excepted) manage on a lot less.

In case I need more I'll tell you.

If others need allocations yours will be split. But 512 bytes for inter-module communications is quite big. I'd advice against sending text data or complete flight plans this way. It is better to have files in a common folder and just use the communication here to synchronise and signal. And multiple uses of other areas can be signalled by "data type" indications in one location, and a handshake from the recipient in another.

In case of the final buffer were smaler I'll tell you too.

The area 6420-661F inclusive is currently marked "temporary" for you. If I need some of it before you release it, I will be back! :lol:

Regards,

Pete

[ihr]

Use 6420-661F for now

Many Thanks!

I calculated 512 Bytes because each FLOAT64 is 8 bytes len. In 512 Bytes there are space for (only!) 64 FLOAT64 variables.

Initially, I need to transfer data for 52 gauges so I spect to use less memory.

Regards,

IHR

[Pete Dowson]

Use 6420-661F for now

I calculated 512 Bytes because each FLOAT64 is 8 bytes len. In 512 Bytes there are space for (only!) 64 FLOAT64 variables.

Use 32 bit floats (C !"float" type). They are most certainly accurate enough for most purposes. In fact for most gauges you can use words or even bytes -- Fs's turn coordinator and slip ball use one byte each!

Initially, I need to transfer data for 52 gauges so I spect to use less memory.

Depending on how fast you want to update these, and whether you are running on the FS PC or via WideFS, you can re-use the same few bytes for many gauges. You just write the gauge number and its indication, wait for the gauge number to be cleared in acknowledgement, then write the next. I'm not saying you should do this, but some gauges need fast updates, some don't. Multiple fuel gauges, for instance, are an example where a serial update would be fine.

Regards,

Pete