Crash with simultaneous ProgressPlugins (on different state types)

[siler]

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.

[inodentry]

Hmm. That makes sense. It never crossed my mind to think about progress tracking on multiple state types in parallel.

Now that you brought that up, I can see why things might break. It's a use case I'd like to support. I'll look into it.

You are probably right that (at least) the single ProgressCounter resource is messing up things. There might also be other things.

[inodentry]

I am trying to implement ProgressCounter being generic over the state type.

One downside I am running into is that now this would introduce extra boilerplate when adding systems. .track() is no longer enough; you would have to specify the state type you want to track for: .track::<S>(). This is completely understandable and desirable in your use case, where you have multiple different state types and you want to track progress independently for them. You would have to specify, for each system, which state type it applies to / where it tracks its progress.

However, this increases complexity and boilerplate for all users, and most users don't need progress tracking on more than one state type…

I wonder if we could come up with some sort of design that can keep things simple for most users, while still allowing for use cases like yours?

[inodentry]

@TheRawMeatball has given me some ideas, I will experiment with it.

[BeastLe9enD]

@inodentry has there been progress on this? I would also like to use this with different state types, and I think it would also be helpful to make AssetsLoading generic over T, so that we can specify assets that should be tracked only for a specific state.

If the complexity thing is still a problem, would it maybe be an idea to have two types, one for a single state (most people need) and one if you need multiple state types?