Amnesia: The Second Dimension [READY FOR LAUNCH]

[Mudbill]

Looks like your mod was featured on the FG facebook page

https://www.facebook.com/permalink.php?s...2416275440

Perhaps they saw it after the PMs went out?

#SaveTheSecondDimension

[Daemian]

Looking good. I bet this is how they do tests at the particles accelerator(?)

[MrBehemoth]

Looks like your mod was featured on the FG facebook page

https://www.facebook.com/permalink.php?s...2416275440

Perhaps they saw it after the PMs went out?

#SaveTheSecondDimension

Yeah, they tweeted it too! Jens mentioned he'd already seen the trailer, so maybe that was Thomas. Now I'm officially not allowed to give up.

It's amazing how many comments there are on FB and YT from people who don't get that it's a mod.

Really? a game plataform? a mario? what a disappointment...I expected another adventure after the country walk of Machine of Pigs (well Waiting Sona then...)

Ahh, the lulz.

Looking good. I bet this is how they do tests at the particles accelerator(?)

Totally. At Black Mesa. Thanks for the help though, it was your idea that saved the day. +rep

Anyways, here's an update... Progress! The "timer-less loop" is now implemented for the player model and NPCs, and it has made a big improvement. It lasts over twice as long before crashing... yup, it still crashes eventually. But, there are still a lot of looped timers in use elsewhere. For example, whilst waiting for the player to read a message (dialogue etc), moving some objects one frame at a time, and some other random stuff.

Over the next few days my mission is to integrate every single timer loop into the "timer-less loop" instead, or as many as possible. Then we'll see how it goes.

[MrBehemoth]

So, like the title update says, not out of the woods yet.

Good news is that I can now play-test right through to loading the 5th level (that's 9 map loads, including the recurring scoreboard.map) before the crash happens, which is a massive improvement. The bad news is the same news as the good news. Here are my current thoughts.

Assumption: a timer is actually just a type of callback. If there is a limit on these as discussed, then it would include timers and all other types of callbacks on a single list.

Mine and Amn's tests showed that you could rack up ~65k timers in a simple map before a crash. That doesn't seem to be what's happening here any more.

I did a lot of work re-coding various systems to make use of the timer-less loop, which only uses 1 callback per map, and re-coded a few puzzles and cut-scenes to use it too, but I wasn't able to get rid of them all. At least not easily.

So to keep track of the remaining callbacks, I overloaded the AddTimer(), AddEntityCollideCallback() and PlayPropAnimation() functions so that every time they are called they are counted and logged.

(These are not used at all and are not counted: CheckPoint(), SetEffectVoiceOverCallback(), StartPlayerLookAt(), SetLanternLitCallback(), AddCombineCallback(), AddUseItemCallback(), SetEntityPlayerLookAtCallback(), SetEntityCallbackFunc(), SetEntityConnectionStateChangeCallback(), ConnectEntities(), SetMultiSliderCallback(). I'm not aware of any other function that could add a callback.)

The last play-through logged just 442 callbacks (211 timers, 228 collide callbacks and 3 anim-end callbacks) before the crash occurred on loading level 5. There would also have been 1 OnPlayerInteract callback per map, added in the level editor, making 451. That's less than 1% of the supposed limit.

I also logged all PlayPropAnimation() calls that don't pass in a callback name (asCallback == ""), just in case they contributed to the limit by some quirk. There are 1242 of those. I really doubt these contribute, but even if they did it would still only make 1684 callbacks total.


So, whatever is now causing the crash, it's something new. It's still not related to any specific map. I'm stumped again.

Anyone got any other ideas?

(Mudbill and Amn [edit: sorry, I mean Daemian], if you want an updated test version, just let me know.)

[Mudbill]

Hmm... This is some tricky stuff. If this issue is unrelated to the original callback issue, then it might take some time finding out what is causing it this time.

I wonder, if this is different than the last crash, would it still happen before? Imagining the callback crash was bypassed, would this crash still occur as a secondary crash? I'm just asking myself here, really. Regardless, it doesn't matter as the original issue is gone. Well, at least so it seems.

Sure, send it over. I can take a look, but I don't know how much of the script I'll understand without some serious determination and research. Perhaps I'll come across a few ideas though.

[Daemian]

Careful... you may not be restarting the game.
Remember this overload thing happens at game level.

So if our tests were correct, if you never exit the game when you test, the counter never got reset.
Is this the case? Or is this crash actually new?

[MrBehemoth]

Naw, I'm absolutely, definitely restarting the engine in a completely clean run each test.

I'll package up a version for you Mud, and Daemian too if you want it, but I want to do a few more tests first.

Tonight I made a very basic level (just a corridor to the exit) and looped it. So it went like test.map > scoreboard.map > test.map > scoreboard.map etc, and it ran through 20 times no problem. I want to try that some more and maybe leave the player character standing in the corridor for a five minutes each time. If it never crashes from the simple corridor map, then I'll add in an NPC and test it again. That should help to narrow it down a bit. I'll let you know how it goes.

[MrBehemoth]

I decided to take a scientific approach to this. Over the last week, all of my free time at home has been spent doing experiments. Setting up test maps, using control groups, tweaking variables and processes, recording and comparing results. I don't know anything about statistical significance or any of that malarky, but, as of tonight I can make a few conclusions that I'm 99.9% sure are accurate. (Some of this has already been said.)

1) There is a limit on callbacks as discussed.

2) This includes timers.

