A workaround for the fs2020_variable_write() not always working

Discuss suspected bugs with other users and Sim Innovations Staff

Moderators: russ, Ralph

Post Reply
Message
Author
ylevesque
Posts: 69
Joined: Wed Jan 09, 2019 6:49 pm

A workaround for the fs2020_variable_write() not always working

#1 Post by ylevesque »

fs2020_variable_write() is not working when the variable value was previously changed by the sim.
It seems that Air Manager does nor update a LVar if he thinks that the value has not changed.
So if a user changes a LVar by pressing a button or a switch directly in the cockpit, the value cannot return to the initial value by fs2020_variable_write().

For example, in the standard Asobo Airbus A320:
fs2020_variable_write("L:BTN_TERRONND_ACTIVE","enum",1) will execute the press the TERR ON ND button and the light will go ON.
If the user press the TERR ON ND button in the cockpit (not in a AM instrument), the light will go OFF.
fs2020_variable_write("L:BTN_TERRONND_ACTIVE","enum",1) will then do nothing because Air Manager thinks that the value is still 1.
Sim Innovation is aware of the problem but we will be able to use a new "executor code," in Air MAnager 4.2 to overcome this problem.

This problem is really annoying when the value is set by the sim itself, for example when the initial value is not 0.

There is a workaround:
executing another fs2020_variable_write() with a value outside the range of values for this LVar before the "real" fs2020_variable_write().
For example, the "L:BTN_TERRONND_ACTIVE" can have value 0 or 1.
So:
fs2020_variable_write("L:BTN_TERRONND_ACTIVE","enum",2) --(2 is not a possible value for this LVar)
fs2020_variable_write("L:BTN_TERRONND_ACTIVE","enum",1)

fs2020_variable_write("L:BTN_TERRONND_ACTIVE","enum",1) will work in all situations because AM now thinks that the previous value was 2.

It is not very elegant but it solves the problem for now.

Yves

User avatar
Crunchmeister
Posts: 222
Joined: Tue Aug 10, 2021 2:06 pm

Re: A workaround for the fs2020_variable_write() not always working

#2 Post by Crunchmeister »

It would be much better if it would just get fixed. This problem doesn't exist with Mobiflight, FSUIPC, or SPAD. This is a unique issue with Air Manager. Having to write extra workaround code of incorrect values can indeed fix it. So can editing aircraft files due to the claim this issue is due to vars not being properly initialized in the plane code. But neither solution is ultimately what I'd consider good.

But I'll definitely try this out on my panels as a workaround nonetheless to get rid of this annoying issue. Thank you for posting this. This is a much better solution than editing aircraft files to make Air Manager work with it.
- Ryzen 5950x, 64GB 3600MHz RAM, RTX3070Ti

Simstrumentation Instrument dev
Free Air Manager instruments for MSFS available at http://www.simstrumentation.com

User avatar
Corjan
Posts: 2936
Joined: Thu Nov 19, 2015 9:04 am

Re: A workaround for the fs2020_variable_write() not always working

#3 Post by Corjan »

Hi,


This is a very generic piece of the code, so I would rather not change it. I also think that this is a weird behavioir of FS2020, variables should be statefull, and shouldn’ do anything when you set it to the same value twice.

I will implement an API function to AM 4.2 where you can a direct execute code. This provides a method to issue an LVAR without the AM code intervering.


Corjan

User avatar
Crunchmeister
Posts: 222
Joined: Tue Aug 10, 2021 2:06 pm

Re: A workaround for the fs2020_variable_write() not always working

#4 Post by Crunchmeister »

The issue is specifically on multi-position switches. If the initial value isn't 0, the switch in AM won't work until it's:

1. toggled in the virtual cockpit first
2. some workaround like what Yves listed
3. What others have suggested as the solution - to edit aircraft files to initialize a var there first.

This is an issue that's unique to AM. AAO, FSUIPC, Mobiflight and Spad all handle this correctly.
- Ryzen 5950x, 64GB 3600MHz RAM, RTX3070Ti

Simstrumentation Instrument dev
Free Air Manager instruments for MSFS available at http://www.simstrumentation.com

User avatar
Sling
Posts: 5237
Joined: Mon Sep 11, 2017 2:37 pm
Contact:

Re: A workaround for the fs2020_variable_write() not always working

#5 Post by Sling »

It’s not just with multi position switches. It happens with 2 position ones too. I have been using my own workaround that doesn’t require out of scope values to be used and it works everytime. I agree though this should be happening inside of AM. I’m not sure another variable_write in the API is a good idea as it will require lots of instrument changes and a non standard way of writing just for LVARs. I urge an amendment to the existing fs2020_variable_write to solve this.

The variable state in FS2020 is being read correctly by AM if using a subscribe so it is indeed getting the right value it just doesn’t seem to be for the variable_write until you force it with a work around.

User avatar
jph
Posts: 2846
Joined: Fri Apr 10, 2020 12:50 pm
Location: Somewhere over the rainbow..

Re: A workaround for the fs2020_variable_write() not always working

#6 Post by jph »

Corjan wrote: Fri Dec 09, 2022 9:16 pm Hi,


This is a very generic piece of the code, so I would rather not change it. I also think that this is a weird behavioir of FS2020, variables should be statefull, and shouldn’ do anything when you set it to the same value twice.

I will implement an API function to AM 4.2 where you can a direct execute code. This provides a method to issue an LVAR without the AM code intervering.


Corjan
That appears to be a good interim solution as no doubt MSFS will offer other 'challenges' in the future.
As you say, the code is a generic base.
I suggest that you implement that and see how things go. If MSFS is 'corrected' in the future then it will do no harm.
In the meantime, the coding changes should be minimal and still allow a standardised API.
Reacting to every issue with msfs is not a good long term strategy as history tells us :shock:
Joe
Joe. CISSP, MSc.

Post Reply