Jump to content
The simFlight Network Forums
gdscei

Incorrect data given by FSUIPC

Recommended Posts

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! :)

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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!

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use. Guidelines Privacy Policy We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.