jarkonik / bevy_scriptum

📜 A plugin for Bevy that allows you to write some of your game logic in a scripting language.
https://jarkonik.github.io/bevy_scriptum/
Apache License 2.0
84 stars 4 forks source link

Test, stabilize and document scheduling behavior #34

Open jarkonik opened 4 weeks ago

jarkonik commented 4 weeks ago

Asked on Bevy Discord by user mgi388

In bevy_scriptum, is there a good way to know when your Rust functions have all finished being executed? The Rust functions are just systems, so can I assume they all ran by the time the R::Schedule schedule (bevy_scriptum's schedule which runs after Update) finishes? For example, I could look at PostUpdate and in that same frame, could I assume the systems have all run? If yes, then I think I can insert a marker component on my script entity once I run it (e.g. MyScriptWasRun), then, in PostUpdate, I can look for my script entity with that marker component, and then insert yet another marker component to say that it should be finished (e.g. MyScriptRanToCompletion). Then, I can use the existence of MyScriptRanToCompletion to actual progress the state of my thing which relies on the script having run to completion.

This came up because I am running a script in OnEnter(SomeSetupLevelState) and all of my level setup is currently happening based on state transitions, and it surprised me that the script ran, but I had to wait for all of the systems the script calls to finish / they run out of order compared to all of my setup level state transitions.

It would be beneficial to have script execution scheduling be stable across library versions and documented. Could be facilitated by writing some execution scheduling tests and documenting the existing behavior in the documentation book.

mgi388 commented 4 weeks ago

I was looking for a “system set” type thing that I could rely on and then I could just run my “I know the script is done” system after that. Would it be as simple as exposing the runtime schedule, and a system set and then I could run my system in that schedule and using after?

That seems less flakey than me just running it in PostUpdate because that’s “the next schedule”.