-
-
Notifications
You must be signed in to change notification settings - Fork 3.6k
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
Implement methods to list all components and all resources (Rebase of PR #3012) #4955
Implement methods to list all components and all resources (Rebase of PR #3012) #4955
Conversation
This allows iteration over all `Component`s registered in a world by implementing `IntoIterator` for the `Components` type.
the Components struct was not just storing metadata on components, but also on resources. WorldData is a new umbrella term for components and resources. also rename the following: `ComponentId` -> `DataId` `ComponentInfo` -> `DataInfo` `ComponentDescriptor` -> `DataDescriptor`
These can be used in systems to get an overview over all available Components and Resources.
Co-authored-by: MinerSebas <[email protected]>
My instinct is that we should merge #4809 first, which should simplify the implementation here significantly. @james7132, are you in agreement? |
For what it's worth you can iterate over all component infos already: bevy/crates/bevy_ecs/src/component.rs Line 401 in 7317473
To find all resource component IDs you can just the components in the resource archetype, something like |
@KevinKeyser Is this a dead PR at this point? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like the ComponentId
-> DataId
change: I think it's genuinely correct and clearer. Resources having a ComponentId
is always baffling. However it makes this PR much harder to review, and should be its own PR.
fn iterate_resources() { | ||
let mut world = World::default(); | ||
world.insert_resource(Vec::<String>::new()); | ||
world.insert_resource(42usize); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These will have to be redone to account for the opt-in Resource
trait.
} | ||
|
||
#[test] | ||
fn remove_tracking() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
fn remove_tracking() { | |
fn removal_tracking() { |
Just to reduce diff noise.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is quite nice: I really like how much clearer DataId
and WorldData
are. If you rebase this and get CI passing I'd be happy to see this merged basically as is.
@KevinKeyser I still really like this work, but at this point it's going to be easier to remake this PR than to solve merge conflicts. I'm going to |
I'd like to pick this up soon. |
|
||
/// The [`SystemParamState`] of [`Components`]. | ||
#[doc(hidden)] | ||
pub struct ComponentsState; | ||
|
||
// SAFE: no component value access | ||
unsafe impl SystemParamState for ComponentsState { | ||
unsafe impl<'a> SystemParamState for ComponentsState { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Probably trivial, but is this explicit lifetime required?
}; | ||
let component_id = if let Some(component_id) = self.data.get_resource_id(TypeId::of::<R>()) | ||
{ | ||
component_id |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should this be resource_id
or data_id
(as well as in other related functions)?
I'm hoping that this PR will help permit me to more easily serialize specific components (when I only have the name) of an entity as well as overwrite the state of a component by deserializing a previous state's Edit: I can get a |
@matiqo15, this seems really useful for bevyengine/rfcs#77. Perhaps we should re-adopt it and get the basic form merged? |
Agree, this could help a lot |
# Objective - Closes #12019 - Related to #4955 - Useful for dev_tools and networking ## Solution - Create `World::iter_resources()` and `World::iter_resources_mut()` --------- Co-authored-by: Alice Cecile <[email protected]> Co-authored-by: James Liu <[email protected]> Co-authored-by: Pablo Reinhardt <[email protected]>
# Objective - Closes bevyengine#12019 - Related to bevyengine#4955 - Useful for dev_tools and networking ## Solution - Create `World::iter_resources()` and `World::iter_resources_mut()` --------- Co-authored-by: Alice Cecile <[email protected]> Co-authored-by: James Liu <[email protected]> Co-authored-by: Pablo Reinhardt <[email protected]>
@alice-i-cecile Now that #12829 has been merged, is this PR still necessary? |
It would still be nice to have something like this for components, but I'm going to close this out regardless. |
Objective
Solution
Changelog
struct ComponentId
->struct DataId
struct Components
->struct WorldData
Components::components
->WorldData::data
struct ComponentInfo
->struct DataInfo
struct ComponentDescriptor
->struct DataDescriptor