Hi all, just though I'd check-in, since this crate is now used regularly by quite a few people!
First of all thanks for all the support and especially to the sponsors! (massive shutout to @shanecelis and @DrLuke)
Refactoring
The crate is massive and really hard to grok, which is one of the reasons it's been fairly hard to maintain, I myself find myself forgetting many implementation details every time I come back to work on BMS!
The latest big thing I've been working is a massive refactor: https://github.com/makspll/bevy_mod_scripting/pull/112. It's been a while since I've started work on that branch but it's finally nearing the point where things are starting to look really good!
I've ported the work over to: https://github.com/makspll/bevy_mod_scripting/pull/149 while also "rebasing" (in quotation marks because it was nowhere near as pretty as a rebase) the latest few bevy updates and PR's to the crate (minus dynamic queries which I am yet to re-integrate here)
This will be the biggest breaking change to the crate so far and will bring many benefits:
Much fewer crates
Simplified plugin structure & less bloat
Actual unit testing
No more reliance on magic macros, but rather traits doing the heavy lifting (very excited about this one)
Improved script lifecycle (no more event priority stuff, it's too confusing), and API's are available at all hooks for a script (setup, post setup, during event handling etc.)
Support for langs which are close enough to existing ones (like fennel) via asset pre-processors
Saner cleaner errors
I am hoping to merge this work right after the bevy 0.15 release (which I am already supporting with 8.0 pre-releases from the staging branch)
Removing dependency on Tealr
I still want to be able to generate docs for lua (and other languages), but Tealr forces us to do this at compile time, and also is quite behind on recent teal developments. As part of supporting generating docs for other langs I'd like to develop a custom documentation format which we can generate (ideally) at compile time, and then produce beautiful docs tailored to our use case.
This will be the next step after the big refactor.
Moving to native reflection
Bevy has come a long way since I've begun working on this crate! To put it into perspective, when the first version of BMS released Enum's were still not supported, and function reflection was unheard of!
As of now many features still rely on bits and bobs of compile time knowledge (including doc gen) which will be hard to get rid of, but I'd finally be able to get rid of the concept of per-type-script-proxies. Ideally we'd have a single LuaProxy type which via dynamic reflection handles ALL methods and fields of a type without relying on compile time knowledge (right now we generate wrappers per native bevy type!)
Script Systems & Components
Supporting OOP style scripting is much harder in a system oriented engine, but once I am happy with it, we could also support the much easier system style scripting, where scripts define dependencies on components and resources at "compile time" (think type or parameter names) allowing us to pre-compute a lot of our runtime safety information!
Hi all, just though I'd check-in, since this crate is now used regularly by quite a few people! First of all thanks for all the support and especially to the sponsors! (massive shutout to @shanecelis and @DrLuke)
Refactoring
The crate is massive and really hard to grok, which is one of the reasons it's been fairly hard to maintain, I myself find myself forgetting many implementation details every time I come back to work on BMS!
The latest big thing I've been working is a massive refactor: https://github.com/makspll/bevy_mod_scripting/pull/112. It's been a while since I've started work on that branch but it's finally nearing the point where things are starting to look really good!
I've ported the work over to: https://github.com/makspll/bevy_mod_scripting/pull/149 while also "rebasing" (in quotation marks because it was nowhere near as pretty as a rebase) the latest few bevy updates and PR's to the crate (minus dynamic queries which I am yet to re-integrate here)
This will be the biggest breaking change to the crate so far and will bring many benefits:
I am hoping to merge this work right after the bevy 0.15 release (which I am already supporting with 8.0 pre-releases from the
stagingbranch)Removing dependency on Tealr
I still want to be able to generate docs for lua (and other languages), but Tealr forces us to do this at compile time, and also is quite behind on recent teal developments. As part of supporting generating docs for other langs I'd like to develop a custom documentation format which we can generate (ideally) at compile time, and then produce beautiful docs tailored to our use case.
This will be the next step after the big refactor.
Moving to native reflection
Bevy has come a long way since I've begun working on this crate! To put it into perspective, when the first version of BMS released Enum's were still not supported, and function reflection was unheard of!
As of now many features still rely on bits and bobs of compile time knowledge (including doc gen) which will be hard to get rid of, but I'd finally be able to get rid of the concept of per-type-script-proxies. Ideally we'd have a single
LuaProxytype which via dynamic reflection handles ALL methods and fields of a type without relying on compile time knowledge (right now we generate wrappers per native bevy type!)Script Systems & Components
Supporting OOP style scripting is much harder in a system oriented engine, but once I am happy with it, we could also support the much easier system style scripting, where scripts define dependencies on components and resources at "compile time" (think type or parameter names) allowing us to pre-compute a lot of our runtime safety information!