Losing control of Lvars on Aircraft reload

[lequinne]

Hi,

We are building an aircraft carrier for P3Dv3 and 4, and it has static aircraft who's visibility is controlled by L:vars which I'm setting through a DLL, which is being loaded by the sim through dll.xml. The issue I'm having is that it all works fine when the ship is loaded after the airplane, but when the aircraft is then reloaded, I lose control of the ship static aircraft Lvars, their indexes seem to have changed, most of their values go to zero, a lot of times some don't, and so it goes. The thing is, I can't seem to find their indexes and regain control of them again after an aircraft reload. I've tried waiting for up to several seconds, then reloading all my Lvars, I've tried waiting, then using check_named_variable() to see if the boat Lvars exist (they do), I tried calling unregister_all_named_vars() when I receive the Aircraft Loading message, but try as I might, I can't seem to set their values through set_named_variable_value(). I even tried setting them all by string each time, i.e. set_named_variable_value(register_named_variable("my_var_name"), value); and this doesn't seem to work either... Are you guys able to offer any insight or guidance?

Thanks so much,
Farley

[JB3DG]

Try posting the modeldef.xml showing the L var used in the animation, as well as your register/check named variable calls.

[AlexisVGR]

The modeldef entries are visibility conditions, such as the one below:

<PartInfo>
<Name>cv41_stern_r</Name>
<Visibility>
<Parameter>
<Code>
(L:cv41_park7, bool)
</Code>
</Parameter>
</Visibility>
</PartInfo>

[lequinne]

Hi,
What I'm doing is running a 6hz simconnect update, and in that callback function, doing the following:

Code: Select all

double oldVals[110];
std::string strings[110];

void On6hzUpdate(){
		for (int i = 0; i < 110; i++){
			set_named_variable_value(register_named_variable(strings[i].c_str()), oldVals[i]);
		}
}

Where the oldVals[] and strings[] were loaded at SimConnect_Open, and have not been modified since. Each array index corresponds to one of Alex's variables as he posted above. They show and hide aircraft on the deck of a ship. I know the variable names and oldVals are correct, because it works correctly as long as the ship is loaded after the airplane. If the ship is loaded, and then the aircraft is changed, the behavior is "undefined" - usually an empty deck, sometimes a couple random planes. That's the issue as it currently stands. I've tried a large number of things, but I think that the above represents the purest distillation of my problem. Hopefully someone at LM is able to shed some light on this.

Thanks,
Farley

[JB3DG]

Something tells me the strings are giving you corrupted L var names. Where are those set up?

[lequinne]

CarrierConfig::CarrierConfig(){
Init();
}

void CarrierConfig::Init(){
strings[0] = "cv41_genvis1";
strings[1] = "cv41_genvis2";
strings[2] = "cv41_genvis3";
strings[3] = "cv41_genvis4";
//etc... all the way to:
strings[109] = "cv43_deck_lights";
}


Class is instantiated in DLLStart(), deleted in DLLStop()

Unfortunately, I'm not writing anything to the array at any other time. Also nothing else in my code takes any sort of special action in terms of allocating memory or writing to arrays (or actually does anything at all) on aircraft load. So it's difficult for me to imagine that I have a heap corruption thing going on.

Farley

[lequinne]

I will try dumping all the string names before and after aircraft load.

[lequinne]

No joy. I dumped the strings to a text file before aircraft reload (while it was working normally), and a few seconds after aircraft reload (when it's broken), compared the two files, and according to my hex editor, they are identical on a binary level.

[dsdawson]

I suspect that continually calling register_named_variable() is causing at least some of the heartache.
I would go with something like:

Code: Select all

void On6hzUpdate()
{
 for (int i = 0; i < 110; i++)
	{
	int k = check_named_variable(strings[i].c_str());
	if (k == 0 ) k = register_named_variable(strings[i].c_str());
	set_named_variable_value(k, oldVals[i]);
	} 
}

Doug

[lequinne]

Hi Doug,

Thanks so much for your reply. Unfortunately, I'm extremely reluctant to suspect the calls to register_named_variable(), as they weren't in my original code. I originally was doing it the normal way, i.e. calling register_named_variable() only in the constructor, at the same time as I set the strings. When I encountered this issue, I suspected that the sim was rearranging the Lvar indexes on aircraft reload. So I tried doing the register_named_variable()s at aircraft reload, then I tried doing it a couple seconds after aircraft reload, then I tried using check_named_variable() on a sample of the Lvars, and checking if they return -1 (not zero, as it turns out), and reloading then, and I also tried reloading after they started returning positive values. The samples seemed to go -1 for 1 cycle and then reappear, sometimes at their former IDs, sometimes changed. I wanted to make absolutely sure that it wasn't a matter of the sim's Lvar index order being changed (as I originally assumed it must be), and that it was a deeper problem than just the IDs, and that's why I switched to calling register_named_variable() every time.

The way I always imagined it, the sims L:Var implementation is simply an array-like container of string/value pairs, that one could lookup either via a string search, or by index. When you call register_named_variable(), it does a string search for the name, returns its index if it finds it, or pushes the string onto the back if it doesn't. This view is supported by the fact that when you call register_named_variable() with new strings, the ID returned is sequential.

My current pet theory (which may be completely wrong) is that the sim, for performance, is compiling and/or optimizing the .MDL xml scripts at load time, and in doing so is changing the (L:VAR,units) statement so that it is actually referencing the Lvar by INDEX rather than by performing a string search each time. To my mind, this theory is supported by the fact that it works perfectly if the airplane is loaded before the ship, but not vice versa. That is: because the Lvars reload only when the User Aircraft loads (more specifically when it unloads), and not when a new ship is loaded, the Aircraft MDL gets the latest Lvar indexes, but the ship MDL is stuck with the old ones. When I do my register_named_variable() calls again after aircraft reload, I of course get the latest indexes as well. That's why - according to my tests in a previous project - I am able to set Lvars on the user aircraft perfectly fine, as long as I call register_named_variable() on them after aircraft reload, but I am unable to get another simobjects MDL to read them. So that's my current theory, and unless I'm missing something major, I feel it fits the evidence well.

Unfortunately I can't currently think of a way to test this conclusively, much less work around the issue, if as I fear, my diagnosis is correct. I'm very much looking forward to hearing the thoughts and opinion of two of the greatest minds in flight sim addon development who have already commented, as well as *nudge nudge* someone from Lockheed Martin.

Ever discouraged,
Farley

[dsdawson]

I'm wondering if you might be better off using events to do this.
I really don't know very much about modelling, but I think you can trap events with MDL xml code. If so, you could use SimConnect to send custom events to move stuff around on the carrier.