38 replies to this topic

[robhol]

What issues, though? Wouldn't it be pretty much the same as... different clients using the same computer now and entering conflicting key strokes?

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? Drawings might be a bit impractical because of "consistency", but several people interfacing with one computer is fairly rare anyway - and it could always just be "posted" to the server-side computer at a lower rate, while the client(s) are able to see changes immediately.

For obvious reasons, the server would still control what the client-side VMs had access to in terms of functions, and some features should be blocked. For example, HTTP should be a server-side feature. Anything that modifies the world would need to be server-side because of consistency between players.

I think this could be a great way to add things like "extra" keyboard features - polling, modifier keys, up/down events for the keyboard and mouse (or even move events). 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.

As a way of integrating it into the world, it could be a peripheral that forms some sort of bridge between the computer and the user. Deus Ex-style augmentations, anybody? Free neuropozyne here.

Edited by robhol, 26 January 2014 - 07:30 AM.

[theoriginalbit]

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.

No! ONLY text translations and rendering is done client-side! based off the rest of your comment you know nothing about neither Minecraft modding nor the basic game design concept of a server client architecture!
SSP runs as a server and as a client, what you see is the client, what actually does stuff in terms of block updates and such is the server! this is why you can open a world to LAN 'cause your server just starts broadcasting out to the network as well as your own client...

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

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

There are entire freaking packages from Minecraft missing client-side — just like there are entire server-side packages missing from the client — so yes it is completely within reason to call this difficult or unreasonable!
I think Lyqyd made a mistake merging the general topic with this one and not relocking it!
Minecraft — as well as the architecture of server/client — does not, and should not, allow for this kind of implementation, full-stop, period, what ever you want to call it, anyone who wants to break that should never consider making a mod, nor doing anything with games!

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.

No! really no! this does not work at all, who deems what should be sent?! no!!!

[robhol]

Bit: 1) calm down, please, you're acting like people are debating shooting your dog. 2) if you can't explain why something won't work, your comment isn't helpful. 3) locking a thread is the crappiest way of "resolving" a discussion.

What's missing from the client side, and why is this a stopper for putting a small Lua VM there? Do you have any sources for your claim that it's literally impossible to do anything else than rendering and GUI? Nobody's saying Minecraft isn't a freaking client-server architecture, that much is common knowledge.

People in this subforum really, really need to be less reactionary.

Quote

who deems what should be sent

the user does, and the mod itself could limit it.

Edited by robhol, 26 January 2014 - 12:06 PM.

[ElvishJerricco]

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

- snip -

No I'm fairly sure you're idea of the client part of the client/server architecture is incorrect. No packages are missing. All the same code is on the java class path from the mod's perspective because the same package is loaded for both the server and the client (a feature the forge devs worked very hard to achieve after 1.3 made that so much more realistic). The client isn't some dummy who only has enough code to put stuff on the screen. To say so shows a lack of experience in the area. For example, whenever writing the code for a TileEntitySpecialRenderer, you need to do synchronization between client and server by taking in packets and using those to put some data in the tile entity (which exists on the client side!), which is passed every frame to the special renderer. There is data and logic on the client side, not just graphics. This page talks about the code necessary to keep tiles synchronized, proving further that there is stuff on the client.

