Closed ronniec95 closed 1 year ago
If you want components A
and B
to be on the same entity, why did you spawn separate entities for them to begin with?
(Figuring out why have to move the component values is the important but as an aside, you can always make expensive-to-clone types cheap-to-clone in Rust by wrapping them in Rc
or Arc
at the cost of another indirection and them becoming immutable.)
The extended example is more realistically
Create entity 1 with component A + state machine S1 (component) to manage the loading status Create entity 2 with component B + state machine S2 (component) to manage the loading status Create entity 3 with component C + state machine S3 (component) to manage the loading status
When the state of all of the entities are READY, I no longer care about the state machine component, or this entity. I then create my real entities which might be configured for example:-
Id, components
Edit: I think I've answered own question here by obviously needing clones of A, B and C. I also agree, RC/arc was an alternative.
I think I can use remove rather than despawn to delete the original entities
This is a design issue, not a issue with hecs
I'm new to ecs so perhaps a naive question
I'm loading some assets which become components for an entity. These are heavy data structures which take a while to load. I'm concerned that I have to clone them to make them part of an entity. Perhaps I'm doing something wrong
Example use case Run system A to load component type A. Create entities sing world.spawn_batch Run system B to load , component type B. Create entities using world.spawn_batch
Run system C, sometime later when user does something. Query for component A and B. Iterate over found entities and join components to create usable entity which has components A&B.
Problem: since query is by reference I have to clone component A & B which is expensive.
Is this the right design pattern? I don't really want clonable components.