I hadn’t considered this detail significant enough to mention, but yes, I reset GSX on the OMDB-OOMS and KORD-KOMA departures I reported way upthread. I’m curious to know if this had an effect on the sim.
I think resetting GSX simply injects more SimObjects back into the sim, which probably contributes to reaching the limit. I have had this issue both with and without resetting GSX, so it is almost certainly not JUST a GSX problem but rather just associated with the fact that programs like GSX and AIG are injecting quite a few simobjects into the sim.
- GSX, on its own, is NOT causing this problem.
- AIG, FSLTL, on their own, are NOT causing this problem.
- Highly detailed sceneries, on their own, are NOT causing the problem.
None of the above is doing anything “wrong”, other than just showing its own objects when it needs.
The problem is, the combination of all of them, can reach a maximum number of the objects the sim can show, before objects start to disappear, Simconnect start stop responding, and in some cases the fps would drop and even whole airports might disappear.
Fact you see some changes by repositioning GSX,doesn’t mean in any way GSX is causing this, especially because “Reposition” and “Reset Position” are totally different commands:
Reposition doesn’t reset anything, doesn’t destroy or create any objects, it JUST “moves” the airplane to a different position, usually by a small amount.
Reset Position" it’s equivalent to Restart Couatl,which means the previous session of the .EXE will close and a new one will start.
Doing a Restart, MSFS will detect the Client disconnection and, will automatically destroy ANY objects created by that .EXE, and this is done automatically without any need for the disconnecting client to code anything specific. If a client disconnects, cleanly or not ( if it crashed, for example ), ALL objects it created WILL be removed, no matter what.
This means it’s very possible that, the disconnection triggered by a Restart, which triggered MSFS to clean up all objects created by the previous GSX session, might have been enough to bring DOWN the number of Simobjects to a manageable level.
Again, the problem is the limit itself, not any specific application. An example:
Suppose the limit is 1000 objects, and before you even start GSX, the combination of the airport, all its default ground vehicles, jetways or anything else that is a Simobject, already places you at 800, if during a GSX session, the combination of passengers + luggage + all GSX vehicle bought the total momentarily to, let’s say, 1100 objects ( I’m making up numbers here ), maybe at that point the sim started to break up and show ghost objects, or became unresponsive to Simconnect commands.
Then you restart GSX, the sim will automatically clean up all its objects, the total would go down to 800 again, and possibly everything might be back. This is not always happening, sometimes the sim gets stuck and only a restart can help, I guess it depends how much you are over the limit.
Of course, exactly the same will happen if you stop an AI Injector: the sim will remove all the Injected AIs, and might also result in going back in a safe number.
That is to say: just because you see something happening in relationship to doing something in a certain program ( like restarting GSX ), doesn’t mean the program itself was the cause of the overall problem: it’s just a side effect of the real problem at hand, which is:
- the sim will break once the maximum overall object limit is reached.
- the limit is usually reached by a combination of product used together.
- it might be possible to exit from that situation, by taking advantage of the automatic clean up MSFS is doing when ANY clients disconnects, that is Exiting or Restarting ANY of these clients that created the extra objects.
I’ve already listed all the possible things you can do in GSX to keep its own contribution to the overall object limit in previous posts, I’ll repeat them again:
Go into the “Config” panel of the FSDT Installer, disable “Ground Clutter” and click the Update/Check button again, to install a lightweight version of the GSX Jetway replacement files, which contains just Jetways and nothing else, so they won’t increase the overall number of object compared to default ( 1 default jetway will be replaced by 1 GSX jetway ), AT DEFAULT AIRPORTS
Lower the GSX “Passenger Density” slider. This affects the maximum number of passengers you can see at the same time on screen. Yes, it will make Boarding/Deboarding slower but, the number of objects created by GSX will be lower as well, lessening the issue.
Of course, you can act similarly on the OTHER add-ons that all contribute to the same problem, for example lowering the maximum number of generated AIs. Again, since everything contributes to the overall number of objects, and nothing in single-handedly responsible, the most effective way to deal with this, would be act on everything, when possible.
“This means it’s very possible that, the disconnection triggered by a Restart, which triggered MSFS to clean up all objects created by the previous GSX session, might have been enough to bring DOWN the number of Simobjects to a manageable level.”
Well but that’s not what happened. Restarting couatl did not bring down the number of simobjects, restarting couatl actually started the situation. See I had GSX services going on, AIG traffic at KLAX, all visible, then I had to reset GSX / restart couatl and suddenly GSX and all AI traffic became invisible. Now this should not have happened according to your explanation, since the couatl restart would have removed and readded the same amount of objects, not changing the total number. But what if that “cache” of simobjects does not get cleared by disconnecting the client as it’s supposed to, instead adding GSX (or AI traffic) over and over again on top? I’ve seen similar bugs with caches in other situations. Are you positive that this cache behaviour you describe is actually working?
Obviously none of this would be GSX fault, we are talking about a possible MSFS simconnect bug.