adding a new system with only before and after dependencies can lead to hard to diagnose errors

[hymm]

What problem does this solve or what need does it fill?

With stageless merged, doing something like this can lead to hard to a hard to fix error for beginners.

// this will error because this will add the system to the `Update` set
// that wants to be after the `transform_propagate` system
// but the `transform_propagate` system is in `PostUpdate` set
// so it can't be both before `PostUpdate` and after `transform_propagate`
app.add_system(my_system.after(transform_propagate);

The way to fix this is to change it to

app.add_system(my_system.in_set(PostUpdate).after(transform_propagate));

But this requires knowledge that the transform_propagate system is in the PostUpdate set. The only way you could know this is to either see this in some schedule debugger tool like bevy_mod_debug_dump or looking up the transform_propagate system in the source code.

What solution would you like?

We can add a couple api's that would allow fixing this without knowledge of how a systems dependency is configured. These won't fix discovery of how to fix the problem, but will at least require less knowledge of how to configure it.

Allow the system to free float

app.add_system(my_system.no_default_set().after(transfrom_propagate));

Calling no_default_set would add the set to the schedule without a default set. This would allow the system to be only contrained by only the after constraint.

Allow system to be added as a "sibling" of a set

app.add_system(my_system.in_sets_with(transform_propagation).after(transform_propagation));

in_sets_with would inherit all the constraints that transform_propagation has. A discussion is probably worth having whether this is just the sets containing transform_propagation or also the run criteria and direct before and after constraints too.

I think we want both of these as they have significantly different behavior.

What alternative(s) have you considered?

Better schedule visualization tools and good error message will help here too.

[alice-i-cecile]

Agreed, I'd like both of these tools.

[maniwani]

Yep, both of these methods are useful. no_default_set will also let people have system sets just for pure logical grouping, i.e. ones that don't really have a position in the schedule but can be used in ambiguous_with, etc.

[alice-i-cecile]

This will be fixed by #7466.

[hymm]

not sure if this is completely fixed by #7466

from discord:

bestRanar — Yesterday at 9:26 PM
Is this expected right now? This is the entire app.

#[derive(Debug, Hash, PartialEq, Eq, Clone, SystemSet)]
struct AfterUpdate;
// ...
app.configure_set(AfterUpdate.after(CoreSet::UpdateFlush));
app.add_system(test.in_set(AfterUpdate));
// panics with SetsHaveOrderButIntersect("Update", "AfterUpdate")

[alice-i-cecile]

Cut from the milestone as we're nearing release. I'm not sure we can or should try to act on this further before gathering more feedback.

[alice-i-cecile]

@hymm, would you call this fixed by #8079, or is there still more work to be done here?

[nicopap]

This is fixed by #8079. The footgun doesn't exist anymore, since the schedule is always explicit.

[hymm]

The in_sets_with api might still be useful, but the basic problem is solved.