-
-
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
A way to determine if an entity exists with Commands
#5850
Comments
asafigan
added
C-Feature
A new feature, making something new possible
S-Needs-Triage
This issue needs to be labelled
labels
Sep 1, 2022
We're already calling Entities.contains on a FYI: another alternative is to use the |
hymm
added
D-Trivial
Nice and easy! A great choice to get started with Bevy
A-ECS
Entities, components, systems, and events
and removed
S-Needs-Triage
This issue needs to be labelled
labels
Sep 1, 2022
james7132
pushed a commit
to james7132/bevy
that referenced
this issue
Oct 28, 2022
# Objective - Fixes bevyengine#5850 ## Solution - As described in the issue, added a `get_entity` method on `Commands` that returns an `Option<EntityCommands>` ## Changelog - Added the new method with a simple doc test - I have re-used `get_entity` in `entity`, similarly to how `get_single` is used in `single` while additionally preserving the error message - Add `#[inline]` to both functions Entities that have commands queued to despawn system will still return commands when `get_entity` is called but that is representative of the fact that the entity is still around until those commands are flushed. A potential `contains_entity` could also be added in this PR if desired, that would effectively be replacing Entities.contains but may be more discoverable if this is a common use case. Co-authored-by: Carter Anderson <[email protected]>
ItsDoot
pushed a commit
to ItsDoot/bevy
that referenced
this issue
Feb 1, 2023
# Objective - Fixes bevyengine#5850 ## Solution - As described in the issue, added a `get_entity` method on `Commands` that returns an `Option<EntityCommands>` ## Changelog - Added the new method with a simple doc test - I have re-used `get_entity` in `entity`, similarly to how `get_single` is used in `single` while additionally preserving the error message - Add `#[inline]` to both functions Entities that have commands queued to despawn system will still return commands when `get_entity` is called but that is representative of the fact that the entity is still around until those commands are flushed. A potential `contains_entity` could also be added in this PR if desired, that would effectively be replacing Entities.contains but may be more discoverable if this is a common use case. Co-authored-by: Carter Anderson <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
What problem does this solve or what need does it fill?
Some times you may be trying to work with entities that may or may not exist anymore. It would be helpful to have a way of determining is an entity exists with
Commands
What solution would you like?
Add a
get_entity()
method onCommands
that returns anOption<EntityCommands>
.Maybe a
entity_exists()
method onCommands
that return abool
.What alternative(s) have you considered?
You could have a
Query<Entity>
and check it before callingentity()
onCommands
.Additional context
There are a lot of issues about handling command errors: #2004, #3845, #2241, #5617.
I feel like this would still be useful even with command error handling.
The text was updated successfully, but these errors were encountered: