ZDoom

Are there any global variables that reliably track the engine's "I'm-not-reading-script-code" state that can be used in this case to allow OnDestroy to function as normal?

Would adding the function override to the Canvas class in ZScript as a "final" instead be a viable alternative?

The lifetime of the canvases is tied to the lifetime of textures/textureids in the texture manager. The code was written under the assumption that the texture manager's texture list is static. If 'restart' reinitializes the texture manager then it should indeed need to be cleared at that point.

About changed OnDestroyed behavior in the engine, then yes throwing an exception here will break, but then what alternative is there really?

The canvas management is one big mess.
They are held in a static array that is never cleared, so they only get collected when the object system is shut down and the scripted OnDestroy method not called anymore. Should anything change here the error will be thrown in the regular destruction process.

This will also cause problems with the 'restart' CCMD, which should clear the AllCanvases array.

Then done with I_Error, this can be closed as suggested.

No, Canvas is a collection of engine managed objects. One for each canvas texture in the map.

If I read the Destroy function correctly (been some days ago I looked at it - could be wrong), OnDestroy is called before it marks it for destruction so as long as it doesn't get further everything is still in a sane state.

Isn't Canvas a static object? I think I'd rather fatal error out to avoid the risk of dangly pointers.

I_Error should be enough here.

class FCanvas : public DObject
{
...
  void OnDestroy() override { I_FatalError("Calling Destroy on a canvas object is not allowed."); }
};

I think the following might do the trick, but I'm not entirely sure:

[code]class FCanvas : public DObject
{
...
void OnDestroy() override { I_FatalError("Calling Destroy on a canvas object is not allowed."); }
};
[/code]

The null check actually doesn't do anything useful other than move the problem somewhere else where it can be traced better. Ultimately though, what seems to be the desired solution has not yet been implemented - and that is the blocking of canvas.Destroy()

Should this be closed? As far as I'm concerned, the issue was resolved on the mod's side and I saw Rachael pushed a Canvas-related null check a few days ago, so if this is all taken care of I'll go ahead and delete the test branch. Stale branches bum me out.

Fixed on my side. Been a while since I last ran into a blatant [Don't do that]. Turns out setting it to null was sufficient. Guess I used Destroy() because the alternative was to use SendNetworkEvent from UI scope to set the play variable to null. Shouldn't have been THAT lazy.

Guess I'll have to look into an alternative solution on my end then.

The only way I see is to throw an exception - preferably in the Destroy function, but if that is not doable, when the non-existent camera texture is accessed.

Nice spot, phantombeta. That Canvas.Destroy() is absolutely not allowed. What is the best way to block that?

The inability to reproduce was my fault entirely, sorry. I messed up one of the CVars. Either way, I can't make a smaller example because I don't know what exactly goes wrong but I did make a branch without the randomness (CVar is irrelevant now) so it should make things a lot easier and faster to debug. Plus I remembered you can turn off the TV manually.

https://gitlab.com/accensi/deathstrider/-/tree/crashtest
Fresh crash report just in case: https://files.catbox.moe/8j34ot.zip

However, I found some things while testing this on my laptop where it doesn't always crash after the episode stops. If you walk up to the TV and press use on it to turn it off after starting the level, without having to i_timescale or wait, then use "map map01", it'll immediately crash. Same thing happens when you fire the gun a couple of times, but not always. Pretty sure at least twice it also crashed when I opened the main menu after the menu sound played, though both of those cases require waiting longer. No idea anymore.

Hopefully this helps. As for the loading times, yeah, I really ought to do something about that later today.

@phantombeta:
Strangely enough this worked flawlessly until recently so something's changed. And I couldn't find another way to get rid of a canvas texture back when this was written.