How to configure more than 16 SystemSet variants with app.configure_sets?

[waxen jasper]

I currently have SystemSet with many variants:

        app.configure_sets(
            Update,
            (
                InGameSet::A.run_if(state_in_game),
                LoadingWorldOrInGameSet::A.run_if(state_loading_or_in_game),
                LoadingWorldOrInGameSet::B.run_if(state_loading_or_in_game),
                InGameSet::B.run_if(state_in_game),
                InGameSet::C.run_if(state_in_game),
                // ... More variants here
            )
                .chain(),
        )

But I've reached the limit of 16.

I've tried nesting the sets in order to get around the limit like so:

        app.configure_sets(
            Update,
            (
                InGameSet::A.run_if(state_in_game),
                LoadingWorldOrInGameSet::A.run_if(state_loading_or_in_game),
                LoadingWorldOrInGameSet::B.run_if(state_loading_or_in_game),
                (InGameSet::B.run_if(state_in_game), InGameSet::C.run_if(state_in_game)).chain(),
                // ... More variants here
            )
                .chain(),
        )

But that doesn't seem to be valid:

the method `chain` exists for tuple `(SystemSetConfigs, SystemSetConfig, SystemSetConfig, SystemSetConfig, ..., ..., ..., ..., ..., ..., ..., ...)`, but its trait bounds were not satisfied

What's the intended solution here?

[gloomy dock]

multiple calls to app.configure_sets

[waxen jasper]

I mean yes... but is there a good wayt o do that without using some sort of meta SystemSet to keep the ordering or duplicating the configuration of a variant to maintain the chaining?

[gloomy dock]

cant you just order the first set of the second call relative to the last set of the first call?

(i remember when we didnt have chain, and just had to make do with tons of before/after calls)

[waxen jasper]

Yea, that's probably the best solution here. It doesn't feel great because if you ever add something to the first configure_sets call after that point you can break the ordering if you don't remember to adjust the other configure_sets call.

[gloomy dock]

hmm i've been thinking

it kinda seems like you use system sets to emulate states

or well

thats not quite accurate

but the chaining here should not be neccessary if your states already guarantee a order. after all, many of these configs sound mutually exclusive anyways

not sure if i'm explaining my intuition clearly

[waxen jasper]

Hmm, I don't think that's the case? The configs are not mutually exclusive note the loading game or in game set. So these are systems that run when you are loading or in game and I want them to be ordered against the other systems that run when you are only loading / in game.

[gloomy dock]

theres combinators like or_else for run conditions though (i dont remember if they easily work for sets, but i would assume they do)

sorry, i'm clearly not articulating why i think theres a different solution to this problem properly

but maybe imagine this: how would you set it up if you wanted to split your game into mostly self contained plugins?

having a giant chain of system sets doesnt make sense then either

[waxen jasper]

Totally open to suggestions, but I'm not sure what that would look like. For what it's worth, the game is separated into mostly self-contained plugins but these SystemSets are in place since they deal with cross-cutting concerns (e.g. pause states, spawning entities, and flush points, etc). They help me orchestrate when that behavior happens regardless of the current state of the application.

I'm aware of the or_else for run conditions, but in many ways this configuration just gives me syntactic sugar and allows me to write .in_set(A) instead of manually in_set(A).run_if(in_state(A)).or(in_state(B)) for every individual system that needs to run when the game is paused or in-game. The project is 10k+ LOC so stuff like that adds up and saves a lot of time and reduces the room for human error.