FOSS gamedev and creative worlds

In the past I have frequently read allusions to a planned Minetest feature called “client-side scripting” or “client-side modding”.

First of all, what's all the fuzz about this?
Second of all, why?
Third of all, what are the goals of this? And what problems are you trying to solve with this which would be impossible under a purely server-sided modding system?

I think the main goal is better client side prediction. This would help with things like doors being slow to open / close, lag essentially bypassing protection.

I think it could have applications in GUI stuff that doesn't have to go to the server and back for a response. You also wouldn't have to worry about the definition being serializable, so you could have callbacks and things as part of the core GUI API.

I believe it makes it possible for mods to listen to key presses (once the callbacks are implemented of course) which is great. Maybe it'll also make it possible to edit the main menu (read: launcher) using mods?

PureTryOut wrote: Maybe it'll also make it possible to edit the main menu (read: launcher) using mods?

The main menu is already in lua

rubenwardy wrote:The main menu is already in lua

Ooh I know, but it isn't possible to edit it using a mod. We have to modify the core instead. It would be great to do that from a subgame for example.

.... why would editing the menu be relevant to "client side scripting"?

And why would you want a mod to be able to modify the menu? Mods aren't loaded until the local server (for offline games) is started anyway.

As for reducing lag effects, I agree that palliative measures don't beat enforcement, but once the client is in control, it has the final say on what happens, if the server respects events fired in the client. If it does not, it means the server still has work to do, duplicating effort for very little gain. Ultimately, lag griefing has good palliatives now (tenplus1's protector implements good options) and if network lag is an issue, there is only so much you can do before admitting that network lag is the main problem to solve, not the game communication itself.

Key presses.... client could send key preses over to server same way as already happens with "Q" (and the behaviour of on_drop is modified that way, in server side scripting) so eh.

Mainly client side scripting just opens up a whole new area of pain from engineering, synchronization and security fronts, which I am actually glad Minetest does not implement. And running code from a server on a client machine is just a no-no anyway, if you can avoid it, which MT does.

My penny for your 2 cents...

taikedz wrote:.... why would editing the menu be relevant to "client side scripting"?

Because you can't do it from a server side mod?

taikedz wrote:And why would you want a mod to be able to modify the menu? Mods aren't loaded until the local server (for offline games) is started anyway.

Because I would like to edit the main menu for myself, without having to make a PR to the core only to see it rejected because literally nobody wants it. I would have to fork the core project and keep it up-to-date myself which is just a PITA.

taikedz wrote:Key presses.... client could send key preses over to server same way as already happens with "Q" (and the behaviour of on_drop is modified that way, in server side scripting) so eh.

I would think so too, however I was told this would only create latency issues... Not sure why mods/the server can't just tell the client what key presses to send back but hey, it's what I've been told.

PureTryOut wrote:

taikedz wrote:.... why would editing the menu be relevant to "client side scripting"?

Because you can't do it from a server side mod?

When you are in the main menu, the client hasn't really started yet. It's a main menu. It's not client side scripting. It's main menu scripting. As for subgame controlled menus, it would only work with local subgames not remote servers.

In summary, this is already possible without C++ engine modifications and doesn't require client side scripting, only main menu scripting. You could make the mainmenu dofile() subgame/menu/init.lua. However, it's worth noting that the mainmenu is not sandboxed so this is a security risk

PureTryOut wrote:

taikedz wrote:And why would you want a mod to be able to modify the menu? Mods aren't loaded until the local server (for offline games) is started anyway.

Because I would like to edit the main menu for myself, without having to make a PR to the core only to see it rejected because literally nobody wants it. I would have to fork the core project and keep it up-to-date myself which is just a PITA.

See the setting which is called mainmenu_scripting_dir or similar. It allows you to get the main menu from somewhere other than builtin/mainmenu

Of course I was referring to client-sided scripting of the actual game. The main menu does not count. You don't have a client-server model for the main menu, so the main menu is irrelevant here. :P

I personally have to agree with taikedz here. I am too pretty skeptical of the idea, to be honest.
It would open a huge can of worms. Especially in terms of complexity.

