#Schedule a system after another

14 messages · Page 1 of 1 (latest)

pure pilot
#

I'm chaining two systems after each other like (place_shape, update_boundary).chain() and while update_boundary certainly runs after place_shape, it seems like the Command changes made by the first system (e.g. despawn_entity) are not yet applied when the second system runs. Is this the case, or is there some other bug in my code?

If it is the case, how do I schedule these systems so the second one runs after the commands of the first have been applied to the world?

sharp meadow
#

There is a system, apply_system_buffers, that applies the Commands as a hard sync point (cannot run in parallel with other systems because exclusive world access)

crimson nymph
#

add a buffer apply at the start of the chain

#

well, in between them, sorry misread

sharp meadow
#

Bevy already includes some of these in its system sets, so it's easiest to add one system to CoreSet::PreUpdate and its commands are applied by CoreSet::Update (where systems are added by default)

#

But you can chain (place_shape, apply_system_buffers, update_boundary).chain() too

pure pilot
#

Ah! I tried sticking apply_system_buffers inbetween them and it worked

#

Probably putting them in separate stages (is the term I was trying to find in the examples e.g. CoreSet::PreUpdate) is better

#

I guess since the stageless update they are not called stages anymore. Either way I couldn't find an example that dealt with this

#

and with how much this has changed in bevy 0.10 it's hard to find on google

#

thanks for the help!

sharp meadow
#

There is a notable difference in that chaining apply_system_buffers in different places does reduce bevy's ability to parallelize work, so separating tasks into sets with a sync point between them tends to work better IMO

pure pilot
#

How do I add systems to PreUpdate? .in_schedule(CoreStage::PreUpdate) doesn't seem to do it

sharp meadow
#

in_base_set(CoreSet::PreUpdate)