FSDreamTeam GSX for MSFS

Discussion Hub Tools & Utilities
, , ,
2079

About the PMDG 777 ignoring the crew settings, let’s clarify better the order or priority when these settings are read:

  • The global setting to ignore the crew, this has the lowest priority, lacking any further information coming from the airplane own code.

  • The Internal GSX database first. The PMDG 777 is not included in the GSX internal database (yet), and we don’t have any custom code like we have with the 737 instead so, nothing in GSX is treating the 777 in any specific way other than any other airplane.

  • The “Developer-provided” profile. This is the one supplied by PMDG, but you cannot change that setting with an airplane profile, it would require some actual code, which could either come from custom GSX code (which again, we DO NOT have for the 777 like we do for the 737) or from custom code in the airplane itself.

  • Any custom GSX integration code in the airplane. This clearly has the highest possible priority, because the airplane developer surely knows better than anybody else what’s supposed to do with those services.

So, for example, if you said you wanted to ignore the crew, but the airplane has explicitly set a number of pilots/crew to board, the airplane “will win”, and this is by design, and has been explicitly requested by several airplane developers to be like this: they don’t want a “wrong” user global setting that might work for any airplane, would either mess up their own internal logic, or force them to write additional code to anticipate all possible users settings that might not be the one they assumed. So, the airplane own integration will alway “win” against most settings.

So we get to the interesting part: since we haven’t coded anything specific to the PMDG 777, and airplane profile can’t change that setting, it leaves us only with one option: which is PMDG has already coded some GSX integration, and for some reason they are not advertising it.

Of course, I always check my facts first before saying anything, so I had a quick look at the PMDG_777_MSFS.wasm file and, sure enough, it contains several GSX LVars, including the ones used to set how many pilots, crew and passengers are on board.

Now, I cannot possibly say exactly how and when they are used, or if all of them are used (perhaps they are working on integration, but haven’t completed it), but you can be sure that, if they set the number of pilots or crew explicitly, those will board the airplane no matter what, for the aforementioned reason the “airplane is always right, the airplane always wins”, that’s why your general preference is ignored.

Of course, GSX has a diagnostic log you can enable, so if you want definitive proof this is what is happening, just look at the log for the following words:

Crew number set by Add-on = xxxx
Pilot number set by Add-on = xxxx
Number of passengers provided by addon is xxxx

That means the airplane code has set those LVars, so GSX is complying with it.

4 Likes
2080

No problems with Deboarding:

image
image1920×1154 294 KB

That’s precisely why:

  • Walking Passengers are created with Simconnect, so they can be affected by Simconnect not accepting any commands to add new objects, because it has decided you hit the limit.

  • Passengers inside the but are not created with Simconnect, they are part of the Bus model and are turned on/off selectively depending on the value of a variable set on the Bus itself, but there’s no Simconnect code to “create” them, they are always there, inside the Bus, visible or not.

So yes, your report is perfectly compatible with just having reached the Simconnect limit, and your last post of passengers being “teleported” from the seat to the Bus simply confirms it, because those are exactly the two operations (disabling the visibility of the ones attached to the airplane and enabling the visibility of the ones attached to the Bus, resulting in a “teleport” ) that don’t require creating new objects.

2081

Yes, unfortunately, sometimes it works, most of the times it doesn’t! It’s worse when passengers have to walk to the terminal, perhaps because it’s more load on the system? All was working fine prior to Version 3.0. I had no issues with passengers before that, it all started with Version 3.0. Could it have anything to do with program removing/reloading passengers in the cabin when the cockpit door is closed/opened? I don’t know why SimConnet is all of a sudden not working properly when it was working fine before Version 3.0? Nothing else has changed on my side! Regardless of what it is, the program is not working as it should and I hope you can come up with a solution.

2082

You keep repeating this, when I already clearly explained that yes, of course having Seated Passengers in addition to Walking passengers, will clearly put more strain on the system, that’s the worst possible moment, even regarding fps impact, because while before, we were just walking a passenger inside the cabin and then removing it ( decreasing the Simobject number when this happened ), now we are removing AND replacing with a seated one, so the net number of Simobject won’t change, which means that, while before the number of passengers visible at the same time was ONLY related to the LENGTH of their walking path and the Passengers Density slider, now you will have as many Simobjects as total number of passengers planned to board, so it’s clearly higher, which means you are getting closer to reaching the Simobject limit.

