register_named_variable returning 0

[JB3DG]

Has anyone had this happen? Any ideas why it happens?

It is rather annoying for me because the L var in question is the one which controls my GPU cart visibility and the result is when I click on my navigation mode knob the GPU appears when it hits the first position.

 

[DragonflightDesign]

Yes. I had two variables with the same name e.g.

xVarOne=register_named_variable("VarOne");
xVarTwo=register_named_variable("VarOne");

Or maybe it was the other way round?

xVarOne=register_named_variable("VarOne");
xVarOne=register_named_variable("VarTwo");

Sorry Jon - all I remember is that it was one of these!

 

[JB3DG]

Well....In my case, the L var is used in both the VC and the external model. Thing is, I can call register_named_variable on an already registered variable and it will behave the same way as check_named_variable and return the existing variable's ID. So I don't quite understand what is happening.

 

[ddawson]

Is there any possibility that this is the first LVar registered?
What happens if you pass a value of zero to get_name_of_named_variable()?

 

[JB3DG]

It definitely isn't the first L var registered by my gauge.

I get all sorts of unpredictable behaviour when I send an ID of 0.

 

[MacFarland Masterton]

I was having some problems like this and I think I was able to trace all of them to register_named_variable not actually being called before the id was used... I eventually did two things: 1) added a logger to my Lvar wrapper class which logs all variable names and IDs returned as they are registered, and 2) initialize all the IDs to -1 and pop up a MessageBox if I try to use a -1 ID.

Here's the simple logger:

#pragma once
#include <fstream>
#include <string>

class Lvar_Debug_Generator
{
std::ifstream file;
std::string str;
bool noWrite;

public:
Lvar_Debug_Generator(const char *filepath) {
std::ifstream test(filepath);
if (test.is_open())
noWrite = true;
else {
noWrite = false;
file.open(filepath, std::ios::trunc);
}
};
~Lvar_Debug_Generator() {file.close();};

void AddLvar(const char *name, int id) {
if (noWrite)
return;

str = name;
str += "\t";
str += std::to_string(id) + "\n";

file << str;
}
};


You can instantiate this globally and then add a call to AddLvar() either in the appropriate places in your Lvar wrapper class or within the register_named_variable macro itself. I think the output may be revealing... All the Lvars in your gauge should appear sequentially, and be ID'd sequentially, unless they have first been loaded in the VC and/or external model (in which case there may be non-sequential IDs). If the output shows you are actually getting Lvars with different names assigned to the same id... then that's highly interesting and I'd very much like to see it, and my first instinct would be to suggest that perhaps someone is unregistering Lvars somewhere - according to my tests, any module which calls unregister_all_local_variables will screw things up for everyone else.

Farley

 

[JB3DG]

Hi Farley

I am not getting a -1 for my GPU L var when I try to register it. I get a 0. No other L var gets a 0 id in my list that I can detect. So not sure it is the same issue. And also pretty sure I have nothing on my sim calling unregister_all_local_variables. And all the IDs are appearing non sequentially in my ID array which I loop through when registering (which is sort of unsurprising since they are all in the VC and/or the external model).

 

[MacFarland Masterton]

Hmm... That is interesting. What is the ID of the navigation mode knob which is conflicting with it?

 

[JB3DG]

260

 

[MacFarland Masterton]

Hmm that's wild. I feel like there must be something else at play here... :/

 

[MacFarland Masterton]

In your model(s) is the GPU L:var inside a <visibility> or <animation> tag? They are loaded differently by the sim...

Edit: And I assume that the gauge is loaded/unloaded with the aircraft? Or is it run from dll.xml?

 

[taguilo]

Jon,

-You register many LVars at once in the same routine -the one with problems incuded-, then you read some of those vars and values are OK, then you read that one and is always 0.

If that is the case, just include a basic XML test gauge right above your gauge entry in panel section of reference, and read the LVar value there.

-Value is coming in 0 to your gauge. Problem is outside of your gauge.
-Value is coming -1 to your gauge (after being detected in the previous step), in the same panel_service where you register the variable, change its value to any other number, then check what is coming in the routine where you are currently inspecting it. Also check its value again in PANEL_SERVICE_DISCONNECT and see what if the new value remains.

Just my 2 cents.

