feat: Complete Rewrite

[makspll]

Todo:

• Global namespace support
• Removal/Overwriting of script functions
• Re-check soundness
• Increase coverage in BMS core
• Add insert component/resource methods
• Decouple code gen away from lua
• Get rid of panicky errors on access violations and in general reduce unwrap usage
• Get rid of script allocator in favour of an actual allocator not possible at the moment
• RHAI
• Optional args
• Documentation registration scaffolding
• Utilities for getters/setters
• HashMap support
• final docs adjustments

[makspll]

There is potential to make the book both a reference and source of integration tests for the various languages

[makspll]

Now released as 0.9.0-alpha.2

[shanecelis]

Important: Keep Going!

This is looking really good! I went through the book. It looks a lot simpler for the user and more controllable too. I think I'm going to try to build with the alpha.5 for my project nano-9 soon.

Unimportant: A Question

One question that's not clear to me is, what is shared between scripts? Do they each have their own context? Is Runtime the facilitator for that?

One thing I'd like to be able to do is load some Lua code for every script. Playing with the example, I got this to work:

    let mut plugin = LuaScriptingPlugin::default();
    plugin.scripting_plugin.add_context_initializer(|script_id: &str, context: &mut bevy_mod_scripting::lua::mlua::Lua| {
        let _ = context.load(r#"
my_global = "BLAH"
"#).exec()?;
        Ok(())
    });

Is this what you'd suggest for loading static Lua code? Your documentation suggested this was good when you had dynamic needs.

I tried simply loading a "script.lua" but the two namespaces appear to be isolated.

I apologize for adding some tech support questions in this PR. I'm not blocked; I don't need any answers. Just thought I'd share what my sticking point is from a 0.8 user.

[makspll]

Hi! All good!

Yes if you have something you'd like to inject into every script that cant be served well with script functions (the dynamic script registry), I'd reccomend using context initializers!

As for sharing contexts, I've made it possible to change context loading settings, so that all scripts actually do end up living in a single Lua context.

I'll add a bit to the docs about that.

As for runtimes, they are not really relevant to Lua, since mlua doesnt have a concept of this separation. For Lua the runtime type is (). For rhai however you can share some stuff with all scripts through the runtime, as well as by interacting with contexts

[makspll]

I found my issue. My cart's lua code had this path: "cart.p8#lua" and that wasn't recognized as a Language::Lua. Got it fixed up with ScriptAssetSettings.

Nice! I will add this to the docs as well

One new issue is, how do you handle optional arguments? I was hoping I could use Option like so:

        NamespaceBuilder::<GlobalNamespace>::new_unregistered(&mut world)
            .register(
                "btn",
                |ctx: FunctionCallContext, b: Option<u8>| {
                    with_pico8(&ctx, |pico8| pico8.btn(b))
                },
            );

But I get, "Error in function btn : Error in function call: expected 1 arguments but received 0." On that note, how do you handle varargs?

Ah yes, this will expect a unit argument, i.e. Nil instead of a lack of arguments. Hmm, i could make the calling mechanism recognize "optional" arguments.

As for varargs, there isn't support for this yet, I think I could however add a variant to the script value which marshalls appropriately 🤔

[shanecelis]

Thank you!

I puzzled this one out myself. Haven't figured out how to exercise it. Looks like FunctionCallContext must come first.

    NamespaceBuilder::<N9Entity>::new(app.world_mut())
        .register("name", |ctx: FunctionCallContext, this: Val<N9Entity>| {
            let world = ctx.world()?;
            // let id: Entity = Entity::PLACEHOLDER; // How do I get the N9Entity's entity field? Oh, I see.
            world.with_component(this.entity, |name: Option<&Name>| {
                name.map(|s| s.as_str().to_owned())
            })
        })

Is this going to do what I want? My hope would be in Lua that I could do some_n9entity:name() and get nil or its name if any.

Is this what we do now instead of implementing UserData?

[shanecelis]

Oh, one thing I thought I'd pass on. You've got some functions with this signature:

pub fn register_script_functions(app: &mut App) -> &mut App;

Perhaps they might be good candidates for the function as Plugin:

pub fn register_script_functions(app: &mut App) {
    NamespaceBuilder::<World>::new_unregistered(app.world_mut()).register("info", |s: String| {
        bevy::log::info!(s);
    });
}
/// ...
app.add_plugins(register_script_functions);

[makspll]

Thank you!

I puzzled this one out myself. Haven't figured out how to exercise it. Looks like FunctionCallContext must come first.

    NamespaceBuilder::<N9Entity>::new(app.world_mut())
        .register("name", |ctx: FunctionCallContext, this: Val<N9Entity>| {
            let world = ctx.world()?;
            // let id: Entity = Entity::PLACEHOLDER; // How do I get the N9Entity's entity field? Oh, I see.
            world.with_component(this.entity, |name: Option<&Name>| {
                name.map(|s| s.as_str().to_owned())
            })
        })

Is this going to do what I want? My hope would be in Lua that I could do some_n9entity:name() and get nil or its name if any.

Is this what we do now instead of implementing UserData?

Yup thats exactly right! Function context comes first, then any args, the method call syntax just desuggars to fn(entity, arg1) and the function context is sort of a virtual argument

[makspll]

Oh, one thing I thought I'd pass on. You've got some functions with this signature:

pub fn register_script_functions(app: &mut App) -> &mut App;

Perhaps they might be good candidates for the function as Plugin:

pub fn register_script_functions(app: &mut App) {
    NamespaceBuilder::<World>::new_unregistered(app.world_mut()).register("info", |s: String| {
        bevy::log::info!(s);
    });
}
/// ...
app.add_plugins(register_script_functions);

I could but i didnt really intend these to be re-usable, mostly a convenient syntax for feature flagging some of these

[shanecelis]

Everything is working on my end with the new BMS. I guess optional arguments is my only want but I don't need it if I use a Lua facade for all my functions.

function rectfill(x0,y0,x1,y1,c)
    return __rectfill(x0,y0,x1,y1,c)
end

function spr(n,x,y,w,h,fx,fy)
    return __spr(n,x,y,w,h,fx,fy)
end

function map(cx,cy,sx,sy,cw,ch,l)
    return __map(cx or 0,cy or 0,sx or 0,sy or 0,cw or 128,ch or 64,l)
end

function print(s,x,y,c)
    return __print(s,x,y,c)
end

[makspll]

I'll have a crack at optionals next, rhai is now back :D

[shanecelis]

What am I doing wrong with this? I can call __map() and return a N9Entity but when I call retain() I get the below error.

#[derive(Clone, Reflect)]
pub struct N9Entity {
    pub entity: Entity,
    pub drop: DropPolicy,
}

pub(crate) fn register_script_functions(app: &mut App) {
    NamespaceBuilder::<N9Entity>::new(app.world_mut())
        .register("retain", |ctx: FunctionCallContext, this: Val<N9Entity>| {
            let world = ctx.world()?;
            world.with_global_access(|world| {
                let mut commands = world.commands();
                commands.entity(this.entity).remove::<Clearable>();
            })?;
            Ok(this)
        })
        ;
}
// ...
.register(
    "__map",
    |ctx: FunctionCallContext| {
        let id: Entity = // ...
            let entity = N9Entity { entity: id, drop: DropPolicy::Nothing };
            let world = ctx.world()?;
            let reference = {
                let allocator = world.allocator();
                let mut allocator = allocator.write();
                ReflectReference::new_allocated(entity, &mut allocator)
            };
            Ok(ReflectReference::into_script_ref(reference, world)?)
    },
)

    if my_map == nil then
        my_map = map()
        my_map:retain()
    end

ERROR bevy_mod_scripting_core::handler: error in script `../carts/nano9/cardboard-toad.p8#lua`: Could not find function: get for type: bevy_mod_scripting_core::bindings::reference::ReflectReference.
Context:
stack traceback:
        [C]: in metamethod 'index'
        [string "/Users/shane/Projects/bevy_mod_scripting/crat..."]:1693: in field 'draw'
        [string "/Users/shane/Projects/bevy_mod_scripting/crat..."]:1735: in method 'draw'
        [string "/Users/shane/Projects/bevy_mod_scripting/crat..."]:1837: in function '_draw'
Event handling for: Language: Lua

[makspll]

That's strange, the error suggests the fallback for the index metamethod is failing, it normally looks for a "get" function in the registry to index into the type with, I.e. to get the properties.

Do you manipulate the script function registry? It may be possible you remove it at some point and forget to insert it, which causes the guard to create a default empty one

[shanecelis]

I have an old UserData impl for it. I'll try taking that out.

EDIT: I removed that. No change. My struct isn't a Component, Resource, or anything. That shouldn't matter, right?

[shanecelis]

Confirm option arguments are working. Woohoo!

[makspll]

EDIT: I removed that. No change. My struct isn't a Component, Resource, or anything. That shouldn't matter, right?

Yeah it should not matter. It definitely looks to me like a symptom of a removed AppScriptFunctionRegistry

[shanecelis]

I got a nice new error with a type id for the missing "get" or "index" function, so I went to confirm that it was my type.

pub(crate) fn plugin(app: &mut App) {
    info!("N9Entity type id {:?}", TypeId::of::<N9Entity>());
    NamespaceBuilder::<N9Entity>::new(app.world_mut()).register(
        "retain",
        |ctx: FunctionCallContext, this: Val<N9Entity>| {
            let world = ctx.world()?;
            world.with_global_access(|world| {
                let mut commands = world.commands();
                commands.entity(this.entity).remove::<Clearable>();
            })?;
            Ok(this)
        },
    );
}

Guess what didn't get logged? Yep, that info! line because it wasn't being called. [Slaps forehead.] Oy vey! Sorry for troubling you about it.

[makspll]

It's all good, this is useful to me for improving the docs!