Some comments about coding style:

• There is a missing dot at the end of the /lua command documentation.
• There shouldn't be 3 empty lines in the code (what you added at the beginning of server/stdinhand.c).

Once the sanitized environment for scripts is implemented, there should be no way to read scripts from a file or in any way interact with the OS, only the game. Look at the proof-of-concept patch, the codestring given to /lua will be interpreted inside the same namespace as the ruleset and scenario code.

Yes, security is absolutely a concern. I didn't think about it before but: Hack access makes sense for the "free scripting" command /lua. However in reality we should allow this at CTRL access. Ideally, scripts can not influence the server, only the game, so CTRL access would be more consistent.

However, every security hole in our script runtime, turns into a remote hole if we allow CTRL access to /lua. Here is an alternative idea to think about:

Allow "triggers" that are similar to the current signal.connect(..) approach. You may register any function call as a custom-named trigger:

in ruleset or scenario script:

function create_new_player()
..
end
trigger.connect("createplayer", "create_new_player")

---

Then we add a /trigger command. The gamemaster or anyone with CTRL access may then say /trigger createnewplayer

So the ruleset may setup triggers like this, and they can be triggered at any time. However it is not as flexible as /lua. Both could be implemented in parallel, with /lua only having hack access. Of course, if we gain trust in our security solution for the script runtime, we can put the "free" version under CTRL access instead.

This is a wishlist/idea bug.

Add a server command that interprets a string of lua script directly in the current game. (This requires hack access since you may for example give victory immediately or so.)

Proposed command:

/lua <script>

The string given is directly interpreted. A single line of lua script may be setting a variable or even defining a function. Defined variables or functions are persistent. As normal, if you define a function of the same name as a previous function (or callback) you override that function.

Examples:

/lua print(find.player(1).name)

/lua create_base(find.tile(40,46), "Ruins", nil)

/lua default_hut_enter_callback = function(unit) return not unleash_barbarians(unit.tile) end

This script access may make it drastically easier for tasks like longturn's inserting of players: It can be mostly implemented as a script function in the ruleset and activated via a '/lua createplayer()' command.

Is it feasible? Of course no one is encouraged to major programming during a game, but it might be useful like the longturn example I gave, as well as for editing or experimenting.