157 posts
Posted 11 May 2014 - 08:37 PM
So event, param1, param2, param3, param4 = os.pullEvent("key"), if you hold shift and enter for example then param1 and param2 are shift and enter and param3 and param4 are nill unless even more buttons are pressed. So holding shift would continously make param1 a shift key value, but as soon as you press enter param1 remains shift but param2 transforms from a nil to an enter value (28). This could be good for multiple values.
Regards
Augustas
2151 posts
Location
Auckland, New Zealand
Posted 12 May 2014 - 09:38 AM
While I know that this can (to an extent) be done in Lua, it would be very useful.
I support this.
570 posts
Posted 12 May 2014 - 11:14 AM
I think it should just return a table, because those can be iterated over. However there should be a separate event for that for backwards compatibility and simplicity purposes.
It doesn't seem to be hard to implement, so I can see this being added.
7508 posts
Location
Australia
Posted 12 May 2014 - 12:04 PM
I think it should just return a table, because those can be iterated over.
local event = {os.pullEvent()}
2151 posts
Location
Auckland, New Zealand
Posted 12 May 2014 - 12:20 PM
I think it should just return a table, because those can be iterated over.
local event = {os.pullEvent()}
True, it'd be better to just add the held keys at the end for backwards
compatibility.
1610 posts
Posted 13 May 2014 - 08:11 PM
I am not sure that this is easily possible. I believe LWJGL sends keys individually, so you'd need to have a system to collect all the keys pressed over a set amount of time into a set of return values.
2151 posts
Location
Auckland, New Zealand
Posted 13 May 2014 - 10:37 PM
I am not sure that this is easily possible. I believe LWJGL sends keys individually, so you'd need to have a system to collect all the keys pressed over a set amount of time into a set of return values.
Yea, that's the issue really. It'd basically be the same system you'd have to implement Lua side.
1522 posts
Location
The Netherlands
Posted 13 May 2014 - 11:58 PM
Though LWJGL has a method isKeyDown or something like that, but that'd be another suggestion. Actually, that is just this suggestion but in a wrapper.
Edited on 13 May 2014 - 09:58 PM
1610 posts
Posted 14 May 2014 - 01:03 PM
Though LWJGL has a method isKeyDown or something like that, but that'd be another suggestion. Actually, that is just this suggestion but in a wrapper.
Maybe we could have os.isKeyDown(keycode)?
2151 posts
Location
Auckland, New Zealand
Posted 14 May 2014 - 01:12 PM
Though LWJGL has a method isKeyDown or something like that, but that'd be another suggestion. Actually, that is just this suggestion but in a wrapper.
Maybe we could have os.isKeyDown(keycode)?
Hmmm,
Dan likes to keep to an events based system.
But I'd like that.
Edited on 14 May 2014 - 11:13 AM
570 posts
Posted 14 May 2014 - 01:17 PM
I am not sure that this is easily possible. I believe LWJGL sends keys individually, so you'd need to have a system to collect all the keys pressed over a set amount of time into a set of return values.
while (Keyboard.next()) {
int key = Keyboard.getEventKey();
// Add key to return values.
}
That should work.
EDIT: Just tested it. It works but the keys have to be pressed at the exact same time. You can't press and hold a key and press another one after a while, it has to be the exact same time. But that's a side-effect of using events. os.isKeyDown would certainly be more suitable for the situation.
Edited on 14 May 2014 - 01:15 PM
197 posts
Location
Czech Republic
Posted 14 May 2014 - 04:07 PM
Though LWJGL has a method isKeyDown or something like that, but that'd be another suggestion. Actually, that is just this suggestion but in a wrapper.
Maybe we could have os.isKeyDown(keycode)?
Hmmm,
Dan likes to keep to an events based system.
But I'd like that.
Me too
1610 posts
Posted 14 May 2014 - 07:06 PM
Though LWJGL has a method isKeyDown or something like that, but that'd be another suggestion. Actually, that is just this suggestion but in a wrapper.
Maybe we could have os.isKeyDown(keycode)?
Hmmm,
Dan likes to keep to an events based system.
But I'd like that.
True, but it can be difficult to do certain things with the event based system. (For games, continuous movement, repeated key combos, etc)
892 posts
Location
Where you'd least expect it.
Posted 15 May 2014 - 03:36 PM
Though LWJGL has a method isKeyDown or something like that, but that'd be another suggestion. Actually, that is just this suggestion but in a wrapper.
Maybe we could have os.isKeyDown(keycode)?
Hmmm,
Dan likes to keep to an events based system.
But I'd like that.
True, but it can be difficult to do certain things with the event based system. (For games, continuous movement, repeated key combos, etc)
This has been discussed many times, and I believe the general consensus is that it would not work within a multiplayer environment, since there would be no viable way to pick which player to test the key on.
The only way I can see something like this happening is if something like this:
http://www.computercraft.info/forums2/index.php?/topic/16841-client-side-programs/ (client side code) was added, and I don't think that will ever happen for reasons discussed in that thread.
Edited on 15 May 2014 - 01:37 PM
570 posts
Posted 15 May 2014 - 03:57 PM
This has been discussed many times, and I believe the general consensus is that it would not work within a multiplayer environment, since there would be no viable way to pick which player to test the key on.
The only way I can see something like this happening is if something like this:
http://www.computerc...-side-programs/ (client side code) was added, and I don't think that will ever happen for reasons discussed in that thread.
Well, that's why we've got packets:
Send key check packet to client –> Client sends result back –> Everyone's happy
However, in order for it to work efficiently, instead of having os.isKeyDown(key), we should have os.checkKeys(…) which allows checking for multiple keys. This allows for sending single packets instead of separate packets for multiple keys, which is, speaking from experience, much faster.
1610 posts
Posted 15 May 2014 - 04:04 PM
Though LWJGL has a method isKeyDown or something like that, but that'd be another suggestion. Actually, that is just this suggestion but in a wrapper.
Maybe we could have os.isKeyDown(keycode)?
Hmmm,
Dan likes to keep to an events based system.
But I'd like that.
True, but it can be difficult to do certain things with the event based system. (For games, continuous movement, repeated key combos, etc)
This has been discussed many times, and I believe the general consensus is that it would not work within a multiplayer environment, since there would be no viable way to pick which player to test the key on.
The only way I can see something like this happening is if something like this:
http://www.computerc...-side-programs/ (client side code) was added, and I don't think that will ever happen for reasons discussed in that thread.
You can have a packet sent to each client. Bam. Done. I don't see the need for polling a specific user: If someone presses a key on your keyboard, the key is still pressed and the computer will still know that regardless of who pressed it.
570 posts
Posted 15 May 2014 - 04:07 PM
You can have a packet sent to each client. Bam. Done. I don't see the need for polling a specific user: If someone presses a key on your keyboard, the key is still pressed and the computer will still know that regardless of who pressed it.
Base it on proximity. Only send packets to users in reaching range of a computer. The key presses will also be sent to the computer nearest to the client. There are better ways but I think this is the safest since it's completely server-side.
EDIT: Derp, I just realised what you meant: How do we know whether the user is in the GUI since they could be faking information?
Edited on 15 May 2014 - 02:10 PM
1610 posts
Posted 15 May 2014 - 04:53 PM
You can have a packet sent to each client. Bam. Done. I don't see the need for polling a specific user: If someone presses a key on your keyboard, the key is still pressed and the computer will still know that regardless of who pressed it.
Base it on proximity. Only send packets to users in reaching range of a computer. The key presses will also be sent to the computer nearest to the client. There are better ways but I think this is the safest since it's completely server-side.
EDIT: Derp, I just realised what you meant: How do we know whether the user is in the GUI since they could be faking information?
The client would be responsible for confirming it's in the GUI.
1426 posts
Location
Does anyone put something serious here?
Posted 17 May 2014 - 03:04 PM
I'd prefer it if another event was raised when the user released a key. This means one can check if two keys are pressed at once. I guess the only issue would be is that someone could press a key, close the GUI, and then release the key. Then the terminal would still think the key was pressed and possibly muck up.
197 posts
Location
Czech Republic
Posted 17 May 2014 - 06:49 PM
I'd prefer it if another event was raised when the user released a key. This means one can check if two keys are pressed at once. I guess the only issue would be is that someone could press a key, close the GUI, and then release the key. Then the terminal would still think the key was pressed and possibly muck up.
Setting some kind of timeout should handle this… good idea
1610 posts
Posted 20 May 2014 - 04:43 PM
I'd prefer it if another event was raised when the user released a key. This means one can check if two keys are pressed at once. I guess the only issue would be is that someone could press a key, close the GUI, and then release the key. Then the terminal would still think the key was pressed and possibly muck up.
Unless the mod gets a rewrite in the backend constantly checking with LWJGL if each key on the keyboard is pressed for each player, this isn't going to happen.
1426 posts
Location
Does anyone put something serious here?
Posted 21 May 2014 - 08:55 AM
I'd prefer it if another event was raised when the user released a key. This means one can check if two keys are pressed at once. I guess the only issue would be is that someone could press a key, close the GUI, and then release the key. Then the terminal would still think the key was pressed and possibly muck up.
Unless the mod gets a rewrite in the backend constantly checking with LWJGL if each key on the keyboard is pressed for each player, this isn't going to happen.
Yeah. I see now that it can't easily be done. I'm used to OpenGL which deals with both up and down key events. Forge/Minecraft only work with key 'type' events. This seems strange but then… Looks like it is impossible.
Sigh.
1610 posts
Posted 21 May 2014 - 02:02 PM
I'd prefer it if another event was raised when the user released a key. This means one can check if two keys are pressed at once. I guess the only issue would be is that someone could press a key, close the GUI, and then release the key. Then the terminal would still think the key was pressed and possibly muck up.
Unless the mod gets a rewrite in the backend constantly checking with LWJGL if each key on the keyboard is pressed for each player, this isn't going to happen.
Yeah. I see now that it can't easily be done. I'm used to OpenGL which deals with both up and down key events. Forge/Minecraft only work with key 'type' events. This seems strange but then… Looks like it is impossible.
Sigh.
Unfortunately, yeah. That's one advantage CC emulators have over CC.
Edited on 21 May 2014 - 12:03 PM
1326 posts
Location
Error 404: Could not find.
Posted 17 June 2014 - 03:26 AM
Or you could do
local event,keya,keyb,keyc,keyd = os.pullEvent(1)
The
os.pullEvent(1)
could state how long it should wait for events to be triggered.
19 posts
Posted 19 June 2014 - 06:50 AM
It should return a table, I definitely approve of this post! :-)
656 posts
Posted 20 June 2014 - 05:03 PM
Wouldn't it be more useful and easier to make two events, "key_press" and "key_release"? I think that would be a general improvement instead of the current event-spamming.
3790 posts
Location
Lincoln, Nebraska
Posted 20 June 2014 - 05:13 PM
Again, that's not exactly as easy as you think it would be. Doing so would require that we constantly check for which user is pressing the keys, and check if they've released the keys. In a multi-user environment, it's not exactly the easiest to do.
656 posts
Posted 20 June 2014 - 06:30 PM
Again, that's not exactly as easy as you think it would be. Doing so would require that we constantly check for which user is pressing the keys, and check if they've released the keys. In a multi-user environment, it's not exactly the easiest to do.
Yea, I see…
1522 posts
Location
The Netherlands
Posted 20 June 2014 - 08:00 PM
Again, that's not exactly as easy as you think it would be. Doing so would require that we constantly check for which user is pressing the keys, and check if they've released the keys. In a multi-user environment, it's not exactly the easiest to do.
It is currently doing that anyway…
Only thing that would change is that events would change to the mentioned ones
Edited on 20 June 2014 - 06:00 PM
7083 posts
Location
Tasmania (AU)
Posted 21 June 2014 - 02:44 AM
No, it's not tracking that at present. Currently there's no way to see who pressed a given key down.
What I don't get is why a release event would require such tracking in the first place. I'm not aware of any real-world operating systems that bother with it - they just hand you the event, and if you're using multiple input devices, then that's your problem.
3790 posts
Location
Lincoln, Nebraska
Posted 21 June 2014 - 08:22 PM
What I don't get is why a release event would require such tracking in the first place. I'm not aware of any real-world operating systems that bother with it - they just hand you the event, and if you're using multiple input devices, then that's your problem.
Example: Almost all computers right now can use multiple keyboards at once. The computer does differentiate which keys are pressed on which keyboard, since key modifiers need to be captured, such as ctrl, alt, and shift. So if we were to implement this in CC, we'd have to track the people who are pressing keys.
7083 posts
Location
Tasmania (AU)
Posted 21 June 2014 - 09:04 PM
Isn't producing different key codes depending on certain combos being held a function of each keyboard's firmware (or driver), though? Certainly, it must be the case that each individual MineCraft client passes the pre-modified presses on to the server.
And if not, wouldn't that imply that ComputerCraft is already tracking information as to who's holding what? How else would the current implementation work?
Edited on 22 June 2014 - 02:54 AM