Using the FixedUpdate Schedule

[johanbluecreek]

I would like the update of the k-d tree to be updated before the systems I have dependent on it in the FixedUpdate schedule. But there does not seem to exist support for setting schedule to FixedUpdate. If I add the following AutomaticUpdate to my "App":

 App::new()
        .add_plugins((
            DefaultPlugins,
            AutomaticUpdate::<KDMarker>::new()
                .with_schedule(FixedUpdate)
                .with_spatial_ds(SpatialStructure::KDTree2),
            LogDiagnosticsPlugin::default(),
        ))

I get this error:

$ cargo run
   Compiling game_of_life v0.1.0 (/mnt/storage/Programming/git_work/game_of_life)
error[E0277]: the trait bound `(bevy::DefaultPlugins, AutomaticUpdate<KDMarker, SpatialSet, bevy::prelude::FixedUpdate>, LogDiagnosticsPlugin): bevy_app::plugin::sealed::Plugins<_>` is not satisfied
   --> src/main.rs:472:22
    |
472 |           .add_plugins((
    |  __________-----------_^
    | |          |
    | |          required by a bound introduced by this call
473 | |             DefaultPlugins,
474 | |             AutomaticUpdate::<KDMarker>::new()
475 | |                 .with_schedule(FixedUpdate)
476 | |                 .with_spatial_ds(SpatialStructure::KDTree2),
477 | |             LogDiagnosticsPlugin::default(),
478 | |         ))
    | |_________^ the trait `bevy_app::plugin::sealed::Plugins<_>` is not implemented for `(bevy::DefaultPlugins, AutomaticUpdate<KDMarker, SpatialSet, bevy::prelude::FixedUpdate>, LogDiagnosticsPlugin)`
    |
    = help: the following other types implement trait `bevy_app::plugin::sealed::Plugins<Marker>`:
              <() as bevy_app::plugin::sealed::Plugins<(bevy_app::plugin::sealed::PluginsTupleMarker,)>>
              <(S0,) as bevy_app::plugin::sealed::Plugins<(bevy_app::plugin::sealed::PluginsTupleMarker, P0)>>
              <(S0, S1) as bevy_app::plugin::sealed::Plugins<(bevy_app::plugin::sealed::PluginsTupleMarker, P0, P1)>>
              <(S0, S1, S2) as bevy_app::plugin::sealed::Plugins<(bevy_app::plugin::sealed::PluginsTupleMarker, P0, P1, P2)>>
              <(S0, S1, S2, S3) as bevy_app::plugin::sealed::Plugins<(bevy_app::plugin::sealed::PluginsTupleMarker, P0, P1, P2, P3)>>
              <(S0, S1, S2, S3, S4) as bevy_app::plugin::sealed::Plugins<(bevy_app::plugin::sealed::PluginsTupleMarker, P0, P1, P2, P3, P4)>>
              <(S0, S1, S2, S3, S4, S5) as bevy_app::plugin::sealed::Plugins<(bevy_app::plugin::sealed::PluginsTupleMarker, P0, P1, P2, P3, P4, P5)>>
              <(S0, S1, S2, S3, S4, S5, S6) as bevy_app::plugin::sealed::Plugins<(bevy_app::plugin::sealed::PluginsTupleMarker, P0, P1, P2, P3, P4, P5, P6)>>
            and 8 others
    = note: required for `(bevy::DefaultPlugins, AutomaticUpdate<KDMarker, SpatialSet, bevy::prelude::FixedUpdate>, LogDiagnosticsPlugin)` to implement `Plugins<_>`
note: required by a bound in `bevy::prelude::App::add_plugins`
   --> /mnt/storage/rust/.cargo/registry/src/index.crates.io-6f17d22bba15001f/bevy_app-0.12.1/src/app.rs:721:52
    |
721 |     pub fn add_plugins<M>(&mut self, plugins: impl Plugins<M>) -> &mut Self {
    |                                                    ^^^^^^^^^^ required by this bound in `App::add_plugins`

For more information about this error, try `rustc --explain E0277`.
error: could not compile `game_of_life` (bin "game_of_life") due to previous error

Am I interpreting this correct that it is not supported to run the k-d tree update system with the FixedUpdate schedule?

[laundmo]

Hmm, if that is the case, its a bug. it should be allowed.

[johanbluecreek]

Is there anything I should try to get it to work, or any other way of troubleshooting this?

Even if I get it to be part of the FixedUpdate schedule, can I add .after and .before dependencies to it somehow?

[laundmo]

Since i'm currently working on a pretty big change to how the entire internal structure of the plugin works, using system chaining to get rid of some of the traits and generics madness and also making the datastructures entities instead of resources, i will try to make sure this works in that new system. I believe it may be a issue with how it currently schedules systems not quite working as intended.