FSDreamTeam forum
Products Support => GSX Support FSX/P3D => Topic started by: Qantas747 on September 09, 2021, 08:37:24 am
-
Hi,
After updating to the latest version of GSX, for some unknown reason my aircraft VC changes from the 77W to the 77F VC. Video here: https://drive.google.com/file/d/1GnhDLgKIlmtfadOW2P_AqNdmz2An0KxO/view?usp=sharing . Is the new update broken?
-
Your video is so blurred and cut parts, which is impossible to even being to understand what your problem is. Please use a proper video capture software and clearly explain what's happening and why you think it has anything to do with GSX.
-
Okay, firstly you must be either sitting 50 meters away from your screen or you're not watching the video. It clearly shows the air conditioning panel changing to the 777F variant and the cockpit door also removes to a curtain once I select boarding using GSX. This started happening when I installed the new update from yesterday...
-
Okay, firstly you must be either sitting 50 meters away from your screen or you're not watching the video.
I don't know what you are trying to say here but, nothing in that video is "clear", not because I'm blind, but because I have no idea of what is happening and several menus are CUT OUT from the video so, I don't know what you are doing and, more importantly, your description of the problem was so vague, that I couldn't possibly know WHAT I need to look for.
It clearly shows the air conditioning panel changing to the 777F variant and the cockpit door also removes to a curtain once I select boarding using GSX. This started happening when I installed the new update from yesterday...
Sorry, but that's not very clear, at all. You are frantically selecting GSX menus and, because the video is cut, I can't see if there are messages on screen. So, again, make a video with a proper video capture software, try to be slower, and try to make it clear what's happening to the plane.
-
Okay, here is a video recorded using shadow play. As shown in the video I selected deboarding and the issue still happens. Note how its changing between panels from the 77W to the 77F. I used time accel to speed up the process. https://drive.google.com/file/d/1Ewbmbi2mCTS9RkrUZP-3dV4eUCMGHk_9/view?usp=sharing
-
Ok, now I understand. So, the next missing information from you would be:
- Which airplane is that, exactly ? Who made it ?
- Is already supported by GSX, or you made a configuration file for it ? A screenshot of the GSX airplane configuration page might be useful, together with the name of the airplane main folder, the one that contains the aircraft.cfg file.
-
Okay so I am using the PMDG 777-300ER. It only happens on the PMDG 777-300ER. The aircraft is supported by PMDG. I edited what containers go into the aircraft and changed the PALLETs that get loaded into the aircraft in the aircraft config page. Sorry I am a bit confused in what pictures you need. Just the one I attached?
-
Yes, that's the picture, it's all default and the plane is supported by GSX internally. Are you able to recognize the exact moment in which the VC changes ?
-
Hi, the issue occurs when the first container/pallet gets loaded onto the loader machine.
-
Upon further researching all the affected cockpit parts in the PMDG virtual cockpit have the visibility condition "custom_vis_IsFreighter_01" So it seems GSX is triggering that variable when the first container is loaded on the loader machine.
-
Upon further researching all the affected cockpit parts in the PMDG virtual cockpit have the visibility condition "custom_vis_IsFreighter_01" So it seems GSX is triggering that variable when the first container is loaded on the loader machine.
I can assure you nothing in GSX triggers that variable. The only PMDG variables used by GSX, are only used to read their status ( to know if doors are opened or closed ), but we never write anything on 3rd party airplanes.
-
Okay so why is it when the container goes on the loader, it triggers that variable? Here is another video showing both views. https://drive.google.com/file/d/1Ywzii74miUk6bTg4DZz0Uyn9erUEN8Fu/view?usp=sharing
It clearly has to be GSX causing this.
-
Hi Umberto, I can confirm I also have this issue, occuring only with GSX
-
It clearly has to be GSX causing this.
That's not sure. What is sure, is that GSX doesn't contain any reference to that variable anywhere in its code, this is not really open to discussion.
But something like this is still possible with L: variables because, they way they work, they are linked to a numeric ID, which can change during the simulation, usually when the airplane model is changed, which triggers a complete GSX restarts so, it would be impossible to have a conflict between IDs, since all variables used by GSX are being registered again with the sim after a complete restart.
GSX always checks with the sim if an ID is already used, before trying to register one of its own L: variables it needs to write to, but every other add-on should do the same, to prevent these conflicts. We don't do it before *each* write, because we used lots of them for animations, and asking the sim if a variable ID is available continuously would likely cause stuttering in animations and, during those years GSX has been out, we never had any problems of conflicting variables with different names ( which can only be caused by conflicting IDs ).
In fact, so many 3rd party airplanes use a large number of custom variables for visibility or animation, if this was a problem in GSX, it should happen with every airplane, at least those that use custom L: variables.
-
Well if it doesn't have anything to do with GSX, why does it occur after I've recently updated your program??? It was working fine and now its not. Sticking your head in the sand and saying no issues here, nothing needs to be fixed is really not the solution here.
-
Well if it doesn't have anything to do with GSX, why does it occur after I've recently updated your program??? It was working fine and now its not
Nothing in the latest update changed anything in the handling of L: variables.
Sticking your head in the sand and saying no issues here, nothing needs to be fixed is really not the solution here
And what kind of comment is that ?
Nobody is "sticking the head" anywhere and you should really stop making this kind of comments, because they are offensive and not related in ANY way to my reply.
NOWHERE I said for sure there's nothing to be fixed in GSX, YOU are the one that is being drawing conclusions without getting all the facts first. You couldn't possibly know if GSX tried to write that variable, I can but, nowhere I said nothing can or should be fixed in GSX because, again, before being "clearly" sure of something, I need to check facts first.
Fact it never happened before, doesn't mean it could never happen because, it also depends on what the airplane own code does to be sure those variables IDs are still valid when they are used.
I already explained GSX does when registering a new variable for it own use, but it doesn't continuously before trying to write to it, because this might cause stuttering during the animations, and this always worked so far, because ID usually change only when the airplane is reloaded.
Has been the PMDG 777 recently updated ?
Maybe, we just got lucky there weren't any conflicts before because, if the issue is really a conflict of IDs ( that's the only thing I can think of, because WE DON'T USE THAT VARIABLE BY NAME!! ), it might have happened before as well, but perhaps a change in the number of custom L: variables in the airplane would expose a conflict that was always possible.
-
The 777 has NOT been recently updated. My guess the last update came out 4-5 months ago.
-
Has been the PMDG 777 recently updated ?
Last update was March 19th, 2021.
-
Is this happening only with the ER version, or even the base LR version ?
-
I have the same issue. I have just tried three different scenarios including the base product as well as the extension both -200ER and -300ER. The issue has only persisted on the -300ER version of the aircraft.
-
The issue has only persisted on the -300ER version of the aircraft.
Is the -300ER version the only one that has a VC that can "morph" between two versions ?
I'm asking because, the 777 is the only PMDG product I don't own in P3D, I bought the FSX version, but decided to pass on the P3D version, because it didn't feel having to purchase it again without even a small discount ( I guess we are the only fools that allowed users that bought GSX in 2012, to use still use it with the same license in P3D V5 and PBR, 9 years later ) so, if I need to buy the 777 just to check this problem, I wanted to know if it also happens with the Base product, or only with Expansion.
-
Indeed that seems to be the case. I have restarted the simulator for each scenario and only the -300ER version experiences the VC "morth" only in the overhead for the air conditioning and fire protection systems. I havent experianced any issues with the other versions, everything seems to run smoothly.
-
Hi Umberto,
It only happens with the 300ER. I tried with the 77L and 77F and they work perfectly
-
I have the -300ER in v5, just tested, and yep sure enough as soon as the pallets start getting loaded into the plane the overhead and door changes, exactly as in the video.
Very strange!
-
I have the -300ER in v5, just tested, and yep sure enough as soon as the pallets start getting loaded into the plane the overhead and door changes, exactly as in the video.
Yes, it's strange and, the only explanation I have, is a conflict with L: variables IDs, since I'm 100% sure there's nothing in the GSX code that ever tries to write on another airplane own L: variables.
Which is strange, since if this could happen, it should have happened years ago, with many other airplanes too, since lots of them use L: variables for everything that is not a standard animation, and PMDG sure always used many of them, so it's strange this is only happening now, with only a single variation of a model.
Does it happen if you configure the airplane in GSX to use Belt Loaders instead of Cargo loaders ?
Also, try this:
- Load the airplane and WAIT until the countdown ends and the airplane is ready to fly.
- Choose "Restart Couatl" from the menu and start loading cargo.
-
...conflict with L: variables IDs...
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?
Does it happen if you configure the airplane in GSX to use Belt Loaders instead of Cargo loaders ?
Interestingly it doesn't appear to happen if you use Belt Loaders
- Load the airplane and WAIT until the countdown ends and the airplane is ready to fly.
- Choose "Restart Couatl" from the menu and start loading cargo.
It still happens if the Cargo doors are set to AKE/Pallets unfortunately
-
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.
-
Hi Umberto,
I tried only with AKE containers and the issue still persists. I posted on the PMDG forums, and they said it themselves that GSX is causing the change.
EDIT: I did also try as you suggested, waiting for the aircraft to fully load and restart couatl and it still persists
-
I posted on the PMDG forums, and they said it themselves that GSX is causing the change.
I was quite sure that would said that but, the issue is, GSX is NOT writing to the variable they use to control the VC visibilities. GSX only writes to its own variables, that's for sure, and I never heard of that particular variable before. Not that it makes any difference since, the only time we need to know of custom L: variables is to READ them ( never write! ) to check the door status.
What I'm not fully understand is ( only them can know that ), where, exactly, their visibility variable is set and what's used for. As far as I understand, the same VC can switch between two variations of the plane depending on that variable but, who's setting the correct value and when ?
Is the airplane gauges when the airplane loads or some kind of support module ? Is the variable being set using the C++ gauge interface ? It is set using the PDK ? It is set by name using the execute_calculator_code ? Is it set through an XML code ?
Each one of these methods can have different results and, for example, not checking if the ID of a variable has changed or its available before registering it ( which GSX surely does, for the precise reason to prevent such conflicts ), would result in the ID originally assigned to your variable being taken by somebody else, because you assumed your ID would never changes.
But of course, even a bug in the sim could possibly cause this. Are you all testing with P3D 5 ? Do you have V4 as well ? Is this happening there too ?
And of course, saying "GSX is causing this" doesn't even begin to explain why it seems to happen only to a single variation of a single model, and it never happened before with any other plane, regardless who made it.
I GSX was really causing this, you should see all sort of crazy things happening when you start loading pallets, because every complex 3rd party airplane can use dozen or even hundreds of these so, if GSX randomly wrote other's L: variables assuming they are its own ( this would be a result of an ID conflict ), it should happen everywhere, any custom animation on any airplane could be potentially screwed up by GSX and this should have been noticed years ago, since GSX always used the same L: variables for animations in years, especially the cargo loaders, that hasn't been updated in a long while.
-
I'm on V4.5 HF3 and VHEBM is on P3D V5.2 latest HF
-
Umberto, how can you solve this issue? I've posted on the PMDG forums - https://forum.pmdg.com/forum/main-forum/pmdg-777-forum/147966-gsx-turning-77w-into-77f-cockpit They're certain its not their end
-
I'm asking because, the 777 is the only PMDG product I don't own in P3D, I bought the FSX version, but decided to pass on the P3D version, because it didn't feel having to purchase it again without even a small discount ( I guess we are the only fools that allowed users that bought GSX in 2012, to use still use it with the same license in P3D V5 and PBR, 9 years later ) so, if I need to buy the 777 just to check this problem, I wanted to know if it also happens with the Base product, or only with Expansion.
The expansion won't work without the base product anyhow, so if you were to check it, I don't know how just buying the expansion would solve anything.
-
The expansion won't work without the base product anyhow, so if you were to check it, I don't know how just buying the expansion would solve anything.
That's not what I meant: I asked if the problem happened also with a model from the base product, so I could buy just that. But I'm afraid it seems I need to get both.
-
Yeah it only happens on the 77W, and in order to get the 77W working you need the base package which is the 777-200LR
-
Don't worry, I just bought all 3 packages, and I can replicate it too. And, as I suspected, I'm not so sure it has anything to do with GSX, at least not directly.
By enabling the Content error report in the sim, I noticed that, when loading the 777-300ER, on exiting the sim, I always get a notice there are errors in the ContentErrors.txt file. So I had a look at it, and it contained A TON of errors, all related to the 777.
The log stops after 1000 errors, so the last section is 999 but and many errors are very similar, some slightly annoying but not critical, like not finding some textures or some effects:
[error.6]
error=Failed to load visual effect "fx_PMDG777_beacon"
[error.7]
error=Texture PMDG_777_MISC_SPEC.DDS failed to load (FE_REQUEST_STATUS==13)
[error.8]
error=Texture PMDG_777_CABIN_METALLIC.DDS failed to load (FE_REQUEST_STATUS==13)
[error.9]
error=Texture PMDG_777_TAIL_SPEC.DDS failed to load (FE_REQUEST_STATUS==13)
Some more troubling, like a failure to load many gauges, due to the wrong version of Simconnect, for example:
[error.17]
error=C-style gauge failed to load: C:\Prepar3D v4\Gauges\PMDG_777X.dll, Gauge: CDU. Verify the correct version of SimConnect is installed.
There are about 80 errors like this, covering all gauges. However, Simconnect is not related to L: variables, so maybe we can ignore these as well.
But the bulk of the errors, which seems to be the most telling, are A LOT of issues that seems to be related to L: variables IDs, here's an example:
[error.111]
error=Gauge/Script Error
Type: Unknown
Name: Unknown
Error: PANELS lookup_var : SimVarGet Failed - Module_Var ID: "673".
There are 888 of them, (that's just because the log stops after 1000 errors), all with different ID numbers. However, most of these ID are repeated so, I ran a script over the error log that would remove all duplicate lines, and it came out with this result:
Error: PANELS lookup_var : SimVarGet Failed - Module_Var ID: "211".
Error: PANELS lookup_var : SimVarGet Failed - Module_Var ID: "211".
Error: PANELS lookup_var : SimVarGet Failed - Module_Var ID: "246".
Error: PANELS lookup_var : SimVarGet Failed - Module_Var ID: "280".
Error: PANELS lookup_var : SimVarGet Failed - Module_Var ID: "673".
Error: PANELS lookup_var : SimVarGet Failed - Module_Var ID: "674".
Error: PANELS lookup_var : SimVarGet Failed - Module_Var ID: "692".
Error: PANELS lookup_var : SimVarGet Failed - Module_Var ID: "693".
These are the unique IDs so, it seems, out of the many L: variables the VC use ( there are probably hundreds of them, at least one for each switch ), ONLY 7 failed to read, for some reason.
After my first test with GSX, to be sure these problems are not caused by a conflict with GSX or any other module, I disabled EVERYTHING
GSX, SODE, FSUIPC, Navigraph, up to a point I don't even had an "Addons" menu anymore. It's just P3D 4.5 HF3 and the 777.
And sure enough, even during the 2nd run, with *all* 3rd party modules disabled, resulted in the SAME errors as before: reports of the wrong version of Simconnect, and hundreds of errors related to reading the Variable IDs.
Now, a quick check on PMDG forums reading users reporting the same errors in the log, always invariably result in comments suggesting to just ignore them, those are only used by developers, and you should turn the Content error option off, and forget about it.
Well, first I find this quite shocking: those errors seems to indicate something is going on with the airplane and, before we do a new GSX release, I always keep it enabled and try my best to be sure I have ZERO errors in the log. When we have errors, they are usually minor, like a missing texture on a specific vehicle variation but, those in the 777 seems to be fairly serious and, specifically, mostly related to issues reading the Variables IDs.
Remember my explanation about the L: variables and their IDs ? That's seems to be the problem: somehow, the simulator is telling this airplane has issues reading L: variables, but that might not be a problem if you use the airplane alone, it only starts being a problem when something else use its own set of L: variables, like GSX, because when two programs that use L: variables are working together, it IS possible to end up with an ID conflict, unless both use the proper care to ensure this doesn't happen.
I think PMDG say you can ignore those errors because, traditionally, L: variables are used by airplanes and, since it's not possible to load two airplanes at the same time, every possible conflict that might happen, won't be visible anyway so, even if their code didn't account the chance of an ID conflict, it won't be a problem, and one can safely assume all IDs are usable when switching planes.
So, having made it clear the airplane has some issues with at least 7 L: Variables even when *nothing* else is installed, why this is happening only with the latest GSX Update, which SEEMS to indicate GSX is the cause ?
My guess is just because we added a bit more variables that will be used by 3rd party developers that interface with GSX, some of them has been added to help FsLabs with their upcoming Concorde, for example. It's possible that, considering the airplane DOES have issues with 7 variables, we just got lucky with previous GSX, because the number of variables used by GSX wasn't enough to start issuing conflicting IDs with the 777. It's difficult to know for sure, without knowing the simulator own strategy to reallocate and reuse IDs but, what I think is happening here is:
The 777 failed to read a variable. We don't know its name from the error log, only its ID so, assume is this one ( if it's not, I'm sure it's one of the other 6 )
Error: PANELS lookup_var : SimVarGet Failed - Module_Var ID: "211".
Here, it seems ( remember, I'm getting this WITHOUT GSX! ), the airplane code for some reason failed to read a variable with ID 211 so, it's likely the simulator would consider that ID "free to use". Let's assume for a moment this 211 number is the variable that causes the VC to change into the freighter version. The real name of the variable is "IsFreighter", BTW, the "custom_vis_IsFreighter_01" is only how ModelConverterX presents it visually.
Now assume we start GSX Deboarding, which at a certain point will ask the sim to register some L: variables used for, let's say, the Cargo loaders, those are the names we use:
FSDT_CargoLoaderGuides
FSDT_CargoLoaderBridge
FSDT_CargoLoaderPlatform
But as I've said before, we use variables by name only the first time when we register them, which means telling the sim we want to use a new custom variable, and the sim will return with an ID.
So, when GSX registers those variables, the simulator is likely considering the ID 211 to be available because when the airplane used it, it FAILED, so it gives ID 211 to GSX.
GSX cannot possibly know the 777 TRIED and FAILED to use that ID already, so it will trust the simulator that ID is in fact available, and as soon one of these animations starts, the 777 L: IsFreighter will be set too, because of the ID conflict initiated by the failure of the airplane to use it which, again, happens even with the simulator is completely clean of add-ons.
I'm fairly confident that, if PMDG can fix their code to remove ALL those 7 variable failures, the conflict with GSX will likely disappear.
-
Hi Umberto,
Thank you for your explanation and investigation into this issue. I appreciate it. I have quoted your reply to my PMDG forum thread and will await for their reply. I'll keep you updated. Thanks again
-
I appreciate it. I have quoted your reply to my PMDG forum thread and will await for their reply. I'll keep you updated.
I've read their reply and, as expected, they are continuing to repeat the problem "must be GSX", just because it happened only after our update, without providing any evidence, like I did.
I think I gave a reasonable enough explanation why it never happened before: we added a couple of variables ( all using FSDT_xxxx names, of course ) more in this version, so maybe now their number it's enough to expose a conflict that could always have happened.
The explanation those errors can be ignored, because they use "custom coding the sim does not understand" doesn't make any sense. The log clearly recognized what the code was doing, and it was a call to an API the sim clearly knows about it, which is used to read an L: variable from the panel system, and the sim said those calls failed.
If they really used "custom coding" to read ALL their L: variables, why the sim is logging failures for just 7 of them, out of the hundreds the panel likely use ?
I think I've gathered enough evidence indicating that, the main reason of the problem starts with those failures, and it was only by chance that, a new version of GSX exposed it because we increased the number of L: variable we use, but that error could have happened before, and I wouldn't be so cavalier telling users to ignore the errors.
I could only guess what PMDG would say IF GSX had so many errors logged, when in fact it has none, and it use lots of L: variables, has *thousands* of multi-livery object variations, yet is completely clean of any errors.
Instead, their plane is able to generate 888 errors using always the same 7 variables in a very short time ( and we don't even know how many more are really happening in the sim, because the log stops after 1000 errors! ), yet for some reason, it's GSX's that must change its errorlog-free code.
If I were them, I would worry about having so many errors (regardless of GSX) and would try to get rid of them, if only for possible performance reasons because, even if the log in the sim stops after 1000 errors, who knows how much more costly in cpu time is having constant errors happening, regardless if they are logged or not...
-
Hello, we found a workaround for this problem.
I still think it might be best if the airplane fixed its errors with those variables but, since it doesn't seem it's going to be fixed, we found a way to fix from our side. Get the update as usual.
-
Hi Umberto,
Thank you for solving the issue and releasing an update very quickly.
-
Hello, we found a workaround for this problem.
I still think it might be best if the airplane fixed its errors with those variables but, since it doesn't seem it's going to be fixed, we found a way to fix from our side. Get the update as usual.
Not that it really makes a difference, but I'm just curious as to what you ended up doing to solve the issue.
-
Not that it really makes a difference, but I'm just curious as to what you ended up doing to solve the issue.
It seems the sim was sometimes confused when we registered some of our variables, and in some cases returned 0 as ID, so we now ignore 0 results and try the registration again until we get an non-0 result.
Not sure if it's an unknown bug in the sim, or a bug induced by the sim having to deal with so many errors ( which even if they are not logged on a file, are still happening ) in a very short time. Ignoring Content error reports it's not safe, since no 3rd party developer can be sure they won't have side-effects on the simulator itself.
-
Interesting.
-
hi. installed the latest update and still having the issue
-
Hi all.
Same as post above.
GSX updater only updated some texture files last update and issue still persists with the 777
(p3dv4.5)
-
Hi Umberto,
I don't understand your program whatsoever. I updated, it worked fine. Went and loaded up to do a flight and boom it happened again... Then ran the live updater and all worked fine again... Do you have an idea what's happening? Other users on the PMDG forum are still experiencing the panel changing
-
Hi Umberto I would also like to say that I also am still having this issue. Possibly the topic should be renamed to not say **SOLVED** as this issue clearly isn't.
-
Okay, so I've noticed it only changes panel during the boarding procedure. Deboarding seems to be fine
-
Sorry, but I cannot reproduce it anymore, and I see other users on PMDG forum reporting it was fixed for them.
I can only guess it might just be an issue of still not getting the latest files, because of the time delay for all Cloudflare servers to get synchronized so, just try again, I've sent a force purge command now on Cloudflare, sometimes it's useful to wake up nodes that never got the update in the first run.
-
Okay, so tested it twice and all seems to be good. Thank you Umberto 👍