3) Once the limit is passed, the engine will crash at the next load. However, it's possible to go way over the limit before loading. That's why it sometimes seems like the limit is ~65k. But using short tests and frequent loading over long periods of time, I've pinned it down as closer to ~58,300, or ~61,700 if OnStart(), OnEnter() and OnLeave() count as callbacks.

I don't know what the significance of these numbers is, unless it's 65,535 with some kind of deduction.

4) This is the important (and disappointing) part. This is not a limit on the number of callbacks (event listeners) you can add. It's a limit on the number of callbacks getting called.

To clarify, if you set up an empty map with two entities and used AddEntityCollideCallback() just once, with no other script, if the entities collide more than about 58,000 times then the engine will crash the next time it loads a map.

5) As well as relying on collision callbacks for all kinds of puzzles and gameplay features, the "timerless loop" uses 60 collision callbacks per second. All this is why almost entirely getting rid of timers made the mod last longer before crashing, but since it still relies heavily on callbacks, it mounts up to over 58k easily in about 15 minutes of play.

6) I really don't know what to do about this.

[Mudbill]

And even if one map reaches only 30k calls, the engine still crashes after 30k more in the next map? The issue was the engine's runtime, not the map runtime, right?

Hmm... No this is tricky.

If there is no fix, perhaps you would be able to add a "timer" timer to each level? By that I mean a time limit counting down. Not for gameplay reasons, but for engine reasons. Give, say, a 10 minute time limit for each level. Then also, at the end of a level, just give an honest warning that we're unable to avoid a crash unless the player restarts the game. It would be very sad to make it so much more difficult than it potentially could be, but we just gotta work with what we got. It would be better than nothing at all.

You could display a message similar to this:

"Warning: Due to the fact that this game engine isn't optimized for side-scrolling platformers, this mod relies on many loopholes to make it work. Unfortunately, these do not come without restrictions. If you wish to continue playing in this session, we urge you to exit to main menu and restart the mod. If you don't do this, you will likely encounter a crash we are unable to avoid. Really sorry about the inconvenience!"

If you add something like this, perhaps also include the fact that the game is saved, just to comfort the players a bit.

[MrBehemoth]

And even if one map reaches only 30k calls, the engine still crashes after 30k more in the next map? The issue was the engine's runtime, not the map runtime, right?

That's right. Engine runtime.

If there is no fix, perhaps you would be able to add a "timer" timer to each level? .....

Hmmm. I would do this as a last resort, but tbh it would really demotivate me to make more levels. I would have to think about it.


However ... I'm experimenting with one more idea. I'm not going to talk about it yet, but we'll see what happens.