Keyboard input

[EducationalPurposes]

Hi,

 

As the title says I need to know if a player presses a key or not. Luckily, we got lwjgl, so that is not really a problem for me.

But I dont know how to follow a player's keystrokes. For example, currently I have setup a system, that adds the players to a list who do a certain thing, but I am really unsure how to follow that specific player's key stuff.

 

I know you must follow the keystrokes client side, but I dont know how I can get on someone's client side or anything.

 

So a recap:how can I get into a player's client?

 

Im not expecting the practical work-out, but I do really like to see some theory what steps I should follow. Not in great detail or anything, but just something that you guys point me in the right direction.

 

Thanks, EducationalPurposes

 

[ThePocketSoul]

Use this

http://www.minecraftforum.net/topic/1798625-162sobiohazardouss-forge-keybinding-tutorial/

[EducationalPurposes]

Use this

http://www.minecraftforum.net/topic/1798625-162sobiohazardouss-forge-keybinding-tutorial/

That is a really good tutorial about keybinding, thanks for that. But what Im looking for is for every key on your keyboard, and then keybinding isnt a real good idea.

 

Thanks for the effort though!

[TheGreyGhost]

Hi

 

If I understand you right, you know how to read keypresses from Keyboard, but you're not sure how to get them from each client to the server?

 

You need to use a custom packet for that - each time the client presses your key of interest, you need to read that on the client (eg in a tick handler), send a packet to the server, then have the server process the packet.

 

http://www.minecraftforge.net/wiki/Packet_Handling

 

-TGG

 

PS this link might also be useful

http://greyminecraftcoder.blogspot.com.au/2013/10/user-input.html

[EducationalPurposes]

Hi

 

If I understand you right, you know how to read keypresses from Keyboard, but you're not sure how to get them from each client to the server?

 

You need to use a custom packet for that - each time the client presses your key of interest, you need to read that on the client (eg in a tick handler), send a packet to the server, then have the server process the packet.

 

http://www.minecraftforge.net/wiki/Packet_Handling

 

-TGG

 

PS this link might also be useful

http://greyminecraftcoder.blogspot.com.au/2013/10/user-input.html

 

That helped quite a bit, thank you for that. But I dont get how you can the actual key input of the client.

I have my tick handler implement ITickHandler, but Im very unsure how to do custom stuff to the actual client.

 

If I understand that, I think I get a big part of minecraft modding, since I never use  those sided Proxies and stuff.

[TheGreyGhost]

Hi

 

The code would look something like

 

boolean myKeyOfInterestIsDown = false;

[code]MyClientTickHandlerMethod() {
  boolean newKeyDown = Keyboard.isKeyDown(MY_KEY_OF_INTEREST);
  if (newKeyDown) {
    if (!myKeyOfInterestIsDown) {
       //send a custom packet to the server to say "I have just received a keypress for MY_KEY_OF_INTEREST" - i.e. when the key goes from up to down
    }
  }
  myKeyOfInterestIsDown = newKeyDown;
}

[/code]

 

look at the start of KeyBoard for the suitable keycodes

eg

public static final int KEY_Q              = 0x10;

 

-->Keyboard.isKeyDown(KEY_Q);

 

There are two main ways I've found helpful when interacting with the vanilla code.

The first is to use one of the many Forge registries or hooks, to add custom blocks, items, or get called when particular things happen.  This is very common.  Unfortunately the documentation is a bit patchy so it's not always easy to know what's available.  A typical strategy I use is to identify an item or block or whatever that does something similar to what I need.  Then I'll look at the vanilla code and trace it through until I figure out how it works, and usually I will stumble over a forge hook or event along the way.

 

The second strategy which is harder and less robust is to override an existing vanilla class and replace any references to it from other vanilla code.  For example, you can overwrite GameSettings.keyBindForward with your own class derived from KeyBinding.  This is usually not necessary and is often not possible.

 

A third strategy which I haven't had to use yet is to edit the base classes to overwrite the vanilla.  ("base mod")  This will probably break everytime Minecraft is updated.

 

A fourth strategy you will hear occasionally is reflection / ASM.  I would avoid this like the plague because it is fragile and very hard to debug.  I had my fill of self-modifying code back in my days of programming assembly and am not keen to go back!!

 

-TGG

 

 

 

 

 

[GotoLink]

I'd recommend using KeyHandler, for compatibility, ease of use, and auto registration of keys into the controls menu, for player convenience.

 

@TheGreyGhost:

Your second, third and fourth strategies would basically break compatibility the same way. They do roughly the same thing.

But reflection is different from ASM.

Reflection is a powerful type of code to make mods compatible between each other without dependency. A practical example is the Forge annotations, those are loaded with reflection. Manipulating classes at runtime, that is the goal of reflection.

ASM is an extremely powerful tool (to break everything without knowing ) relying on bytecode (read: manipulating lines of code, at an "internal" level). If you master it, you can change as much things as Forge without shipping Minecraft code.

A practical example is the Forge event system, which use @ForgeSubscribe in a mod class to hook with reflection, then apply changes with ASM.

[TheGreyGhost]

Hi

 

I'd recommend using KeyHandler, for compatibility, ease of use, and auto registration of keys into the controls menu, for player convenience.

Wish I'd heard of that before.  Do you have a link with more information on it, and where/how it's called from the vanilla code?

 

@TheGreyGhost:

Your second, third and fourth strategies would basically break compatibility the same way. They do roughly the same thing.

Well, the difference to my mind is that the second strategy (overriding a single method) is less likely to be broken if the vanilla classes are updated, compared with overwriting the entire class with a modified copy, or god forbid relying on the bytecode being the same.  But I agree it's not as robust as using the forge methods.

 

But reflection is different from ASM.

Reflection is a powerful type of code to make mods compatible between each other without dependency. A practical example is the Forge annotations, those are loaded with reflection. Manipulating classes at runtime, that is the goal of reflection.

ASM is an extremely powerful tool (to break everything without knowing ) relying on bytecode (read: manipulating lines of code, at an "internal" level). If you master it, you can change as much things as Forge without shipping Minecraft code.

A practical example is the Forge event system, which use @ForgeSubscribe in a mod class to hook with reflection, then apply changes with ASM.

I agree with you that both ASM and reflection are very powerful tools in the hands of the Java uebercoder, unfortunately those ranks don't include me :-)  I also doubt that the extra flexibility is really necessary unless you're doing forge-like magic, i.e. you need to link in other classes at runtime and you don't know in advance what they are.  (I understand the ethical objections against shipping even small parts of the Minecraft code, to be honest I really doubt that the Mojang folks would care that much given how long Forge was doing it).

 

At the end of the day I prefer to use chainsaws for cutting trees rather than trimming my nails, and I struggle enough with getting my code to work as it is without trying to get my mind around the extra runtime complexity :-).  Maybe once I've got a couple years Java experience I'll think differently...

 

-TGG

 

 

 

[GotoLink]

Well the KeyHandler is a ready-to-use class implementing a client tick handler.

Its use is basically explained in ThePocketSoul linked tutorial, now that i look at it.

 

@TheGreyGhost

You should consider trying reflection first, it is just "normal" code really. If you know java rules of coding, you are good to go

 

[EducationalPurposes]

At this point I figured out on how to solve my problem that I had. Thank you all for your help!

 

(I used a player tick handler, and from there you can just get the input via the lwjgl library. )