With the increasing complexity of the simulation and simconnect still being a
key way for adding objects into the sim, the (what i can only imagine as )
historic limit of approx 1000 simobjects in the sim is becoming limiting. This
is leading to invisible objects when using AI aircraft packages combined with
airport enhancements, boat package etc etc. Could this 1000 object limit be
increased or removed? It would seem like its left over from days of highly
limited system memory.
I second this. This limit is very penalizing, when considering the recent
ability to use Attached objects, which can improve flexibility quite a bit
compared to having monolithic Simobjects, but result in an increase of their
number, making the limitation all the more apparent.
With the release of Just Flight’s FS Traffic - this has just added another app
that can be impacted by and contribute to hitting this limit. Would be great
to get a view from Asobo on if this will be considered and if not - what they
would suggest all the third parties do?
1 Like
Highly needed request, specially as long as we have the 1% Ground Vehicle bug
(spawning all airplane services for each AI airplane) as well…
@FlyingRaccoon
@Boris1 Dear Asobo, do you have any updates on this
important item. Kind regards Duncan
This is certainly causing us a few headaches. Would at least like to see the
limit increased.
Asobo should take action on these
1 Like
Hi everyone,
Apologies for the delay in getting back to you on this topic.
We have had a look at this issue and here is what we found:
- Contrary to populary belief, there is no hard limit on the number of SimObjects you can spawn through SimConnect.
- However there is a hard limit on the number of SimConnect requests each connection can handle at once - and this limit is 1000.
- When you exceed the said limit, you receive a SIMCONNECT_EXCEPTION_TOO_MANY_REQUESTS exception.
- The SIMCONNECT_EXCEPTION_TOO_MANY_OBJECTS exception has nothing to do with the number of SimObjects - it is sent when a single connection registers too many Defines (unique “DefineID” as used in AddToDataDefinition and AddToClientDataDefinition). The current limit is 1000.
NOTE: when I say that limits apply “per connection”, it means “per handle returned by SimConnect_Open” - these are not “global” limits or “per add-on” limits as has been suggested elsewhere.
With that in mind:
- We are surprised that so many people mention the SIMCONNECT_EXCEPTION_TOO_MANY_OBJECTS exception : even if you spawn tons of SimObjects, you usually use the same DataDefinition to get/set information for them. Please let us know if this is not the case.
- However it seems very possible that traffic generation software reach the request limit and hence receive the SIMCONNECT_EXCEPTION_TOO_MANY_REQUESTS exception. This is because you usually create (at least) one request per generated SimObject to track its movements/state.
Following these findings, we propose to increase the limit on the number of requests for SU16: not sure yet about the new limit but something between 10k and 50k is being discussed. Please note that according to our tests, spawning 10k animals around the aircraft already hits performance quite significantly, so we are not too keen on setting this new limit too high either.
Comments are welcome!
Best regards,
Eric / Asobo
2 Likes
Hello Eric,
thanks a lot for having a serious look about this, because this issue has really been a great source of pain for both developers and users.
However, following your explanation, I wanted to add the following observations:
-
I was able to intentionally reproduce the SIMCONNECT_EXCEPTION_TOO_MANY_OBJECTS Exception, but only with purposely built test programs, and in some situations, I’ve seen it in diagnostic logs provided by users, but not very frequently.
-
I never got the SIMCONNECT_EXCEPTION_TOO_MANY_REQUESTS, ever.
This is weird, because the empiric observation seems to be the opposite of what is supposed to be, because, we surely reuse DataDefinitions for different objects, but we also need to create individual Request for object, precisely because we need to track and control movements for every object we generated. This is in GSX and I guess it should be similar for AI generation add-ons, I expect they would reuse DataDefinitions, but consume quite a bit of data requests.
However, I never got a single diagnostic log containing the TOO_MANY_REQUESTS Exception, but I got very few logs with the TOO_MANY_OBJECTS Exception, and these are also very rare
Of course, in our diagnostic log, we can only see “our” Exceptions, not the ones eventually sent to other clients, so maybe they are happening, but we wouldn’t know, unless the user enabled the overall Simconnect diagnostic mode.
However, we can easily see the effect of what we always attributed to the Simobject limit, and it’s very consistent to how many Simobjects are already in the scene, suggesting the overall number of Simobject in the scenery does affect all add-ons, and they manifest as follows:
-
First objects start to disappear. This stage of the problem looks like as if the sim is not accepting creation of new objects anymore, because it seems to affect only objects created via Simconnect.
-
The 2nd stage of the problem is sometimes entire airports disappear usually at landing.
-
The 3rd stage of the problem shows a sharp collapse of the frame rate, dropping to extremely low levels, like 2-3 fps.
-
In some rare cases, after the fps drops, the sim might eventually crash.
In almost ALL situations, reducing the overall number of Simobjects created by all running add-on will fix this.
As an example, we supply GSX with two sets of pre-made .BGL, to replace Jetways on default airports.
One set includes extra “ground clutter” like Traffic Cones, FOD Bins, Towbars, randomly placed around Parking spots, to add extra detail to default sceneries, and these are added as Simobject embedded in the .BGL, so there’s no Simconnect involved, but on a large airport, they might add 150-160 Simobjects.
The other “lightweight” set has the same .BGL, without those extra Simobjects, so 1 default Jetway in the original scenery is being replaced by 1 custom Jetway, resulting in the overall number of Simobjects added by the .BGL being the same as in the default scenery. This has been confirmed by multiple users that helps A LOT in preventing the problem, at least on default airports.
Are we possibly looking at a completely different problem here ? These are Simobject added statically in a pre-compiled .BGL, yet they seem to contribute to the problem nonetheless.
Is there some other check possibly related to memory allocation or scenery complexity in general ?
And why entire airports disappear ? Is it possibly related to the fact airports buildings don’t usually use multiple LOD levels, so the strategy to disable objects with less than 3 LOD starts to kick in ? Is that behavior currently enforced on PC, or it’s just an Xbox-specific thing ?
Because from all users reports and empiric observation of the problem and the resolution, while from a purely Simconnect point of view the Simobject limit might not be global, we just had too many reports that, the overall number of Simobjects does have an effect and when acting on multiple add-ons settings to reduce the number of objects created, the problem is almost always solved, so maybe there’s more to it than “just” Simconnect DataDefinitions and Requests ?
Another example, sometimes I can see the issue in action in the Devmode Debug SimObject window: If I go to a very dense airport, with lots of Jetways, lots of Ground Vehicles and AI airplanes, I can see the list of Simobjects is already large, with Simobject reportedly created by different sources. Then I run any app that creates Simobjects (GSX, but not only), and when the number of objects goes up ( surely way less than 1000! ), I start seeing new objects being created in RED, as if their creation failed because there were already too many objects in the scene.
The same exact code, running on a smaller airports with few or no jetways and less traffic, no problem.
Hi @Umberto67,
Is there any chance you would still have the test programs you used to trigger the SIMCONNECT_EXCEPTION_TOO_MANY_OBJECTS? Reading your post, I started wondering if we had mistakenly done something wrong with the SIMCONNECT_EXCEPTION enum but it doesn’t look like it.
What I did to investigate the issue is to create an external EXE that purposely creates too many DataDefinitions and then too many Requests - getting the exceptions I described along the way.
- I could easily spawn 10k SimObjects without any error (but not monitoring them with a request)
- I could easily get the TOO_MANY_REQUESTS exception when creating too many requests.
- I managed to workaround the limit (please don’t do this!) by creating multiple connections (multiple handles through SimConnect_Open).
I haven’t seen SimObjects disappear, even when using multiple instances of my test EXE, so I am curious to know if someone knows how to reproduce this easily.
Your remark about SimObjects spawned through BGLs is very interesting, I’ll talk to my colleagues to check if this could actually be related. I’ll also double (triple) check the whole code to see if I missed a potential limit put somewhere else.
You may very well be right when writing “maybe there’s more to it than “just” Simconnect DataDefinitions and Requests” - we’ll find out and I’ll keep you all posted here. In the meantime, if anyone has a working example of a SimConnect client allowing to reproduce the issue, I’ll be happy to use it to investigate.
Best regards,
Eric / Asobo
I will run a few checks and write you a demo setup if I can get it replicated - not really tested it over the last months
Was able to replicate the issue
1423 Injected airplanes, some are invisible. I guess it might be performance related and the Sim is not loading them - or just very slowly?
@EPellissier will send you the Demo
While looking into the bug with the test app I mentioned before (spawning 10K giraffes), I noticed that they did appear a lot more slowly than I would have expected - I guess it can be even worse with more complex SimObjects such as planes.
That being said, when waiting long enough, I had my 10K giraffes in the scene.
I haven’t looked into this part of the issue because I assumed that people had waited long enough before stating that the SimObjects were not spawned - the truth is, as soon as you can see a bounding sphere it means that the SimObject has spawned, so maybe the real issue is that the models take too long to load?
@Kaiii3, I’ll be happy to check the issue again with your sample app, thanks a lot for this.
Best regards,
Eric / Asobo
Hey Eric, wirh that info i guess the issue are the longer loading times.
I always had the sphere visible while noticing the issue, but my frames were never that low that i would guessed that is is just slow loading… because we saw the issue somtimes still after 15minutes.
The test App is using default airplanes, that might have a bigger impact on Performance compared to optimized AI objects. I can send you low poly objects if you need them as well.
Just my $0.02 on this topic - I devised a scheme that loads/unloads SimObjects dynamically based on range parameter from the observer (current user aircraft) and this works very well. Would I be able to see a proverbial giraffe from 500m away? No 