• Which the release of FS2020 we see an explosition of activity on the forun and of course we are very happy to see this. But having all questions about FS2020 in one forum becomes a bit messy. So therefore we would like to ask you all to use the following guidelines when posting your questions:

    • Tag FS2020 specific questions with the MSFS2020 tag.
    • Questions about making 3D assets can be posted in the 3D asset design forum. Either post them in the subforum of the modelling tool you use or in the general forum if they are general.
    • Questions about aircraft design can be posted in the Aircraft design forum
    • Questions about airport design can be posted in the FS2020 airport design forum. Once airport development tools have been updated for FS2020 you can post tool speciifc questions in the subforums of those tools as well of course.
    • Questions about terrain design can be posted in the FS2020 terrain design forum.
    • Questions about SimConnect can be posted in the SimConnect forum.

    Any other question that is not specific to an aspect of development or tool can be posted in the General chat forum.

    By following these guidelines we make sure that the forums remain easy to read for everybody and also that the right people can find your post to answer it.

FSX:SE Lvar limitations XML/C++

Vitus

Vitus

Resource contributor
Messages
1,480
Country
newzealand
Hello friends,

I am currently running into a weird issue: if I compile my C++ project in debug mode, everything works fine. When I switch to Release, at least one of my L-vars doesn't work in one of the XML gauges. The variable in question is used both by an XML gauge as well as the DLL module. It gets set to a fixed value of 22 and won't change.

I ran into trouble with L-vars before and a previous solution was to get rid of some of them and taaaa-daaaaa, the rest behaves fine again. The weird thing now is that the problem only occurs when I compile a release version of the DLL. Does that make any sense to you?

My questions are: Is there a hard limit for the number of L-variables used in a project? If so, what is it?

Furthermore, how/why/when does an LVar ID get overwritten in the C++ module?
 
My questions are: Is there a hard limit for the number of L-variables used in a project?
Click to expand...
as far as I work with Lvars, and I have 1200+ lvars on single aircraft non of them have issue.
 
Hard to say what my count is. I use LVars for debug purposes and some of my objects generate a lot of them. So it's possible I am well over your count. Or not. I don't know...

Like I said, the really weird part is that it works when the DLL is compiled in debug mode. Make sense of that.... o_O
 
Chances are, if you check the ID of the L var in question, it is 0. This is a perfectly valid L var ID (sub zero is unregistered I believe). Somewhere in your code however, you are sending a 0 to the set_named_variable_value L var ID parameter, along with a 22.

The quickest way to debug is to attach the debugger (Release mode can be debugged), and put a break point next to any random set_named_variable_value call. Check the value of the L var ID being sent, and the variable value being sent.
Then open Visual Studio's disassembly. Press F11 to step through the ASM code until it switches out of your code to the panels.dll. Identify the registers containing your L var value and L var ID value, and put a conditional breakpoint in the panels.dll ASM code that only gets triggered when these registers are set to your L var ID value and L var value of 22. When it gets hit, check your call stack to identify which line of code in your gauge dll is causing the trouble.
 
You must log in or register to reply here.
Back
Top