store all data into buffer

[doia]

Pete,

How would I go about to store all of the offset data into a large buffer? I figured this is the best way to request large amounts of parameters(requested by an external input) without having to make multiple Process calls. Then I can pick the data requested by the input from that buffer. I am just not sure what type of buffer receptacle or offset number to use.

char buffer[Max_size];?

FSUIPC_Read(0x230, 200?, &buffer?, &dwResult)

Regards,

Isa

[Pete Dowson]

How would I go about to store all of the offset data into a large buffer?

ALL of it? You shouldn't do that. You shjould only ask for what you need. Some of that stuff needs calls into different parts of FS to obtain and you shouldn't be asking for that to be done for data you don't need.

I figured this is the best way to request large amounts of parameters(requested by an external input) without having to make multiple Process calls.

You never have to make multiple Process calls, only multiple FSUIPC_Read or Write calls, which only build up your list of data requirements. The Process call just sends the request to FSUIPC -- one Process call for ALL of your requests, once per cycle.

There's little cost in the Read and Write calls as these only add your request to a shopping list.

Regards

Pete

[doia]

Pete,

Thanks for the help- again. For my application I don't know how much data I'll be requesting - it is dependent on an external input - so it would be impossible to allocate a separate variable for each read request and build up the Read requests, hence my question about saving all data to a larger buffer.

So that you have a better idea of what I want to do here's the outline of my application:

The program reads an input file:

INPUT FILE

Parameter name / parameter location / conversion factor

Lateral Acceleration 45 0.2223355

Vertical Acceleration 70 1.23333

Then my program looks up the name, correspondent offset number, byte size, conversion factor and "receptacle type" from a second file like this:

LOOK UP TABLE

Lateral Acceleration 0x6040 8 0.2223355 double

The program uses the values acquired from the Table as the inputs the FSUIPC_Read request.

Because my input file is "volatile" and has a huge quantity of parameters (300) I can't make individual reads and writes. My final output should do be an array with (the lateral acceleration from sim * conversion factor form input file) stored on its 45th index(parameter location from input file).

Regards

[Pete Dowson]

For my application I don't know how much data I'll be requesting - it is dependent on an external input - so it would be impossible to allocate a separate variable for each read request and build up the Read requests, hence my question about saving all data to a larger buffer.

You can use any sort of buffer you like, but it is not a good idea to read data you don't want. As far as the FSUIPC interface is concerned all data is just bytes, so you can still build up your read requests with the correct offsets and the correct sizes (in bytes), asnd have them read into your character-based buffer at your own computed offset, or even the FSUIPC offset. e.g

Reading 5 bytes at 0x8954 (a fictitious examples):

char my_big_buffer[65536];
...
FSUIPC_Read(0x8954, 5, &my_big_buffer[0x8954]);
...
more reads
...

FSUIPC_Process. ..

Then you know you have the 5 bytes at 8954 in your buffer, but you don't need to read all 65536 offsets to get it!

Because my input file is "volatile" and has a huge quantity of parameters (300) I can't make individual reads and writes.

Yes you certainly can, and in fact it is by far the best way! There is no reason why the offset (0x8954) and size (5) in my example can't be from parameters. Just loop reading the parameters, doing the reads. Then one Process.

Pete

[doia]

Because my input file is "volatile" and has a huge quantity of parameters (300) I can't make individual reads and writes.

Yes you certainly can, and in fact it is by far the best way! There is no reason why the offset (0x8954) and size (5) in my example can't be from parameters. Just loop reading the parameters, doing the reads. Then one Process.

Wouldn't I still need 300 different memory locations to store these values then?

[Pete Dowson]

Wouldn't I still need 300 different memory locations to store these values then?

You need locations for all the data in any case. How small are you trying to make your program? If you want to read 1000 bytes worth of data you need 1000 bytes. The number of different variables isn't relevant in any case. They are never going to squeeze 200 variables into 6 bytes! Even if they are only one byte each that is 200 bytes.

How much memory does your PC have? What is your obsession with memory usage?

My example above assumed you were more concerned about ease of programming, and there's nothing much easier than simply declaring an area equal in size to the offset space, i.e. 65536 bytes, and locating your copies of the variables you need at the same offsets as they would be if FSUIPC's offset memory were genuinely as it is pictured to be.

Regards

Pete

[doia]

Pete,

Thanks for the help.I got confused, my PC has plenty of memory, and it does seem a whole lot easier to just make the buffer the size equal to the offset space so I will just take your suggestion.

One last question, what exactly do you mean when you say:

if FSUIPC's offset memory were genuinely as it is pictured to be.

Regards,

Isa

[Pete Dowson]

One last question, what exactly do you mean when you say:

if FSUIPC's offset memory were genuinely as it is pictured to be.

Well, all this is explained, probably in a different way, in the FSUIPC docs somewhere, but here goes ...

The FSUIPC interface is derived from an original design by Adan Szofran, for FSW95 originally and updated for FS98, which simply provided access to a module in FS called "Globals.dll", in which most of the variables which FS cared about were stored and activated from. In that interface the "offset" was a genuine offset (i.e address difference) from the start of the Data in the GLOBALS.DLL. The fact that the data moved about from release to release (i.e. from FSW95 to FS98) was irrelevant to the interface as it was then -- it was up to the implementer of applications to work out what was what. Folks simply had to modify their programs for each FS update.

When Adam gave up (he was recruited into Microsoft) I was faced with an FS2000 with another different FS Globals arrangement and, worse, some things moved out of GLOBALS and into other FS modules. This prevented many of my applications (ones I'd paid for, for example), so I wrote my own replacement for Adam's work. His were called FS5IPC and FS6IPC (for FS5 and FS6), I called mine FSUIPC, with "U" being for "Universal" as I intended it to work with FS98 programs, which I had, in FS2000 -- and any future FS.

As FS was developed, "GLOBALS.DLL" became a thing of the past. All of the values previously at "known offsets" in "known modules" in FS became buried in private data in black box (they call it "encapsulated") modules -- the results of "Object Oriented Programming", the new rage! Worse, many values were only computed on demand.

In the end, FSUIPC3 (for FS9 and before) retains compatibility between FS98, CFS1, FS2000, CFS2, FS2002 and FS2004 simply because it has tables which tell it where or how to get each item of data relating to each "offset" entry in its long list. FSUIPC4 (for FSX and ESP) does it the same way, but it populates almost all the data in only one way -- by asking SimConnect for it. SimConnect was really a result of my long-term negotiation with Microsoft's FS team for a decently consistent way of interfacing to FS. It had potential but sadly was never really finished before Microsoft clobbered everything.

Regards

Pete