On the one hand you tell us that assembling the pushback vehicle from three separate objects saves memory/fps/ctds, on the other hand you tell us that there are often problems with GSX because Simconnect cannot handle the large number of objects.
As with everything we do, the reason for doing something always have a very sound logic, which always give preference to the long term growth of the product and the sim, trying to use all features from the SDK that achieve that goal.
The "Attached objects" method came out with SU9, which was released in April 2022, before GSX, so we obviously took a chance to use it, because it's a way more efficient method of making large collection of objects without wasting memory and needlessly duplicating files. If we used the old style monolithic approach like FSX, following the example of the small tug, we have:
- the tug which carries the luggage carts, which uses a small towbar trolley
- the SAME tug used in a pushback role, which uses an airplane towbar
- the SAME tug used as a wandering ground traffic, which has no towbar
- the towbar driver, which is one from GSX when the vehicle is called by GSX, and one from Asobo when the tug is used as a default ground traffic.
In FSX/P3D, to achieve this, we would need to create separate versions of the SAME tug object, while in MSFS using the Attached objects method, there's only one Tug, a separate trolley towbar, a separate airplane towbar and the driver is separate.
Now, you might think the different is small but, in order to make up all variations, you would need to multiply that number by:
- The number of ground handlers ( currently 256 )
- The number of different drivers ( currently 6 )
Which means, the 4 truck variations * 256 * 6 = 6144 different variations JUST to represent the 4 roles for the small Tug, compared to just 256 ( one for each operator ) + 6 drivers + a couple of towbars.
If we wanted to add a new operator, with the "single object" method, it will add 24 new Tug variations ( 6 drivers * 4 different roles ) while now, when we add a new operator, it will only add ONE variation for each GSX object class.
If you take into account all GSX objects classes, the saving in variations is HUGE, like ten of thousands objects LESS compared to having every object made a single object. Because I hope you don't really think there's no limit on the number of variations as well. While we don't know if there is an hard limit, each variation will need to be scanned at start to be "mounted" in the VFS ( virtual file system ), and this table is allocated in memory so, not only adding a huge number of variations will affect the startup time, but their number will also affect the system memory.
Some users already complained with GSX the sim can take up to a minute more to start, imagine how bad this would be if we didn't use attached objects, so we had like 15-20K more variations, with hundreds of new variations added when adding a new operator.
In addition to that, by separating an object into these major components that are shared between objects, we give the simulator a better chance to optimize its memory because consider this:
Suppose we have an American Airline Tug with a Male driver and Towbar embedded on a gate, with a United Tug with a Female driver on the next gate.
- With the legacy monolithic approach we only added two objects to the sim, but they are surely larger and, in this case, data for the identical towbar has been loaded twice for sure, since the sim has no way to optimize for the duplicated towbar, which is present in both objects.
- With the attached object method, we added 6 objects to the sim ( 2 tugs, 2 drivers and 2 towbars ), but now the sim CAN recognize it already has a towbar in memory, so it can optimize it and load it only once, and use instancing to let the video card draw it multiple times with a very low cost in fps.
This might seem a small benefit but, that's just with two gates to make the example clear but, what about a whole airport, were you might have dozen of identical objects like towbars and drivers in use ? It should be obvious THIS is a way better method, it wouldn't be added to the SU9 SDK if there was no benefit.
And this method worked just fine, UNTIL some AI traffic products came out, around October, and it was then then suddenly the maximum number of Simobject became an issue. You couldn't reach it with GSX alone, and you still can't, if you are flying online with real user planes instead of AI traffic.
As I've said, so many times already, it's nobody's fault if the limit is reached, and the PROPER solution for the long term growth of the sim is to Asobo to finally have a serious look at it and fix it, instead of reverting back to a way worse method to create multiple objects, which comes with serious issues on its own.
It's like when we only had 32 bit simulators, and sceneries more and more complex started to appear, up to the point nobody could use a complex airplane with a dense airport without an OOM ( P3D V3 was the worse: it consumed more memory because it had better graphic than FSX, but it was still 32 bit ), so the PROPER solution was to fix the simulator itself, and move to 64 bit, today is the same, since memory ( at least on PC ) is not really a problem, the PROPER solution is to remove the max number of Simobjects limitation, otherwise shortly nobody will ever be able to do anything in the detail users ask for.
Because detailed airport interiors, detailed airport ground clutter, they ALL contribute to the max number of objects, it's NOT a single product that causes this, it's always the combination.
