more docs

Author: makspll

docs/src/ReleaseNotes/0.15-to-0.16.md

@@ -0,0 +1,39 @@
+# Migrating to 0.16.0
+
+## https://github.com/makspll/bevy_mod_scripting/pull/455
+Replace all usages of `CallbackSettings<P>.callback_handler` with `P::handler()(..)` and `P::handle(..)`
+
+## https://github.com/makspll/bevy_mod_scripting/pull/456
+Replace all usages of `CallbackBuilder<P>.load` and `CallbackBuilder<P>.reload` with `P::load(..)` and `P::reload(..)` or `P::context_loader()(..)` and `P::context_reloader()(..)`
+
+## https://github.com/makspll/bevy_mod_scripting/pull/463
+If you were relying on BMS enabling some features in Bevy crates, your builds might be pulling in less features than you expect. Ensure you explicitly select all features you need from bevy. BMS will now only pull in strictly necessary features and crates from bevy
+
+## https://github.com/makspll/bevy_mod_scripting/pull/470
+Switch all references of `ContextLoadingSettings` to `P::readonly_config(world.id())`.
+
+## https://github.com/makspll/bevy_mod_scripting/pull/471
+`RuntimeSettings` and `RuntimeContainer` are removed, replace usages with `P::readonly_settings(world.id()).runtime)` access to initializers is no longer possible outside the plugin setup phase
+
+## https://github.com/makspll/bevy_mod_scripting/pull/472
+if you implemented a scripting plugin you will need to correct your function signatures for the above aliases, and fetch the config yourself to access callbacks via `Plugin::readonly_configuration(world_id)` using the world id you will now receive.
+
+## https://github.com/makspll/bevy_mod_scripting/pull/473
+references to `StaticScripts` should be replaced with appropriate resident calls on `ScriptContext` filtered by the attachment kind
+
+## https://github.com/makspll/bevy_mod_scripting/pull/474
+- **ScriptContext Access**: Use `.read()` and `.write()` to access ScriptContext (now wrapped in `Arc<RwLock<>>`); replace `get()` with `get_context()`
+- **HandlerContext**: Replace with direct ScriptContext access; remove any `with_handler_system_state()` calls
+- **Script Callbacks**: Use new `call_context_dynamic()` or `call_context()` methods from the CallContext trait
+- **Custom Context Types**: Implement the new `GetPluginFor` trait to provide mapping from context to plugin type
+- **Lua Interaction**: Replace `mlua::Lua` with `LuaContext` wrapper type in all Lua code on BMS side
+- **Script Callback Running**: Replace `run_with_handler()` calls with `run_with_context()` or `run_with_contexts()`
+
+## https://github.com/makspll/bevy_mod_scripting/pull/475
+- References previously resident in `bevy_mod_scripting_core::asset`/`bevy_mod_scripting::core::asset`  will now need to come from `bevy_mod_scripting_asset` or `bevy_mod_scripting::asset`
+- Adding supported extensions will now need to be done via `scripting_plugin.add_supported_extension("extension")` rather than via the app directly
+- Plugin implementors will need to add the new crate as a dependency and should not directly rely on the top workspace crate
+
+## https://github.com/makspll/bevy_mod_scripting/pull/477
+- Update imports to new crates (`bevy_mod_scripting_bindings`, `bevy_mod_scripting_display`, `bevy_mod_scripting_asset`) where appropriate, if you rely on the workspace these will be re-exported under `bindings`, `display` and `asset` respectively
+- Replace `DisplayWithWorld` usage with `DisplayWithTypeInfo` / `DebugWithTypeInfo` and use `WithTypeInfo::new(value)` in format strings. Ensure that the WorldGuard is in scope when printing using these utilities, or you might see raw type id's

docs/src/ReleaseNotes/0.16.0.md

@@ -0,0 +1,35 @@
+# 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.

docs/src/Summary/managing-scripts.md

@@ -35,7 +35,8 @@ This will not evaluate any code yet.
 ## Evaluating
 A script does not participate in any callbacks until it is evaluated, to evaluate a script you must first attach it to an entity, or to a static script entry.
 
-To evaluate a script, add it to a `ScriptComponent` or to `StaticScripts`.
+To evaluate a script, add it to a `ScriptComponent` manually attach it.
+
 ### Load File via `AssetServer`
 ```rust
 # extern crate bevy;