The thread is/ was about two separate problems:

1) The Nexus variable in the debug panel "exploded" in some levels of my game, from an average value of about 40MB up to 7-49GB. The reason for this was simple though, the max_nexus set before you start the game simply was too low in some cases (in prior versions/ years ago there used to be an error message then).

2) For debugging purposes I've written a level protocol function which among others lists the functions currently running in the level. However, in my project (and at least one other project) there is one/ two functions which yield broken names and lead to crashes.

1) is clear - the displayed number was wrong in some cases - but can you upload an example for 2)?

A test project which has been reduced to a reasonable size in a reasonable amount of time has been sent to the support. Thank you in advance.

Have you already had the time to take a look at the sample project/ issue 2)?

At least partially. The developer had followed your installation instructions with the data.skd file, but still got error messages at start, and could not reproduce the problem with your game - there was also no "Continue", but just a black screen after the menu. But he found something suspicious in the engine_gettaskinfo function, apparently no function and entity names were returned under some circumstances. This will be corrected in the next update.

Thank you for the response. The error messages or warnings appear when no data.skd file was found on game start. I've just tried it again, unpacked the zip file, created a Superku folder (in "Eigene Dokumente"), copied the data.skd file there, and started superku_crashes.c with a Test Run. On the 4th try the L2C error appeared.

However, I hope the developer has found the issue even so.

This function still crashes for me.
Was the fix included in the most recent update?

Yes, engine_gettaskinfo was modified in that version. But it was maybe not responsible for the crash, as it could not be reproduced here anyway. Do you have a simple, stripped down example for reproducing the crash?

The problem with crashes in huge games is that it can take a long time of testing and playing around until we can see the problem, if at all. We've meanwhile collected a bunch of large games over time, all with described problems or crashes that we could not reproduce in a reasonable amount of time. The more hidden the problem is in such a project, the higher the chance that it stays unfixed.

Thanks for the response, I forgot about it.

Yes, I understand. The problem for me with trying to make a small self contained example in that regard is that I don't think I can make it crash each time even in my full game.
Maybe I should invest a week or two, playtest and log/ diag extensively and proofread the whole game code (for invalid array/ memory stuff, ...).

Either way I'm going to monitor this and try if I can isolate the issue.