Closed Ratysz closed 3 years ago
Closing, mostly superseded by #13: it doesn't allow the "neat" custom run criteria attaching, but I think that's fine. Unfortunately, it looks like we'll have to rely on "pub
everything" for cases where plugin customizability is needed, until a good method is developed and endorsed by the ecosystem, or (more preferably) Bevy gains a first-party solution to problems like these.
This is not inteded to be merged as is.
A rough prototype of how to let users attach their own run criteria to systems of the plugin - this is the building block that lets enabling/disabling the plugin via user-defined states. I haven't considered if the criteria even make sense on all of these systems.
The main hurdle in the way of making this less gnarly is that Bevy's run criteria (and thus states) are stage-specific. Plans to mitigate that do exist, but aren't quite ready yet; resolving this would make a single copy of a criteria (or label) sufficient for the entire config, instead of a producer function (aka bootleg clone).
Another thing I'm not sure if I like is that the nested plugins have to rely on the same config struct as the top-level plugin. This might be possible to rework, but I don't know how valuable would that be in this context.