ZDoom

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

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...)

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.

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.

Hi _mental_, I'd just like to say THANK YOU for [url=https://github.com/coelckers/gzdoom/commit/fc1f14b2ebfe1b1bebdd863054a6fd9f31692f8a]this commit[/url] 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

Here's the [url=https://github.com/Realm667/WolfenDoom/commit/a15e0813270de107fe6eb277e4e556018d119952]WolfenDoom commit[/url], and the [url=http://www.ciinet.org/kevin/myimages2/doom/bugs/save8.zds]savegame[/url], 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.

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

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.

[quote="Nash"]if your changes get merged, I can easily test (with my project) save/load and level-travel.[/quote]
Actually why don't you test the PR now with an inhouse build?

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.

Ok I'll try to recreate it and provide more detail, in a new thread. I'd actually already made a thread about it before but I A) can't find it right now B) it got closed as a "don't do that", so I didn't pursue it any farther.

Waterlevel is just a member of Actor, it also gets serialized. See p_mobj.cpp, line 268. If you cannot give specifics about the crash it's hard to investigate.

[quote="_mental_"]
It's all about pointers. Other types like integers cannot be the primary reason of such issues.
[/quote]

Could it be that it had trouble accessing the "waterlevel" variable? I mean not the integer value of it. I mean, it can't even find the variable.

I'm sorry if this is unhelpful, I'm not much of a programmer. :) At any rate, if your changes get merged, I can easily test (with my project) save/load and level-travel. Hopefully the crashes will be gone.

[quote="Nash"]_mental_: a long time ago, I've had similar crash-on-load - and also traveling back and forth between hub maps - triggered by having a certain inventory item on the player, and debugger showed it was related to actor waterlevel. Perhaps you can add that to your list of serialization fixes?[/quote]
It's all about pointers. Other types like integers cannot be the primary reason of such issues.

[quote="drfrag"]I wonder if LZDoom is affected as i didn't merge the level refactor.[/quote]
Cherry pick [url=https://github.com/coelckers/gzdoom/pull/1039/commits/0ed3dac686053513bda6068f60514ff642461001]this commit[/url]. If it begins to error out during saving or loading, it's affected.
It may require several tries to reproduce one of these bugs. Maps with portals have higher chances.
I won't be surprised if you will encounter a serialization error even with all three commits merged.

I wonder if LZDoom is affected as i didn't merge the level refactor.