Jump to content




Client Side Programs



38 replies to this topic

#1 misson20000

  • Members
  • 18 posts

Posted 25 January 2014 - 12:11 AM

Maybe, there could be some sort of API to launch a program that instead of running on the server runs on the client's computers, so it's not affected by lag, and this client program could for example get keyUp/keyDown events without sending them over the network. The client program could interpret the events, for, if example, you want to do key combinations, and send only the relevant data to the server.
There should be some sort of limit on the data transferred between the client and server, to keep network lag to a minimum, and stuff like redstone interaction/filesystem should have to be server side. What do you think?

#2 theoriginalbit

    Semi-Professional ComputerCrafter

  • Moderators
  • 7,332 posts
  • LocationAustralia

Posted 25 January 2014 - 03:30 AM

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

#3 oeed

    Oversimplifier

  • Members
  • 2,095 posts
  • LocationAuckland, New Zealand

Posted 25 January 2014 - 03:38 AM

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?

#4 theoriginalbit

    Semi-Professional ComputerCrafter

  • Moderators
  • 7,332 posts
  • LocationAustralia

Posted 25 January 2014 - 03:43 AM

View Postoeed, 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?

View Posttheoriginalbit, on 25 January 2014 - 03:30 AM, said:

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

Edited by theoriginalbit, 25 January 2014 - 03:43 AM.


#5 oeed

    Oversimplifier

  • Members
  • 2,095 posts
  • LocationAuckland, New Zealand

Posted 25 January 2014 - 04:15 AM

View Posttheoriginalbit, on 25 January 2014 - 03:43 AM, said:

View Postoeed, 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?

View Posttheoriginalbit, on 25 January 2014 - 03:30 AM, said:

infeasible suggestion. the Minecraft server/client architecture does not allow for this.
I get that it may be impossible at the moment, but if it were in the future those would be my problems.

#6 theoriginalbit

    Semi-Professional ComputerCrafter

  • Moderators
  • 7,332 posts
  • LocationAustralia

Posted 25 January 2014 - 04:31 AM

View Postoeed, 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.
Minecraft won't be moving away from the current server/client architecture they're using. Nothing that ComputerCraft does will be able to change this architecture, all the client ever does is render blocks and GUIs, and play sounds, the server does everything else... Even SSP runs as a server/client which is why you're able to open your worlds to LAN and play SMP.

This is how it is now possible with OpenPeripheral to install it server-side only and not require it client-side unless you also install OpenPeripheral-Addon which adds blocks.

Edited by theoriginalbit, 25 January 2014 - 04:33 AM.


#7 Lyqyd

    Lua Liquidator

  • Moderators
  • 8,465 posts

Posted 25 January 2014 - 06:00 AM

Nope.

Computers only run server-side, period.

Edit: Well, it seems that people are overly interested in discussing this. There's no reason to clutter up General, though.

#8 ElvishJerricco

  • Members
  • 803 posts

Posted 25 January 2014 - 11:19 AM

So this suggestion thread got locked prematurely in my opinion. The idea is that you could run code on the client side which would then be capable of picking up other types of events like key-up and key-down. The claim against it is that computers run server-side. Period. Also it was claimed that the Minecraft server/client architecture doesn't allow for this.

The idea that this is impossible is ridiculous. When coding a mod, you have to take special care to make sure you're doing the right things on the right side of the network. It's actually not too hard to screw up and accidentally do something client side that was only meant to happen server side. The architecture absolutely allows anything to happen on the client side that you want. You just have to work around the need to communicate all the right things back and forth. It shouldn't be hard to make an API that can leverage the client side of CC. The client has to have LuaJ packaged with it anyway so creating an instance of a Lua VM that can run some code isn't a problem. The question is just what to communicate back and forth. Server side, two things would be needed.
  • 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.

  • 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.

Here's an example script for detecting key combos and sending them back to the server.

-- 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

I personally would greatly enjoy some networked coding and having a set of APIs for the client opens up a lot of doors for the developers in the future. This could actually allow PDAs to have pixel-accurate displays because only one player needs to look at the GUI, meaning a client-side API could exist which manipulates single pixels without bandwidth hogging.

