ZDoom

In custom ZScript code, it's practically become a regular thing that every single call to DamageMobj needs a null check afterwards because some actors will simply stop existing and become null immediately as they have no Death state defined. Some people don't know this, and it ends up causing VM aborts, and it has to be patched up. Besides, something like this makes it difficult to perform other operations afterwards, such as spawning/tracing blood from the actor after it takes damage.

I don't understand why the base Actor class can't just have a simple Death state that's a single TNT1 A 1. Would that cause some sort of problem?

A default death state cannot be added because some features check the presence of the state. What could be done is to switch to a dummy state if a null state would be set otherwise.

Would going in the other direction, namely making actors non-destroyable by regular damage by default not achieve the actually desired result, actors not being removed unless they are supposed to be killed?

ZzZombo wrote: ↑Fri Feb 10, 2023 8:41 am Would going in the other direction, namely making actors non-destroyable by regular damage by default not achieve the actually desired result, actors not being removed unless they are supposed to be killed?

That's not what the issue is here. The issue is actors that are supposed to be destroyable, like monsters. It's not uncommon for monster mods with "fancier" effects to spawn something like an explosion effect for monsters like lost souls and instantly remove the monster actor, and that'll trigger this issue.

Honestly, the real issue is that any pointers to a shootable actor like this get instantly NULL'd within the call to DamageMobj so it's practically impossible to do anything with them after the fact.

In that case make it a habit to inherit from a custom actor that defines a death state.
We cannot change the original for backwards compatibility reasons.