-
-
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
Do not add OnUpdate
system set to CoreSet::ApplyStateTransitions
#7634
Conversation
I remember running into this in the initial migration, and I don't see a good way around it. To me, that suggests that alternative 2 is probably the right choice? |
d7878e8
to
afa65bc
Compare
OnUpdate
system setOnUpdate
system set to CoreSet::ApplyStateTransitions
For (2), impl IntoSystemConfigs for SystemConfigs {
fn on_update<S: States>(self, state: S) -> Self {
for system in &mut self.systems {
system.conditions.push(new_condition(state_equals(state.clone()));
}
self
}
} I argued for (3) when we were trying to get the RFC merged. Users can't get Also, that |
I was also planning on campaigning against I'm strongly against removing a strict ordering from OnUpdate that makes it behave like CoreSet::Update. It should work "as expected" (as in ... like an Update system, designed under the assumptions that it will run after necessary engine feature prep and before engine "responses" to user code) without requiring users to supply their own orderings. It exists only for this purpose. If we remove this, we should should remove the abstraction entirely. We already agreed that run conditions were the way to support "non update" scenarios like "adding state_equals(X) systems to PreUpdate". I think that design is the right approach. Compromising the OnUpdate abstraction because adding run conditions to SystemConfigs isn't currently supported seems wrong. Even the current situation where repeating the condition per-system (or using an the organizational set) is preferable. In these cases, organizations sets are probably the right move in most cases anyway? It seems like we could support In short I think we should:
|
Awesome, I'm quite happy with that conclusion. |
#7632 shows a user expecting What is clear is that the 0.10 blog post / book / API docs needs to specifically spell out how Also, I still think that |
Given that we have "default base sets that default to Update", I think theres a world where we can reasonably remove OnUpdate in favor of
Also not something I'd want to do for 0.10, given the time constraints. Removing OnUpdate is something we should consider later. |
Sure, I'm not saying we need to get rid of I do like |
Closed in favor of #7667, as discussed above. |
# Objective Fixes #7632. As discussed in #7634, it can be quite challenging for users to intuit the mental model of how states now work. ## Solution Rather than change the behavior of the `OnUpdate` system set, instead work on making sure it's easy to understand what's going on. Two things have been done: 1. Remove the `.on_update` method from our bevy of system building traits. This was special-cased and made states feel much more magical than they need to. 2. Improve the docs for the `OnUpdate` system set.
# Objective - Improve readability of the run condition for systems only running in a certain state ## Solution - Rename `state_equals` to `in_state` (see [comment by cart](#7634 (comment)) in #7634 ) - `.run_if(state_equals(variant))` now is `.run_if(in_state(variant))` This breaks the naming pattern a bit with the related conditions `state_exists` and `state_exists_and_equals` but I could not think of better names for those and think the improved readability of `in_state` is worth it.
# Objective - Improve readability of the run condition for systems only running in a certain state ## Solution - Rename `state_equals` to `in_state` (see [comment by cart](#7634 (comment)) in #7634 ) - `.run_if(state_equals(variant))` now is `.run_if(in_state(variant))` This breaks the naming pattern a bit with the related conditions `state_exists` and `state_exists_and_equals` but I could not think of better names for those and think the improved readability of `in_state` is worth it.
…engine#7667) # Objective Fixes bevyengine#7632. As discussed in bevyengine#7634, it can be quite challenging for users to intuit the mental model of how states now work. ## Solution Rather than change the behavior of the `OnUpdate` system set, instead work on making sure it's easy to understand what's going on. Two things have been done: 1. Remove the `.on_update` method from our bevy of system building traits. This was special-cased and made states feel much more magical than they need to. 2. Improve the docs for the `OnUpdate` system set.
# Objective - Improve readability of the run condition for systems only running in a certain state ## Solution - Rename `state_equals` to `in_state` (see [comment by cart](bevyengine#7634 (comment)) in bevyengine#7634 ) - `.run_if(state_equals(variant))` now is `.run_if(in_state(variant))` This breaks the naming pattern a bit with the related conditions `state_exists` and `state_exists_and_equals` but I could not think of better names for those and think the improved readability of `in_state` is worth it.
…engine#7667) # Objective Fixes bevyengine#7632. As discussed in bevyengine#7634, it can be quite challenging for users to intuit the mental model of how states now work. ## Solution Rather than change the behavior of the `OnUpdate` system set, instead work on making sure it's easy to understand what's going on. Two things have been done: 1. Remove the `.on_update` method from our bevy of system building traits. This was special-cased and made states feel much more magical than they need to. 2. Improve the docs for the `OnUpdate` system set.
# Objective - Improve readability of the run condition for systems only running in a certain state ## Solution - Rename `state_equals` to `in_state` (see [comment by cart](bevyengine#7634 (comment)) in bevyengine#7634 ) - `.run_if(state_equals(variant))` now is `.run_if(in_state(variant))` This breaks the naming pattern a bit with the related conditions `state_exists` and `state_exists_and_equals` but I could not think of better names for those and think the improved readability of `in_state` is worth it.
…engine#7667) # Objective Fixes bevyengine#7632. As discussed in bevyengine#7634, it can be quite challenging for users to intuit the mental model of how states now work. ## Solution Rather than change the behavior of the `OnUpdate` system set, instead work on making sure it's easy to understand what's going on. Two things have been done: 1. Remove the `.on_update` method from our bevy of system building traits. This was special-cased and made states feel much more magical than they need to. 2. Improve the docs for the `OnUpdate` system set.
# Objective - Improve readability of the run condition for systems only running in a certain state ## Solution - Rename `state_equals` to `in_state` (see [comment by cart](bevyengine#7634 (comment)) in bevyengine#7634 ) - `.run_if(state_equals(variant))` now is `.run_if(in_state(variant))` This breaks the naming pattern a bit with the related conditions `state_exists` and `state_exists_and_equals` but I could not think of better names for those and think the improved readability of `in_state` is worth it.
# Objective - Fixes #7659 ## Solution The idea of anonymous system sets or "implicit hidden organizational sets" was briefly mentioned by @cart here: #7634 (comment). - `Schedule::add_systems` creates an implicit, anonymous system set of all systems in `SystemConfigs`. - All dependencies and conditions from the `SystemConfigs` are now applied to the implicit system set, instead of being applied to each individual system. This should not change the behavior, AFAIU, because `before`, `after`, `run_if` and `ambiguous_with` are transitive properties from a set to its members. - The newly added `AnonymousSystemSet` stores the names of its members to provide better error messages. - The names are stored in a reference counted slice, allowing fast clones of the `AnonymousSystemSet`. - However, only the pointer of the slice is used for hash and equality operations - This ensures that two `AnonymousSystemSet` are not equal, even if they have the same members / member names. - So two identical `add_systems` calls will produce two different `AnonymousSystemSet`s. - Clones of the same `AnonymousSystemSet` will be equal. ## Drawbacks If my assumptions are correct, the observed behavior should stay the same. But the number of system sets in the `Schedule` will increase with each `add_systems` call. If this has negative performance implications, `add_systems` could be changed to only create the implicit system set if necessary / when a run condition was added. --------- Co-authored-by: Carter Anderson <[email protected]>
Objective
The inclusion of timing information in
on_update
is surprising to users, and leads to fairly tricky to debug errors whenever they attempt to schedule it.Fixes #7632.
Solution
The
OnUpdate
system set is no longer added toCoreSet::ApplyStateTransitions
. This lets users change the base set, reduces the number of concerns and allows theCoreSet::Update
base set get applied by default. This is closest to 0.9 behavior.This can result in a set which can span multiple base sets, which can be tricky to visualize.
Alternatives
OnUpdate
set (which stuck the system inStateTransitions
, in favor of simply havingsystem.on_update(state)
as sugar forrun_if(state_equals(state))
.on_update
sugar completely and let people use run conditions themselves.OnUpdate
set, and add anOnUpdate
schedule, which is run via a system which is by default run immediately afterapply_state_transition
.2 doesn't work well, since I can't easily implement
.run_if
forSystemConfigs
, as it seems to require cloningCondition
s.Changelog
The
OnUpdate
set is no longer configured to run inCoreSet::ApplyStateTransitions
.Migration Guide
If you needed the timing information imposed by
OnUpdate
, also addin_base_set(CoreSet::StateTransitions))
.