0.16.0

Improved printing and error ergonomics

Printing has been extracted into its own bevy_mod_scripting_display crate, and brand new traits including the reflectable DisplayWithTypeInfo were written.

There are now Debug and Display equivalent traits which receive type information from semi-static thread local objects in order to print things like TypeId's with full information.

You can now also register ReflectDisplayWithTypeInfo against your types in the reflect registry, to customize printing.

A great re-slicing

Bindings have been split out into individual crates, for example bevy_reflect has a corresponding bevy_reflect_bms_bindings crate which contain's its bindings. This is possible thanks to a brand new tool which allows us to calculate crate dependencies across a workspace during codegen (see bevy_mod_scripting_codegen)

At the same time more bindings are now being generated after fixing some bugs in type discovery.

Other refactorings include bevy_mod_scripting_bindings, bevy_mod_scripting_display and bevy_mod_scripting_asset being pulled out into their own crates.

This has significantly improved compile times allowing us to pack more bindings!

Getting rid of HandlerCtxt

HandlerCtxt has been removed and all of its containing resources have been put in P::readonly_configuration, which is a semi-static, WorldId parameterised static.

At the same time ScriptContext<P> has been wrapped in an Arc allowing us to run callbacks within callbacks, as long as they don't modify the same contexts!

The great bevy minification

BMS has historically pointed at the top level bevy crate, this was handy but fairly clunky as it brought way more dependencies than necessary.

From now on all BMS crates point at bevy subcrates directly, with default features disabled, this means we pull in the minimum amount of dependencies possible (in theory, as long as we didn't miss a feature)

Brand new scripting pipeline

A shiny new overhauled loading/unloading script pipeline which:

• Is much more customizable (want custom callbacks, or don't like how we named our core callbacks? Just disable them and add your own!)
• More scalable, allowing you to load thousands of scripts, without hogging your framerate (by abstracting loading into tickable state machines)

See the new docs section for details.

Pre-expanding generated code

Generated code is now expanded at generation time via cargo expand saving on compilation time for consumers.