Missing LVAR after 3066 Lvars loaded (since SU11)

[michel78320]

Hi,

Now, with FENIX A320, there are some missing lvars.
When listing Lvars, I have the message "Welcome to FSUIPC - 3066 Lvars loaded, 220 hvars loaded ...".

Some Fenix Lvars are missing !
It happens since last SU11 (new aircrafts).

Is there a solution to this problem?
Thanks in advance.

[John Dowson]

3066 is the maximum number of lvars supported by FSUIPC.
However, any single aircraft should not have that many lvars - many are probably either from the previous aircraft loaded, or aircraft sitting in your Community folder.
You can try restarting - using the same aircraft as the previous aircraft used after a restart may reduce this number of phantom lvars (i,e, from other aircraft), Otherwise, the usual procedure is to clear out ither aircraft that you are not using from your Community folder before starting MSFS, Many people use the MSFS Add-in Manager (freeware) to do this.

John

[michel78320]

Thank you for this information, which I had read in the documentation (FSUIPC7 History.pdf) : It is 3066 from version 7.3.5.

I fly with a community reduced to the minimum. However, I need the planes that my friends use in network flight : A320 (Fenix and FSW), B747 from Salty).
Otherwise, I don't see them with the right type of plane.

Indeed, from one launch to another, the number of Lvars  changes and generally remains less than 3066 Lvars.
I used the Wasm.ini option to delete LVars at launch, but as indicated in the documentation, this does not seem effective.

In order not to be obliged to launch and restart the simulator, would it be possible (in a future release) to have an option to choose this maximum number of LVARS, or directly 4.000 ?

[John Dowson]

21 hours ago, michel78320 said:

In order not to be obliged to launch and restart the simulator, would it be possible (in a future release) to have an option to choose this maximum number of LVARS, or directly 4.000 ?

