#1
Posted 25 January 2014 - 12:11 AM
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
Posted 25 January 2014 - 03:30 AM
#3
Posted 25 January 2014 - 03:38 AM
#4
Posted 25 January 2014 - 03:43 AM
oeed, on 25 January 2014 - 03:38 AM, said:
theoriginalbit, on 25 January 2014 - 03:30 AM, said:
Edited by theoriginalbit, 25 January 2014 - 03:43 AM.
#5
Posted 25 January 2014 - 04:15 AM
theoriginalbit, on 25 January 2014 - 03:43 AM, said:
oeed, on 25 January 2014 - 03:38 AM, said:
theoriginalbit, on 25 January 2014 - 03:30 AM, said:
#6
Posted 25 January 2014 - 04:31 AM
oeed, on 25 January 2014 - 04:15 AM, said:
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
Posted 25 January 2014 - 06:00 AM
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
Posted 25 January 2014 - 11:19 AM
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
Posted 25 January 2014 - 11:43 AM
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
Posted 25 January 2014 - 11:48 AM
Engineer, on 25 January 2014 - 11:43 AM, said:
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.
Engineer, on 25 January 2014 - 11:43 AM, said:
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.
Engineer, on 25 January 2014 - 11:43 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.
Edited by ElvishJerricco, 25 January 2014 - 01:55 PM.
#11
Posted 25 January 2014 - 01:07 PM
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
Posted 25 January 2014 - 01:48 PM
ElvishJerricco, on 25 January 2014 - 11:48 AM, said:
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
Posted 25 January 2014 - 01:58 PM
Engineer, on 25 January 2014 - 01:48 PM, said:
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
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
Posted 25 January 2014 - 07:11 PM
Quote
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
Posted 25 January 2014 - 08:06 PM
Engineer, on 25 January 2014 - 07:11 PM, said:
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
Posted 25 January 2014 - 09:24 PM
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
Posted 25 January 2014 - 11:22 PM
tomass1996, on 25 January 2014 - 09:24 PM, said:
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
Posted 26 January 2014 - 01:31 AM
#19
Posted 26 January 2014 - 03:02 AM
Bomb Bloke, on 25 January 2014 - 11:22 PM, said:
tomass1996, on 25 January 2014 - 09:24 PM, said:
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
Posted 26 January 2014 - 03:46 AM
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