PureTryOut wrote: Maybe it'll also make it possible to edit the main menu (read: launcher) using mods?
rubenwardy wrote:The main menu is already in lua
Because you can't do it from a server side mod?taikedz wrote:.... why would editing the menu be relevant to "client side scripting"?
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.
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.
PureTryOut wrote:Because you can't do it from a server side mod?taikedz wrote:.... why would editing the menu be relevant to "client side scripting"?
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.
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.
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.
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.
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.
minetest.register_client_script("is_protected", function(pos,player)
-- some code
end)
Wuzzy wrote:I would be glad if some core dev could step up here and maybe tell us more about the idea.
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.
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 exampleYour 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.
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.
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?
Users browsing this forum: No registered users and 17 guests