Tom

 

[JB3DG]

@Farley the L var is in a viz tag. The gauge is loaded/unloaded with the aircraft from the panel cfg.

@Tom It is not the value that is 0. It is the ID returned by register_named_variable/check_named_variable that is 0. The problem I am having is that if I set my nav mode knob L var to 1, the GPU L var gets set to 1 as well, and when I try to set the GPU L var to 0 I get no response.

 

[MacFarland Masterton]

Another question:
When you click on the navigation mode knob, does the navigation mode knob also function/change position as well as the GPU? or does it fail to function?

Unfortunately I can't claim to understand what's going on here. I've had somewhat similar difficulties with <visibility> Lvars (which, unlike <animation> variables, get loaded as indices rather than strings) - but only on models and DLLs whose lifetime extends beyond that of the user vehicle. I'm still tempted to think that it may be something outside of the sim itself (i.e. in your gauge - something like the ID of the nav mode knob having a scope issue or something. But if that's done in xml, then probably that's not it...) But I'm very curious and will run some tests of my own and see if I can duplicate the issue.

In my own experience I have not found the zero index to be inherently problematic - it's only become "problematic" when it revealed my use of other unregistered (therefore still 0) Lvar indices. However, if that's incorrect, then something which could solve your immediate problem, albeit in an ugly way, would be to put an un-evaluated "dummy" Lvar in the visibility script ahead of the GPU L var. Something like:

(L:zeroIndexedLvar,bool) (L:GPU_visible,bool)

Or if the sim is smart enough to ignore the unreferenced variable (which I highly doubt) then something like:

(L:zeroIndexedLvar,bool) 0 * (L:GPU_visible,bool) or

The idea being that the unused "zeroIndexedLvar" gets assigned to the problematic zero index, and "GPU_visible" gets shifted to 1.

If they're switched, then:

(L:GPU_visible,bool) (L:zeroIndexedLvar,bool) 0 * or

You get the point. It's ugly - and any change to the modeldef and/or model is likely to break it. But it's the only thing I can think of at the moment. Let me know if you figure it out - after my own battles with the L:var system for the SimWorks carriers, I (apparently wrongly) thought I had it 100% nailed down, so I'm very curious about this one...

Anyway, that's a lot of talk for practically no actual help. My apologies.
Farley

P.S. There are a couple other things you can try, which also may possibly shed some light:

1) Try Re-registering the nav mode and GPU Lvars every time you use them.

2) Try setting them using execute_calculator_code() with 1 or 0 as part of the string.

 

[JB3DG]

The navigation mode knob functioned perfectly.

Thanks for that dummy var idea...It does look like it will solve my problem should it arise again. The frustrating part is...The issue has suddenly resolved itself. So I don't know what to think.

 

[MacFarland Masterton]

Ahhh roger, that's definitely frustrating! Please let me know if you're ever able to gain further insight into what it was...

Farley

 

[JB3DG]

Willdo.

 

[JB3DG]

Found the problem. It sure was a sneaky one. I have an enum list of all the L vars I use. That way, I can just call LVS(lvid[STEER_MODE], 1) (with LVS being my redefinition of set_named_variable_value). However, in my nav computer code I was referencing an enum called HSI_TF_FLAG. I fell into the Intellisense trap. There are other enums in my enum list that start with HSI_ and as I result I forgot that I didn't have such an enum. HSI_TF_FLAG has a value of 853, when my max L var count is 353. The space of memory being referenced there just happened to be 0 and as a result, it would get set to 1 from another part of my code when steer mode happened to be 1.

 

[MacFarland Masterton]

Aaaah, sneaky indeed. That explains why the Lvar initialization log didn't catch it. Didn't occur to me that it could be something else changing due to the nav mode knob, rather than the knob itself. Glad you found it, and thank you very much for the report, it's good to know the Lvar system is still intact, and we're not all going crazy!

 

[JB3DG]

Yep. This is one of those times knowing assembly comes in handy. Had to bring up the assembly view in VS, go to the set_named_variable_value address, and put a conditional break point at the line where the ID value is evaluated. It would break only when ecx (the register in this case) was 0, indicating an ID value of 0. Then by checking the callstack I could trace which line of my code was offending. Hope this tidbit will come in handy in other areas.