Amnesia: The Second Dimension [READY FOR LAUNCH]

[MrBehemoth]

Yeah, perhaps I should join in on this testing and experience the crashes myself. That'll probably give me a better idea. PM?

I'll PM you and Amn shortly, just uploading the "custom stories" version.

Do these loops run on a timer? If so, maybe you're able to stop the timer in OnLeave() and restart it in OnBegin()? This may allow the Engine a moment to slow down and readjust itself. Over time, a timer, even if it is set to update every 1/10ths of a second, it will fail to catch up and either try to fix itself or say "I need more memory" which may be also what is happening. (I've noticed this in a few apps I make in VB.Net.) The only problem is if these timer's update 'global' things, which you'll have to store before you stop the Timer.

If you've already done this though, disregard

Yeah, that's about right Rom, but I've already done it. All looping timers are stopped and the engine is given a few seconds to catch up with itself before changing maps.

Hey, listen, I just tested this timer error on a new cs, empty level.
I reproduced these timers there plus a counter var, and the results are these:

Aprox. at 65,000 timer calls the game crashes. Not right away, just when you attempt to load another level (or the same).

The error it's always the same, an access violation

Spoiler below!

Which it's when it tries to access something that doesn't belong to it. -according to internet-

The curious thing is, this number 65,000 is very close to the data type uint16 (mentioned here.)

So maybe the game is trying to control/organize his timers using an array that its
index is an uint16 data type. (65,535 max.)
And the crash happens when it tries to load back that data, one that was stored beyond that limit (and failed).

Anyone can confirm any of this? I'm just guessing.

Good thinking! It's go to be this, it makes perfect sense. This is pretty much what I already suspected (some memory range is overflowing), but I never thought of counting the loops. It would also explain why it's not directly related to system memory and why it lasts a bit less that 10 min, whatever levels I playtest. Some levels seem to bring it on slightly earlier, and come to think of it, those are levels that use lots of timers themselves.

I guess that each iteration of a timer is given a unique index as a uint16. It would make sense as FG would never have needed 65,535 timers, and would not have suspected that a modder would need even more.

Now, if this is the case, it's kind of a brick wall. Even if I consolidated the 3 loops into one loop that only runs 30 times a second (which makes the player character look awful) and had no other timers (which would be difficult if not impossible, and would severely limit gameplay options) then the engine would give up just short of 20 minutes in.

I can't think of a way of doing this without this many timers. The only alternative would be functions that don't exist, or if FG release an update that uses uint/uint32 to index its timers... and that's not gonna happen.