-
-
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
[Merged by Bors] - Replace RemovedComponents<T>
backing with Events<Entity>
#5680
Conversation
I think re-thinking this I might just store the events in a Where |
RemovedComponents
with an Event<RemovedComponent<T>>
RemovedComponents<T>
backing with Events<Entity>
82e2672
to
1561a1d
Compare
235770c
to
39d7af6
Compare
Reworked this a good bit to be less invasive of the ECS stuff, I would like #5735 to get merged before this because right now it isn't really possible for me to return empty iterators of components that haven't been removed yet. |
Why did you change course on this? This seems like a cleaner API, and I think I remember cart saying he preferred it. Edit: it was Alice, not Cart. |
Summary of why: |
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 think I'm on board with these changes. Having to add mut
on the SystemParam
is unfortunate, but IMO it's worth it for the consistency brought by double buffering.
1ae0b76
to
e71ada6
Compare
91cc714
to
df404c2
Compare
11a3ca7
to
95e5212
Compare
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.
Thoughts:
ComponentIdFor
is very interesting. @jakobhellermann may find it useful for working with dynamically typed APIs.- Oh right: Events used to live in bevy_ecs. That's a good explanation of why we didn't just use them originally.
3.I really like removing the "one frame" footgun, and reducing the tech debt of just using events.
Formatting Fix some docs Unnecessary imports impl From rather than Into for ToComponentId Try to fix CI errors Fix up test to expect double buffering Fix linnk in docs Simplify component id initializing/fetching Remove from system params Move component id for to component file Move ComponentIdFor to component.rs Deref and don't allow modifying the component id IntoIterator for RemovedComponents Formatting Example for ComponentIdFor Improve documentation MaybeIter inbetween Remove unnecessary type for iterator Improve safety comment, don't box unnecessarily formatting
95e5212
to
4d63994
Compare
bors r+ |
Merge conflict. |
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.
bors r+
# Objective Removal events are unwieldy and require some knowledge of when to put systems that need to catch events for them, it is very easy to end up missing one and end up with memory leak-ish issues where you don't clean up after yourself. ## Solution Consolidate removals with the benefits of `Events<...>` (such as double buffering and per system ticks for reading the events) and reduce the special casing of it, ideally I was hoping to move the removals to a `Resource` in the world, but that seems a bit more rough to implement/maintain because of double mutable borrowing issues. This doesn't go the full length of change detection esque removal detection a la bevyengine/rfcs#44. Just tries to make the current workflow a bit more user friendly so detecting removals isn't such a scheduling nightmare. --- ## Changelog - RemovedComponents<T> is now backed by an `Events<Entity>` for the benefits of double buffering. ## Migration Guide - Add a `mut` for `removed: RemovedComponents<T>` since we are now modifying an event reader internally. - Iterating over removed components now requires `&mut removed_components` or `removed_components.iter()` instead of `&removed_components`.
Pull request successfully merged into main. Build succeeded:
|
RemovedComponents<T>
backing with Events<Entity>
RemovedComponents<T>
backing with Events<Entity>
Objective
Removal events are unwieldy and require some knowledge of when to put systems that need to catch events for them, it is very easy to end up missing one and end up with memory leak-ish issues where you don't clean up after yourself.
Solution
Consolidate removals with the benefits of
Events<...>
(such as double buffering and per system ticks for reading the events) and reduce the special casing of it, ideally I was hoping to move the removals to aResource
in the world, but that seems a bit more rough to implement/maintain because of double mutable borrowing issues.This doesn't go the full length of change detection esque removal detection a la bevyengine/rfcs#44.
Just tries to make the current workflow a bit more user friendly so detecting removals isn't such a scheduling nightmare.
Changelog
Events<Entity>
for the benefits of double buffering.Migration Guide
mut
forremoved: RemovedComponents<T>
since we are now modifying an event reader internally.&mut removed_components
orremoved_components.iter()
instead of&removed_components
.