EDIT: To add one more possible feature to the API concept, sending events to the client would be useful, like the client sent to the server.

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

Edited by ElvishJerricco, 25 January 2014 - 01:49 PM.


#9 Engineer

  • Members
  • 1,378 posts
  • LocationThe Netherlands

Posted 25 January 2014 - 11:43 AM

It isnt ridicioulous that the server-client architecture doesnt allow us to do it. Because the MineCraft client only renders and opens GUI, nothing more or less!
You are familair with modding, take the IGuiHandler for example. You open the container on the server because you want to save the slots on the server (for instance when creating a chest). Second of all, the server doesnt need the graphical crap that the actual GUI is, it only cares about those containers.

If you want to do special actions when a mouse is somewhere on the GUI, you have to send a packet. This packet only should contain that the mouse was there, again, nothing more or less.

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 plus it gives extra lagg to each client if it has to process that code.

If something like this gets implemented, probably not, then the server is going to send packets to the client and process that further on. One problem with that is: never ending loops. They just kill your client.

It will be too much of a hassle to get it implemented, because the payer must be tracked like crazy. I simply agree with Lyqyd. Code is ran server side.

#10 ElvishJerricco

  • Members
  • 803 posts

Posted 25 January 2014 - 11:48 AM

View PostEngineer, on 25 January 2014 - 11:43 AM, said:

- snip -

The reason so much is done server-side is for synchronicity's sake, which isn't an issue in this case. It's not that nothing can be done client-side. In fact, lots is done client side. So just pop open a Lua VM, listen for instruction packets from the server, run the code, send some response packets if the code asks to. It's java on both sides so you can do as much as you want. It's not really any more difficult. Redundant at worst, but that's easy to deal with.

EDIT: Also, 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.

View PostEngineer, 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

LuaJ is in the cc zip file on the client. You open a VM just like normal. And it's no less efficient than running the VM on the server side when playing in single player mode. The client is still java and LuaJ is still there. It's literally no worse than any other instance of opening a Lua VM, which happens a lot with CC.

View PostEngineer, on 25 January 2014 - 11:43 AM, said:

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

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.

Edited by ElvishJerricco, 25 January 2014 - 01:55 PM.


#11 robhol

  • Members
  • 182 posts

Posted 25 January 2014 - 01:07 PM

While this is slightly off-topic... it's nothing new that the Suggestions forum is chock full of entirely unnecessary hostility. I get that repetitive suggestions are annoying, but for god's sake, the way people act in there is ridiculous. I also completely agree that there's no reason to lock every thread, but the main issue is the fact that stubbornness and, to put it bluntly, being an asshat, seems to be condoned on that particular subforum.

I also reacted to that thread. I was tempted to call BS on the architecture thing, but I am after all... not a MC modder. It just seemed weird to me. Then someone jumped the gun (well, the lock button) as usual, and there was suddenly no room for discussion...

#12 Engineer

  • Members
  • 1,378 posts
  • LocationThe Netherlands

Posted 25 January 2014 - 01:48 PM

View PostElvishJerricco, 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.
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

#13 ElvishJerricco

  • Members
  • 803 posts

Posted 25 January 2014 - 01:58 PM

View PostEngineer, 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

Ah you ninja'd me and posted this right before I did my edit so I'll just quote myself

Quote

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.

As for not being able to differentiate between client and server code, did you not read my post at all? I gave a clear example of how the API could work. You send a string representing the program for the client to run and the client runs it. The client code has access to certain APIs and features, and those differ from the APIs and features of the server code. Then the two sides are capable of sending messages to one another.

#14 Engineer

  • Members
  • 1,378 posts
  • LocationThe Netherlands

Posted 25 January 2014 - 07:11 PM

Quote

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.
This just proves that the client only does the rendering, because if you put a @SideOnly(Side.SERVER), you would never see a lightning bolt if the method gets executed. Sure, there are two version of the tiles, but that doesnt mean that the client is capable of handling such a VM. Because rendering takes already a good amount of portion of the RAM you use.

