-
-
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
Add a straightforward API for simple system ordering #4220
Comments
Should/could this work within a For example: app.add_system_set(SystemSet::on_update(MyState::InGame).with_system(system_a.then(system_b)); |
I don't think this is a super important use case, but I think that it'll just happen automatically. If my intuition is right, I think it's fine to allow it to continue to work, rather than to try to explicitly forbid it. |
One idea that came out of the Discord discussion that spawned this is a |
This adds the concept of "default labels" for systems (currently scoped to "parallel systems", but this could just as easily be implemented for "exclusive systems"). Function systems now include their function's `SystemTypeIdLabel` by default. This enables the following patterns: ```rust // ordering two systems without manually defining labels app .add_system(update_velocity) .add_system(movement.after(update_velocity)) // ordering sets of systems without manually defining labels app .add_system(foo) .add_system_set( SystemSet::new() .after(foo) .with_system(bar) .with_system(baz) ) ``` Fixes: #4219 Related to: #4220 Credit to @aevyrie @alice-i-cecile @DJMcNab (and probably others) for proposing (and supporting) this idea about a year ago. I was a big dummy that both shut down this (very good) idea and then forgot I did that. Sorry. You all were right!
This adds the concept of "default labels" for systems (currently scoped to "parallel systems", but this could just as easily be implemented for "exclusive systems"). Function systems now include their function's `SystemTypeIdLabel` by default. This enables the following patterns: ```rust // ordering two systems without manually defining labels app .add_system(update_velocity) .add_system(movement.after(update_velocity)) // ordering sets of systems without manually defining labels app .add_system(foo) .add_system_set( SystemSet::new() .after(foo) .with_system(bar) .with_system(baz) ) ``` Fixes: bevyengine#4219 Related to: bevyengine#4220 Credit to @aevyrie @alice-i-cecile @DJMcNab (and probably others) for proposing (and supporting) this idea about a year ago. I was a big dummy that both shut down this (very good) idea and then forgot I did that. Sorry. You all were right!
Took a crack at the I don't think it's very feasible until #4391 (or equivalent cleanup) occurs. |
This adds the concept of "default labels" for systems (currently scoped to "parallel systems", but this could just as easily be implemented for "exclusive systems"). Function systems now include their function's `SystemTypeIdLabel` by default. This enables the following patterns: ```rust // ordering two systems without manually defining labels app .add_system(update_velocity) .add_system(movement.after(update_velocity)) // ordering sets of systems without manually defining labels app .add_system(foo) .add_system_set( SystemSet::new() .after(foo) .with_system(bar) .with_system(baz) ) ``` Fixes: bevyengine#4219 Related to: bevyengine#4220 Credit to @aevyrie @alice-i-cecile @DJMcNab (and probably others) for proposing (and supporting) this idea about a year ago. I was a big dummy that both shut down this (very good) idea and then forgot I did that. Sorry. You all were right!
This wasn't added in the stageless changes, but is now unblocked. |
I feel like requiring |
What problem does this solve or what need does it fill?
Creating simple orderings between systems is harder than it should be. Users must define a label, and then use a .before or .after method.
In many cases, we have two (or maybe a few more) systems that need to be linearly ordered, which are defined in the same plugin.
This is both verbose and harder to read / reason about
What solution would you like?
The
.then
method onIntoSystemDescriptor
converts a system function into aSystemSet
.What alternative(s) have you considered?
System set chaining
Adapted from https://github.com/bevyengine/rfcs/pull/45/files#diff-d319c5378a207f7eae8b553b1df6b026d7bfc885b016f776a64b48ed86935d5fR769
System graph
We could use a full system graph API, as defined in #2381 (and the bevy_system_graph crate that came out of this).
This is probably too complex and unwieldy for this very simple but common case, but may be desirable later regardless.
add_system .then
Naively, a mechanism that works like the current
.chain
seems desirable.Unfortunately, this won't work under the hood: add_system expects a single system.
Additional context
Related to #4219, which proposes additional ergonomics improvements.
We may want to rename
add_system_set
toadd_systems
, following the suggestions in the Stageless RFC, to improve ergonomics. This should probably be done in a follow-up PR to improve reviewability.The text was updated successfully, but these errors were encountered: