RFC : Support for LUA

[Lisias]

That's the drill:

Thus guy had a hell of an idea, but I think it's too much of a hassle to implement.

So...

What if the all the advanced patch would be implemented on LUA, a pretty simple, straightforward language with a very lightweight runtime?

The code would reside on a file with the same name as the patch file, but with the excetion lua. MM would check the source URL of the patch, then check if it exists a correspondent .lua file and if finds it, load it. Then a simple syntax change on MM itself would make the call for the code on that file.

This will be simpler to implement (I have experience on LUA from my sjasm++ project) and since KSP2 team is using LUA extensively on the development, and assuming they will expose it for the Add'On authors, we would have one less barrier on supporting KSP2 later.

Additionally, there's this project embedding (or trying to) LUA into KSP, what makes the task more feasible.

[Monniasza]

Patches would have to be ordered, which is more difficult in Lua.

[Lisias]

That's the trick - you will still need traditional patches.

But a new operator would call a lua function:

@PART[my-fancy-part]
{
    mass = $@#$@$%@:lua_call(yada, yeda, yida) // this would return a float
   %MODULE[whatever]
    {
        $@#$@$%@:another-lua_call(yada, yeda, yida) // this would return a dictionary with keys-values
    }
}

The hard part (aside shoving lua on MM, of course) is where the lua code will reside. Having a config.lua in the same place config.cfg is would be the most convenient solution. It's certain that this will make the patching sensibly slower, but the really time consuming tasks are the texture loading so, frankly, we have a lot of time to burn on this stunt.

[Monniasza]

That's the trick - you will still need traditional patches.

But a new operator would call a lua function:

@PART[my-fancy-part]
{
    mass = $@#$@$%@:lua_call(yada, yeda, yida) // this would return a float
   %MODULE[whatever]
    {
        $@#$@$%@:another-lua_call(yada, yeda, yida) // this would return a dictionary with keys-values
    }
}

The hard part (aside shoving lua on MM, of course) is where the lua code will reside. Having a config.lua in the same place config.cfg is would be the most convenient solution. It's certain that this will make the patching sensibly slower, but the really time consuming tasks are the texture loading so, frankly, we have a lot of time to burn on this stunt.

However, there should be no-return calls too, like this:

@PART[my-fancy-part]
 {
     $$@#$@$%@:lua_call(yada, yeda, yida) // this would return a float
    %MODULE[whatever]
     {
         $$@#$@$%@:another-lua_call(yada, yeda, yida) // this would return a dictionary with keys-values
    }
 }

[Lisias]

That's the trick - you will still need traditional patches.
But a new operator would call a lua function:

@PART[my-fancy-part]
{
    mass = $@#$@$%@:lua_call(yada, yeda, yida) // this would return a float
   %MODULE[whatever]
    {
        $@#$@$%@:another-lua_call(yada, yeda, yida) // this would return a dictionary with keys-values
    }
}

The hard part (aside shoving lua on MM, of course) is where the lua code will reside. Having a config.lua in the same place config.cfg is would be the most convenient solution. It's certain that this will make the patching sensibly slower, but the really time consuming tasks are the texture loading so, frankly, we have a lot of time to burn on this stunt.

However, there should be no-return calls too, like this:

@PART[my-fancy-part]
 {
     $$@#$@$%@:lua_call(yada, yeda, yida) // this would return a float
    %MODULE[whatever]
     {
         $$@#$@$%@:another-lua_call(yada, yeda, yida) // this would return a dictionary with keys-values
    }
 }

No necessarily. Every function needs to return something - otherwise this feature has no place on Module Manager. Perhaps a MM Extension would be a better solution for this particular use case.

But, even if we discover a feature where this would be necessary, the function can return NULL and MM would discard NULL returns silently.

[Monniasza]

That's the trick - you will still need traditional patches.
But a new operator would call a lua function:

@PART[my-fancy-part]
{
    mass = $@#$@$%@:lua_call(yada, yeda, yida) // this would return a float
   %MODULE[whatever]
    {
        $@#$@$%@:another-lua_call(yada, yeda, yida) // this would return a dictionary with keys-values
    }
}

The hard part (aside shoving lua on MM, of course) is where the lua code will reside. Having a config.lua in the same place config.cfg is would be the most convenient solution. It's certain that this will make the patching sensibly slower, but the really time consuming tasks are the texture loading so, frankly, we have a lot of time to burn on this stunt.

However, there should be no-return calls too, like this:

@PART[my-fancy-part]
 {
     $$@#$@$%@:lua_call(yada, yeda, yida) // this would return a float
    %MODULE[whatever]
     {
         $$@#$@$%@:another-lua_call(yada, yeda, yida) // this would return a dictionary with keys-values
    }
 }

No necessarily. Every function needs to return something - otherwise this feature has no place on Module Manager. Perhaps a MM Extension would be a better solution for this particular use case.

But, even if we discover a feature where this would be necessary, the function can return NULL and MM would discard NULL returns silently.

I agree with both solutions: separate scripting language and LUA functions