Especially I have no idea how you would want to implement proper security. Minetest barely managed to set up mod security for The-Version-That-Comes-After-0.4.14, but by introducing client scripting, things become messed up again, I fear.
If I understand correctly, the “client-side scripts” have to come from the server. This is a big problem already. First: Can the client trust the server? Second: Can the client trust the connection (no man in the middle)? Say “No” to either question and your client may end up happily executing rogue code.
I think it is generally a VERY bad idea to automagically execute random code from unknown sources, but I kinda fear this is implied by “client-side scripting”.
(Just look at how the web looks: It STILL has problems with security, and XSS (for example) is still a thing.)
If people can't present a sensible security model for client-side scripting, I guess I will have to be opposed to the idea before it even started.

In the issue tracker many people allude to the idea client-side scripting as if it would be the silver bullet. :D
What I wonder is this: Are there any tasks which would be truly impossible or just very, very hard to do on the existing server-only scripting architecture?

I *think* many tasks can be done without client-side scripting but instead just making the client (C++) smarter or improving the data or communications.
For example, key presses have been suggested but I don't see the point. It does not look like something which requires client-side scripting. Just add a bunch of new “generic” keys to the protocol.
For smarter predictions, I am also not convinced that this requires client-side scripting. The client already implements a bunch of predictions and predicts things successfully and without any scripting. I don't see what kind of prediction would be impossible without scripting on the client-side.



I also opine that client-sided scripting should not be introduced lightly, because this would be a major design change. I would also say that the modding community should have a say in this.

I would be glad if some core dev could step up here and maybe tell us more about the idea. Maybe I have an incorrect understanding of the idea (not much is known about it). Maybe someone already has a more specific design or something. That would be interesting to know.
But so far, I honestly remain skeptical.

I don't think it is so hard to sandbox a lua script. You can just start by running it with an empty global environment, meaning it would have no access to anything dangerous, barring an exploit in Lua or LuaJIT itself. Then you can progressively add things that seem safe, though I guess there is likely to be some exploit to be found within whatever mod API is provided to client side scripts.

Can someone confirm or decline: does the server handles all mouse and keyboard events from its clients?
If its true, then client side scripting can simplify inventory handling. Instead of sending "left mouse button down at x,y","mouse moved to x1,y1"(multiple times),"left mouse button up at x1,y1", the client will send "move item from slot #X to slot #y". This will decrease amount of networking traffic and allow servers to handle more players.

Xudo wrote:Can someone confirm or decline: does the server handles all mouse and keyboard events from its clients?
If its true, then client side scripting can simplify inventory handling. Instead of sending "left mouse button down at x,y","mouse moved to x1,y1"(multiple times),"left mouse button up at x1,y1", the client will send "move item from slot #X to slot #y". This will decrease amount of networking traffic and allow servers to handle more players.

No it's not handle it in that much detail. Client sends things like "right click node at x,y,z" then if it's a door for instance the server updates the node at the position and sends the map changes back to the client. The client does prediction for digging which is why when there is lag you can dig through a protected wall and walk through before the server sends back the map changes which replaces the node you dug.

When the client punches an entity it does it's own prediction on how much damage is done, this is why you can beat an entity to 0hp and when the server catches up it may still have half it's hp.

It also does inventory prediction so instead of sending click at x,y it sends something like "move itemstack from inventory1 to inventory2"

Wuzzy wrote:I personally have to agree with taikedz here. I am too pretty skeptical of the idea, to be honest.
It would open a huge can of worms. Especially in terms of complexity.

Yup. Complexity is a necessity, but not beyond the necessary complexity. I do not recall what essay/philosophy talks of "inherent" and "emergent" complexity, but the problems bubbled up by adding client side scripting, both for engine devs and for modders, would be definitely non-inherent.[/quote]

Wuzzy wrote:If I understand correctly, the “client-side scripts” have to come from the server. This is a big problem already. First: Can the client trust the server? Second: Can the client trust the connection (no man in the middle)? Say “No” to either question and your client may end up happily executing rogue code.

Nail on head. I can imagine there might be a suggestion to limit the effects of a passed-on script to non-filesystem, non-OS operations, but who's to say there isn't going to be an obscure hole in the Lua engine? Nothing is 100% secure, so the less opening you give a potential attacker, the better.

It is only because of the nature of the game that mods are allowed and 3rd party code is running on a ton of servers, and unfortunately that means server admins do have to make sure their servers don't get compromised by bad code - but if lazy administration may compromise a server, it should certainly not mean as a result that client machines get compromised too.

