I understand what you're saying and know the terrains are flat, but didn't realise you can't remove the terrain due to it not releasing memory.

Either moving terrains is the issue OR not releasing memory when removing terrains. As moving terrains has been like this since I remember and there's no plan on changing this, our problem is not being able to remove a terrain efficiently.

If moving terrains were possible, you'd only need to create n amount of terrain tiles and move them around which you could just make in MED or at least prior to runtime and not require using ent_createterrain.

(You will always have the problem of not being able to exceed the limitation of a VAR though).

Okay, last question from me: Have you tried ent_create instead of ent_createterrain?

I see how that might perhaps be what you're already doing, and the example you posted was just using ent_createterrain to be an asset-free example we can all run, but just checking. ent_createterrain inherently creates a new terrain file, while ent_create would allow you to re-use terrains. Using that in combination with ent_purge might just do it.

I've had look at ent_create for .hmp files and still have the same problem of not releasing memory on ent_remove with or without ent_purge.

MrGuest: (first post) Correct on all points, and an excellent summation
of this entire thread, and clear description of the reason for my first post.

Jibb: Yeah, I have GONE BACK to working with entities now. But I was HOPING
that terrains would be do-able, but at this point it looks like terrains are out.
So back to working with entities it is. I AM makeing progress with them.
But terrains would have required less 'messing about' than entities require.

MrGuest: (second post) Yeah, but BOTH HMP's and MDL's dont release ALL memory on removal.
Thats just how the engine works. And after a long discussion with JCL an age back,
it made sense how thats the only way it can work... Assuming I understood him correctly.

Actually, I meant ent_create-ing terrains. It's possible according to the manual, anyway.

No can do JibbSmart. It suffers from the same memory-hungry losses.
But creating a fixed number of entities and re-using them is working so far.

Okay, that's ridiculous (as you're obviously already aware). Glad you got it working with MDLs.

Jibb

Its very IRRITATING, but not actually ridiculous, as JCL explained to me once.

We'll see how well I remember. Its all got to do with how GS caches its memory.
Im just talking about "level-cache" memory, not video memory...

Lets say you ent_create 'ModelA', and it uses 100K of memory.
Later on, you ent_remove it. This memory is no longer used, but is still cached.
Now ent_create another 'ModelA', and it uses ANOTHER 100K of memory.
Later on, you ent_remove it. This memory is no longer used, but is still cached.

Thats where all the memory goes... BUT, its not really that bad, because if
you do a level_load or a level_free, THEN the memory is completely cleared and released.

But thats no good to ME, because I NEVER DO any level_load or level_free's because
I dont want to lose ALL the game-objects created since the last level_load or level_mark.


Do you want further reasoning about WHY the ent_removed memory stays allocated?
I cant remember sorry, all I can remember is that the memory DOES get used for
other stuff, but never re-used by entities.
I THINK it was something like that GS doesnt know how much level-cache an entity
will need until it is FINISHED loading into cache, and so to avoid trying to load
it into a 'gap' that is too small, and thereby corrupting following data,
they simply avoid the issue by always getting loaded on the end of the cache.

Thats my understanding anyway...

Yuck. I never, ever level_load either (except on startup). That's really awful. But in my game I can probably handle it with some careful level_mark and level_free, as everything created after a certain point is temporary. In your situation that obviously doesn't work.

At least I learned something. Thanks.

my pleasure.