After looking back over my old code, which I havent played with in quite a few of months,
I found my "partially" developed linked-list system that I was going to use with my terrains...
Since then Ive gone for an array(grid) with a fixed number of pre-created entities.
My old stuff has MUCH in common with yours, including a NOTATION suggesting more research/testing
of an "ent_create as needed with limit" approach. Sound familiar?
Some other 'notes to self' were as follows.
Dual linked lists. Identical structure, one is 'active' other is 'spare'. Entity moves from list to list as its status changes.
Dual-priority ent_recreate [you called yours ent_create_2]. Dual priority calling.
HIGH priority = use first found 'spare' entity. LOW priority = search list to try to find matching model to requested one.
ent_idleize (your ent_remove_2) PASSABLE, INVISIBLE, Z=-5000, kill any actions.
And thats just a few.
I too am concerned about ent_morph, and because I normally need to use ent_clone alot, I worry about it too.
With your usage of Malloc, Free etc, you should shift to SYS_malloc and SYS_free etc.
More engine friendly, and they DO release all memory for re-use...
ALSO!!! BEWARE OF sizeof.... check my posting in the BugHunt forum.
Actions are not a problem. But they are 'faked' actions. Like so...
void My_Action(ENTITY* ME)
{
me = ME;
...
everything else as normal
And you just call it from inside the ent_recreate function, with the 'new' entity as the parameter.
And inside the entities action-loop, just watch to see if "I" am in the ACTIVE linked-list,
or in the IDLE linked-list. If I am in the IDLE list, just execute a RETURN;
I would never do something this 'dirty', but you get the idea.
But Im not actively working on this ATM... A few sub-projects stand in the way.
Im helping Esper out with his menu system, and I've got some outstanding weapon-system stuff for 3run I gotta get to,
and then I have to take a look at my ancient port-IO contribution for someone...
Busy, busy, busy...
