FSUIPC v7.2.0 beta support: Adding Lvars to Offsets

[John Dowson]

This topic is for questions and issues on the v7.2.0 beta release, which includes a new facility for adding Lvars to Offsets using the FSUIPC7.ini. This release is available here: 

 

 

[Nenad Bogojevic]

Hello John,

Thanks a lot for this update. I have tested it, and lvars from the profile ini file were well mapped to offsets for read and write (and conditions 👍)  

Meanwhile I have hit the 64 char limit for the ipc.execCalcCode, would it be possible to extend it to 128 or maybe even 256?

Cheers,

Nenad

P.S. Here's list of hvars for DA40 TDI (different fron DA40-NG).

DA40 TDI.hvar

[John Dowson]

1 minute ago, Nenad Bogojevic said:

Thanks a lot for this update. I have tested it, and lvars from the profile ini file were well mapped to offsets for read and write (and conditions 👍)  

Thanks for the update - good to know!

1 minute ago, Nenad Bogojevic said:

Meanwhile I have hit the 64 char limit for the ipc.execCalcCode, would it be possible to extend it to 128 or maybe even 256?

Maybe, I'm not sure yet, its something I need to look into. I'll take a look in the day or two to see if this is an easy change or not.
If it looks to be something that could be tricky and/or risky, I may have to leave this limit. However, I could add an additional FSUIPC control for executing calculator code, which could except up to 256 characters (I was planning to add this anyway).

Thanks for the additional hvar file!

Cheers,

John

[John Dowson]

1 hour ago, Nenad Bogojevic said:

Meanwhile I have hit the 64 char limit for the ipc.execCalcCode, would it be possible to extend it to 128 or maybe even 256?

Have you actually tested with a calc code string > 64 characters? The limit I have currently set for this is 256 characters (and this can be increased relatively easily, but would require an update of the WASM module to handle), so maybe I was mistaken with the lua limit.

I will check this - tomorrow though....

[Helibrewer]

Tried to install, getting message that FSUIPC is already running. I rebooted and don't see it running anywhere but I am still getting that pop-up when trying to install. What am I missing?

[Nenad Bogojevic]

2 hours ago, John Dowson said:

Have you actually tested with a calc code string > 64 characters? The limit I have currently set for this is 256 characters (and this can be increased relatively easily, but would require an update of the WASM module to handle), so maybe I was mistaken with the lua limit.

Just tested and it works with more than 64 char expressions - up to 255. Over that FSUIPC crashes.

[John Dowson]

11 hours ago, Nenad Bogojevic said:

Just tested and it works with more than 64 char expressions - up to 255. Over that FSUIPC crashes.

Ok, good to know it works, but it shouldn't crash when the limit is exceeded - I'll fix that and log a message when the limit is exceeded.
Do you think 256 chars (well, 255 + a terminator) is enough? I could easily extend further (up to 8k, the max size held in a Client Data Area).

[John Dowson]

@Nenad BogojevicCould you try the attached build please. Not sure why its crashing when using more than 255 characters, but I've added a check for this now.
Sorry, still now working, looking into it...

 

Edited May 20, 2021 by John Dowson
attachment removed

[John Dowson]

14 hours ago, Helibrewer said:

Tried to install, getting message that FSUIPC is already running. I rebooted and don't see it running anywhere but I am still getting that pop-up when trying to install. What am I missing?

Are you sure its not running? The installer performs a simple check to find the process FSUIPC7.exe, and if found will display a message and abort.
I can't see how this check can fail - and it hasn't changed or been an issue since release....Sis you check in the windows Task manager?

[Helibrewer]

7 minutes ago, John Dowson said:

Are you sure its not running? The installer performs a simple check to find the process FSUIPC7.exe, and if found will display a message and abort.
I can't see how this check can fail - and it hasn't changed or been an issue since release....Sis you check in the windows Task manager?

Never figured it out, rebooted, used the uninstaller and it couldn't delete the exe either. I was able to rename the exe, reboot, then I could delete it. I have no idea what was loading FSUIPC at boot but it didn't show in task manager that I could see. 7.2 is now installed so I can start figuring out this lvar offset stuff now....thanks!!

[John Dowson]

2 minutes ago, Helibrewer said:

Never figured it out, rebooted, used the uninstaller and it couldn't delete the exe either. I was able to rename the exe, reboot, then I could delete it. I have no idea what was loading FSUIPC at boot but it didn't show in task manager that I could see. 7.2 is now installed so I can start figuring out this lvar offset stuff now

Ok, very strange, but glad its now working.

[John Dowson]

@Nenad Bogojevic Looks like a problem with the build of the last version I posted. Here's one I tested - max characters allowed is 255 (or 256 with terminating \0):FSUIPC7.exe
Also contains a minor update to change the value parameter when creating an lvar from a dword to a double. There's also a corresponding  update to the WASM for this, but the latest published one will still work Ok.

[Nenad Bogojevic]

8 hours ago, John Dowson said:

Here's one I tested - max characters allowed is 255 (or 256 with terminating \0)

 No crash anymore and so far no problems with new exe file - error shown in the log when expression too long 👍

Quote

    17187  [ERROR]: Error setting Client Data Calculator Code: code contains 256 characters, max allowed is 255

 

[RCFlyer]

I have tried to download beta v7.2.0, but, the link doesn't work for me.  Is there another link/place I can get the download?

 

[John Dowson]

9 hours ago, RCFlyer said:

I have tried to download beta v7.2.0, but, the link doesn't work for me.  Is there another link/place I can get the download?

The link should be fine, but quite a few people have reported the links on SimMarket not woeking for some reason. Try a righ-click and select 'Save as...'.

[asessa]

Hi John, great news.

