0
\$\begingroup\$

Why is my code not working?

using UnityEngine;
using System.Collections;

public class NewBehaviourScript1 : MonoBehaviour 
{
    public float moveSpeed;
    public Vector3 input;
    public Rigidbody rb;

    void Start () 
    {
        rb = GetComponent<Rigidbody>();
    }

    void FixedUpdate () 
    {
        moveSpeed = 2;
        input = new Vector3(Input.GetAxis("Horizontal"), 0, Input.GetAxis("Vertical"));
        rb.AddForce(input * moveSpeed);
    }
}
\$\endgroup\$
3
  • \$\begingroup\$ Have you got any error? \$\endgroup\$
    – klaymen
    Commented Feb 5, 2017 at 6:23
  • \$\begingroup\$ because your Move Speed isn't enough.you can test it with moveSpeed = 50 or you can decrease Mass in Rigidbody.because when you multiply small float * big float = small float e.g 50 * 0.1 = 5 \$\endgroup\$ Commented Feb 5, 2017 at 6:45
  • \$\begingroup\$ Little nitpick: input and rb should likely be private variables. \$\endgroup\$
    – Philipp
    Commented Apr 15, 2017 at 12:50

1 Answer 1

1
\$\begingroup\$

After testing your code, the only conclusion I can come to is that you are not actually including a Rigidbody on your player. When we use GetComponent<t>(), we are referencing an existing component on the host GameObject.

Given your above code, on an object that contains a Rigidbody, the object moves quite clearly. I have included a recording, for reference.

With a valid rigidbody, the script easily allows me to move a cube around the screen.


Ensure your GameObject has a Rigidbody through code

You can add a simple tag to any script to force it to require a component. If said script is attached to a GameObject via the Inspector, the required component is added, too. You can do this with any Component; this is what it would look like if you forced your script to attach a Rigidbody:

[RequireComponent(typeof(Rigidbody))]
public class NewBehaviourScript1
{
    // ...
}
\$\endgroup\$
3
  • \$\begingroup\$ The information presented about FixedUpdate is misleading. FixedUpdate ticks at a regular rate, so unless you're changing your fixed update rate manually you won't get varying results from it - that's the whole point of a fixed update loop. Time.deltaTime returns a constant in FixedUpdate, and does not vary frame-to-frame. Also, AddForce does not specify how many units or units-per-second to move, it specifies how many Newtons of force to apply. The actual speed of movement will accelerate as the force continues to be applied, and time scaling is already built in. \$\endgroup\$
    – DMGregory
    Commented Feb 5, 2017 at 15:47
  • \$\begingroup\$ Yes, I am sure that scaling an AddForce argument by time is not appropriate. You can think of this in terms of physics units: with the default ForceMode.Force, the input is in Newtons. Multiplying this by Time.deltaTime which is in seconds would give you a value measured in Newton-seconds (ie. an impulse), or mean that your Inspector parameter was measured in Newtons-per-second, neither of which is typically what we want for a basic constant force. ;) As for consistency, FixedUpdate can be skipped, but it will never run with a different time delta, so again deltaTime is not the right tool. \$\endgroup\$
    – DMGregory
    Commented Feb 5, 2017 at 21:08
  • \$\begingroup\$ @DMGregory, when put like that, that actually does make sense. I will have to investigate 'FixedUpdate' some more. I came to the conclusion that it was skipping frames when I was able to output different fixed delta times through the debug log in a single play test. This was several versions backs, and we were playing a game of "let's try and break physics", so perhaps we tripped a bug. Thanks for the clarification, though :) \$\endgroup\$
    – Gnemlock
    Commented Feb 5, 2017 at 22:58

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .