 |
It seems that there are about 8240 events pumped during game loading. If I bump MAX_EVENTS to 16K, then I get error in idEvent::ServiceEvents ("Event overflow. Possible infinite loop in script."). If I then bump MAX_EVENTSPERFRAME to 16K too, then save is loaded properly. Now the question are: 1) Is there any sure upper bound on the number of events generated? Is it approimately "one event per entity"? How much would be enough? 2) Maybe we should not stress event system with all these? |
 |
It seems this mission is pushing too hard against limits, given the number of complaints filed in its release thread. I encountered this with one of my missions, and the way I solved it was to not try to do everything at mission start. Delaying some events by a few seconds at a time when it doesn't matter allowed the event queue to flush itself almost back to zero and make room for new events. |
|
|
But this event is hardcoded in C++ code for every loaded object. The description shows the place in the code where it is pushed. |
|
|
Is it crashing because there's a problem in the line of code, or because the queue is too full to add another event? |
|
|
SWAG: if (cameraTarget) { PostEventMS( &EV_UpdateCameraTarget, 0 ); } Would need testing. |
|
|
Yes, doing this conditionally is much better. Could you explain 1) what this event does? 2) what is cameraTarget and in which cases it should be present? 3) where can I find maps for testing this "camera" thing? |
|
|
With such fix there are only two "camera" entities which post the event. Hence, I get about 200 events processed initially, instead of 8K+. Still wonder what are the cameras and how to test them. There are two of them in this map. Is camera used for a cutscene when player goes to bed? |
|
|
A camera GUI (a screen viewable by the player) can obtain its view from different entities. Think of it as a single screen where the player can touch multiple buttons and bring up the views from multiple cameras. This code comes from id. By changing the cameraTarget spawnarg on the GUI during runtime, the screen display gets changed dynamically. I'll attach a test map. |
|
|
In the attached map, you'll find two buttons on each side of the main screen. Press the lower button on either side and the screen view will change to the appropriate camera view. |
|
|
I looked at the Marsh map, and as I suspected, it's right up against the entity limit. So having each and every entity coming in during a loadgame setting up an event to make sure its (possibly non-existent) cameraTarget is updated will easily overload the event queue. |
|
|
So I believe the test proposed above will fix the overflow problem. To test: 1. Make the fix. 2. Save/load the game with one camera displaying on the screen GUI. The display should still come from that camera after loading. 3. Press the button to switch to the other camera's view. 4. Repeat 2. The possibility of a crash w/o the fix is NIL in this map because there aren't enough entities. The test is focused on making sure that the GUI displays the correct camera view after each loadgame. |
|
|
I don't see anything in the attached test map. There are three black screens: one is a bit larger without margins, the other one has four buttons around it. It toggles between black and wooden material when I toggle the left-upper button. I don't see anything like security camera, and clicking other three buttons has no effect. Does it work for you now? Did it work on some particular version? Is it used in real maps/upcoming maps? Did someone requested it? P.S. I also see a bunch of "uninitialized member" warnings in debug build with this idSecurityCamera. |
|
|
I don't know why it doesn't work for you. It works fine for me. Atm, I don't have the time to try to rectify it. Sad, but true. At this point, my recommendation would be to go with the suggested fix. The issue is to eliminate the crash, not to debug the test map. |
|
|
Committed the fix in svn rev 8191. Also bumped number of events from 8K to 10K to avoid such nasty cases in future. Mappers should hit the entity limit only, not many limits at once. |
|
|
Thanks for finding the root cause and committing the fix. Since you've set this as a fix to 2.08, I'll have some time at some point to do some testing; just can't manage it atm. I'm going to change the status to 'feedback' from 'resolved' as a reminder to myself to do the testing. |
|
|
I need to test the fix to make sure that skipping the initial update at loadgame time isn't detrimental. I doubt that it is. |
|
|
Well, I have some worries about cases like "save game, enable camera, load game". Another idea is to filter entities by class. I.e. post event only for the entities of idCamera class or something like this. If it is even possible to do this. |
|
|
That won’t help. Any entity can have the cameraTarget spawnarg. |
|
|
I need to test this. |
|
|
Was it tested? Could you please test it and resolve with target&fixed-in = 2.08 ? |
|
|
Tested 5x with 2.08. No crashes. |
- Anonymous
