-
-
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
Per-Entity Events #1626
Comments
Because channels are just entities with components, you could also query for them directly: fn my_channel_system(mut my_events: Query<&Events<MyEvents>, With<MyChannel, HighPriority>>){
for mut e in my_events.iter_mut (){
// Modify the events in some strange direct fashion
}
for e in my_events.to_event_reader().iter(){
// Act on the events
}
} This could also be an alternative to extending the |
#2116 is an attempt at implementing this flavor of design. |
This is blocked on an Event trait, and #2073. |
No longer blocked; although configurable event storage will be better. Some prior art: https://crates.io/crates/bevy_eventlistener |
This has been resolved by observers :D |
What problem does this solve or what need does it fill?
Events in Bevy often want to be sent to specific consumers, but existing obvious solutions to ensure that this occurs have serious drawbacks. This is particularly true with UI.
What solution would you like?
Event<T>
components on entities.WorldQuery
forEventReader
andEventReader
.What alternative(s) have you considered?
You could simply not use a global events resource, and carefully examine each event to see whether it's designed for the intended recipient. This is error-prone due to poor conceptual clarity, results in possibly large amounts of wasted work and doesn't parallelize well.
System chaining is a very bad solution, because it causes the systems to share resource access, doesn't work across frames, is only one-to-one and so on.
You could create new event types for each channel using a wrapper. This leads to a frustrating proliferation of events.
Channels could be implemented using a resource instead. This is harder to query for in a composable way, and you can't easily add metadata.
Additional context
This would be a valuable possible direction for #1622. It was first discussed on Discord here, with follow-up discussion.
The text was updated successfully, but these errors were encountered: