-
-
Notifications
You must be signed in to change notification settings - Fork 4.1k
Closed
Labels
A-ECSEntities, components, systems, and eventsEntities, components, systems, and eventsC-FeatureA new feature, making something new possibleA new feature, making something new possible
Description
What problem does this solve or what need does it fill?
Ok so the name isn’t that great but I’ll try to explain what I mean.
Currently, when you have a simple system that doesn’t need any resources or so other than a simple query, and it may call code (maybe with if statement, so it could be called, but mustn’t) which needs more components and other resources, you have to implement them in the system, just to pass them to the next function. This is messy and also not ideal. So i want a new parameter for system where they can slide in and schedule new systems.
What solution would you like?
Something like this:
#[derive(SystemLabel)]
enum MyLabels {
First,
Second,
}
fn main() {
App::new()
.add_system(main_thing.label(MyLabels::First))
.add_system(info_thing.label(MyLabels::Second).after(MyLabels::First))
.add_plugins(DefaultPlugins)
.run();
}
fn main_thing(mut scheduler: SystemScheduler) {
if random(10) <= 5 {
scheduler.schedule_once(perhaps_system.label(MyLabels::First)); // this will still run before info_thing
}
}
fn perhaps_system(mut query: Query<..>, mut my_cool_resource: ResMut<Cool>) {
// here we can do things with them without any nasty code in main_thing :)
}
fn info_thing() { .. }
What alternative(s) have you considered?
Still using the nasty code with unused parameters and piping them through functions.
Additional context
it would really be nice if this would be possible with the new stageless concept :)
Metadata
Metadata
Assignees
Labels
A-ECSEntities, components, systems, and eventsEntities, components, systems, and eventsC-FeatureA new feature, making something new possibleA new feature, making something new possible