Got is in one ... nearly. As I would expect of you.

Its being used on a grid of 'visible' entities that are the tiles in a
much larger array of custom-structs.

Have a look at Esper's latest post in Projects|"What are you working on?"


The grid is fully populated with null-entities after level_load.
Then the array gets fully ent_morphed with map-data defined models
by the map_load function, or a sub-function thereof.

Then as each row and/or column gets beyond a set 'distance' from the camera,
the entitys in that row/column gets physically moved to the opposite side,
and then ent_morphed into its 'base model' correlating to its new XY position
within the master map-grid. The model also gets rotated to an sppropriate PAN
value at this point. (to reduce the number of MDL files we need to design)
Then the model gets its 'edge' vertices 'stitched' to its neighbour, using the
XY positions of the neighbours matching vertex.
Now you can see why I WANTED ent_morph and ent_clone to work together.

Thats was the plan IF my question had been answered with YES...

This attempt was following my previous one which was using ent_remove & ent_create,
when a slight lag was noticed when scrolling a row AND a column. AND I havent
even implemented the 'stitching' process yet.
I cant afford ANY noticable lag at this early stage because this projects
'mapping system' is only at a 'framework' stage so there is so little cpu-load
at this time I should never get ANY lag. Otherwise it will just get worse later.

Thats the primary reason why I was looking to avoid the ent_remove/ent_create process.
There are other reasons, future reasons, but they can be worked-around easily.

So I think I will soon go back to the ent_remove/ent_create process, and
figure out some way to buffer the ent_remove's (and maybe ent_creates too)
in order to 'smooth out' the cpu-load-balancing so there will be no
significant lag, even later when more game-mechanisms are installed.