Is there any way of telling what L: variables are being sent and when? - I have FSUIPC (paid), but I'm a bit of a rookie when it comes to stuff like this. Would this log/output what you need to confirm suspicions?
The issue is, this would be very difficult to troubleshoot with normal tools, because they always handle variables by name and you can be 100% we DO NOT use their name, the only variables we write to, are our own variables, which all starts with something like FSDT_xxxxxxx.
As I tried to explain, L: variables are never handled by their names, at least not when using the fastest and more native C++ methods ( you use their names in XML gauges instead ). When C++ program tries to use a variable, it first should ASK the sim if the variable is available and if it is, call a function to register that variable in the sim, which will return with a numeric ID, which is just a number. From that moment on, the name is not used anymore, to read or write to an L: variable, you give only the ID and the value.
When an airplane is unloaded from memory ( because you switched to another airplane ), all IDs used by L: variables created by that airplane are ( or should ) considered available again for other running modules to register. Since an airplane reload triggers a GSX complete restart, a conflict between IDs used by the airplane and those used by GSX should never happen, especially considering you are reporting something happening only when the cargo loaders start loading pallets, not during a GSX restart that happens while the airplane might still loading.
That was the reason for asking to *wait* for the airplane to finish loading and then restart GSX, but it didn't seem to make any difference, so it's not something that happens during a restart.
If the problem is really a conflict of variable IDs ( which again, should have been noticed years ago, and not just with a single airplane model ), and I don't see what else could be, perhaps some new undiscovered bug in the sim which is giving to us an ID that is already used by the airplane, it would be very difficult to troubleshoot with normal tools, which usually refers to variables by their names, unless you know of a tool which logs every possible ID continuously, to monitor of every change, so we might trace what's happening.
I guess that, if you try to troubleshoot this with a LUA script in FSUIPC, it might give you a misleading result of GSX trying to write to BOTH its own variable and the PMDG variable at the same time, when in fact what is *really* doing is writing only to its variable, because it trusted the sim the ID it was given back when it registered the variable was free to use.