Yes, to be clear, I was just reiterating ideas people had stated here previously (and again to be fair the idea is not new).

Actually I would not extract them at all.

I may extract them when they're destroyed. But that would have a safe and deliberate process separate from life or death. Such as purge or maybe decay.

This wouldn't really just be delayed extraction. The concept in rom is usually removing the chardata and replacing it with objdata. I'd simply design a corpse to be chardata and never extract. It would still be a corpse the same.

Why make a duplicate? I don't get it.

If you don't move the character out of the list they're in until the END of the combat round, there shouldn't be any need to play these kinds of games. If there's some reason POS_DEAD isn't good enough, stick a NO_REALLY_IM_DEAD flag in the structure and set it, and make damage just return if the victim is dead.

Once the combat round is done, THEN go through and move dead players to their new location, replace npc's with corpses if you like, whatever needs to be done.

For that matter, I never understood why Diku felt the need to keep seperate structures for NPC's and players. But that's another story.

I went with a single interface for any living thing.

I kinda think its even less of a nobrainer as far as combining the pcdata and chardata goes. This is trying to milk more mileage out of the code as far as memory was concerned. However, the practice falls out of favor once the target platform always has more than enough ram. These days the matter of kilobytes saved isn't enough to warrant complexity in the code like this.

Maybe not new, but I hoped to have a more direct answer in my char_looping thread about this problem.
Seems like a lot of people still not get why you have to do this especially when you deal with area spell.
Or the one who do not see that testing for a null pointer will never work.
And a solution that can be applied to ROM without rewriting everything.

void example(int *Ptr) {
  free(Ptr);
  Ptr = 0;
}

int *test=malloc(sizeof(int));

example(test);
if (test)
    *test = 1337; // no good

Code via phone is pretty fail but here is an example for anyone who doesn't understand why the issue exists.

Memory concerns I imagine, as Runter pointed out. However it became popular in later years to try and make mobs act more like players, with some muds even introducing mobs that earned exp and gained levels.

It always makes me chuckle when some newbie announces how impressed they are that the mobs in my mud have proper stats and abilities, just like players - as if it was some clever feature that I'd added.

Nope, I just didn't see any point in splitting them up into different Creature types.

I remember once having a rather amusing bug where players with the same name as a mob would actually take over that mob's body when they connected. One player, by the name of Dragon, caused some serious havok before I was able to fix the issue…

Same here my mobs use the exact same methods a char use, with same limitation, same fight engine same saves etc, they are just a little beefier. And in ROM their structure is the same, so it is easy to do so.
both MOBS and player shares CHAR_DATA, PC_DATA being specific stuff like host, last connection, and some other useless stuff for mobs.