Client Side Programs

oeed, on 25 January 2014 - 03:38 AM said:

I can see the merits in this, but what if someone else opened the computer while you were using it? What happens when you log off?

theoriginalbit, on 25 January 2014 - 03:30 AM said:

infeasible suggestion. the Minecraft server/client architecture does not allow for this.

theoriginalbit, on 25 January 2014 - 03:43 AM said:

oeed, on 25 January 2014 - 03:38 AM said:

I can see the merits in this, but what if someone else opened the computer while you were using it? What happens when you log off?

theoriginalbit, on 25 January 2014 - 03:30 AM said:

infeasible suggestion. the Minecraft server/client architecture does not allow for this.

oeed, on 25 January 2014 - 04:15 AM said:

I get that it may be impossible at the moment, but if it were in the future those would be my problems.

1. An event to tell the computer when a player opens/closes the GUI and what their username is.
This is necessary to track whether there's even a client to use, and to provide the necessary information to connect to that client.
2. An API for sending code to run client-side.
The API would either take a function (and use something to the effect of string.dump to serialize it), or just a string of code and send the data to the client to run. The available APIs on the client side would be completely separate from those on the server side, although sharing many features for sure, not allowing client code to use the redstone API, for example.

-- client_connect event returns the username of the client
local e, username = os.pullEvent("client_connect")
-- client is an API with any functions needed to send a program to the client to run
-- client.connect sends a string of code to the specified user.
-- When the client picks that up, it runs the code in the client-side Lua VM
client.connect(username, [[
    while true do
        -- Many APIs are the same between client and server, such as os.pullEvent
        -- Although the client gets different events to send
        local e, key = os.pullEvent("key-down")
        -- The client is capable of determining is a key is down
        if key == keys.a and keys.isKeyDown(keys.leftCtrl) then
            server.send("ctrl_a")
        elseif key == keys.q and keys.isKeyDown(keys.leftCtrl) then
            -- The server API provides all the functions needed to send information back to the server
            -- server.send simply sends a string back to the server.
            server.send("client_done")
            -- Breaking the loop causes the code to reach its end and the client stops executing
            break
        end
    end
]])

while true do
    local e, received_username, msg = os.pullEvent("client_message")
    if username == received_username and msg == "ctrl_a" then
        print(username .. " pressed ctrl+a!")
    elseif username == received_username and msg == "client_done" then
        print(username .. " pressed ctrl+q and is done")
        break
    end
end

client.connect(username, [[
    local e, msg = os.pullEvent("server_message")
    if msg == "some_event" then
        ...
    end
]])
client.send(username, "some_event")

Engineer, on 25 January 2014 - 11:43 AM said:

- snip -

Engineer, on 25 January 2014 - 11:43 AM said:

If you just take that as an example, how would you run a Lua VM on the client side? Well, you simply dont. Because it's highly inefficient

Engineer, on 25 January 2014 - 11:43 AM said:

plus it gives extra lagg to each client if it has to process that code.

ElvishJerricco, on 25 January 2014 - 11:48 AM said:

No. Each client isn't processing all clients' code. Each client is sent code that the programmer asks the computer to send. Specific code is run on specific clients. Adds no lag except what messages the user decides to send between client and server.

Engineer, on 25 January 2014 - 01:48 PM said:

I never stated that the client will process all code of all the clients. It's obvious that the client only runs their code.
The issue is though, the client is not meant to do that. It is only meant for the graphical aspect, except for the position updating then.
The main reason why I dislike this, is how are you going to differ client code between the server code.
Maybe some extra events should be added like 'player x opened the hui' but nothing more. Imagine it to be real life, please don't come with the silly argument that mc is not real life, you cannot run code on a person. Because that seems to me what you are asking for.. the client should not be bothered with running code for some vm, because that is more towards the old mc architecture.

I just don't have no arguments for this, but code should only be ran server side, otherwise a piece of code is ran 100 times the same..

It's complicated, just don't make it more complicated than it is already

it's not true that all the client does is rendering and GUIs. When I first attempted some modding, I was confused as to why my tile entity which just printed to the console printed everything twice. Turns out, your SSP game has the world loaded for the server, and again the world loaded for what the client needs. This actually means there's two instances of your tile entity class for each tile. Same with almost everything. There's an entire client version of the world, which is why synchronicity gets confusing; sometimes you do something that seems to work visually, but not physically, because you did it in the client world instead of the server world. Point is, the client does a lot more than graphics. And it certainly does enough to pop open a Lua VM whenever you open a GUI.

it's not true that all the client does is rendering and GUIs. When I first attempted some modding, I was confused as to why my tile entity which just printed to the console printed everything twice. Turns out, your SSP game has the world loaded for the server, and again the world loaded for what the client needs. This actually means there's two instances of your tile entity class for each tile. Same with almost everything. There's an entire client version of the world, which is why synchronicity gets confusing; sometimes you do something that seems to work visually, but not physically, because you did it in the client world instead of the server world. Point is, the client does a lot more than graphics. And it certainly does enough to pop open a Lua VM whenever you open a GUI.

Engineer, on 25 January 2014 - 07:11 PM said:

- snip -

tomass1996, on 25 January 2014 - 09:24 PM said:

I think it's an interesting idea, though it may breach the 'no breaking the 4th wall' rule

Bomb Bloke, on 25 January 2014 - 11:22 PM said:

tomass1996, on 25 January 2014 - 09:24 PM said:

I think it's an interesting idea, though it may breach the 'no breaking the 4th wall' rule

