Jump to content
The simFlight Network Forums

Lvar offset


yvesb

Recommended Posts

The addition of offsets for the Lvar is a great novelty. However, since the reading of these variables is not done completely when starting planes, we must do a Lvar reload after a while from a menu . Is it possible to create a fsuipc specific offset for reloading variables without having to use the menu?

Thank you and have a nice day.

Yves

 

Link to comment
Share on other sites

5 hours ago, yvesb said:

However, since the reading of these variables is not done completely when starting planes, we must do a Lvar reload after a while from a menu 

The problem is that there is no event that can be caught that tells you when a plane is fully loaded (or ready-to-fly) which can then be used to start the lvar scan.
There is an ini parameter that you can set in the WASM ini file (FSUIP7_WASM.ini, in the WASM folder under your MSFS Community folder) that can delay the scanning of lvars.
The parameter is called LvarScanDelay, and is documented in the Advanced User Guide.  The parameter is in milliseconds, with the default being 2500 (2.5 seconds). The (current) maximum allowed value is 10000 (10seconds), so you could try adding that (you will need to restart MSFS).

I thought I had added am fsuipc control and/or lua library function to initiate a WASM reload call, but it looks like I missed this. I will add a control + lua function for this (no need for a specific offset).

John

Link to comment
Share on other sites

@yvesbPlease try the attached version, v7.2.2a.  This has an additional Reload WASM (FSUIPC7) control, as well as an additional lua function ipc.reloadWASM() 

FSUIPC7.exe

I have also changed the default value of LvarScanDelay from 2500 to 5000, and have increased the max allowed for this parameter from 10000 to 60000. However, as these are WASM module updates, they won't be released until I release the updated WASM module, which will be done when I make 7.2.2 the official/latest release.

John

 

 

Link to comment
Share on other sites

Allo John,

Although I have been using your app for over 10 years, but I do not use macros or Lua scripts.
So I configure in FSUIPC_WASM.ini LvarScanDelay to the maximum and I still have to reload using the menu.

The 10 second delay is too short. So i will wait modifying the WASM module to see if 60 seconds will suffice.

I program with the Fsuipc Java SDK several modifications of the MCP of aeroSystem737 avionics software to make it work
with other planes than the 737.  I have more then 10 differents home made "MCP"
 

Hence the interest for me in offsets for lvars; this will allow me to control variables inaccessible with standard offsets.

It is for this reason that I would like to reload without using the menu because I control all my planes remotely, all the time !

Would it not be possible to do an automatic recharge of the Lvars at programmable intervals in the FSUIPC_WASM.ini ?

Thank you for your help

Capture.PNG

Link to comment
Share on other sites

5 hours ago, yvesb said:

Would it not be possible to do an automatic recharge of the Lvars at programmable intervals in the FSUIPC_WASM.ini ?

Yes, this is something I could add. I am planning to refactor aa few areas of the WASM in the coming weeks, so I will also look into adding some sort if automatic lvar refresh.
For the time being, you can now easily do this with a simple lua script- just a matter of using event.timer to call a handling function at regular intervals, then in the handling function just call ipc.reloadWASM(), i.e.

local period = 600 -- period in ms, adjust as needed

function reloadLvars(time)
    ipc.reloadWASM()
end

event.timer(period, "reloadLvars")

Save that to a file called reloadLvars.lua, then add a line to the [Auto] section of your FSUIPC7.ini (create section if you don't have it):

[Auto]
1=Lua reloadLvars

 

6 hours ago, yvesb said:

I program with the Fsuipc Java SDK several modifications of the MCP of aeroSystem737 avionics software to make it work
with other planes than the 737.  I have more then 10 differents home made "MCP"

Wow - impressive! If using the Java SDK, you could also access lvars directly using the WASM API (WAPI). There is a dynamic library available that you can use (via the Java Native Interface). Using that, your program would have access to an internal table of all lvars/hvars directly.

Link to comment
Share on other sites

Allo again !

Your lua script is working wonderfully. Thank you!

Since you are thinking of modifying your WASM server, it would be interesting to get the data type when you view the Lvars list. You may need to determine it since the values are exact. Ex: FMC_VOR_FREQUENCY: 1 = 116300000.000000

I could then correctly generate my configuration lines for the fsuipc7.ini file with my bash script if I had the data type (byte, int, double). Right now I take it for granted that these are all bytes and then correct by hand.

#!/bin/bash

offset=0x66C0
indice=0

for i in $(cat cj4_lvar_complet.txt | cut -f1 -d" " )
do

   echo -n $indice=L:$i=UB0x
   printf "%X" ${offset}
   offset=$(($offset +1))
   indice=$(($indice +1))

echo
done

0=L:XMLVAR_YokeHidden1=UB0x66C0
1=L:XMLVAR_YokeHidden2=UB0x66C1
2=L:Generic_Master_Caution_Active=UB0x66C2
3=L:Generic_Master_Warning_Active=UB0x66C3
...

When you talk about Java Native Interface, are you referring to the Wasmer Java framework :

 

Link to comment
Share on other sites

3 minutes ago, yvesb said:

Since you are thinking of modifying your WASM server, it would be interesting to get the data type when you view the Lvars list. You may need to determine it since the values are exact. Ex: FMC_VOR_FREQUENCY: 1 = 116300000.000000

That is not going to happen I'm afraid. All lvar values are just treeted as 8-byte/64-bit values. It is up to the user to know the actual type and treat accordingly.

5 minutes ago, yvesb said:

When you talk about Java Native Interface, are you referring to the Wasmer Java framework :

No. The Java Native Interface (JNI), which is what is used to call narive C/C++ code from java. See https://www3.ntu.edu.sg/home/ehchua/programming/java/javanativeinterface.html.

There may be other frameworks built on top of JNI that are easy to use, but I don't know about them. I was a java/J2EE programmer/architect for many years, but now I'm back in the C/C++ world I haven't touched java for 3-4  years or so....

 

Link to comment
Share on other sites

 

Your Lucky Luce : Man who reply (shoots) faster than his shadow  😀

That's Ok, for the moment I reorder the list to place at the beginning what seems to be bytes and I replace the other types at the end.

All right, for the JNI, I'll try to get the gist of it. A great challenge for a weekend programmer!
 

Thank you for your help and have a nice day !
 

Link to comment
Share on other sites

  • 2 weeks later...

@yvesb It looks like the LvarScanDelay WASM ini parameter had no effect, regardless of what this was set to. I have now corrected this in the attached (beta) release.
Could you please try this as I think if this is working then there should be no need to have a regular automatic re-scanning of lvars. The lvarScanDelay parameter is also now in seconds (rather than milliseconds), with a max value of 120.
There are also some other corrections for when using lvars, such as not auto-starting luas or macros until the lvars have been loaded.

Install_FSUIPC7.2.2c.zip

John

NB. If you have problems downloading from that link, try right-clicking and selecting 'Save as...'.

Link to comment
Share on other sites

Allo John,

I removed the lua script from FSUIPC7.ini and added LvarScanDelay = 60 in FSUIPC_WASM.ini and indeed after 60 seconds the update was activated and all offsets were available.
 
Thank you
 
Yves
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • 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.