View Issue Details

IDProjectCategoryView StatusLast Update
0005028The Dark ModCodingpublic27.08.2020 14:45
Reporterstgatilov Assigned Tostgatilov  
Status closedResolutionfixed 
Platformx64OSWindows 10 
Product VersionTDM 2.07 
Target VersionTDM 2.09Fixed in VersionTDM 2.08 
Summary0005028: Crash on loading game in March of Rahena (EV_UpdateCameraTarget)
DescriptionI experience stable crashes on game load in "March of Rahena" map.

It always happens in idEntity::Restore on this line:
  // // grayman 0004615 - update the camera target (will handle a NULL "cameraTarget")
  PostEventMS( &EV_UpdateCameraTarget, 0 );
Sometimes it crashes when accessing player's physics being NULL, sometimes it justs exits in recursive error/fatal error.
In both cases, it happens while reporting "idEvent::Alloc : No more free events" error.

People playing the mission report similar problem:
Steps To Reproduce1) Start "March of Rahena" map.
2) Quicksave.
3) Quickload.

I got crash from first try on 2.07-hotfix.
It also always crashes in "Debug with Inlines" and "Release" configurations on current SVN.
TagsNo tags attached.


related to 0004615 resolvedduzenko Remote camera lost when saving\loading 




21.04.2019 17:07

administrator   ~0011749

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?


21.04.2019 17:20

viewer   ~0011750

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.


21.04.2019 17:34

administrator   ~0011751

But this event is hardcoded in C++ code for every loaded object.
The description shows the place in the code where it is pushed.


21.04.2019 17:36

viewer   ~0011752

Is it crashing because there's a problem in the line of code, or because the queue is too full to add another event?


21.04.2019 18:10

viewer   ~0011753


if (cameraTarget)
    PostEventMS( &EV_UpdateCameraTarget, 0 );

Would need testing.


22.04.2019 04:22

administrator   ~0011754

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?


22.04.2019 04:37

administrator   ~0011755

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?


22.04.2019 19:16

viewer   ~0011756

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.


22.04.2019 19:25


camera.pk4 (2,478,576 bytes)


22.04.2019 19:27

viewer   ~0011757

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.


22.04.2019 19:30

viewer   ~0011758

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.


22.04.2019 19:35

viewer   ~0011759

Last edited: 22.04.2019 19:35

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.



24.04.2019 15:37

administrator   ~0011760

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.


24.04.2019 16:50

viewer   ~0011761

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.


25.04.2019 03:16

administrator   ~0011762

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.


25.04.2019 13:19

viewer   ~0011763

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.


25.04.2019 13:21

viewer   ~0011764

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.


25.04.2019 15:55

administrator   ~0011765

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.


25.04.2019 16:48

viewer   ~0011767

That won’t help. Any entity can have the cameraTarget spawnarg.


23.11.2019 01:57

viewer   ~0011880

I need to test this.


28.06.2020 04:21

administrator   ~0012637

Was it tested?

Could you please test it and resolve with target&fixed-in = 2.08 ?


27.08.2020 14:45

viewer   ~0012765

Tested 5x with 2.08.

No crashes.

Issue History

Date Modified Username Field Change
21.04.2019 16:42 stgatilov New Issue
21.04.2019 16:42 stgatilov Status new => assigned
21.04.2019 16:42 stgatilov Assigned To => grayman
21.04.2019 16:42 stgatilov Relationship added related to 0004615
21.04.2019 16:45 stgatilov Summary Crash in EV_UpdateCameraTarget on March of Rahena => Crash on loading game in March of Rahena (EV_UpdateCameraTarget)
21.04.2019 17:07 stgatilov Note Added: 0011749
21.04.2019 17:20 grayman Note Added: 0011750
21.04.2019 17:34 stgatilov Note Added: 0011751
21.04.2019 17:36 grayman Note Added: 0011752
21.04.2019 18:10 grayman Note Added: 0011753
22.04.2019 04:22 stgatilov Note Added: 0011754
22.04.2019 04:37 stgatilov Note Added: 0011755
22.04.2019 19:16 grayman Note Added: 0011756
22.04.2019 19:25 grayman File Added: camera.pk4
22.04.2019 19:27 grayman Note Added: 0011757
22.04.2019 19:30 grayman Note Added: 0011758
22.04.2019 19:35 grayman Note Added: 0011759
22.04.2019 19:35 grayman Note Edited: 0011759
24.04.2019 15:37 stgatilov Note Added: 0011760
24.04.2019 16:50 grayman Note Added: 0011761
25.04.2019 03:16 stgatilov Note Added: 0011762
25.04.2019 03:17 stgatilov Status assigned => resolved
25.04.2019 03:17 stgatilov Fixed in Version => TDM 2.08
25.04.2019 03:17 stgatilov Resolution open => fixed
25.04.2019 13:19 grayman Note Added: 0011763
25.04.2019 13:21 grayman Note Added: 0011764
25.04.2019 13:21 grayman Status resolved => feedback
25.04.2019 13:21 grayman Resolution fixed => reopened
25.04.2019 15:55 stgatilov Note Added: 0011765
25.04.2019 15:55 stgatilov Status feedback => assigned
25.04.2019 16:48 grayman Note Added: 0011767
23.11.2019 01:57 grayman Status assigned => feedback
23.11.2019 01:57 grayman Note Added: 0011880
22.03.2020 12:07 grayman Target Version TDM 2.08 => TDM 2.09
28.06.2020 04:21 stgatilov Note Added: 0012637
28.06.2020 04:21 stgatilov Status feedback => assigned
27.08.2020 13:57 stgatilov Assigned To grayman => stgatilov
27.08.2020 13:57 stgatilov Status assigned => resolved
27.08.2020 13:57 stgatilov Resolution reopened => fixed
27.08.2020 14:45 grayman Status resolved => closed
27.08.2020 14:45 grayman Note Added: 0012765