Repository navigation
Add .with_system_set method to SystemSet #2722
Description
What problem does this solve or what need does it fill?
Reusing system sets is currently challenging: users may for example want to run a collection of systems in several states at once.
What solution would you like?
Add with_system_set to match with_system on the SystemSet struct.
What alternative(s) have you considered?
More completely overhaul / reorganize system sets and scheduling.
Additional context
This should be relatively straightforward for newcomers who want to get to know the ECS a bit better. Follow the impl here:
and push the systems from the new system set into self's corresponding field instead.
Activity
Zengor commentedon Aug 24, 2021
Hi, looking into this. Two questions:
self's?SystemDescriptoreven implementsClone)alice-i-cecile commentedon Aug 24, 2021
Hmm. Prioritize self IMO? That will need to be clearly documented though.
I don't mind implicit cloning here: this should be a one-time cost. IMO we should try to
impl Clone for SystemDescriptorin this PR and then use that. I could see it being useful elsewhere as well for similar reuse patterns.Zengor commentedon Aug 24, 2021
wrt implementing
Clone, I ran into the issue thatBoxedSystemandBox<dyn ExclusiveSystem>are not clonable and I'm not quite sure how to work around that (the systems themselves are functions using the function traits so I don't think they are clonable at all). Maybe there is some workaround that could be done with anArcbut I'm not sure where to go from here.alice-i-cecile commentedon Aug 25, 2021
Hmm. I think we should table this for the moment then; we can review it as the schedule and state story improves.
Ratysz commentedon Aug 26, 2021
You can't clone systems - there is, ordinarily, no point to doing that, and adding that restriction just for the sake of this API isn't a good idea. This is not going to "improve" in the future.
What might be possible instead: introduce a
Clone-like extension trait implemented on the descriptor obtained from clonable systems. I can't visualize how that's even going to work (descriptors are meant to be nongeneric), you might have to plumb in a whole pile of these traits and create a duplicate of most of descriptor logic but with cloning built in.cart commentedon Aug 26, 2021
I think other scenarios tie in to this:
We already have ways to address systems:
Maybe we need a way to say things like:
Ratysz commentedon Aug 26, 2021
They do, but this issue is kind of structured around the idea of cloning the systems.
To me, a good solution for those would be a dedicated out-of-schedule storage for systems, indexed by labels and/or a kind of a unique key (system name?).
We've been referring to this as "label properties": i.e., do things to systems by doing things to their labels. I don't think this is feasible to implement until we untangle the stages/states/lifecycle doom triangle, we need a completely flat systems storage if we want to do this sanely.
james7132 commentedon Feb 16, 2023
SystemSets, as used prior to stageless, no longer exist. Closing this issue for now.