You keep repeating it “didn’t happen before 3.0”, as if this was a kind of “bug” in 3.0, because you seem to ignore the Simobject limit (which is a combination of ALL running add-ons, it’s difficult to reach it with just GSX running), which is real and it’s just nothing we can do, the only one which can do something about it, it’s you, by stop assuming it’s a “GSX bug” and instead work with your settings trying to stay away from it.

It’s your decision if Seated passengers are more worthy than lots of AI, and they all contribute to reaching the Simobject limit and/or breaking Simconnect because of too much traffic, but you can’t fault GSX because you want to eat your cake and have it too, because we have no solution for this, the only real solution would be Asobo/MS acknowledging the problem and doing something about it.

And if this wasn’t clear enough: having this popular feature in a popular program like GSX, might increase the chance the problem would be seriously looked at, something that might never happened if we even tried this feature, because of the Simobject limit.

It already happened once, with the Navdata API which arrived with SU10 first and was completed in SU12. The product which benefit the most from it was, you guess, GSX, because before that, it only worked on unencrypted airports, with users buying airports on the Marketplace questioning their purchase, because they couldn’t use GSX there. You can be sure that, if GSX wasn’t very popular, the request from having a Navdata API to extract data from encrypted airports without any hacks might have not been taken very seriously, but of course this API can now benefit every add-on, such BATC, which uses it to get information about taxiways, parking spots, etc.

Now, we have TWO major improvements we are hoping for in MSFS 2024 that would make the Seated Passengers so much easier and usable, which are:

  • An “Attach API”, that could allow us to attach stuff on airplanes (or other objects), without having to modify the airplane files. It’s a very similar situation as the Navdata API: you can’t have Seated Passengers on airplanes bought on the Marketplace, because we can’t patch those encrypted files. Having an “Attach API” would fix this, would allow users to create their own airplane profiles to add Seated Passengers to any airplanes, and would make the somewhat confusing “Add new Livery, go back to the Installer to re-patch the new files” go away entirely. Ironically, P3D does have an Attach API, so we could have added Seated Passengers to P3D way more easily, but of course that’s not what the market want’s, isn’t it?

  • A serious look at understanding the Simobject limit, and getting rid of it, or make it smarter, because while we surely need to add lots of objects, they are extremely well optimized.

So we are again in a similar situation, where a popular new feature in a popular add-on might eventually lead to an general improvement that will benefit everybody: GSX users, users of Marketplace airplanes and other developers that I’m sure will find useful use cases for an Attach API and will be very happy to not be hampered in what they do by the Simobjects limit.

4 Likes
2083

If you have seated passengers disabled in the config (which you said you did), then afaik opening / closing the cockpit door shouldn’t do anything within GSX…

2084

Just fyi, I have the passenger disabled for a while. And as far as I know and Asobo (Seb) has mentioned, SimObject limitation is per addon and not an overall limitation. Each addon gets 1000 objects. This is what they said in one of the recent live Developers Updates Q/As.

I will repeat myself that I did not have this issue whatsoever before version 3.0. Whatever happened, happened after that! You can come up with all the explanation but I do this pretty much every day or at least 5 days a week so I know what I know.

Thanks for the long explanation. Hope MSFS 2024 addresses the issue. For now the passengers are useless for multi-leg flights using GSX and I think you need to disclose this to your new customers.

And don’t get me wrong, I love GSX and can’t think of the Sim without it. If I complain, it’s because I want it to work properly, as it generally was before the update.

2085

That’s assuming it’s working as intended. I think what Asobo said, is the Simobject limit it’s supposed to be 1000 per add-on, but we all know from testing that it’s shared, because:

  • We surely don’t create more than 1000 objects in GSX. In the worst possible case, that is a long walking path with a full A320, we could at most have:

180 Passengers (total walking + seated)
3 baggage carts, which are 2 Simobjects per cart + 11 bags each + front tug + driver = 80 Simobjects
3-4 extra objects like Pushback, Stairs, counting maybe 10 Simobjects more including their drivers

If you are on a GSX Airport profile that uses VGDS, you’ll have an extra object for each static VGDS, plus an extra Simobject for each character of the Active one. A scenery that has one of the highest count of VGDS is our KORD, with about 180 VGDSs so, it would be at most about 220 Simobjects, since the matrix for the largest VGDS is 6x7, so the active would generate 42 Simobject if all characters are visible. Note that, you can save those static objects, by disabling the option to create static VGDS in the Airport profile.