I will try with A320FBW Hot Brake, boolean

Did i do right this ?

[LvarOffsets.A320FBW]
0=A32NX_BRAKES_HOT=SB

[John Dowson]

1 hour ago, asessa said:

Did i do right this ?

[LvarOffsets.A320FBW]
0=A32NX_BRAKES_HOT=SB

No! Where is the offset (location), i.e. the place to store the value? Please see the provided documentation: 

Quote

Once you have created the section, you can add the lvars to the offsets you require by adding lines of the following
format to this section:
    <index>=<lvar name>=<size><offset>

 

[asessa]

55 minutes ago, John Dowson said:

No! Where is the offset (location), i.e. the place to store the value? Please see the provided documentation: 

 

Ah ok, I understand now

[RickFSN]

I'm gonna ask this just to see if I did everything right or not.

So, I'm trying to asign the LVAR resposible for toggling the beacon light in the Aerosoft CRJ 550/700. I know the LVAR name is ASCRJ_EXTL_BEACON.

Looking at the offset from the manual, I find the correct value. And I add the line to the FSUIPC7.ini

Is this correct? If so, what would be the next step? Do I bind the joystick button through FSUIPC7?

[Pete Dowson]

1 hour ago, RickFSN said:

Looking at the offset from the manual, I find the correct value. And I add the line to the FSUIPC7.ini

Is this correct? If so, what would be the next step? Do I bind the joystick button through FSUIPC7?

It is not a good idea to try to use an offset which is already being handled by FSUIPC. Whatever value to put there or receive will be overwritten. Use one of the User Offsets (66C0-66FF).

Then assign your switch to an Offset Byte Set or Offset Byte ToggleBits control with your chosen offset and an appropriate parameter. For On I assume you'd Set 1, for Off probably Set 0, or for a toggle button ToggleBits with parameter 1.

Pete

 

 

[RickFSN]

What I don't understand is how the plane will know that the LVAR ASCRJ_EXTL_BEACON has been toggled. I'm trying to wrap my head around the entire LVAR situation as it is completely new to me. And so far, the Aerosoft CRJ has been the only plane to use them because of dev decision. 

I have already asked for help on the aerosoft forums, but I've just been ignored or told to spend more money on Spad.Next. Fortunately, I had FSUIPC from a while ago, but it is proving difficult for me to bind my Virpil Control Panel and Logitech Throttle Quadrant to interact with the plane systems.

[Pete Dowson]

32 minutes ago, RickFSN said:

What I don't understand is how the plane will know that the LVAR ASCRJ_EXTL_BEACON has been toggled.

L:Vars ("Local Variables" as I think of them) are mostly the plane's own internal controls or status indicators. Not all of them will change switches etc -- some are more really outputs -- status indicators or memories. You have to try them to see how they operate.

Pete

.

 

[John Dowson]

4 hours ago, RickFSN said:

Looking at the offset from the manual, I find the correct value. And I add the line to the FSUIPC7.ini

Is this correct? If so, what would be the next step? Do I bind the joystick button through FSUIPC7?

As well as not using a free offset, as Pete has said, you shouldn't have a space between the size identifier and the offset (although it might work, I'm not sure).

2 hours ago, Pete Dowson said:

Then assign your switch to an Offset Byte Set or Offset Byte ToggleBits control with your chosen offset and an appropriate parameter. For On I assume you'd Set 1, for Off probably Set 0, or for a toggle button ToggleBits with parameter 1.

As you have defined the size of the offset to be SW (Signed word), when you read or write/assign. you should use the Offset Word Set/Setbits/Togglebits/etc controls for assigning, and ipc.readSW if reading in lua. i.t. ALWAYS match the controls/functions that you are using to write/read to the actual size you have defined for the offset to hold the lvar.

Alternatively, and better, if that lvar just holds a 0/1 to designate on/off, store it in an unsigned byte offset, using the UB size designator, then assign to Offset Byte Set or Offset Byte ToggleBits assuggested by Pete (and using a free user offset, e.g. A000).

John

[Nenad Bogojevic]

Hi John,

I discovered an issue with ipc.execCalcCode. As long as parameter sent is exactly the same, subsequent calls are not re-evaluated. As soon as there is a different expression, between those calls it works. The easiest way to spot it is toggle buttons - if there is expression behind only the first toggle works. 

In following example only the first toggle is executed. There can be any amount of time between two calls - it can be on different events for example - it always toggles just once.

-- This toggles marker mute

ipc.execCalcCode("(A:MARKER BEACON TEST MUTE, Bool) ! (>K:MARKER_BEACON_TEST_MUTE)")

-- Some time later

-- This should toggle marker mute to original state, but it doesn't

ipc.execCalcCode("(A:MARKER BEACON TEST MUTE, Bool) ! (>K:MARKER_BEACON_TEST_MUTE)")

 This code, however, toggles correctly:

-- This toggles marker mute

ipc.execCalcCode("(A:MARKER BEACON TEST MUTE, Bool) ! (>K:MARKER_BEACON_TEST_MUTE)")

-- Some time later

-- Dummy expression, always evaluates to 1 without side effects

ipc.execCalcCode("1")

-- This now toggle marker mute to original state

ipc.execCalcCode("(A:MARKER BEACON TEST MUTE, Bool) ! (>K:MARKER_BEACON_TEST_MUTE)")

If there is execution of any other different gauge expression between calls with same parameter, those work are executed.

Cheers,

Nenad.

[John Dowson]

@Nenad Bogojevic I'm not sure but I think it may be a timing issue. Can you try with an ipc.sleep call in between the two execCalcCode calls (try with 1000 initially and if that works, reduce). If that doesn't work, I will look into it. Thanks.