Rescanning LVars generates spurious events (since 7.3.17)

[Djeez]

In my Lua scripts I use event.Lvar() calls to subscribe to Lvar changes to activate/deactive a corresponding LED.

It seems as if an automatic Lvar rescan triggers the events: For every Lvar that was 1, I see two events: the Lvar being 0 and immediately thereafter the Lvar being 1 again.

As a consequence, I see all LED's that are ON in my cockpit flicker whenever the number of Lvars changes. From the log file I can see this coincides with the change in number of LVars.

10220203 Lvars received: 4494 L:vars & 0 H:vars now available

This flickering did not happen before 7.3.17.

[John Dowson]

In the current released version, when lvars are received they are given a default value of 0 and then the actual value is received a short time layer, < 1s. In the latest beta, I have delayed the sending of the lvars by 1 second and so this should hopefully resolve this issue. Please try the latest beta, available here: 

 

If you get the same issue then please let me know - I have other ideas that can prevent this in the next official release, but was hoping that the delay introduced in this version should prevent this.

John

[Djeez]

Hi John.

Thanks for the reply.

I installed the version as you indicated (showing 7.3.18b in the About box).

Unfortunately, the problem is still there. Just before the "Lvars received: ..." line appears in the log, I see that the Lvars I subscribed to get a callback with parameter 0 and soon thereafter a callback with parameter 1, effectively making the LED's flicker for a moment.

It is not critical, just annoying (every time it happens I have this little fear that my custom hardware fails...) so I can wait for a final version that fixes this. If you would like me to test a beta release I am very happy to do so.

-Emile.

[John Dowson]

Hi Emile,

the update in 7.3.17 was only to give the initial 'lvars ready' callback when the lvars are first loaded, which is now delayed until the initial values are received. When new lvars are found, the current lvar list is dropped and the update lvars are given a default value of 0. I can look into locking read-access to lvars on an update until the new values are received. In the mean-time, you can prevent the automatic scanning and updating of the list of available lvars by setting the following parameter in your FSUIPC_WASM.ini:
     LvarScanFrequency=0

Note that it is better to do this in the FSUIPC_WASM.ini under your AppData folder, not the one under the WASM Community folder, as this would get overwritten on updates - see the Advanced User guide for details on the locations of this ini file. 

John

[John Dowson]

On 3/6/2023 at 8:00 PM, Djeez said:

I installed the version as you indicated (showing 7.3.18b in the About box).

Unfortunately, the problem is still there. Just before the "Lvars received: ..." line appears in the log, I see that the Lvars I subscribed to get a callback with parameter 0 and soon thereafter a callback with parameter 1, effectively making the LED's flicker for a moment.

Could you please try the latest beta release, available here: 

 

Not 100% sure this will fix your issue though...please let me know!

On 3/7/2023 at 10:30 AM, John Dowson said:

In the mean-time, you can prevent the automatic scanning and updating of the list of available lvars by setting the following parameter in your FSUIPC_WASM.ini:
     LvarScanFrequency=0

You should be able to remove this now as well, but test with this if you get the same issue. Thanks,

John

[Djeez]

3 hours ago, John Dowson said:

Could you please try the latest beta release, available here: 

<<7.3.18c>>

Not 100% sure this will fix your issue though...please let me know!

It works great. I see Lvars discovered in the log window but my event handlers on subscribed Lvars are not called, so no flickering anymore.

Thanks for the fix!

-Emile.