In regards to that, the idea only "makes sense" if there's some gameplay-perspective reason for the code to be client-side. From the player's perspective, they themselves should be the only thing that "exists" at their end.

One excuse might be that the code's running on a pair of glasses the player is "wearing". Another might be that the code is executing within some sort of neural interface the player has "installed". A PDA they're carrying. What doesn't make sense is for this to be implemented into regular CC computers, which can be viewed by multiple players at the same time - what they show one player, should be the same for all players. Likewise, they should not treat input from one player as somehow different to input from another.

ElvishJerricco, on 25 January 2014 - 11:48 AM said:

It's not that nothing can be done client-side. In fact, lots is done client side.

ElvishJerricco, on 25 January 2014 - 08:06 PM said:

There is no technical reason to call this difficult or unreasonable.

robhol, on 26 January 2014 - 07:29 AM said:

It would have to be coded "manually" client-side, and it wouldn't waste too much bandwidth because you only need to send this info to the server if you need it in that particular program. Hell, there could even be a traffic limit to prevent people directly "funneling" all the high-frequency events straight through to the server.

who deems what should be sent

theoriginalbit, on 26 January 2014 - 09:53 AM said:

- snip -

robhol, on 26 January 2014 - 07:29 AM said:

Also, I could be wrong, but I think some people here are taking this the wrong way. Immersion seems irrelevant? Surely, this would be transparent to the user - the server asks the client to, I dunno, do some timing-sensitive drawings, or to listen up for keys being released, or any number of other things that currently aren't feasible purely because of traffic or lag. It would actually be completely out of sight until you decide to use it. Am I right?

Bomb Bloke, on 27 January 2014 - 07:09 AM said:

and synchronise these with the one running in the server thread.

Bomb Bloke, on 27 January 2014 - 07:09 AM said:

Bear in mind that in terms of whether the suggestion will be heeded, it makes no difference whether I am right about that - Dan need only read the first post of a suggestion to know whether it 1) is feasible 2) interests him, so ultimately any further discussion (for or against) is purely for our own amusement.

Cloudy, on 27 January 2014 - 01:22 PM said:

I don't get the point. "Why" is my major question. I honestly haven't seen a good usage case other than "I would just like to do this".

Cloudy, on 27 January 2014 - 01:22 PM said:

While it wouldn't be impossible, that isn't to say it wouldn't be a great bit of work - and then there are other things to consider, like what happens in Single Player worlds? We can't simply instance two versions of the Lua VM - one for the "client" side and one for the "server" side.

Cloudy, on 27 January 2014 - 01:22 PM said:

Add to this the fact that having the client and server side separate wouldn't make sense in an in game point of view - from Steve?'s perspective, the server computer is all what should exist.

Cloudy, on 27 January 2014 - 01:22 PM said:

While I'm not a CC dev anymore, I don't think this is something that Dan would have any interest in doing.

Cloudy, on 27 January 2014 - 01:22 PM said:

I also agree with the fact there is a lot of unnecessary hostility here. I don't see why this is!

robhol, on 27 January 2014 - 01:48 PM said:

Steve doesn't care. :P/>
As I was saying earlier - the gameplay impact would be small or non-existent. The only reason it'd have ANY impact would be something like a peripheral being added, purely to explain why these added features are now possible, and as a way to balance them. If that's not a good idea, it could just be ignored. Either way, the feature wouldn't affect existing scripts in any way, and would hardly affect gameplay. About all it'd be doing is to offload certain fairly specific tasks (drawing? better input handling?) to the client, removing network lag and traffic from the list of potential problems.

D3matt, on 15 February 2014 - 03:08 PM said:

robhol, on 27 January 2014 - 01:48 PM said:

Steve doesn't care. :P/>/>
As I was saying earlier - the gameplay impact would be small or non-existent. The only reason it'd have ANY impact would be something like a peripheral being added, purely to explain why these added features are now possible, and as a way to balance them. If that's not a good idea, it could just be ignored. Either way, the feature wouldn't affect existing scripts in any way, and would hardly affect gameplay. About all it'd be doing is to offload certain fairly specific tasks (drawing? better input handling?) to the client, removing network lag and traffic from the list of potential problems.

But steve does care. He's sitting there wondering why he has a magical "client-side" program on the computer he's sitting in front of, and wondering why that's different than the normal programming he's been doing.

The player's computer does not exist in-game, and therefore running code on it that never hits the server is a huge, HUGE break of the 4th wall. You guys are trying to justify this by saying that the player isn't affected. But the player is affected. Programmers are still players.

gollark8, on 15 February 2014 - 03:44 PM said:

D3matt, on 15 February 2014 - 03:08 PM said:

robhol, on 27 January 2014 - 01:48 PM said:

Steve doesn't care. :P/>/>
As I was saying earlier - the gameplay impact would be small or non-existent. The only reason it'd have ANY impact would be something like a peripheral being added, purely to explain why these added features are now possible, and as a way to balance them. If that's not a good idea, it could just be ignored. Either way, the feature wouldn't affect existing scripts in any way, and would hardly affect gameplay. About all it'd be doing is to offload certain fairly specific tasks (drawing? better input handling?) to the client, removing network lag and traffic from the list of potential problems.

But steve does care. He's sitting there wondering why he has a magical "client-side" program on the computer he's sitting in front of, and wondering why that's different than the normal programming he's been doing.

The player's computer does not exist in-game, and therefore running code on it that never hits the server is a huge, HUGE break of the 4th wall. You guys are trying to justify this by saying that the player isn't affected. But the player is affected. Programmers are still players.

What's the issue with being allowed to do this with a PDA?