Leaderboard

Committed all the changes to trunk: 8761-8764: new diagnostics for event overflow error. 8765-8766: new cvars: crash on error (allows saving crashdump), promote warnings to errors. 8767: fixed the main problem with flying AIs which caused event spam in Hidden Hands.

I have implemented some code to simplify diagnostics of events overflow without a pocket coder When number of alive events exceeds 2K (controlled by g_eventAliveSoftLimit), a warning is posted to console every 5 seconds. Along with this warning, 10 currently alive events (controlled by g_eventNumberPrintedOnLimit) are printed to console. Half of them are chosen randomly, the other half are the very last in the queue. When something bubbles the event queue, all of the printed events will most likely be related to the problem. For instance, here is what I see for Hidden Hands: WARNING:Soft limit of alive events exceeded (2048)! Some events printed below: Event idAI::_reEvaluateArea on elemental_l2 at T=10351854 Event idAI::_reEvaluateArea on elemental_l1 at T=10353214 Event idAI::_reEvaluateArea on elemental_l2 at T=10354606 Event idAI::_reEvaluateArea on elemental_l1 at T=10359374 Event idAI::_reEvaluateArea on elemental_l1 at T=10363582 Event idAI::_reEvaluateArea on elemental_l2 at T=10368174 Event idAI::_reEvaluateArea on elemental_l2 at T=10368190 Event idAI::_reEvaluateArea on elemental_l1 at T=10368190 Event idAI::_reEvaluateArea on elemental_l1 at T=10368206 Event idAI::_reEvaluateArea on elemental_l2 at T=10368206 Total: 2048/10240 events alive WARNING:Soft limit of alive events exceeded (2662)! Some events printed below: Event idAI::_reEvaluateArea on elemental_l2 at T=10353470 Event idAI::_reEvaluateArea on elemental_l1 at T=10354414 Event idAI::_reEvaluateArea on elemental_l1 at T=10363566 Event idAI::_reEvaluateArea on elemental_l2 at T=10363630 Event idAI::_reEvaluateArea on elemental_l1 at T=10367598 Event idAI::_reEvaluateArea on elemental_l1 at T=10373182 Event idAI::_reEvaluateArea on elemental_l1 at T=10373198 Event idAI::_reEvaluateArea on elemental_l2 at T=10373198 Event idAI::_reEvaluateArea on elemental_l2 at T=10373214 Event idAI::_reEvaluateArea on elemental_l1 at T=10373214 Total: 2662/10240 events alive ... Aside from that, the new command listEvents prints all the currently alive events to console. When number of events processed in single frame exceeds 5K (controller by g_eventPerFrameSoftLimit), warning is posted to console. In fact, two warnings are posted: the first when it hits the limit, and the second when processing ends (if it ends properly, of course). First 10 events (controlled by g_eventNumberPrintedOnLimit) after exceeding the limit are printed to console between the two warnings. Here is how it looks in Painter's Wife: WARNING:Soft limit of 5120 events per frame exceeded! Some events printed below: Event idThread::<immediateremove> on multistateposition::onMultiStateMoverArrive at T=20318312 Event idThread::<execute> on tdm_elevator::storeTrigger at T=20318312 Event idThread::<execute> on multistateposition::onMultiStateMoverLeave at T=20318312 Event CMultiStateMover::propagateSound on marlow_elevator at T=20318312 Event CFrobDoor::propagateSound on scissorgate_1 at T=20318312 Event idThread::<immediateremove> on multistateposition::onMultiStateMoverLeave at T=20318312 Event idThread::<immediateremove> on tdm_elevator::storeTrigger at T=20318312 Event idThread::<execute> on multistateposition::onMultiStateMoverArrive at T=20318312 Event CFrobDoor::propagateSound on scissorgate_1 at T=20318312 Event idThread::<immediateremove> on multistateposition::onMultiStateMoverArrive at T=20318312 This spam gets posted every frame when the limit is exceeded, without any speed limit. I think if someone manages to consistently process 5K+ events per frame, the game will slow down dramatically, and playing it won't be nice anyway. Interestingly, there are several moments when I see 1100 or 2700 events processed in one frame during game start. These events are usually something like calling postspawn function for most of the entities. If we see a problem with it in the future, I suggest increasing the limit x10 times during the very first frame after game start of game load. UPDATE: Created issue 5270 for improving events overflow diagnostics --- that's worth being tracked.

