koobas.hobune.stream
Shift key down? help
I am beyond confused. I have already searched through the ask questions and googled this problem, I can't seem to get it to detect the shift key. The current script I am using is if (Input.GetKeyDown("shift")) { Debug.Log("shift key was pressed"); }
Unity recognizes "left shift" and "right shift", but not "shift".
Use something like this:
Input.GetKeyDown("left shift")
Or this:
Input.GetKeyDown(KeyCode.LeftShift)
To respond to either key, you can check both of them:
Input.GetKeyDown(KeyCode.LeftShift) || Input.GetKeyDown(KeyCode.RightShift)
You can find a full list of supported keys at the input manual page or KeyCode enum page.
Am I doing something completely wrong than, I tried all 3 ways for this code and it's not showing test on the debug log D: if (Input.Get$$anonymous$$eyDown($$anonymous$$eyCode.LeftShift)) { Debug.Log("test"); }
You often want GetKey(), which stays 'true' as long as the key is depressed. GetKeyDown() only becomes true in the one frame you start pressing it. For example, I use it to tweak scroll wheel behavior, so:
if(Input.GetKey(KeyCode.LeftShift)) modify_size; else modify_position;
The Input.* method works in Update(). If you're in a custom inspector or EditorWindow, you'll want to use event.shift instead, which contains the state of the SHIFT key as it happened at the time the event took place (which is better than the current state of the SHIFT key really).
In your update method, you can do this:
void Update()
{
bool isShiftKeyDown = Input.GetKey(KeyCode.LeftShift) || Input.GetKey(KeyCode.RightShift);
}
You need to use GetKey() instead of GetKeyDown(). The first one will return true if the shift key is down. The second one will return true only the moment the shift key is pressed (one frame).
There is no internal association with the Left/Right Shift keycode.
This is a confirmed bug by Unity. It has been in Unity since forever (pre-2010), but I reported it myself about two weeks ago.
It's Impossible to check Event.current.keyCode using the "KeyCode.LeftShift" and "KeyCode.RightShift" representations of the object Enum. The Enum object exists, but the numerical value it was supposed to associate with "LeftShift" and "RightShift" objects (written in the Documenation) does not actually exist. The LeftControl and LeftAlt variations do work. It is only LeftShift/RightShift that doesn't associate with anything that can be tested in "Event.current.keyCode".
How you can reproduce it:
Easy -- Just make a new project, make a new C# script called "TestKeycodes" then place it in an "Editor" folder, and finally, simply paste the following code into that new Editor Script:
using UnityEngine;
using UnityEditor;
[InitializeOnLoad]
[ExecuteInEditMode]
public class TestKeycodes : EditorWindow
{
[InitializeOnLoadMethod]
public static void InitTest()
{
SceneView.onSceneGUIDelegate -= OnGUI;
SceneView.onSceneGUIDelegate += OnGUI;
}
static void OnGUI()
{
Debug.Log(Event.current.keyCode);
}
}
Make sure your class runs in Edit Mode constantly and automatically!
Now run the script and watch the Console.
It will display "None" constantly in the console. Press LeftControl or RightAlt or the "A" or "P" keys. You should see them registering in the Console. Now Press LeftShift and RightShift however many times you want. You will see nothing about them appearing in the console no matter when or how you press them. This is because they don't exist.
Seriously? This has just bit me. Is there any workaround? This has cost me time.
Yep, I reported the bug several months ago -- I don't suspect it's fixed yet either.
Anyway, I think the closest I've gotten to this is a manual "Event.current.shift" check in an OnGUI event that fires when the enum of a player's custom key config is set to $$anonymous$$eyCode.LeftShift's value as an "int" (I think its int value is 310 or something? I'm probably wrong, but it's somewhere like that.) But yeah, then you'll have to use OnGUI to check the result from that Event.current.shift and manually send it to the game loop if you want to legitimately grab a player's input. You can just increase an int every game step while Event.current.shift is pressed and if it's == 1, it's the initial keypress, if it's 0 then it's not pressed, and if it's > 0 then it's been pressed for more than 1 frame.
Hope that helps!
While it is true that OnGUI won't receive shift key down / up events it was never meant for this. The shift key is a modifer key and it's state can be queried with Event.current.shift. Apart from that using Input.GetKeyDown(KeyCode.LeftShift) inside Update works fine. So the KeyCode for LeftShift and RightShift is a valid keycode. It has an actual value and it works. It's just that OnGUI doesn't receive keydown / up events for those keys.
I'm not sure why they do not propergate the shift key down / up events in OnGUI but as i said it was never meant to be used as general input method. Unfortunately Unity doesn't provide a way to manually queue new events. If you want to use OnGUI to process key events you can however create a seperate method that processes events and manually send those events. Something like this:
void Update()
{
if (Input.GetKeyDown(KeyCode.LeftShift))
ProcessEvent(new Event(0) { type = EventType.KeyDown, keyCode = KeyCode.LeftShift, shift = true });
if (Input.GetKeyDown(KeyCode.RightShift))
ProcessEvent(new Event(0) { type = EventType.KeyDown, keyCode = KeyCode.RightShift, shift = true });
if (Input.GetKeyUp(KeyCode.LeftShift))
ProcessEvent(new Event(0) { type = EventType.KeyUp, keyCode = KeyCode.LeftShift });
if (Input.GetKeyUp(KeyCode.RightShift))
ProcessEvent(new Event(0) { type = EventType.KeyUp, keyCode = KeyCode.RightShift });
}
void OnGUI()
{
Event e = Event.current;
ProcessEvent(e);
}
void ProcessEvent(Event e)
{
if (e.isKey)
{
Debug.Log("Event: " +e.type + " Key: " + e.keyCode + " shiftState: " + e.shift);
}
}
The ProcessEvent method will get all events you would get in OnGUI but in addition it gets the left and right shift down and up events. However we only get those events once when the key is pressed down. That means, unlike the control key for example, the key down event is not repeated with the keyboard repeat rate. Also it should be obvious that you can not use GUI methods inside "ProcessEvent". GUI functions only work when they are called from an actual GUI callback. Unity has an internal flag that signals this. This flag will even make Event.current to return null when used outside a GUI callback. So this is only a solution if you just want to process key events like that.
OnGUI won't receive shift key down / up events -- it was never meant for this. The shift key is a modifer key and it's state can be queried with Event.current.shift.
This is not true. Although hardware can be different, keycodes are meant to come across no matter what context they are used. To prove my point, use $$anonymous$$eyCode.LeftShift in any "Input" method call, and just like in OnGUI (at least when I tested it last), it still refuses to work. Additionally, you don't have the option of using Event.current.shift to check both at once. -- In contrast, $$anonymous$$eyCode.Left/RightControl and $$anonymous$$eyCode.Left/RightAlt work fine -- in BOTH "Event" and "Input" contexts -- and also do keyup/keydown events too.
Because a general-purpose keycode like $$anonymous$$eyCode.Shift doesn't exist to perform the equivalent function of the Event.current.shift option from OnGUI in the "Input" methods, it's clear Unity intends you to use the Left/Right versions of the keycode independently (and/or simultaneously, if you needed it) -- in all cases.
Additionally, even after writing 14+ lines of code to do this with the exact code you did it, I was still not able to get that code to generate input's $$anonymous$$eyDown and $$anonymous$$eyUp events using those two $$anonymous$$eyCodes. I have submitted the bug report some months back on this and Unity reproduced it -- but I'm not sure whether it will be fixed in the near future or not.
use KeyCode.LeftShift in any "Input" method call [ ... ] it still refuses to work
The shift keycode has always worked for me in any Input.GetKey / Down / Up method since Unity version 2.6 and it's still working.
And no, keycodes are not necessarily be meant to be valid in all contexts. This even applies to windows API callbacks and windows messages. Windows has it's own virtual key code list and not every key has an actual constant (like the number keys(0-9) and letter characters (a-z,A-Z) for example). Though they may still be present. Likewise depending on the callback certain virtual keycodes might not be returned by certain callbacks. OnGUI is a gui callback is was never meant to process gameinput. It's meant to process keyboard input for the GUI controls.
Don't get me wrong, I did not say that i'm happy with the fact that the shift key down / up events are not send through the GUI event queue. I have just explained the current behaviour and the fact that it is nowhere documented which keys are actually processed through the legacy gui system.
Also note that virtual keycodes are mapped to actual scancodes which are generated by the actual hardware. Depending on the hardware, the used driver and the used keyboard layout it's never guaranteed to get the same result on different devices.
I've tested the code i've posted in my answer and it works fine on my Win10 installation.