I get your point, but it doesnt make any sense at all. Why do you want to follow just a player when it is in the GUI? I mean, as Im writing this my brother could hit my keyboard too and the computer doesn't know about it, it just thinks, hey, the user pressed the key.

Sure, it is minecraft, imagine the impossible to be impossible, but thats beyond the point. I rather would like to see better key input as handling rather than sending Strings manually back and forth. It is like your example, you dont have a .keysDown method in our CC Lua, so it would even be impossible to do.

You probably see me as some guy who is f*cking things up, but I really think this is unnecessary. The mod already does a lot of packet handling behind the scenes, and not to mention that more mods use packages. If the system is abused, it sure can cause for a lot of lagg. Plus, it wouldnt be reliable, because if one is sending a shit tonne of messages, it really cause for problems. And for the stability for the mod, I just would shake my head left and right and simply, like Lyqyd did, lock the topic if I could.

And my opinion is that this topic never should have existed.. but yeah, again my opinion.

#15 ElvishJerricco

  • Members
  • 803 posts

Posted 25 January 2014 - 08:06 PM

View PostEngineer, on 25 January 2014 - 07:11 PM, said:

- snip -

There is no technical reason to call this difficult or unreasonable. You are right though that there could be some problems with overusing the network. But A ) I've seen modders use the network much more irresponsibly than would be possible with this API on one computer (although many could be a problem), and many people still used and enjoyed those without major problems. And B ) It wouldn't be too difficult to throttle the rate at which data can be sent back and forth, preventing most of the lag issue.

As for unnecessary, so is half of what CC does. And so were half of the features that have been added over the years. Touch screens and colors, anyone? This idea adds for some really entertaining programming and makes many really cool features possible. I think that's enough reason.

Edited by ElvishJerricco, 25 January 2014 - 08:09 PM.


#16 Xtansia

  • Members
  • 492 posts
  • LocationNew Zealand

Posted 25 January 2014 - 09:24 PM

I'm not going to weigh in on the whole architecture argument,
But
1) You would most definitely limit data sent between the server and client
2) The same rules per yielding should apply to client programs, maybe with a shorter non yield timeout because the server should be handling the heavier programs
I think it's an interesting idea, though it may breach the 'no breaking the 4th wall' rule

#17 Bomb Bloke

    Hobbyist Coder

  • Moderators
  • 7,099 posts
  • LocationTasmania (AU)

Posted 25 January 2014 - 11:22 PM

View Posttomass1996, 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.

In fact my first thought on reading the suggestion was "so you want to run CC code, but not on a MineCraft server - so why not just use CCDesk?".

Granted, I can see some benefits to this. For example, a player could have a whizz-bang high-res animating interface to play with that has next to no impact on the server he's playing on... but it can still control other objects that're on that server (by sending events to and fro, so the client side knows eg when a redstone signal just got triggered server side, and so the server knows eg when the client wants to trigger a redstone signal itself).

Can it be done? Sure, anything's possible.

Would it be a lot of work to implement? Indeed it would, as simple or otherwise, there'd be a large amount of code to write and re-write.

Is that work worthwhile? Well, if I were in charge of coding it, I'd say no.

On the other hand, IIRC we're going to be getting laptops or something soon. Those would be the perfect excuse for this sort of thing.

#18 D3matt

  • Members
  • 830 posts

Posted 26 January 2014 - 01:31 AM

All technical issues aside, wouldn't it completely ruin immersion by abstracting the minecraft client and server like this? It would be very strange to have to run client and server code on the same computer, would it not?

#19 Sebra

  • Members
  • 726 posts

Posted 26 January 2014 - 03:02 AM

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

View Posttomass1996, 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.

IF code would be able to run on item AND item would be in your inventory THEN it would have sense to run on your client side.
But there would be problem to move RUNNING code to/from your inventory.

#20 oeed

    Oversimplifier

  • Members
  • 2,095 posts
  • LocationAuckland, New Zealand

Posted 26 January 2014 - 03:46 AM

As I mentioned in the original post this would definitely have it's advantages but you run in to issues when your leave or someone else tries to use your computer at the same time.

Some of the posts on this topic are really long too!





1 user(s) are reading this topic

0 members, 1 guests, 0 anonymous users