Savegame breaks in Blade of Agony

[drfrag]

Thanks as i understand those errors are random and rare until now that the problem has been exposed, may be merging them before the next release could make things even worse.

[drfrag]

if your changes get merged, I can easily test (with my project) save/load and level-travel.

Actually why don't you test the PR now with an inhouse build?

[Talon1024]

I built my own build of GZDoom from the code in mental's fork, and I noticed something interesting.

I have a savegame on INTERMAP before C1M2, and if I load that save from the main menu, the game will fail to save once I enter C1M2 due to an out-of-bounds array value, which is apparently "blockingline" (I modified the code to print the name of the variable being serialized).

However, if I start a new game from chapter 1, skip to INTERMAP, and THEN load the aforementioned saved game, the out-of-bounds array value issue will not occur.

[_mental_]

Please post this saved game along with the actual BoA commit hash.

[Talon1024]

Here's the WolfenDoom commit, and the savegame, which requires Freedoom: Phase 2 to be used as the IWAD in order for it to show up on the savegame list. However, I can't seem to reproduce the non-breakage after starting a new game and loading that saved game.

[Nash]

Hi _mental_, I'd just like to say THANK YOU for this commit which finally brought me directly to the source of my problem with dangling pointers and apply a solution for it. This has been plaguing our project for almost a year, maybe even more. :D

[_mental_]

There is a chance that some pointer serialization issues are still present in the engine itself. So, the corresponding errors may occur even with valid scripts.
Unfortunately, it's impossible to find them without very extensive testing. This, in turn, is impossible without committing my changes to master.

[SanyaWaffles]

I just encountered this in my own project. The same blockingline. I've never encountered this before.

My main thing is I have genuinely no idea how to fix this now.

[Nash]

While I was lucky in that I knew where the problem came from (I knew which actor to look for from the start); I think one improvement that can be added to the help text is print some more detailed information, like which actor class is trying to serialize the dangling pointer? What do you think, _mental_?

(This is relevant only for actors obviously, for the other sources of dangling pointers, I have no new ideas, plus I've never encountered them yet so far...)

[_mental_]

It's not that simple. There is no such information available at the place of added checks.