2.x vs 3.x

[ZoriaRPG]

@ZoriaRPG
UIDs might change again internally. You shouldn't even have to know how they are managed; that's kinda the whole point. Before, an UID was a dynamically allocated node kept sorted using a self balancing tree. Now they use contiguous blocks of memory, are stored in order, and retrieval by a simple 'divide and conquer' algorithm. Later, they might be something else entirely. I sorta broke enemy::swap already, so we'll see.

I would actually prefer it if all the OOP cruft could be removed from the sprite-entity stuff.

Well, I was hoping that at some point, users would be able to reference an npc by its UID, as that shouldn't change as long as it remains valid, and might be useful for specific effects targeting; but I can see how that could be a problem if this is in flux.

@ZoriaRPG
Please explain what you mean by the memory pool stuff.
FFCs don't need hit boxes although they could use Drawing and Effect offsets. Which would achieve a similar effect that and the ability to increase the size of ffc effect range from 1 to 64 regardless of ffc size. And no @Moosh , I'm not giving you bigger ffcs. :tard:

@Gleeok mentioned the memory pool stuff the other day; and he mentioned dynamic ffc creation by script, and I approve of this mightily.

The advantage of a hitbox is that you can have an ffc with an EffectWidth and EffectHeight, that is entirely unlinked to its hitbox. That allows more freedom without any great sacrifice. I'm not sure that I see a problem with enlarging the maximum ffc size (combos) either, except that it's more work. We certainly don;t need any of these things in the next main build, but they might be interesting for the future.