OK, here is a VERY simplified version of what I need to do...



Now, my problem is this...
You can see I play with the mesh and skins in the 'ent_randomize' function.
AND I usually have multiple occurances in the level of each of the MDL files.

So, NORMALLY that means I need to do an ent_clone in "ents_startup",
and everything would be fine.


But, I am concerned that later the ent_morph will 'break' the ent_clone's changes.
So to allieviate that I would then NOT do an ent_clone in "ents_startup",
and do it after the ent_morph in "ent_recreate" instead.
That would probable do it I think.... (I really hate, but need, ent_clone)


Now for the big BUT! Here is an expected life-cycle of my entities...

So you can see the entities will be getting ent_morph'ed many times in their lifespan.
I am now worried this is going to cause a memory blowout due to calling
ent_clone multiple times on the same entity...


So... what Im looking for is this....

Has anyone else come across this hurdle before? How did YOU cross it??

Hell, is it even a hurdle? Would an ent_clone in "ent_startup" be all I actually need?

Does anyone know IF ent_clone gets broken by ent_morph?



FOOTNOTE::
I have been thinking about ent_clone in ents_startup and just doing a mesh-swap in ent_recreate...
But I would LIKE to avoid this if possible as it would cause me problems this post doesnt show...


Thanks muchly guys and gals...

Still looking for an answer on this from you guys....

NO ... Im not being very impatient ... much ... this is mainly an 'update'.

Ive done some testing and I was correct in my initial post.
Ent_morph DOES bulldoze over an ent_clone.

So if you perform the following, you will get an out-of-memory crash VERY quick.
Process "ent_create; do{ ent_morph; ent_clone; wait; }"

I am not so sure what exactly you're up to. If you use ent_clone and ent_morph later on you're just wasting memory, because the cloned data remains in memory. ent_clone is pointless anyways when you use ent_morph later on. If you really need this I'd just go the simple way:

1. Create the entity.
2. Use ent_clone as you see fits.
3. Instead of using ent_morph remove the entitiy. (This will free the cloned data)
4. Create another entity with the file you would have selected in ent_morph that replaces the cloned one.

Unfortunately, I CANT go the simple way. Also please remember that all
the code in my initial post is an EXAMPLE of what I need to do, NOT a snippet.

Once all the entities get created (by ents_startup), there will be multiple
other functions and actions that form links directly to some of these entities
BY REFERENCE, rather than be ents-index-number.

Because of this, I am unable to ent_remove any of these entities without risking crashes.
Thats why Ive gone with the ent_morph, which is a new function for me.
Ive always gone for the ent-remove & ent_create combo before now.

Seeing as I now KNOW that ent_morph 'breaks' the ent_clone,
then YES it is obvious that ent_clone followed by ent_morph is a waste.
And as I said before, ent_remove is not available to me.


So I think my next option is to try playing with ent_purge and ent_preload.
Maybe by juggling with one or both of them I can find a way to flush out the
ent_clone'd data and be able to reuse its memory space...
eg: "ent_create; while{ ent_purge; ent_morph; ent_clone; wait;}" ... or something.

Ok, here are some random ideas:

- ent_purge won't help you AFAIK as it only releases video memory.
- randomizing entities - you usually do this to make cloned entities less noticeable - can also be done with a shader.
- I'd ask JCL about the semantics of ent_morph. If ent_morph does not remove clone data from memory this can maybe be implemented in a future version.
- If you only have few entities to manag you could also create invisible and passable dummy entities for your managment code and let these dummy entites carry their visible counterparts around. This way you could remove the "coulisse" entities and recreate them.

So, i gave it a quick try and it seems when calling ent_morph the ent_clone memory isn't freed. If you let the following code snippet run for a while it will give you an out of memory error. You can even see the memory go up in the debug panel.