Script Systems & Components

[makspll]

The idea of using scripts as systems, i.e. having a script declare functions which act like systems, with specific dependencies on the world, and scheduling them in such a way that they can access the world safely

• Dynamic world access system

• Handler resources should have interior mutability at bms_core level, so systems can run in parallel if they access different scripts

• Reflecting schedules and systems, querying the ordering

• Dynamically injecting systems into bevy schedule safely

• Injected systems to specify access ahead of time, and dynamic systems are parallelizable against other systems

• Multi threading scripts not necessary

• Command - Deferred versions of the WorldGuard bindings (i.e. insert_component_deferred + better warnings if aliasing is broken, geared towards script authors who might not know rust)

• Allow specifying read/write access in script builder as an optional argument as well as for queries

[makspll]

The linked PR, will allow us to create world guards compatibile with the schedule at the point of insertion, while it doesn't get us all the way there, it does solve the first part necessary in achieving script systems, I.e.:

• syncing the accesses map with the bevy schedule

In theory, now even without a dynamic script insertion mechanism, you could have a number or "sync" points predefined by the author which could bootstrap script systems into specific parts of bevy.

The big limitation though is that if you insert a script at any point of the bevy schedule which accesses ANYTHING in the world, your script won't be able to get global access, I.e. it will have to schedule component insertions like a normal system

[makspll]

Dynamically adding event handlers is now possible through: #335, including ordering constraints against rust systems

[makspll]

This is very close with #361 working as expected