No, sorry, I will not be increasing this number for the time being (for various technical reasons. This is really an MSFS issue - it should only provide lvars that are in use with the current aircraft. Try raising a bug report to Asobo...hopefully they will fix this at some point, and the more people that complain the better the chance of this getting fixed.

Note that you can still set/change lvars that are not known to FSUIPC by using calculator code, but you will not be able to read the value.

John

[michel78320]

OK. I fully understand your point of view.
Thank you for these explanations.
Now I understand better why my Lua scripts sometimes have problems, mainly in reading lvars.
Using Calculator code works even if LVars are not known, it's good to know that.

have a good day. 🙂
Michel

[John Dowson]

2 minutes ago, michel78320 said:

Now I understand better why my Lua scripts sometimes have problems, mainly in reading lvars.

When using/reading  lvars in lua, you  can check that they exist before trying to read them as follows:

id = ipc.getLvarId("L:myLvarName")
while id == nil do
    ipc.reloadWASM()
    ipc.sleep(100)
    id = ipc.getLvarId("L:myLvarName")
end
-- Lvar now available!

Of course, the while loop would never end if the lvar doesn't become available, so you may also want to add a counter and exit the script (or do something else) if the lvar doesn't become available after a fixed number of attempts.

John

[FlyingDutchman77]

On 11/13/2022 at 2:22 PM, John Dowson said:

Otherwise, the usual procedure is to clear out ither aircraft that you are not using from your Community folder before starting MSFS, Many people use the MSFS Add-in Manager (freeware) to do this.

Hi John, although I understand your suggestion, this is becoming increasingly more difficult with the increasing amount of Marketplace aircraft that cannot be used with Addon Manager very easily.... The limit is really becoming an issue now. Just for understanding, could you explain maybe a bit with this limit is there?

[John Dowson]

It is for technical reasons in how the lvar names and values are passed from the WASM to FSUIPC (via the WAPI). I could increase this (would involve an update of the WASM and WAPI), and have already done this once (from 2044 to 3066) quite recently, in version 7.3.5 released 29th May. I may consider increasing the  maximum limit again, but not at the moment. I don't want to be increasing this every 6 months if the number of  available lvars keeps increasing like this. MSFS should only provide the lvars for the aircraft currently loaded - the rest are just noise.

John

[Moderate Chop]

John,

It seems with SU11, based on a couple of quick tests, that we've reached somewhat of a conundrum with MSFS LVARs and FSUIPC.

The iniBuilds A310 in SU11 loads ~2800 LVARs all by itself.  Using Add-ons Linker, I can 'unlink' the A310 folder from the sim, but the next time the sim starts it forces a mandatory update that re-installs the A310.  A workaround seems to be to actually uninstall the airplane from within the sim - MSFS seems to respect your decision to uninstall, and doesn't force a re-install.  Needless to say, this is less than ideal.

My one other Marketplace airplane, the Aerosoft CRJ, loads ~1575 LVARs.  So if I have just these two airplanes active, I'm well over the 3066 limit.

As you say, MSFS should only provide LVARs for the currently loaded aircraft.  And those of us who use FSUIPC can certainly raise this issue with Asobo.  My concern is that this is so far down their priority list that it will not be addressed in the near future, if at all.  [I would note also that it's not just aircraft that load LVARs - GSX, for example, loads ~60]

I certainly don't expect you to provide a workaround for Asobo's LVAR implementation/architecture decisions.  I was just poking around and thought I could shed a little more light on the scope of the problem.

Cheers,

Eric

 

[John Dowson]

10 hours ago, Moderate Chop said:

t seems with SU11, based on a couple of quick tests, that we've reached somewhat of a conundrum with MSFS LVARs and FSUIPC.

The iniBuilds A310 in SU11 loads ~2800 LVARs all by itself.  Using Add-ons Linker, I can 'unlink' the A310 folder from the sim, but the next time the sim starts it forces a mandatory update that re-installs the A310.  A workaround seems to be to actually uninstall the airplane from within the sim - MSFS seems to respect your decision to uninstall, and doesn't force a re-install.  Needless to say, this is less than ideal.

My one other Marketplace airplane, the Aerosoft CRJ, loads ~1575 LVARs.  So if I have just these two airplanes active, I'm well over the 3066 limit.

You should not uninstall default aircraft, as they will get re-installed the next time that you restart. There is no need to do this..
The problem with lvars, especially with default aircraft, is that the lvars from the previously loaded aircraft are still available. If I load the A310, I get the max of 3066 lvars, and this is with the Aerosoft CRJ, FBW A320, PMDG 737, JF PA28, Flying Iron Spitfire and several more aircraft in my Community folder. If I then switch to the C171, I still get 3066 lvars. However, if I then exit and restart MSFS, use the same C172, I only get 150 lvars.

So, the solution at the moment would, when switching planes, first switch planes in MSFS, then exit and restart, and you should see the number of lvars reduce substantially.
Can you try this as well to see if you see the same behavior?

Cheers,

John

[michel78320]

4 hours ago, John Dowson said:

So, the solution at the moment would, when switching planes, first switch planes in MSFS, then exit and restart, and you should see the number of lvars reduce substantially.
Can you try this as well to see if you see the same behavior?

Thank you for the explanations.
Your solution is exactly what to do.

I loaded MSFS with the HPG-145 and I had its Lvars.
I leave MSFS and run it again with the A320 : the HPG-145 Lvars are still there.
I leave MSFS and run it directly with the A320 : the HPG-145 Lvars have disappeared.

 

[Moderate Chop]

Ah, yes indeed, this is the behavior.  Selecting an airplane and then restarting seems to load only that airplane's LVARs, in addition to ~100-115 that always load on my system for various other things.  This includes GSX (~60), the new SU11 Beaver (~11), a collection of 'XMLVAR...' entries, etc.

To your comment above re: airplanes in the Community folder, this does not seem to be an issue, at least on my system.  With a full collection of PMDG, Fenix, JustFlight, Maddog, etc., all enabled, I don't see any LVARs loading that shouldn't.  So that's something.

With respect to "any single aircraft should not have that many lvars...", I think iniBuilds has taken that as a challenge!  Loading the A310 using the 'restart' technique still results in 3066 LVARs.  And yes, this is at least 2900+ unique to the airplane.  If the 'ID=nnn' in the log list is an indication of load order, then yes, FSUIPC is still reading 'A310_' LVARs when it runs out of room.  So far I think I have what I need to assign hardware, but I'm only a little ways into modifying my scripts.

Thanks for your insights!  I've again learned new things about how MSFS works.

[NovemberUniform]

On 11/21/2022 at 12:52 AM, Moderate Chop said:

As you say, MSFS should only provide LVARs for the currently loaded aircraft.  And those of us who use FSUIPC can certainly raise this issue with Asobo.  My concern is that this is so far down their priority list that it will not be addressed in the near future, if at all.

That's my concern, as well. I don't have high hopes they come to this in the foreseeable future, with all the stuff they are working on. Are they even aware of this? They have a voting system, as far as I know. Is there already a thread I could upvote?

Not knowing any of the internals, I ask myself, what consequences it would have to increase the number of accessible LVARs in FSUIPC / WASM module to a limit, that can hardly be reached in the future, like factor 10 of what we have now (please don't shoot me for writing this 🙈). Is this even possible? Would it impact performance?

It's good to have a work around with restarting the sim for the time being. Thanks for the info. I just came across this issue when the A310 arrived and I flew something else than just the Fenix A320. 

[John Dowson]

20 minutes ago, NovemberUniform said:

Not knowing any of the internals, I ask myself, what consequences it would have to increase the number of accessible LVARs in FSUIPC / WASM module to a limit, that can hardly be reached in the future, like factor 10 of what we have now (please don't shoot me for writing this 🙈). Is this even possible? Would it impact performance?

This is a technical issue in the way that I have implemented the passing of lvar/hvar names from the FSUIPC WASM module to FSUIPC (using the WAPI - the WASM Application Programming Interface). This is really quite technical... all lvar names are passed across in Client Data Areas (CDAs), which have a maximum size of 8K. Therefore, the maximum number of lvar names that can be sent in this area depends on the size (number of characters) in the lvar name. And the number of lvars handled depends on the number of these CDAs that I enable. The 2nd restriction is on how the lvar values are passed. All lvar values are passed in each update (whatever that is designed to be). therefore there needs to be enough space for the value CDA's to hold the data for the number of lvars available. 

These things are changeable up to a point.... Currently, these are the sixes defined for the WASM/WAPI interface:

#define MAX_VAR_NAME_SIZE		56 // Max size of a CDA is 8k. So Max no lvars per CDK is 8192/(this valuw) = 146
#define MAX_CDA_NAME_SIZE		64 
#define MAX_NO_VALUE_CDAS		3 // Allows for 3*1024 lvars 
#define MAX_NO_LVAR_CDAS		21 // 21 is max and allows for 3066 lvars - the max allowed for the 3 value areas (8k/8) is 3072
#define MAX_NO_HVAR_CDAS		4 // We can have more of these if needed

So, the maximum size I allow for an lvar name is 56 characters, As each CDA is 8k, this means I can pass (8*1024)/56 = 146 lvar names in each CDA.  I am currently allowing 21 lvar name CDAs, which allows for 21*146 = 3066 lvars. The number of CDAs for the values of these lvars is then sized accordingly, so each lvar CDA can support 1024 lvars (8k per CDA, 8bytes per value). and so 3 lvar value CDAs are needed to support 3066 lvars (although they can support i[ to 3*1024v = 3072 lvars if needed).

The way this was implemented was done after trialing various different mechanisms, including using one CDA to pass lvar names repeatedly, and another to pass values. However, there are various issues with this as you have to consider multiple clients connecting at different times, and the data must be consistent with all clients, regardless of the time they connect, and also regardless of other clients using the WASM facilities (the WASM provides an API and can be used by many clients at the same time).

If you need further information on this, the WAPI is open source (available on GitHub) and you are welcome to take a look and suggest any improvements.

John

[Fragtality]

Hello John,

the Limit is becoming more and more an Issue. Users have to specifically control that MSFS is started with the Plane they want to fly, just to access a small portion of the Lvars via FSUIPC. 

Are there Plans to implement another Method of accessing Lvars? For Use-Cases like my StreamDeck-Plugin, I don't need to know and access every Lvar that exists. It would suffice enough to just "subscribe" (dynamically!) to the Lvars it currently needs and only these would then be transmitted via WASM, especially though the CDA-Bottleneck.

Sure it is very handy to scan/see all available Lvars for Debugging/Development ... but which "normal" Use Case does need access to 3066 Lvars in parallel?! A Subscription-based Model would be much more efficient and the Limit of 3066 would only be experienced in very specific and rare Cases.

It is really annoying to restart MSFS just because you want to load another Plane and that for the sole Reason so "FSUIPC does not get confused".

[John Dowson]

No, there are no plans to implement another method or to increase the number of lvars available.
What you suggest may be ok for you, but not for the vast majority of FSUIPC users. How would you even know what lvars are available if FSUIPC couldn't list them? I would receive a lot of support requests if this was the case...

As I keep saying, the problem here lies with Microsoft / Asobo. I suggest you raise a ticket/bug report with them, saying that all lvars from a previous aircraft should be cleared before loading the lvars for a new aircraft, and the ids re-used. This would solve the issue.

FSUIPC doesn't get confused, and you don't need to restart FSUIPC. It is the WASM module that asks/scans for lvars by id using the Gauges API, and it is this scan that is returning the lvars from the previous aircraft.

Note also that lvars don't have to be known by FSUIPC to use/write to them - you can use calculator code for that. However, they do have to know by FSUIPC if you want to read them (including adding them to offsets),

John

[Fragtality]

25 minutes ago, John Dowson said:

No, there are no plans to implement another method or to increase the number of lvars available.
What you suggest may be ok for you, but not for the vast majority of FSUIPC users. How would you even know what lvars are available if FSUIPC couldn't list them? I would receive a lot of support requests if this was the case...

I was thinking of two different Modes - the current "Full Scan" Mode if there is Need to see (explore) all Lvars. And a second "Subscription" Mode which only transfers the Lvars requested by any Client (whether it is the UI, a Lua Script or the C# Client). For the Fenix and the FBW for Example I don't need FSUIPC to know the Lvars. They can be looked up in a File / the Homepage. So it can be known in Advance without the need of doing a "Full Scan".
I'm also getting support requests because my Plugin is not working (although FSUIPC has the Issue) and I don't see any money for my Software.

Please give me one Example of that vast majority.

 

25 minutes ago, John Dowson said:

As I keep saying, the problem here lies with Microsoft / Asobo. I suggest you raise a ticket/bug report with them, saying that all lvars from a previous aircraft should be cleared before loading the lvars for a new aircraft, and the ids re-used. This would solve the issue.

I highly doubt MS / Asobo will ever improve this because some Application wants to transfer all Lvars via CDAs ... It is not really a Bug or Issue that needs fixing on their Side.

 

25 minutes ago, John Dowson said:

FSUIPC doesn't get confused, and you don't need to restart FSUIPC. It is the WASM module that asks/scans for lvars by id using the Gauges API, and it is this scan that is returning the lvars from the previous aircraft.

I did not say restart FSUIPC. That would be somewhat bearable. It is restarting the whole Sim.
Yeah right, FSUIPC is not confused ... it is Users wondering and troubleshooting why XY does not work anymore.

 

25 minutes ago, John Dowson said:

Note also that lvars don't have to be known by FSUIPC to use/write to them - you can use calculator code for that. However, they do have to know by FSUIPC if you want to read them (including adding them to offsets),

I know. But just writing an Lvar without the need to ever read it is very very seldom.

 

 

So in the End my Plugin-Users and I are between a Rock and a Hard Place. I guess I have to evaluate if writing a dedicated SimConnect-Client/WASM-Plugin for my Plugin is an doable Option ...

[John Dowson]

24 minutes ago, Fragtality said:

I was thinking of two different Modes - the current "Full Scan" Mode if there is Need to see (explore) all Lvars. And a second "Subscription" Mode which only transfers the Lvars requested by any Client (whether it is the UI, a Lua Script or the C# Client).

This would involve a huge amount of work, on FSUIPC, the WASM and the WAPI. And as I don't see any value in this for me (i.e. more sales), it is not going to happen. There are many other more useful things I could be doing that would provide far more value to the vast majority if users. However, the WAPI is open source, and I will also open source the WASM, so you are welcome to implement yourself...if you did this, I would consider using this in FSUIPC. However, I am not sure how I could implement two different lvar access methods in FSUIPC - I would have to think about that.... 

I will consider making the current method more flexible in the future (no guarantees when), i.e. allow the user to define how many lvars they want to support via WASM (and possibly WAPI) ini parameters.

28 minutes ago, Fragtality said:

Please give me one Example of that vast majority.

Strange question....me!

29 minutes ago, Fragtality said:

I highly doubt MS / Asobo will ever improve this because some Application wants to transfer all Lvars via CDAs ... It is not really a Bug or Issue that needs fixing on their Side.

Well, I disagree here. The Gauges API even provides a function for this - unregister_all_named_vars, although the documentation for that references token variables,, not named variables (i.e. local variables or lvars) - the other 'named variable' functions reference lvars (e.g. get_name_of_named_variable). I have tried using this but to no avail. There is also unregister_var_by_name  but I haven't looked into this.

50 minutes ago, Fragtality said:

It is restarting the whole Sim.

I don't see a problem with this, and I think most advanced users, especially those with home cockpits, tend to concentrate on one aircraft, or maybe a small subset, and don't have any issues restarting if/when occasionally changing aircraft.

52 minutes ago, Fragtality said:

guess I have to evaluate if writing a dedicated SimConnect-Client/WASM-Plugin for my Plugin is an doable Option ...

You can do that, or you can update the FSUIPC WASM / WAPI for your needs if you like and use that (I cannot guarantee that I will use such updates in FSUIPC).

I have nothing more to say on this and do not want a prolonged debate on the issue - I consider this closed. If you want access to the WASM code before I open source it (make it public), you can PM me your email and I will send you a github invite.

John

[Fragtality]

Me neither 🙂 (on having a prolonged debate)

But just one last Question: Why did you not open a Bug-Report for that? Your Voice has another "weight" and you have far more expertise on explaining the Issue.

[John Dowson]

1 hour ago, Fragtality said:

Why did you not open a Bug-Report for that?

I gave up registering bug reports...I raised many in the early days and got nowhere with them (no response except something like 'issue closed'), and no way to track or see any progress. Although most (if not all - difficult to track) now seem to be resolved. Things may have improved, but I will ask about this on the developers channel - I seem to get more response from Asobo through that. I will also try with unregister_var_by_name, but the documentation for that one says "...unregisters a named variable from another gauge..." so I don't think that will do the trick anyway. But I will have a play around and raise this issue with Asobo - although I may have already done this but not sure.

Seen your PM - will look into this early next week - need to do/check a couple of things first...suggest you start by looking at the WAPI source if interested in updating this as that will give you an idea of what needs updating on the client side.

Will PM you on Monday or Tuesday once I have given you access to the WASM. Weekend off for me this weekend!

Cheers,

John

[Fragtality]

Great, Thanks 🙂

I've opened an "Idea" on the DevSupport 😃

https://devsupport.flightsimulator.com/idea/14234/clear-aircraft-lvars-after-unload-of-that-aircraft.html

[John Dowson]

9 minutes ago, Fragtality said:

I've opened an "Idea" on the DevSupport 😃

https://devsupport.flightsimulator.com/idea/14234/clear-aircraft-lvars-after-unload-of-that-aircraft.html

Ok, I will add a comment with more info to that....

[Clamb]

I'm currently running into the same issue.
For now I'll add a notification to my application to warn the user (and me) that some LVARs are missing.

[John Dowson]

10 hours ago, Clamb said:

I'm currently running into the same issue.

As explained in this post, if you get 3066 lvars loaded it is best to just restart MSFS with the aircraft loaded that you intend to use, and you should see the number of lvars reduce.

[Clamb]

Apparently the iniBuilds A310 uses more than 3066 LVARs.

I did the following:
1) Start a flight with the A310
2) Close MSFS
3) Launch MSFS
4) Select a departure aerodrome in the main menu and start the flight

This already results in 3066 LVARs being loaded.

 

I also noticed that PMDG does not create all LVARs when the aircraft is loaded, but some are only created when they are not 0 anymore.
For example, all EGPWS Callout Lvars in the PMDG 737 only come into existence when the event is trigger. Like "egpws_baba" for the bank angle voice alert.
Of course, this is not a bug by your WASM module, but has to be taken into account when working with them.