Saving failed due to BlockingLine

[Nash]

Also, Cooke, in case it wasn't obvious - are you getting that error with vanilla no mods, or with mods? If it's with mods, check the mod isn't doing any "Don't do that"'s. You know how wild it is with ZScript...

[Graf Zahl]

BlockingLine should be cleared at the very latest when the old map is freed in ClearLevelData. Whatever is in STAT_TRAVELLING at that point needs to be handled.

[Talon1024]

With GZDoom 53199e455, I got this problem at the beginning of Equinox MAP10 after leaving Equinox MAP09. If I play it normally, without any mods, and (mostly) let the monsters infight to the death, "blockingline" is out of bounds and I cannot save on MAP10. For some strange reason, however, if I god/noclip my way to the exit, the issue with blockingline doesn't happen.

[_mental_]

BlockingLine should be cleared at the very latest when the old map is freed in ClearLevelData. Whatever is in STAT_TRAVELLING at that point needs to be handled.

Should it be done like this?

[Graf Zahl]

I would have done it in ClearLevelData, before the travelling starts. But it will have to be checked if this is sufficient.

[_mental_]

Moved resetting of pointers to FLevelLocals::ClearLevelData() as it works fine as well. At first, I missed somehow that you wanted the code to be added to this function.

[_mental_]

Merged the change as it fixes the dangling pointers issue for inventory items.

[Marisa the Magician]

There's still one minor gripe I have with this. Sure, the I_Error calls were replaced with a Printf, but it's an unconditional print, rather than something that'd be silenced unless, say, developer message level is set to "warnings".

[_mental_]

Making these messages developer only would make a chance to catch related errors very slim.