Incorrect data given by FSUIPC

[gdscei]

I am currently using Paul Henty's .NET client DLL. I have multiple users reporting two main issues with the data:

- Taxi lights on Aerosoft's AXE. Probably because of the 3-state taxi light switch, when the taxi light is in the TO position, it is still registered "on" (which is true technically, but not really useful if you are trying to figure out if the nose light is on).

- Landing rate. This seems to be quite inconsistent, and sometimes even over the top with landing rates above 1000 fpm.

 

If you have any info on either of these, if they are known, if they're are fixable, that would be awesome. Thanks! :)

[Paul Henty]

FSUIPC can only get information from Flight Sim. It doesn't know about add-on aircraft (except for PMDG 737ngx). Flight Sim only has two states for the taxi lights, on and off. If planes like the AXE need more than two states they must model that themselves, outside of Flight Sim.

 

Some manufacturers have a way of accessing this extra data with SDKs or LVars (which can be accessed via a LUA plugin for FSUIPC). But each aircraft is different so you would need to investigate each one separately.

 

The landing rate (030C) is just a snapshot of the vertical speed offset (02C8) taken when the ground flag changes. Bounces can sometimes affect this reading. If you don't like the values it gives you can always monitor 02C8 and the on ground flag (0366) in your code and come up with your own logic to capture the VS at touchdown. For example you could average all the VS readings taken during the last 1 second before touchdown. You could further analyse each rate and filter out any anomalies.

 

If you'd like me to check your code for the 030C offset, paste the offset declaration and the conversion formula.

 

Paul

[gdscei]

FSUIPC can only get information from Flight Sim. It doesn't know about add-on aircraft (except for PMDG 737ngx). Flight Sim only has two states for the taxi lights, on and off. If planes like the AXE need more than two states they must model that themselves, outside of Flight Sim.

 

Some manufacturers have a way of accessing this extra data with SDKs or LVars (which can be accessed via a LUA plugin for FSUIPC). But each aircraft is different so you would need to investigate each one separately.

 

The landing rate (030C) is just a snapshot of the vertical speed offset (02C8) taken when the ground flag changes. Bounces can sometimes affect this reading. If you don't like the values it gives you can always monitor 02C8 and the on ground flag (0366) in your code and come up with your own logic to capture the VS at touchdown. For example you could average all the VS readings taken during the last 1 second before touchdown. You could further analyse each rate and filter out any anomalies.

 

If you'd like me to check your code for the 030C offset, paste the offset declaration and the conversion formula.

 

Paul

 

Hello Paul,

 

Thanks for the information. I guess I will have to look up what Aerosoft can offer me in terms of SDK. Other aircraft, probably will just have to make exceptions for it.

 

In terms of my declaration for the 030C offset...

private readonly Offset<int> _landingRate = new Offset<int>(0x030C);

I am pretty sure that's alright. Thanks for the information on the landing rate, that can explain the strange behaviour. I will probably indeed have to make my own logic. I might post it here if I can make it work!

[gdscei]

FSUIPC can only get information from Flight Sim. It doesn't know about add-on aircraft (except for PMDG 737ngx). Flight Sim only has two states for the taxi lights, on and off. If planes like the AXE need more than two states they must model that themselves, outside of Flight Sim.

 

Some manufacturers have a way of accessing this extra data with SDKs or LVars (which can be accessed via a LUA plugin for FSUIPC). But each aircraft is different so you would need to investigate each one separately.

 

The landing rate (030C) is just a snapshot of the vertical speed offset (02C8) taken when the ground flag changes. Bounces can sometimes affect this reading. If you don't like the values it gives you can always monitor 02C8 and the on ground flag (0366) in your code and come up with your own logic to capture the VS at touchdown. For example you could average all the VS readings taken during the last 1 second before touchdown. You could further analyse each rate and filter out any anomalies.

 

If you'd like me to check your code for the 030C offset, paste the offset declaration and the conversion formula.

 

Paul

 

Hello Paul,

 

How would you recommend I read the values in my application from the LUA script that gets the LVars? I believe there is no offset available to just read whatever LUA outputs, right?

[Paul Henty]

You are right, there is no offset or any feature in FSUIPC to transfer data to or from lua.

There are spare offsets you can use in FSUIPC, I think called user offsets or free offsets in the docs. Sorry for being vague but I am away at the moment with no access to the docs. You can have your lua program copy the LVAR data into these offsets and read them from your program in the normal way. If your program is being released to the public then it is advisable to ask Pete for some allocated offsets for this purpose instead of using the free block.

Another way would be writing the data to a local file in lua and then reading it from your program.

Or you can open a local tcpip socket connection using the libraries in lua and .net and have the two program's communicating over that connection.

I think those are your options.

Paul

[gdscei]

You are right, there is no offset or any feature in FSUIPC to transfer data to or from lua.

There are spare offsets you can use in FSUIPC, I think called user offsets or free offsets in the docs. Sorry for being vague but I am away at the moment with no access to the docs. You can have your lua program copy the LVAR data into these offsets and read them from your program in the normal way. If your program is being released to the public then it is advisable to ask Pete for some allocated offsets for this purpose instead of using the free block.

Another way would be writing the data to a local file in lua and then reading it from your program.

Or you can open a local tcpip socket connection using the libraries in lua and .net and have the two program's communicating over that connection.

I think those are your options.

Paul

 

Hello Paul,

 

Thanks you very much for the info. I think I'll go with writing to offsets to keep consistency across my application. 

I'll see what I can get done and have a chat with Pete if necessary for the offsets.

[Gypsy Baron]

L:Vars can be declared in an MCRO file. This adds them to the list of controls that can be

manipulated by FSUIPC4 via the Buttons & Switches menu and the axis assignment menu.

 

Lua has the ability to read L:vars and offsets as well as write to them (ipc.read and ipc.write)

 

The User defined offsets, 0x66C0 - 0x66FF, can be used as you wish. I suggest that you read

and re-read the Advanced User Guide PDF as well as the Lua Library PDF in the documents

folder. Those two, along with the Revised_List_of_FSX_Controls.pdf and FSUIPC4_Offsets_Status.pdf,

should answer a lot of questions and enlighten you to the poser of FSUIPC4 and Lua.

 

   Paul

[gdscei]

Thanks Paul!

 

I was able to figure it out, and succesfully was able to get the correct taxi light value I need.

If anyone else needs it, the LUA script is quite easy:

while 1 do
  taxi = ipc.readLvar("L:AB_TAXI_LT")
  if taxi == nil then
    break
  end
  ipc.writeUB(0x66C9,taxi)
  ipc.sleep(100);
end

[Paul Henty]

Just a small suggestion; you might want to look at using the "event.Lvar" function rather than the infinite while loop. I believe it's far better from a performance point to view.

 

Paul