-
-
Notifications
You must be signed in to change notification settings - Fork 3.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Better tools for working with dynamic collections of components #3227
Comments
One existing tool for this is |
I don't see what's impractical about making Your description of something to add arbitrary |
This would be great for what I'm working on now. I have a simple prefab system set up where you can specify components in a scene-like way but with way less boilerplate:
If we could iterate over bundles in a generic way I could just drop them right in. I poked at it a little but I know next to nothing about the unsafe land of rust so sadly beyond me to implement: |
Talking it over, the more aggressive direction would be to attempt to replace the
This allows Along with that, you'd:
Effectively, this would serve as an alternative to #2974. It would also make issues like #792 much easier. |
Also related to #2157, which is another way we could make bundles more flexible in more constrained ways. I don't immediately see any direct overlap, but I'll chew on it. |
Please don't, a tuple doesn't add any allocations, unlike a potential vec solution. |
Deal: you've convinced me on this point here (and other have explained more use cases on Discord). |
Have you tried using heterogenous lists (I know them from the shapeless lib in Scala)? There seems to be a Or it should be possible to add an |
This is my preferred path forward: if we can get this working, we should just use this approach. |
More detailed error messages:
|
Also note you cannot have a method take
I expect everything else to be mechanical but I am against the duplication here (even if they are codegened) unfortunately a quick pass didn't lead to an obvious removal of |
As a heads up, I have a WIP prototype for this (coauthored with @alercah) on https://github.com/alice-i-cecile/bevy/tree/dyn-bundle-mad-science. Feel free to poke at it, steal from it, shamelessly clean it up and submit a PR or so on. I'm a little busy, but the initial direction here is promising. |
After #12311, Component is no longer a object-safe trait. That PR might need to be reverted if this is something we want to support. |
I've been using Bevy and Rust for a few days and have bumped into exactly this issue. I'm wondering if there are any new potential solutions. |
I am seeing bad performance upon receiving a lot of components from game server that need to be added to entity for the first time for hundreds of entities. As there could be multiple possible combinations of components for entity I can not use bundles. Pseudocode: for entity_data in entities_data_from_server {
let entity = get_entity_or_spawn(...., entity_data.entity_id);
for component in entity_data.components {
match component {
ComponentA(comp) => { entity.insert(comp); }
ComponentB(comp) => { entity.insert(comp); }
....
}
}
} As much as I understand: It looks like something similar can be done with unsafe: https://docs.rs/bevy/latest/bevy/ecs/prelude/struct.EntityWorldMut.html#method.insert_by_ids |
What problem does this solve or what need does it fill?
Working with dynamic collections of components (as might be used in advanced spawning patterns) is very painful at the moment: every straightforward path is blocked due to missing impls. This cannot be fixed in end user code, as they do not own the
Component
trait, or the common wrapper types likeVec
andBox
.What solution would you like?
Component
forBox<dyn Component>
, which uses the box's data as the component.Rc
andArc
(and any other common smart pointers).Bundle
forIntoIter<Item=Component>
, which combined with the above would allow us to use structs likeVec<Box<dyn Component>>
as bundles.Notes:
DynClone
for this pattern to actually work, which would probably force aDynComponent
trait layer.What alternative(s) have you considered?
Other possible approaches:
Bundle
itself object-safe, obviating 3. I don't think this will be feasible.Component
for&Component
, since we can get these out of our boxes. This doesn't work nicely though, due to the need to clone components out of a standard storage.#1515 would provide an alternate path to some of the use cases.
Some very limited workarounds may exist using commands (and entity commands) in certain use cases.
The text was updated successfully, but these errors were encountered: