Doraku
Make IntDispenser injectable
Hi, first of all, great library !
I'm working on synchronizing worlds and bump into a minor issue with IntDispenser hidden inside World. It would be nice to make it injectable so we can implement another that would avoid us to do the entity mapping among worlds.
Thanks in advance
Hey thanks you :)
About the synchronization of worlds I am not sure how providing a custom implementation of the internal IntDispenser would help as you still wouldn't have a hand in the creation of entities. Even if two entities from different worlds have the same ids, they don't share anything as data is world specific (an entity is made of both an entity id AND a world id (and a version)). I just want to be sure to understand what you want to achieve with this change .
I guess having same entity id would mostly help with the debugging.
On the other hand, having control of the id generation have more than one purpose. It might be authoritative server side control, negative id in one world and positive on another, or id generation determinism if we don't care much about the performance hit.
For the data, Entity.CopyTo(World) and the EntityCommandRecorder can be used.
What I have in mind to keep the same id is to hack the Entity.CopyTo, using a custom IntDispenser (that hold the mapping) for the copied world. But of course, it is even better to make CreateEntity "injectable", with EntityGenerator for example, but I was afraid is too much to ask :-)
Again thank you, keep up the good work !
negative id in one world and positive on another
The entity id is the actual index used to look for the entity data, so having something negative here would be... problematic :D It is highly linked to the internal implementation and if done wrong, could make everything behave badly, that's why I am careful about opening it ^^"
What I have in mind to keep the same id is to hack the Entity.CopyTo, using a custom IntDispenser (that hold the mapping) for the copied world.
So instead of having your mapping id as a component on the entity (or even use the entity itself as key if it is not supposed to be destroyed) you would still need a mapping between ids in your custom IntDispenser anyway, I am not sure it would give you a big benefit.
Appart from that I am currently looking into changing DefaultEcs to an Artifact ECS implementation that may help speed up entity copy as a side effect if that's what you are really after.
The entity id is the actual index used to look for the entity data, so having something negative here would be... problematic :D It is highly linked to the internal implementation and if done wrong, could make everything behave badly, that's why I am careful about opening it ^^"
The negative number was meant to scare ;-) Kidding aside, we did it for a game with our in-house ECS about 8 year ago, where we needed to economize the number of components due to the bit-wise implementation made for the check entity and system masks. It was an easy way to partition the data, because we did not have worlds either. We had Entity Generator though.
So instead of having your mapping id as a component on the entity (or even use the entity itself as key if it is not supposed to be destroyed) you would still need a mapping between ids in your custom IntDispenser anyway, I am not sure it would give you a big benefit.
Having the mapping in a component is the usual way to go, but for our current context it is not preferred because we don't really suspense/resume during a sync and it helps to reduce the exchanged data over the network. The mapping in the custom IntDispenser would be the workaround, because we only need the entity id to match. Without it, we would have to send the mapping over the network for debugging purpose.
Appart from that I am currently looking into changing DefaultEcs to an Artifact ECS implementation that may help speed up entity copy as a side effect if that's what you are really after.
It is always good to have speed, but it was never the first goal in my experience :-) That's why I consider this a minor issue. Your implementation ticks many right boxes for me! And thanks for the feedback.
cleaning up old issues in the end that's definitely not something that's going to be opened as it's too much tied to the internal implementation.