Any progs.dat/QuakeC risks reusing free edicts?

[Baker]

[Spike]

all engines reuse entities, if they're free.
you get a 2-second grace time before the entity can be reused (except during initial spawn, when the grace time is ignored completely).
if you exceed the limit then you get engine-specific behaviour (either reusing entities before the grace time runs out, or just out-right crashing).

if an engine doesn't give 2 seconds grace, then yeah, expect problems with mods that expect it.
players also go through a 2-sec zombie state on disconnect, preventing their slot from being reused and sucking up any warnings about bad packets. or maybe this is qw only.

only entities present just after spawn are given any baseline info. these entities are also assumed to remain valid for the entire game. its not really a problem if they're not, but meh.

[Cobalt]

Recently I became aware that nextent() will point to a free edict, at least in regard to DP.

DP luckily has a "wasfreed" () function to detect if it is a currently free edict, so I was able to continue past and ignore them because my code was only really looking for active edicts. The engine seems to decide / keep track of them, and its possible the engine will re-use a previously freed edict. Not sure if its a convienience based calculation based on RAM, or completely random.

Also, of note, if you makestatic() the ent during the game, or I think after the worldspawn() / Quaked stuff , its completely removed from the game....wont show on the ent list....but the engine will draw it for new clients entering an MP game. Becomes part of the sign on message if I recall?

[Spike]

nextent() is meant to skip free entities... sounds like a DP bug.
wasfreed() comes from FTE.
makestatic() acts as a remove(), yes. the entities visuals become handled by the engine somehow (svc_spawnstatic inside the msg_init buffer, if you must know). this builtin might be buggy if you call it at any point other than during spawn functions (ie: players currently on the server won't see additions to the msg_init buffer, although some engines *might* fix this by writing to both msg_init and msg_all although you might still see some flickering).

[Cobalt]

[Spike]