So, the hard numbers are telling us that GSX, even in the worst possible case, of a big airport with tons of VGDS, boarding luggage and seated passengers with a full airplane all at the same time, can generate AT MOST about 400 Simobjects, there’s no way we could exceed 1000 just with GSX.

  • If you don’t trust what I said, it’s very well known you can reach the limit even if you just use any of the various AI injectors and push the number of AIs high enough even without GSX and there’s no way any of those add-ons are generating more than 1000 AIs

And this is just the empirical reasoning but, as always when I say something, every single piece of information you are getting from me, it always come after a proper testing so no, I don’t “speculate”, if I say something, it’s because I made proper tests so, here’s another “long explanation”:

The Simconnect SDK has a proper error code called “TOO MANY OBJECTS”, and this can be triggered by a single Simconnect app that is really trying to create too many objects. I can trigger this intentionally by writing code that is doing that on purpose, just to see if the exception works and, in fact, it works.

However, when the number of Simobjects is already high because other apps (or the airport itself, since airports can include Simobjects, like Jetways, Vehicles, etc.) have created those, you don’t get the error code if YOUR app is creating less objects but the combination of other objects surpassed the max Simobject limit.

This seems to indicate that, while the Simobject limit was intended to be by-app, it’s not really working that way, so it behaves as if it’s shared.

4 Likes
2086

Thanks for the info. Yes, I remember I used to have issues with SimObject limits when using AIG. But the issue got resolved a while ago (don’t remember through which Sim update). I don’t fly in any extravagant airport and pretty much only fly in Iran with relatively small airports. Haven’t had any issue with AIG planes disappearing on return flights for a long while now and I was the creator of "Fixed live traffic planes getting stuck at the center of the airports" Not Fixed which was a SimConnect related issue.

It’s interesting that before version 3.0 I did not have any GSX related Simconnect/passenger related issues and I am flying to/from same airports, same routes, same everything! Mind bugling.

2087

You are now making another assumption: that just because another add-on could “fix” the issue, the Simobject limit somehow would magically disappear for all add-on and they all could fix it in the same way.

You keep repeating this, when I explained, multiple times that, with Seated Passengers, you are obviously closer to the limit, which means you must be more careful with it. I’ll try to explain it again, hopefully for the last time:

  • Without Seated Passengers, the number of passengers (each one being a Simobject) visible at the same time was variable, depending mainly on the Passengers Density and if Boarding/Deboarding was made with a jetway or not, with jetway being the lighter option, Passenger Bus more heavy (if the airplane has two passengers door) and Walk-in gates the heaviest because, with a very long walking path, you could have possibly see ALL passengers the airplane can carry at the same time so, with a full A320, the absolute maximum would have been seeing 180 passengers at once.

  • With Seated Passengers, if you are boarding a full A320, you’ll always see 180 passengers at a time, because the walking ones are no longer destroyed when the reach the cabin, they are replaced by Seated ones.

I hope it’s finally clear now and, it should be obvious that, if you Disable the Seated Passengers, there’s zero difference between 3.0 vs previous versions so, if you still have disappearing objects or Simconnect being broken, you can be sure it’s NOT caused by GSX, but you reached the Simobject limit because of other stuff.

That is without even saying: don’t you think that, if version 3.0 had a real bug or problem, we would have seen a lot more similar reports by now, instead of just you?

2088

And you Keep repeating the same thing. Let me tell you again: I DON’T have the seated passengers on! It’s unclicked, off! And it has been for a while! The issue persists and I did not have any issue before Version 3.0! That’s that. There are other people complaining too! Perhaps not many do multi-leg flights. But I have seen complaints on your own forum and also Fenix discords account.

2089

Because from your reply about “didn’t happen before 3.0”, it looks like you still don’t understand why the only difference, is Seated Passengers.

Then it’s impossible you would see any difference compared to “before 3.0”, since with Seated passengers Disabled, there aren’t been any changes to the way Boarding/Deboarding works and surely the number of objects created is identical as it used to be.

So the only possible explanation according to your report, is that you reached the Simobject limit by other means, and it happened around the 3.0 update, so you linked them two unrelated facts together.

You are now assuming they are in the exact same situation as yours, which you shouldn’t do, because each case is separate. do those very few people you said are complaining have Seated Passengers disabled as you said you have ? do they have the problem only on an arrival or on a multi-leg flight ? is their problem also not fixed by restarting GSX ?

