I was thinking about this after I posted and I came up with a terrible solution (but that has some similarities with yours): loading on startup a certain number of each type of entity that will be repeated alot on the terrain. For example load 100 of tree1.mdl, another 100 of bush5.mdl, 100 of tree3.mdl, etc, etc etc... and moving them all to somewhere well hidden from (like lower than any terrain (vec_set(my.x, vector(0,0,-1000000))). whenever I need a tree instead of ent_load I just set its pos to the correct location, and instead of deleting one I just set it back to (0,0,-100000000). But I didn't really like this idea and it seemed like a very sloppy workaround with many limitations.

After reading your answers, ent_morph + storing unused entities seems like a very smart approach to this problem (and much better than my terrible&&painfull idea).

I have been thinking about this for a while and come up with a another concept to fix some of the problems both systems have. My idea has severe limitations. Your approach of loading a ship-load of entites + ent_morph for re-use is much better but also has certain limitations and a potencially extreme load time.

In another aspect of my game I have been working alot with malloc() sizeof() and free() for several linked lists, and this is what gave me the idea. We create an empty linked-list on startup and program our own ent_create_2 and ent_remove2 functions.

The linked list would just be a struct of 2 pointers, one entity pointer, and one struct pointer.

The ent_create_2 function first looks at the linked list, if it is empty it creates a new entity with our position and model parameters. else if there is already an item in the list, it modifies it position properties and uses ent_morph with the model parameter, and removes the item from the linked list.

The ent_remove_2 function sets the model's invisible and passable flags, morphs it to a very simple dummy model (one centered vertex), places it in a hidden location well under our terrains (0,0,-1000000000), and add the item to the linked list.

with this system you avoid having to create a ship-load of entites on launch, saving alot of load time. it only increases the amount of entities loaded when needed (you reach an area with more entities than the previous areas you visited). and in the worst-case scenario you will never have more entites loaded (used + not_used) than the zone you visited that had the most entities. This system also solves the problem of not knowing how many entities you will need before reaching a certain area.

My only concerns now are the free() and ent_morph() instructions... Seeing how ent_remove() works I am now scared that any other removal/modification instruction may also leave behind unused memory. But even though ent_remove() is terrible, if these other two instructions do work how they are supposed to we might have solved the problem with free() and ent_morph(). Do you think it is worth a try? Do you know if free() and ent_morph() also leaves behind unusable memory?

If this system works I will probably make it a separate module and include it in every future project and never ever use ent_remove again. (even on projects that dont have infinite worlds! After reading this thread I have developed a passionate hatred of the ent_remove function!)

The only problem I see with your approach (and also my linked-list approach) is that action functions cannot be used with entities using this system (and that potencially also includes events).

I will post back in a while with a modified version of my current linked-list system adapted for this problem.

EDIT: You made me laugh with this answer when re-reading my initial post: