You donāt need to include Time.deltaTime with physics operations, since they run at a fixed update interval.
My guess is the problem isnāt with the input not being detected, but the value of y * Time.deltaTime given to the AddForce method results in such a tiny number that it is basically 0.
Especially if gravity is on, it will dramatically overpower this tiny amount of force.
That said we donāt have nearly enough of the code to be sure that this is the problem. What function is this line in? Is that function even being run? What is yās value?
using System.Collections;
using System.Collections.Generic;
using UnityEngine;
public class PlayerMovement : MonoBehaviour
{
public int x,y,z;
public Rigidbody rb;
// Start is called before the first frame update
void Start()
{
}
void FixedUpdate()
{
if(Input.GetKey("w")){
rb.AddForce(0,0,z*Time.deltaTime);}
if(Input.GetKey("a")){
rb.AddForce(-x*Time.deltaTime,0,0);}
if(Input.GetKey("s")){
rb.AddForce(0,0,-z*Time.deltaTime);}
if(Input.GetKey("d")){
rb.AddForce(x*Time.deltaTime,0,0);}
if(Input.GetKeyDown("space")){
rb.AddForce(0,y*Time.deltaTime,0);}
}
}
the other keys work though, if i change space to g for example, it works
Do you have gravity? If you have gravity and are sliding along the floor, then your force would have to be large to overcome it and get off the ground.
As mentioned above, donāt use Time.deltaTime in this situation. AddForce takes the time into account already.
What are the values of x, y, and z? These are intās, which is immediately suspicious to me - an int * float becomes an int, which truncates anything beyond the decimal point, so x*Time.deltaTime would have to be returning 0 unless x > 50ish, for example.
In any case, definitely always use the KeyCode version of GetKey() - it makes it impossible to mess up stuff like capitalization/spelling in the string version of it.
On a side note, please look into some general guides about code structure. Your code is quite unreadable to someone on the side and my guess is it will be quite unreadable to you in the future if you decide to come back to it.
You should avoid using GetKey in FixedUpdate. GetKey returns true only on frames the key is held down, but FixedUpdate does not run every frame. So it can and will miss some quick key presses.
Capture your input in Update, act on it in FixedUpdate.
OK, thatās officially bizarre. The video helps to rule out a lot of possible rookie errors that may cause issues, and leaves us withā¦ uhā¦ I honestly donāt know.
Is there any chance you have an unusual keyboard setup (where unusual = ānot American Englishā in this context)? Iām grasping at straws a bit.
Try adding this to your script and seeing what the result is - letās confirm whether you can actually receive spacebar input:
private static readonly KeyCode[] KeyCodes = Enum.GetValues(typeof(KeyCode))
.Cast<KeyCode>()
.Where(k => ((int)k < (int)KeyCode.Mouse0))
.ToArray();
private void Update()
{
if (Input.anyKeyDown)
{
for (int i = 0; i < KeyCodes.Length; i++)
{
KeyCode kc = KeyCodes[i];
if (Input.GetKeyDown(kc))
{
Debug.Log($"Input detected: {kc.ToString()}");
}
}
}
}
Press spacebar and see what this outputs. On my computer, I get āInput detected: Spaceā.
it says: The name āEnumā does not exist in the current context [Assembly-CSharp]
i dont know what to do to fix that i just have surface level c# knowledge
Work around it until the bug is fixed. As far as bugs go, this oneās not too hard to work around, assuming that your spacebar consistently reports as an āOā, etc. Something like:
if (Input.GetKeyDown(SpacebarKey() ) {
....
public static KeyCode SpacebarKey() {
if (Application.isEditor) return KeyCode.O;
else return KeyCode.Space;
}
Do the same thing for any other key you need to check a KeyCode for. Whenever the bug is fixed, just remove the if/else part and just return KeyCode.Space.
Hi! Just wanted to hop in and say that I was experiencing this same exact problem. Spacebar reports as āOā in my environment, as well. So, +1 on this workaround being helpful. I was going nuts trying to figure it out. Tried different installs of Unity and Linux, even. Huge sigh of relief
_
Thank you, so much!
-Don
@ Iāve been using 2019.4.7f1 when I encountered the issue. I also tried 2020.1.1f1 and 2018.4.25f1 in my troubleshooting attempts, and had the same issue in those. However, I didnāt have a problem when 2019.4 was 2019.4.6-something. I may dig through the version archives, out of curiosity, at some point.