Besides, that has virtually nothing to do with the issue anyway. As long as LuaJ is on the class path (and it is, because all CC's classes are loaded, even client-side), CC has the ability to open a new Lua VM whenever and where ever it wants. So when the GUI is opened, it can open a Lua VM. Then whenever the server sends a packet saying "the Lua code over here asked to run some client code, here it is." the client runs that code in the Lua VM. This Lua VM has a small number of APIs built in, one of which instructs java to send a packet to the server, telling it that the client has sent a message to the server. Really not that complicated.


As for the bandwidth problem, it's really not much worse than having a display at all. Every tick, any changes on the screen are sent to the tile on the client side, assuming CC optimizes that (which it might not. It might just be sending all the data to all viewers every single tick). So just changing one character on the screen every sleep(0) is enough cause hoards and hoards of packets to be sent while not falling to the issue of coroutine yielding. Limit this API to one packet per tick and lag problem solved as well as the display's lag problem is.

What's impossible about this? Can you give me a technical reason this doesn't work besides your incorrect assumption that all the client is capable of is rendering, which is based off the fallacy that so much code simply doesn't exist client side?

Edited by ElvishJerricco, 26 January 2014 - 12:13 PM.

[Symmetryc]

Wait... doesn't OpenComputers already do this? (I think)?

[Bomb Bloke]

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?

That depends who you consider to be a "user" - I'd say "no", on the basis that anyone using the ComputerCraft mod (be it to run or to write scripts) counts, meaning that if there's a visible API for this accessible on a regular CC machine then the fourth wall has indeed been broken.

Hence a system that is even capable of only running code for a given client only makes sense if that system is only accessible by that client.

Following this logic, the inference is that by assuming that local code can only run on local devices (eg laptops in the player's inventory), you thus don't have to implement a "run this code locally" API at all. The simple fact that you're running a given script on eg a laptop in the player's inventory is enough to tell ComputerCraft to run the whole thing via the client's VM. The only data that gets sent back and forth between the server and client would be eg wireless rednet events.

Thus any changes to APIs would be along the lines of allowing eg the drawing of pixel-thin lines on such laptops, on the basis that bandwidth is a total non-issue when using those systems for that purpose. Of course, then you'd have people posting to the suggestions board that those functions should be available to "regular" Advanced Computers too - after all, shouldn't "desktop" machines be "more powerful"? It's rather difficult to envision an implementation that doesn't break "immersion".

This is all side-stepping the issue of the rather hefty workload involved in implementing all this - again, simple or not, a prohibitive amount of work would need to go into it. Makes for somewhat interesting discussion though.

[robhol]

Fourth wall? Huh? What are you even talking about.

I still think you might've misunderstood the point. It's not about laptops, it's just about running code in a different layer. The "peripheral" I mentioned would just be an excuse, pretty much, for why it's possible, AND a way to balance it a bit.
If it didn't work on any kind of computer, there'd be almost no point. PDAs are neat, but they already have their own uses.

Pixel graphics have been shot down, not (just) because of bandwidth cost, but due to issues with "style".

[Bomb Bloke]

The fourth wall is the reason why you might want to use an excuse such as your proposed peripheral (as opposed to just granting all ComputerCraft computers these powers by default or worrying about "balance").

In a nutshell, in a given imaginary scene (be it a game, TV show, theatre, whatever), the side of the scene that you look through to observe it is the fourth. To "break" it is to reach out to the viewer through that "wall", by way of which the fiction admits that it's a fiction with a viewer. Granting a ComputerCraft computer the power to magically show one thing to one player and another thing to another player, or differentiate between input from those players, would be admitting that it's not a real computer and so would break the wall.

[robhol]

I know what it means. I don't see how it applies. Suspension of disbelief is a better fit, but even then, it's kinda silly for something like Minecraft. I mean, it's implied that Computercraft boxes use redstone for their computational power. How much redstone do you think you would need to make something like this? Because I'll promise you right now, it's a hell of a lot more than one block.

The peripheral I mentioned could have an ID which would let the computer distinguish between clients - or it could just be glossed over and ignored the way keystrokes are now. It's not a new problem, and it's not a good reason to shoot down otherwise valid suggestions, even if that's the go-to maneuver on this subforum.

[Bomb Bloke]

Er, no, my point was that there are ways around that particular "issue".

The reason to "shoot the suggestion down", so to speak, is that ComputerCraft would suddenly need to get Lua VMs running in (or alongside) the client threads, and synchronise these with the one running in the server thread. A whole lot of work (both in terms of development and processor time) for relatively little gain - unless one wants to be able to pile a much larger workload onto a given VM (eg, by increasing the display resolution and whatnot). For keystrokes? That seems like overkill to me, to put it lightly. But that's no fun to discuss. Too obvious.

Or so it seems to me. 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.

[ElvishJerricco]

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

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

Nope. The whole idea is that the client and the server remain independent. You just run code on both sides and are capable of sending messages back and forth, similar to socket.io. No synchronization necessary on CC's part.

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.

Nope. Reading the first post only provides an extremely incomplete view of the subject (especially with this particular suggestion), and to judge an idea by the first words about it would be silly.

Edited by ElvishJerricco, 27 January 2014 - 07:28 AM.

[Cloudy]

I don't get the point. "Why" is my major question.

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.

I honestly haven't seen a good usage case other than "I would just like to do this". 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.

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

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

Edited by Cloudy, 27 January 2014 - 01:23 PM.

[robhol]

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

It would allow a number of features that have otherwise been impractical due to traffic, and it would be a neat way to add some features the community has been clamoring for. Which isn't a bad reason in and of itself, subforum culture notwithstanding...

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.

I sort of... didn't think it'd work that way? The server and client are still "separate" when playing singleplayer, surely? They just happen to run on the same computer. Otherwise, what was the point from Mojang's perspective in making Minecraft "entirely" client-server?

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.

Steve doesn't care.
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.

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.

Well, only one person can really answer whether he'd be interested...

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!

I personally think it stems from certain members of the "staff", habit-forming refusal of ideas (to be fair, a lot of them are crap) and natural toadying. Force of habit and peer pressure.

[Cloudy]

The Client/Server share the same memory space. They communicate via shared memory space using a queue in Single Player. Only one Java VM is running.

I still maintain that it just doesn't make sense from an in-world point of view.

Vague "it will allow to implement features" doesn't constitute a selling point for this feature.

[D3matt]

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

Steve doesn't care.
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]

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

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

Steve doesn't care. />
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?

[D3matt]

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. />
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?

The only issue discussed earlier with that is "Why can my PDA do stuff that my gigantic 1x1x1 brick of a desktop can't?" but I don't feel that's reason enough not to do. However, I also don't see a particular need to add this and I still feel it makes things overly-complicated and less unified.

[sci4me]

no, i dont think its a good idea... causes too much issues for very little benefit.

[GopherAtl]

Some better issues with doing it with the PDA: they're gonna be wireless. Suddenly rednet messages have to cross the client-server divide. Would also require one of two responses to dropping a pda, storing it in a chest, etc: either shutting it down (which doesn't seem ideal to me), or somehow transfering the entire lua state of the device back and forth between client and server. It's possible the PDAs are going to shutdown when not held anyway, I dunno what direction dan's going with that and can't guess from their current state in the beta, but either way, making rednet into something that has to be transmitted between client and server seems like a bad idea.