Aside from fixing the actual problem, I think we should change something in the event system in general. Here is my proposal: Post a warning if 2K and 5K events are created (either in total or per frame). Mappers should know about the problem far earlier than it starts crashing. When soft limits named above are exceeded, print some information about a few events in the queue. It should make it easier to diagnose the problem without serious code diving.

Hey everybody, As some of you have seen, I started streaming myself making a level for The Dark Mod, with the intent of showcasing the process of making a level. About a year after starting, I'm releasing the first playable version of the map, and would like people to play and give feedback. It's still very early on and very rough; mostly I'm concerned about the layout of the map at this point and the "funness" of it. If you're interested and okay with filling out a survey I can review the results of onstream, let me know! I'll post a thread for the map in the Beta Testing forum in the morning.

Speaking of the second case with an elevator in Painter's Wife, it looks like an error in the custom script. The script code for onMultiStateMoverLeave was: if (door.IsOpen()) { door.Close(); tdm_elevator elev; elev=mover; sys.waitFrame(); elev.stopMoving(); //mover.disable(); while(door.GetFractionalPosition()) { sys.waitFrame(); } //elev.lastTriggeredBy.trigger(elev); elev.activate(elev.lastTriggeredBy); So when you call and elevator, which is at some station with door open, it starts calling activate, which in turn calls onMultiStateMoverLeave again, creating an infinite loop.

Here is another announcement, arguably more important than what would happen to 32-bit executable. Starting from version 2.09, TDM will not run on Intel HD 3000 and below. The reason is that TDM 2.09 will require OpenGL 3.3 to run. OpenGL 3.3 is the final version of GL 3, and both NVIDIA and AMD have updated their drivers to support it on every hardware which supports GL 3 (e.g. GeForce 8600 from 2006 is OK). Despite Intel HD 3000 being only 9 years old, Intel has already discontinued it (last driver update in 2015, no Win10 support), and did not upgrade the driver to version 3.3. Going with GL 3.3 will greatly simplify rendering code, and will finish the effort of removing deprecated stuff. There is no plan for further increases in required OpenGL version. OpenGL 3.3 will be enough to play TDM for a long time. More recent OpenGL features will be used via extensions, only in case your hardware supports them. Speaking of TDM 2.08, we tried to do our best to support HD 3000, leaving some hacks around. Despite that, we bumped into problems with running the game on the GPU when we accidentally found it. In case you are trying to play TDM 2.08 on Intel HD 3000, please set cvar: r_uniformTransforms 0

Feel free to enjoy whichever brand of dog food you like.

I'm trying to reproduce using this data in Hidden Lands, did not succeed from the first try, but succeeded on the second. The culprit is idAI::_reEvaluateArea on two elementals: elemental_l1 and elemental_l2. They spam all the 10K events except for 60 normal events. These events are sorted by their time, which increases from 10313870 (current time) to 10431966 (two minutes in the future). All for same area 307. Investigating further.

2500 is still supported (ironically being the next generation to 3000) it's 2000/3000 and older that will be gone (and already are problematic) Windows 10 includes drivers for 2000/3000, even if Intel does not offer those on their web site But in my tests, r_uniformTransforms is not enough. I also had to r_useFenceSync 0 and only one of x32/x64 worked (can't remember which now)

I made both One Step Too Far and Down by the Riverside on an Intel HD 3000, so it's a shame to see that chapter come to a close. That said, the performance of that old chip has degraded so considerably with time that even the simplest test map runs at single digit fps, let alone any real map, which is unplayable even for the stoutest players.

Actually with an Intel HD 630 you *can* play @1280x720, no AA and no AO, Stencil Shadows and no Soft Shadows. See my last post in the beta thread.

I tried playing on my work PC (Ivybridge i7 quadcore with integrated HD Graphics 4000) once and it was literally unplayable because of single-digit FPS. So i would not expect the iGPU support to be missed a lot...