Wuzzy wrote:I also opine that client-sided scripting should not be introduced lightly, because this would be a major design change. I would also say that the modding community should have a say in this.

Yes - to add to this, it would either mean that mods need to explicitly register client code -- say for example



Or it would mean passing all registered functions to the client -- warts, arbitrary code and all -- to be interpreted there too. No we wouldn't pass just a subset of `minetest.register_*` functions over, because eventually requests for adding and adding and adding would pile up to include the entire scripts set. Just better not to start.

Wuzzy wrote:I would be glad if some core dev could step up here and maybe tell us more about the idea.

Frankly Wuzzy, I think you have it hit it squarely and fully.

To argue the other side however, I guess it would be of interest to take another view - object state machines (to use a big word).

Say for every block loaded, a compressed summary of the current state of the meta-data was passed to the client, and for each piece of metadata, the states it can change to with possible states/values, that could be interesting....

Say for a door, it can be {open or closed}, and may have an owner with {owner can action | custom} calls. You could possibly have something implemented generally engine-side, and if-and-only-if it has a "custom" action set, it would have to wait for server validation -- this is purely for improved prediction, and even that looks like it would be a massive overhaul so am not saying it is "desirable" in any way.

It would cause an entirely new API too, adding extra code and, whilst I appreciate the prediction gain from this, I still think network latency is an issue unto itself and separate.

From the cheating side, I could easily throttle my network ad-hoc to enable lag-griefing abilities in the current setup, but who's to say I can't use a non-client-side-scripting-enabled version of the client to bypass client processing of predictions?

Honestly....... still not worth it IMHO.

taikedz wrote:Nail on head. I can imagine there might be a suggestion to limit the effects of a passed-on script to non-filesystem, non-OS operations, but who's to say there isn't going to be an obscure hole in the Lua engine? Nothing is 100% secure, so the less opening you give a potential attacker, the better.

Possible but all Lua exploits that I heard about are centered around loading Lua bytecode. Of course it's possible that bytecode is simply easier to exploit.

taikedz wrote:

Wuzzy wrote:I also opine that client-sided scripting should not be introduced lightly, because this would be a major design change. I would also say that the modding community should have a say in this.

Yes - to add to this, it would either mean that mods need to explicitly register client code -- say for example

Your phone or window isn't wide enough to display the code box. If it's a phone, try rotating it to landscape mode.

Code: Select all

minetest.register_client_script("is_protected", function(pos,player)
-- some code
end)


Or it would mean passing all registered functions to the client -- warts, arbitrary code and all -- to be interpreted there too. No we wouldn't pass just a subset of `minetest.register_*` functions over, because eventually requests for adding and adding and adding would pile up to include the entire scripts set. Just better not to start.

A new modding API will need to be created anyway if client-sided mods are to become a reality. Currently the plan is for Lua code that's suppose to be executed be the client to be stored in a separate folder and be sent to the client at connection time.

taikedz wrote:Say for every block loaded, a compressed summary of the current state of the meta-data was passed to the client, and for each piece of metadata, the states it can change to with possible states/values, that could be interesting....

Say for a door, it can be {open or closed}, and may have an owner with {owner can action | custom} calls. You could possibly have something implemented generally engine-side, and if-and-only-if it has a "custom" action set, it would have to wait for server validation -- this is purely for improved prediction, and even that looks like it would be a massive overhaul so am not saying it is "desirable" in any way.

It would cause an entirely new API too, adding extra code and, whilst I appreciate the prediction gain from this, I still think network latency is an issue unto itself and separate.

Well that sounds fairly hard to implement, and It wouldn't be nearly as versatile as client-sided scripting. Client-sided scripting could also be easily used for other things for example formspecs. Of course it would be hard to disagree it would be better from a security stand point.

taikedz wrote:From the cheating side, I could easily throttle my network ad-hoc to enable lag-griefing abilities in the current setup, but who's to say I can't use a non-client-side-scripting-enabled version of the client to bypass client processing of predictions?

Wouldn't disabling client processing of predictions just make your client seem more laggy? It shouldn't influence the state of the server.
EDIT: Shouldn't this discussion be in feature discussion, not general?