Conditional system execution

[aclysma]

I didn't want to derail #125 but I think there are other usecases that are similar, some of which I encountered while prototyping:

• Things that only run in an editor
• Things that only run on server or client in a networked game
• Things that only run when the game is paused/unpaused

I prebuilt schedules in legion for a few permutations and it worked fine but I don't think it was ideal. The number of permutations can grow quickly.

Another approach I had considered was using a bitflag. When you kick off the schedule, you provide bits and the systems could require certain bits be high. You could in theory have a bit for a particular timestep. This sounds a lot like (2) mentioned in bug #125 at a conceptual level. "Tags" might be another way to think about it conceptually. (i.e. tag systems, and then filter which ones will run by enabling/disabling systems by tag)

I was also running a separate schedule for a simulation thread and a rendering thread and pipelining them. (I was rendering frame N while simulating frame N+1). I could see the same approach working for other systems like network and audio where you copy over a bunch of immutable data into another system, let it crunch an entire frame's data, and produce a result.

Mainly just wanted to mention that there are quite a few scenarios I think make sense and there may be some intersection between them and the original issue #125 that was mentioning fixed timesteps.

[cart]

Good points. The networking case alone is enough to convince me, but the editor is another good callout. And I'm glad you pointed out that this is related to fixed timesteps. On the surface they seem separate, but the implementations should inform each other.

Separate schedules seems like the simplest from an implementation perspective. However users probably just want to register their systems once. Bitflags might allow us to refactor the current "startup system" design (ex: add a startup bit flag).

[eadgbear]

Could you take the approach of going a bit Meta on it? Systems of Systems? Could treat the systems as Entities themselves with Run/NoRun components and state.

[TehPers]

Separate schedules seem like a great idea. Another simple (although probably very inefficient) solution is to just rely on a query and predicate for running the system. This can be implemented by creating an outer system which runs the conditional, and storing the original system to run if the predicate returns true:

fn my_system(a: &SomeComponent) {}

fn main() {
    App::build()
        .add_system(my_system.system().when(|paused: Res<PauseState>| paused != PauseState::Paused))
        .run();
}

[BimDav]

Maybe this can also be done with an extension of Resources? For example fixed timesteps is the use case for which I wanted a ChangedRes query: all systems with fixed timesteps would query the ChangedRes<Frame> resource.
For the other use cases it could be interesting to have a FlagRes resource that behaves like ChangedRes but for user-defined flags, and directly looks at the Resource's boolean value before calling the system.

I'm working on ChangedRes here, I'll have a better version with Or<T: Resource> soon.

[BimDav]

I am not sure it answers everything or if it is an optimized implementation but in this PR #434 I added an example which presents how systems can be called on fixed timesteps, as well as conditioned on a predicate, using Resources queries.

[alice-i-cecile]

This should be addressed by run criteria and states, so I think this issue can be safely closed.