[1.7.2] KeyHandler to KeyEvents, how to replace keyUP() method?

[AXELTOPOLINO]

Hello Forge users,

I'm updating my mod from 1.6.4 to 1.7.2.

My main problem right now is the new way for handling key events.

I mean, they are working fine, but I don't know how to do stuff only when the key is up (after it has been pressed).

So the problem is that I don't know how to update the old KeyHandler method called keyUp().

 

I have found only this topic: http://www.minecraftforge.net/forum/index.php?topic=18138.0

but the solution suggested is really terrible (I don't want to check for keys in a onUpdate() function..) 

 

Thanks for the help in advance,

Axel

[coolAlias]

There's not much that can be done that I know of; for my own mod, I took the following approach:

 

1. Rethink my implementations to do the work when the key is pressed instead of released

 

2. For those that absolutely must use keyUp type functionality, attempt to encase it in a custom object that can be updated each tick when necessary, but also removed when no longer needed so as not to waste time every tick. Example: a skill that activates when key is released -> create a skill class, instantiate the object during key input event for that key and, now that the object exists, it updates each tick checking if the key is still pressed; as soon as it isn't, the skill does its thing and removes itself as needed.

 

3. Failing all the above, use a solution such as that in the topic you mentioned.

 

Sorry that may not be very helpful, but those are the only things I was able to come up with to attempt to replace the sadly extinct keyUp method. I hope we see it make a come-back some day.

[jabelar]

While it is good practice to avoid any extra processing every tick (due to the processing burden), the reality is that the code is already doing tons of stuff every tick and a simple event handler that is updating some boolean flag isn't going to break a modern computer.  I agree it would be better to have an built-in (i.e. performance optimized) keyUp type event but I wouldn't be so loathe to implement it yourself.  A pain yes but hardly a performance killer.

[AXELTOPOLINO]

Thanks guys for your answers, I will probably follow coolAlias steps. It's just that I seriously don't like when the code is messy and having all the key events around the code is surely a terrible behaviour for any good coder

 

Hope Forge guys will re-add this useful feature anytime soon,

Axel

[AXELTOPOLINO]

EDIT: I still don't get how can I detect the key released in a onUpdate function. I tried this, but it will override also all MC keybinds:

 

@SubscribeEvent
public void tickClient(ClientTickEvent e)
{
	System.out.println("TESTING");
	while (Keyboard.next())
	{
		System.out.println("TESTING STUFF0");
		if (Keyboard.getEventKeyState())
		{
			System.out.println("TESTING STUFF1a");
			FMLCommonHandler.instance().fireKeyInput(); //KeyInputEvent (on key press)
		} else {
			System.out.println("TESTING STUFF1b");
			SWKeyHandler.keyUp(Keyboard.getEventKey()); //My KeyOutputEvent (on key release)
		}
	}
}

 

Do you have any other solution?

Thanks again,

Axel

[coolAlias]

I store when my custom keys are pressed, and loop through that each tick to see if they are unpressed, rather than all the keys.

 

The best way I've found is still using the custom objects, so when I press my 'special attack' key, it activates an instance of special attack or whatever, and that object is then updated each tick (charging up or whatever) and checks as it updates if the custom key is still pressed or not; this way, I'm only checking keys that I know were pressed.

 

You could do the same with a dynamic list of currently pressed keys, or if you made an array for your keybindings it would probably be more economic to simply run through it each tick instead of adding and removing entries to a list, depending on how many keys you have.

[AXELTOPOLINO]

Thanks coolAlias for your useful answer,

on the keyDown event I'll add that key to a list which is looped every tick. For each entry of that list I will check if it is still pressed. If it's has just been released, it will apply the correct code and remove that entry from the list. Seems really fair to me, but dirty

 

Thanks again!

[jabelar]

The problem here (imho) is where FML placed the KeyInputEvent hook.

It fires from within the Keyboard.next() loop of Minecraft, but only if getEventKeyState is true, meaning it only fires for key-down events. The hook should be moved down one line, and it could be used properly.

 

Yeah, I was looking at this too last night.  Furthermore the FML KeyInputEvent event parameter passed could have more useful fields.  It seems that polling Keyboard directly and maybe firing custom events (or just processing at the time) is more generally useful, although ideally you'd want to implement the key binding as well to allow user mapping.

 

One question about the Keyboard.next() is: does invoking this method clear the list of key events from Keyboard?  I mean if you call next() do you then have to fully process it or will it still work as expected in addition to anything you might do?

 

Another question: Regarding the "key up" detection, doesn't the getEventKeyState() method do this?  From the comment description for the method, it seems that if Keyboard has a key event where getEventKeyState() returns false that means that the key was released.

[jabelar]

KeyEvent fires for every key event that happens. It is up to you to retrieve the information from the Keyboard class....Indeed it does. If getEventKeyState is false, that means that the current event is a "release-key" event. The problem is: due to the placement of the FML hook, FML's event does not fire in this case, which was my point.

My point about polling and creating own events was about augmenting/replacing the FML hook event.  In other words, by accessing Keyboard class KeyEvent directly you can detect both key down (including repeat it seems) and key up.  So can't you poll and then fire your own events for KeyUp?

 

A question about polling performance.  On the one hand doing something every tick seems like a performance burden, but of course the built-in code is already doing a lot of such polling.  Is the built-in code performance optimized in some way?  It just seems to me that polling, while a bit heavy, is something that computer should still be able to handle fairly well -- just poll KeyBoard.next() and fire off a KeyUp custom event as needed.

[jabelar]

Oh. Yeah I misunderstood you. The problem is that the only place to reliably detect key inputs is in a .hasNext() .next() loop. Which MC already has, so you can't really just put in your own.

 

Okay, so I just tried the following:

	@SubscribeEvent(priority=EventPriority.NORMAL, receiveCanceled=true)
public void onEvent(ClientTickEvent event)
{
	while (Keyboard.next())
	{
		System.out.println("Keyboard event detected");
		FMLCommonHandler.instance().fireKeyInput();
	}
}

 

And it "nicely" detects both key down and key up events.  However, it seems to entirely override any other keyboard processing by Minecraft (even ESC no longer works!).  Basically, (like I suspected when asking my first question) that iterating through the Keyboard KeyEvents removes them from the queue and so they no longer get processed by rest of Minecraft. 

 

So the problem with creating your own key up hook is figuring out how to do it without blocking vanilla keyboard processing.  One way might be to put the stuff that is read from the Keyboard.readBuffer back.  There is a readNext() method that is private that is called by the public next() method, and readNext() just reads out the values from the buffer.  You could probably use reflection (right) to access readBuffer and put back what was just read out.  I suspect that would allow vanilla keyboard processing to continue.

 

The other method would be to recreate all of the Minecraft class' keyboard processing but I suspect that would be difficult as it would likely run into issues with private fields/method calls and also potentially would change the sequence of processing in a way that might muck up actual game. 

 

I think I'll play around with using reflection to restore the readBuffer as it seems like a fairly possible way to make the KeyInputEvent hook extend to include key up.

[jabelar]

Okay, I'm stuck on the reflection already -- I'm not sure what the instance of the Keyboard  class really is.  It seems that there is no constructor or any call that instantiates it.  Instead it creates its own "implementation" instance of InputImplementation but that is also a private static field within the class.

 

Diesieben07, you're good at reflection -- is there any way to use reflection on this readBuffer field in Keyboard class?  Without an instance to reference I'm not sure how to use reflection...

[jabelar]

Oh hell please don't hack into the internals of LWJGL You'll most likely cause all sorts of problems, because most of LWJGL is natives.

The right solution is to make a PR to FML to fix the placement of the hook

 

yeah, I could tell I was getting into dangerous territory.  I think I'll try polling the keybindings instead and see if I can fire a useful key up event from there.

 

But out of interests' sake: is there a way to do reflection on fields in a non-instantiated class?

[AXELTOPOLINO]

As diesieben07 said, the only way is moving the Forge line in the Minecraft run() method. It's an easy fix, but someone must do it (I'm not good at github at all unluckily).

Jabelar, I tried the same stuff yesterday and I already said your thoughts in my previous posts, like:

 

EDIT: I still don't get how can I detect the key released in a onUpdate function. I tried this, but it will override also all MC keybinds:

 

Obviously, you mustn't use reflections for native code and using the workaroud diesieben07 suggested is good enough, just remember to remove the keybind from the list when it has been released.

Anyway we are all waiting for this little feature and I hope to see it in the next Forge versions

 

Have a good day guys!

Axel

[coolAlias]

https://github.com/MinecraftForge/FML/pull/479

And again, diesieben07 saves the day! Seriously man, you're like a super-hero the way you deliver solutions to everyone's modding troubles. Major kudos to you yet again.