Could be a bug, or intended to be that way. Depends on weather or not you believe the freed ent is still really an ent if it was freed up already. I say, yea it would be technicly, but of course its now an irelevent ent in regards to what the progs considers otherwise useful in some way.
If you were to be debugging, and wanted to count how many ents in your mod of a certain class wound up being freed, I guess this could be a way to find them and count them....in code that may otherwise not be removing any other ents for example.
wasfreed() is def a neat one, glad you added it.
Strange , to me remove () should act more like makestatic () as the remove does not really remove the ent, "frees" it up, is not the same as completely discarding it, which is closer to what makestatic does - if you go nextent and walk down the ent list, you wont find any makestatic ents ever.
I did have a need for something along these lines where I was redoing the bubbles code for the air bubbles, and in the case where the bubble traveled up and was blocked by a piect of the map sticking out, it would travel randomly around , and if it could now move past the obstacle, it would begin traveling up again. The case where it would never find an exit would be a timeout after moving around for a long time, then I would count how many of those cases there are, and if too many would be an fps hit, I decided instead of removing them, use makestatic. Of course if you watched this process happen, the bubble would disappear, unless you reconnected...then you would see the bubble in the last place it was at, not moving. Experiment concluded, though it would be nice if you could classify those kinds of ents somehow so that they dont disappear, or somehow get them to be only moving around a small fraction of what they use to and have it only client side. Perhaps csqc would be a possibility?
Spike wrote: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).