Because I need to repeat it again, if something like this is NOT fixed by restarting GSX it cannot possibly by a GSX problem because, as I’ve several times, when you RESTART GSX, it’s NOT a multi-leg flight anymore!

The one and only thing that forces you to restart the sim to break out of those Simconnect issues is the Simobject Limit!!

2090

Ok Thanks! We won’t get anywhere with this. I am getting this issue on first leg too unfortunately (once I land) half the passengers empty correctly and the other either teleport or don’t show up at all.

If you were able to send me a link to a version before 3.0, I would be able to do more testing for you. Not sure if that’s possible. But again, I never had this issue before. You say, it has nothing to do with Version 3.0, then it has nothing to do with it. My eyes see something different but I will ignore them.

2091

You said that maybe not many users reported it, because they don’t do multi-leg, so I assumed it only happened to you in multi-leg flights.

Now you are saying it happens on landing too but, is your previous statement that it’s NOT fixed by Restarting GSX still valid ? If yes, it cannot possibly be a GSX problem, because after a Restart, it’s as if you are starting from scratch.

What your eyes has anything to do with this ? It’s not as if I don’t believe you are seeing this, I said it’s just a coincidence you noted a difference with 3.0 without Seated Passengers, and again, if you restart GSX and is still not fixed, it can only be the Simobject limits being hit somewhere during the flight.

2092

Yes, now I am seeing this issue after landing the first leg also. Not always but sometimes! Last night for example, the first bus of passengers were deboarded correctly the 2nd bus was teleport! I don’t think you mean to restart GSX before deboarding correct?

It’s ok. I will just not pay attention to the passengers. I don’t like to keep restarting the GSX as it messes up immersion and integrations. I just wished that I had never downloaded the Version 3.0 and after. Too late now…

2093

As I’ve said already, teleport is clear indication of the Simobject limit, especially because it’s on the 2nd bus.

Yes, of course I meant restart before Deboarding

That’s just a TEST to verify if the problem is only temporary, so it can be fixed by a GSX restart so it might be a GSX problem ( but not in ALL cases, it might still be a Simobject limit issue, but not serious enough to cause Simconnect breaking up, the restart would just place the max simobject number limit back under control because restarting would result in the sim automatically removing all objects created by GSX).

But if it’s NOT fixed by restarting GSX, then you can be 100% sure it’s nothing related to GSX, it’s just the plain old and very well known Simobject limit that has broken Simconnect to the point it needs a simulator restart.

That’s why I say TRY to Restart GSX, both as a TEST but also as a fix for the less serious cases.

And again, with Seated Passengers Disabled, NOTHING changed with passengers.

As I’ve said, it was just a coincidence and in fact, since GSX is updated very often, it’s easy to be misled thinking the “latest update” has a caused issues, because with frequent updates, the chance of something else changed in your system to be confused with a “GSX update” are very high.

2094

This from PMDG in relation to the crew and pilots always boarding…

‘‘The only GSX comaptibility we have coded… Is the GSX profile. There is nothing else coded from our side related to GSX’’

Not sure where to go with this…

2095

Well, then they must have one coder doing stuff without telling his boss. Or, a support person not fully knowing the whole product. Or for some reason they don’t want to advertise the integration, but surely they did something.

As I’ve said, I cannot possibly say how and when they use of if they are them all, or some of them, or they are a start from a future planned integration they are testing (which might explain why they haven’t advertised), but fact is, in the PMDG_777_MSFS.WASM file, you can find the following references to GSX-specific variables:

FSDT_GSX_BYPASS_PIN
FSDT_VAR_Frozen
FSDT_GSX_MENU_OPEN
FSDT_GSX_MENU_CHOICE

FSDT_GSX_NUMPILOTS ( this is what makes pilots always boarding if it’s set to non-zero )
FSDT_GSX_NUMCREW ( this is what makes the crew always boarding )
FSDT_GSX_NUMPASSENGERS

And of course, in case of the number of pilots/passengers/crew, the GSX log will indicate if the variable has been setup by the add-on, so you can check if it’s used as I explained in my previous post.

1 Like
2096

Thanks, I am not saying you are wrong, it is all good information.

Btw is it possible for us edit this WASM file as it looks like they won’t admit to it?

2097

I don’t suggest it, even a tiny mistake, like changing the wrong byte, and you might easily end up with a corrupted file and an airplane completely screwed.

2098

OK! Thanks for the info. I will leave it and just be completely frustrated that I have to wait for myself to board even though I’m already sat in the cockpit….