-
-
Notifications
You must be signed in to change notification settings - Fork 3.5k
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
Remove StateTransition
schedule in favor of using observers
#15133
Comments
If this is meant to replace the fixed once-per-frame state transitions schedule instead of providing an additional option, I'm strongly opposed. If not, I'd like to see an example use case that isn't already covered by |
Can you explain why you prefer a fixed once-per-frame state transition? And yeah, we can just add commands.run_schedule. |
I'm actually not super sold on the importance of "run state transition at any point in time", I think we should have it as a niche feature and keep synchronized transitions as the main feature. The biggest use for state transitions is spawning in entities, which may be processed in multiple schedules. |
From Pyrious on Discord
From doot on Discord |
Actually, There is actually a proposal in the hackmd called "Flush hooks as observers" where the But again, whether this proposal should be implemented depends on the existence of an example use case, which I don't have but I also haven't thought much about. |
What problem does this solve or what need does it fill?
Updating the app state is a very flexible and expressive operation, which is fundamentally deferred. States typically changes only once per frame, after
PostUpdate
.This can lead to unwanted delays when handling multiple dependent transitions at once.
What solution would you like?
As discussed in #15127, it would be nice to remove this meta-schedule, and instead run the various
OnEnter
/OnExit
/OnTransition
schedules on demand, leveraging the new observers. This is a good fit for "highly complex rarely exercised logic", and resolves the delay problem mentioned above while simplifying the mental model for consumers.#15127 should be tackled in concert with this, removing
NextState
completely, and relying entirely on commands to handle transitions.What alternative(s) have you considered?
Users can manually add more state transition systems to their schedule, including in their own schedules that run inside of
Main
. This is somewhat messy, nonstandard and hard to discover.Additional context
Discussed briefly on Discord with @MiniaczQ here.
This design was not originally taken (including in the substates refactor) because observers didn't exist at the time!
The text was updated successfully, but these errors were encountered: