Can we consider renaming this crate as long as it's not widely used yet? I find the name bevy_loading misleading, because loading is only one use case, while the functionality the crate offers is progress tracking in general. This can be applied to loading, but also to (terrain-) generation, connection, or simple task tracking.

How about bevy_progress_tracking?

Using iyes_progress to track asset loading in a loopless state. When I run my game, I get an error message:

thread 'main' panicked at 'State Transiton Stage not found (assuming auto-added label)', cargo\registry\src\github.com-1ecc6299db9ec823\iyes_loopless-0.5.1\src\state.rs:240:18

Looking at the cargo.toml, it seems that iyes_progress is requiring an older version of iyes_loopless. Would it be possible to update iyes_progress to require v0.6.0 or at least v0.5.0 and above?

The way the dependencies are currently setup, one cannot use the bevy git version. This way it always tracks bevy_main without resorting to patches (which are ignored for those using it in their repository)

Instead of marking the plugin as not unique, give it a unique name depending on the state it's loading in.

This means that

        // Add plugin for the splash screen
        .add_plugin(
            ProgressPlugin::new(AppState::Splash)
                .continue_to(AppState::MainMenu)
                .track_assets(),
        )
        // Add plugin for our game loading screen
        .add_plugin(ProgressPlugin::new(AppState::GameLoading).continue_to(AppState::InGame))

will work, but

        // Add plugin for the splash screen
        .add_plugin(
            ProgressPlugin::new(AppState::Splash)
                .continue_to(AppState::MainMenu)
                .track_assets(),
        )
        // Add plugin for our game loading screen
        .add_plugin(ProgressPlugin::new(AppState::Splash).continue_to(AppState::InGame))

won't, blocking adding by mistake the plugin twice with the same state

With these deps:

bevy = "0.8.0"
iyes_loopless = "0.7.0"
iyes_progress = "0.4.0" 

And a system like this:

            .add_system_set(
                ConditionSet::new()
                    .run_in_state(GameState::Loading)
                    .with_system(setup.track_progress())
                    .into(),
            )

Where setup looks something like:

pub fn setup(mut commands: Commands) -> Progress {
    commands
        .spawn()
        .insert(RenderCamera::default())
        .insert(Controller::default());

    true.into()
}

I consistently get an unhappy compiler:

error[E0277]: the trait bound `ParallelSystemDescriptor: IntoSystem<(), (), _>` is not satisfied
   --> src\camera.rs:71:34
    |
71  |                     .with_system(setup.track_progress())
    |                      ----------- ^^^^^^^^^^^^^^^^^^^^^^ the trait `IntoSystem<(), (), _>` is not implemented for `ParallelSystemDescriptor`
    |                      |
    |                      required by a bound introduced by this call
    |
    = help: the trait `AddConditionalToSet<ConditionSystemSet, ()>` is implemented for `ConditionalSystemDescriptor`
    = note: required because of the requirements on the impl of `iyes_loopless::condition::IntoConditionalSystem<_>` for `ParallelSystemDescriptor`
    = note: required because of the requirements on the impl of `AddConditionalToSet<ConditionSystemSet, _>` for `ParallelSystemDescriptor`
note: required by a bound in `iyes_loopless::condition::ConditionSet::with_system`
   --> c:\dev\tools\cargo\registry\src\github.com-1ecc6299db9ec823\iyes_loopless-0.7.0\src\condition.rs:652:12
    |
652 |         S: AddConditionalToSet<ConditionSystemSet, P>,
    |            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ required by this bound in `iyes_loopless::condition::ConditionSet::with_system`

For more information about this error, try `rustc --explain E0277`.

It isn't clear to me why this wouldn't be satisfied, but I'm relatively new to Rust trait stuff.

bevy has recently switched to using IntoSystem so as to allow users to not have to specify .system everywhere. I believe that this should be reflected in the track function as well and would make it fit more.

• [x] Point to upstream iyes_looplesas soon as IyesGames/iyes_loopless#24 is merged

• we need a manual StageLabel impl now

• some formatting (just cargo fmt)

• fixed doc test from the bevy_loading times

• makes preparation and check system exclusive
  • preparation runs at_start
  • check runs at_end
  • this removes the requirement for manual system ordering in most scenarios
• support persisting Progress for the rest of the loading State

based on/merge after #11

There might be other plugins or custom systems taking care of the state progression, so I made the next_state optional.

Changes due to Bevy 0.7 are minimal, but some changes were required (no more system config API).

I can't seem to use the tracking function with exclusive systems (can they even return something and be chained?). It also currently is not possible to manually update the ProgressCounter because the fields are private and no functions are exposed to update them.

How can I track the progress of exclusive systems?

I have two separate state machines, Client and Network. Client has the states LoadingGame and InGame and Network has Connecting and Connected. Each of these pairs has a ProgressPlugin associated with it. The transition of Network::Connecting to Network::Connected is one of the items I want to track in the outer progress plugin (Client->InGame), but when the inner one (Network->Connected) completes it pops the ProgressCounter resource leaving Client without one (at least I think this is what is happening, I haven't verified the root cause).

This might be solvable by making ProgressCounter generic over S in ProgressPlugin.

The following code also increases the total counter for already added handles which shouldn't be the case.

https://github.com/IyesGames/bevy_loading/blob/5981c76aa2f98b56d322d29b536617343015e91c/src/asset.rs#L29-L32

This should fix it:

pub fn add<T: Into<HandleId>>(&mut self, handle: T) { 
     if self.handles.insert(handle.into()) {
          self.total += 1;
     }
}