Skip to content
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

Simple methods to list all components and all resources #3007

Open
alice-i-cecile opened this issue Oct 22, 2021 · 6 comments
Open

Simple methods to list all components and all resources #3007

alice-i-cecile opened this issue Oct 22, 2021 · 6 comments
Labels
A-ECS Entities, components, systems, and events C-Usability A targeted quality-of-life change that makes Bevy easier to use

Comments

@alice-i-cecile
Copy link
Member

alice-i-cecile commented Oct 22, 2021

What problem does this solve or what need does it fill?

Having a list of all resources or all components is useful for debugging purposes.
This will be particularly valuable in the editor.

What solution would you like?

~~Add a Resources system parameter.

On both the Components and Resources system parameter, implement Iter, returning ComponentInfo as the item.~~

EDIT: this has been fixed for resources by #12829, but an equivalent for components is still missing.

What alternative(s) have you considered?

Right now, you can use the complex method listed in https://bevy-cheatbook.github.io/cookbook/print-resources.html for resources, but no such obvious method exists for components.

Blindly check component IDs from Components by trying all of the usize options (or hoping they're strictly contiguous and start at 0).

World::inspect_entity can be used to inspect all of the components of a specific entity, and was added in #5136.

Additional context

#15435 improves this situation for query errors and could be helpful inspiration.

@alice-i-cecile alice-i-cecile added A-ECS Entities, components, systems, and events C-Usability A targeted quality-of-life change that makes Bevy easier to use labels Oct 22, 2021
@alice-i-cecile
Copy link
Member Author

Related to #1130.

@hymm
Copy link
Contributor

hymm commented Oct 22, 2021

for reference here's how I do it in my library https://github.com/hymm/bevy_mod_debug_console/blob/c9117098711dd81c0fd2b4a0f98ce4a96e05e427/src/ecs.rs#L35-L73

@sseemayer
Copy link
Contributor

sseemayer commented Oct 23, 2021

I would like to take this up by implementing additional types ComponentsIter, Resources, and ResourcesIter and implementing Resources as a SystemParam (have not fully understood how to do this but will give it a try) and implementing Iterator on the *Iter types.

Edit: I think I can get by with just implementing IntoIter on Commands and Resources with type Item = std::slice::Iter<'_, ComponentInfo>, passing on the iterator of the underlying Vec.

@sseemayer
Copy link
Contributor

sseemayer commented Oct 23, 2021

Now that I am starting to understand how resources are implemented, the task at hand is becoming a bit less clear for me.

I see that Resources are just a special case of a component that gets inserted into the Components::components Vec inside of the Components system parameter (1 2 3).

I could distinguish between proper Components and Resources by using the Components::indices and Components::resource_indices, but then I am wondering what the best API would be to expose this.

I can currently see these options:

  1. Keep the Components system parameter as is and implement iter_components and iter_resources methods returning the appropriate iterators.
  2. Create a new Resources system parameter. When into_iter() is called for &Resources, somehow obtain the Components associated with the world, the components list therein, and filter to iterate only over Resources using the resource_indices field. Adjust the into_iter() for &Components to filter to return only ComponentInfos for proper Components.
  3. Fully split out the management of resources out of the Components struct and put that logic into a new Resources system parameter.

What would you prefer? Can you see any other options?

@sseemayer
Copy link
Contributor

Option 3 was chosen after some discussion with @alice-i-cecile and @BoxyUwU on Discord - thanks for the help!

@sseemayer
Copy link
Contributor

Update: decoupling components and resources to be stored separately turned out to be too hard to do, so we have now decided to rename Components to WorldData to denote that WorldData manages both Components and Resources. There will now be two new system parameters Components and Resources to iterate over those two things, respectively.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-ECS Entities, components, systems, and events C-Usability A targeted quality-of-life change that makes Bevy easier to use
Projects
None yet
3 participants