FSX:SE Lvar limitations XML/C++

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?
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


Resource contributor
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.