Free FSUIPC offsets for external programm

[guenseli]

Hello Pete,

hope you had nice holiday!

 

we try to make the simulator communicate with some external gauges.

For testing purposes I found now one way to make a LUA script:

FT = ipc.readLvar("FuelTankTop")
ipc.writeUW(0x66C0, FT)

 

and let offset 66C0 read from the external software what is working actually.

 

So, now my two questions:

1)

I know there's a range of free offsets one can use ... however I haven't found any documentation what range it is. I found 66C0 somewhere (don't ask me where, I do not remember) and do need now some more free offsets I could use

 

 

2)

The LUA script is executed now (for testing) just by pressing a joystick button -  so the data is just sent, when the button is pressed.

How could I make the script running continiously to send the data, and is there any danger of "overloading" the sim with it?

Or do you have a better idea how to send or grab that values?

We talk about the A2A Spitfire. And like with every advanced addon there are functions which couldn't be read as standard FSUIPC offsets. So, I have seen you have provided an offset mappig for 737/777 directly in FSUIPC... so, is this something I could achive also (without using LUA scripts) or is that sth. just you could provide with native code inside FSUIPC?

 

I hope you understood my question ;)

 

many thanks!

Günter

[Pete Dowson]

2 hours ago, guenseli said:

I know there's a range of free offsets one can use ... however I haven't found any documentation what range it is. I found 66C0 somewhere (don't ask me where, I do not remember) and do need now some more free offsets I could use

Why not refer to the Offsets Status document installed in your FSUIPC Documents folder? That is what it is for! Just search on the word "Free". It includes 66C0.

Documentation is provided for you to use. Much more efficient than posting here, surely?

3 hours ago, guenseli said:

I have seen you have provided an offset mappig for 737/777 directly in FSUIPC

Because that is the only way to get the information. The PMDG implementation simply provides a data block to be read.

3 hours ago, guenseli said:

just you could provide with native code inside FSUIPC?

No, I cannot possibly support every aircraft out there and most certainly not those which don't provide data in a mappable form.

Pete

 

[guenseli]

4 hours ago, Pete Dowson said:

Why not refer to the Offsets Status document installed in your FSUIPC Documents folder? That is what it is for! Just search on the word "Free". It includes 66C0.

Documentation is provided for you to use. Much more efficient than posting here, surely?

 

In the document I can see (and that is where I get the number):

66C0 Free for general use, for example in button or keys programming.

 

But it doesn't tell me if there are other offsets I can use and if so, what the numbers are. That was my question.

 

I'm no mathemathician or programer, so I could just assume that there are possible offsets between 66C0 and 6700? If so, the next question is how I could count these type of numbers?

[Pete Dowson]

1 hour ago, guenseli said:

In the document I can see (and that is where I get the number):

66C0 Free for general use, for example in button or keys programming.

But it doesn't tell me if there are other offsets I can use and if so, what the numbers are. That was my question.

It clearly says there are 64 bytes -- that's 64 x 8-bit values (BYTE ot Character), 32 x 16 bit ones (WORD), 16 x 32 bit ones (DWORD or FLT32) or 8 x 64 bit ones (double or FLT64).

So how many are useful to you depends on how you use them. For things like switches, on/off, you could put 8 in each byte or use one byte for each, but only values 0 and 1.  If there are all floating point numbers you'd need 32 or 64 bits each, so less different values.

I missed this question in my last reply:

9 hours ago, guenseli said:

The LUA script is executed now (for testing) just by pressing a joystick button -  so the data is just sent, when the button is pressed.

How could I make the script running continiously to send the data, and is there any danger of "overloading" the sim with it?

You use one or more events, which keep the plug-in running but idle just waiting for one of those events (a change in the value). You get the plug-in running by using an [Auto] section entry in the INI file -- either a generic [Auto] section to run it always or a Profile specific one [Auto.profile name] to have it running only for specific aircraft.

And no, since the plug-in only runs when something changes, there's no overloading.

Pete

 

[guenseli]

thanks Pete