Added add_scripting_api function to AppBuilder

[dansionGit]

Proposed Changes

The possibility to add lua functions from different plugins after running

.add_scripting::<LuaRuntime>(|b| { // not needed })

At the moment all the lua functions have to be defined in the add_scripting call this becomes messy quickly, especially when working with big projects with different parts of the game put in separate plugins.

With the proposed change it it possible to do the following:

impl Plugin for PluginA {
    fn build(&self, &mut App) {
        app
            .add_scripting_api(|r| {
                r
                    .add_function("plugin_a_func_1",|| {})
                    .add_function("plugin_a_func_2",|| {})
                    ...etc...
            });
    }
}

struct PluginB;

impl Plugin for PluginB {
    fn build(&self, &mut App) {
        app
            .add_scripting_api(|r| {
                r
                    .add_function("plugin_b_func_1",|| {})
                    .add_function("plugin_b_func_2",|| {})
                    ...etc...
            });
    }
}

fn main() {
    App::new()
        .add_plugins(DefaultPlugins)
        .add_scripting::<LuaRuntime>(|b| {
            // not needed or for global stuff
        })
        .add_plugins(PluginA)
        .add_plugins(PluginB);
}

I think this change promotes separation of concern, improves readability in big projects and makes defining lua system-functions more flexible.

p.s.

I made this change without wanting to touch the original code. I guess this code can easily be merged into the BuildScriptingRuntime.

[jarkonik]

Hi! First of all thank you for your contribution ❤️! I agree with the benefits of supporting your use-case.

I think it would be fine to just add this as another method in BuildScriptingRuntime trait as you said.

It would be really great if we also added a test and/or example and/or a documentation paragraph that would allow keeping track of supported features and allow users to easily discover them. If you are not interested in contributing those that's fine - I can do that later :)

[dansionGit]

Gladly!

I moved the code to the BuildScriptingRuntime. Because of that there is also still one use of the callbacks_resource code you mentioned, so extraction of that code is not required and with that I resolved that comment.

I added a working example for lua and will work on the documentation a bit tomorrow.

Honestly I tried implementing mlua myself and failing miserably at that before I found this crate. It was all a bit above my skill level, saying that I looked into the test script and have to admit I'm not sure how that's working.

So ideally I work on the documentation some more, add a rhai example, work on any comments you may have and then leave writing the test(s) to you 😉.

And thank you for this crate!

[dansionGit]

Hi,

I added a short description in the book and the Rust docs.
I think it should be pretty complete now.

One thing which maybe is a good improvement for the future is to remove the ScriptingRuntimeBuilder from the add_scripting call.

and make it like this:

 App::new()
        .add_plugins(DefaultPlugins)
        .init_scripting::<LuaRuntime>()
        .add_scripting_api::<LuaRuntime>(|runtime| {
          ..
        |);        

It will make it more clear that init_scripting needs to be called before any other scripting call and also removed the maybe unnecessary closure parameter.

Also it is maybe a bit more inline with Bevy naming conventions like init_resource, init_schedule etc.

I understand it may be a big change for now, but maybe in a future version.

Anyway for I think this pull-request is complete and I'm glad I could contribute to this crate, don't hesitate to comment on the code though and let me fix stuff up 👍.

[jarkonik]

Merged. Thank you for your work on this! :)