addrelative force is broken in 2017.2

addrelative force doesnt work in 2017.2 anymore
it all happens in world space

is this a bug?

 

found that its only happening on instantiated gameobjects

 

still havent found a way to fix it

 

Maybe you're using the wrong forcemode, or maybe instantiated objects are considered inactive on the frame they are created, and AddRelativeForce cannot come into play. Could we see your script?

 

It's working fine for me (2017.2.0f3).

Check your prefab settings, and throw together a simple test scene to isolate the problem.

 

it worked fine in 2017.1 and unity5
heres the code

Code (CSharp):

1. IEnumerator ejectshell(float waitTime)
2.     {
3.         yield return new WaitForSeconds(waitTime);
4.         GameObject shellInstance;
5.         shellInstance = Instantiate(shell, shellPos.transform.position,shellPos.transform.rotation) as GameObject;
6.  
7.         shellInstance.GetComponent<Rigidbody>().AddRelativeForce(60,70,0);
8.         shellInstance.GetComponent<Rigidbody>().AddRelativeTorque(500,20,800);
9.     }

 

if i add force in a script directly on the instantiated prefab it works fine
i just dont want to modify all my code

 

If the is same project/functionality works fine in 2017.1, but stops working in 2017.2, then you most likely found a regression.

Unity Technologies made various changes to the Physics System in 2017.2 and most likely their tests don't cover your use-case.

Therefore I recommend to submit a bug-report following the advice in this document.

Using the bug-reporter seems to be an important step, because it makes sure the report is in Unity Technologies bug-tracking pipeline and has to be processed at some point. Using the forum is often used to add to a little more attention to a bug-report, but does not replace submitting the bug-report.

It's from advantage to attach a project to the bug-report that UT can use to reproduce the issue and test their fix against. The easier an issue can be reproduced by QA, the more likely it is to get forwarded to a developer, who might or might not work on a bug-fix for that at some point.

After you submitted the bug-report, you receive a confirmation email with a Case number. UT often asks us to post the Case number in the forum thread, which allows them to find that bug-report if they look at your post.

Following these steps will increase the chance that UT is looking at your issue tremendously.

 

ill submit a bug report
just wanted to know if it was a bug or it was just me doing something wrong
ill add the force directly in the prefabs script for now as a workaround

 

Yield return WaitForEndOfFrame, or null to wait a single frame after instantiating the shell prefab and before adding the force, to see if that might fix the issue. It seems like it might be a bug, but the single (or partial) frame wait probably isn't important enough to go out of your way and bother writing the eject functionality into the prefab instead.

 

oooh adding waitforendofframe before addforce actually fixed it, tnx!

 

Please still submit a bug-report to Unity, so they can actually fix the issue.

 

allready done

 

im lost
that didnt fix it for everytime, still happens occasionally

 

Did you try just yielding null so it waits until the next frame?

 

how do i yield null? dont find it in the scripting ref
edit
nevermind found it, will try that

 

Code (CSharp):

1. yield return null;

 

yes that fixed it
tnx

 

unity replied to the bug report and it basicly says im doing it wrong in my scripts.
so why did it work before then?
im not submitting bug reports anymore, what a waste of time
tnx for the help here tho

 

How did they say you should be doing it?

 

They probably meant that ForceMode.Force (the default) is supposed to be little bits of force each fixed update, so is usually placed in FixedUpdate after instantiating it. The type of ForceMode to use for this kind of instant force all at once at the beginning should be ForceMode.Impulse I think, which probably works a lot differently internal to the physics engine and maybe handles being immediately called after instantiation better.

It actually didn't even occur to me to change this code to use ForceMode.Impulse instead- you should try removing the yield null and changing that and see if it also fixes the problem.

 

heres the reply:
AddRelativeForce works on the rotation of the object you're adding force to. Because the object is always instantiated with the direction of the object in which the script is attached(i.e transform.rotation of "knifeWeapon" or any other currently equipped), in this case 0,0,0, it will always go in the default direction.

A recommendation would be to rotate the object properly on start or use a direction between the Player character and certain gameobject ahead him.

 

I'm running into this same issue. I have a bow/arrow setup, that is using AddRelativeForce to fire the arrow.
In one frame I make the arrow LookAt the target it is going to fly towards then AddRelativeForce, the relative force seems to be applying to the last frames rotation not to the rotation I just set using the LookAt.

This worked in prior versions of unity fine.

Code (CSharp):

1. _arrow.CacheTransform.LookAt(finalPos);
2.  
3. _arrow.CacheRigidbody.AddRelativeForce(new Vector3(0, 0, power), ForceMode.Impulse);

This is easily remedied by just using AddForce instead, but this should still be considered a bug as it make AddRelativeForce unreliable.

 

yes i also think its a bug as it worked fine in previous versions. i hope they fix it

 

Received a reply from Unity after submitting a bug report.

Here was the code I sent for testing.

Code (CSharp):

1. using System.Collections;
2. using System.Collections.Generic;
3. using UnityEngine;
4.  
5. public class AddRelativeForceBug : MonoBehaviour
6. {
7.     public bool fireProjectile = false;
8.     public Transform aimPoint;
9.     public Transform firePoint;
10.     public GameObject arrow;
11.     public float power = 10;
12.  
13.     private GameObject _arrow;
14.    
15.     // Update is called once per frame
16.     void LateUpdate ()
17.     {
18.         if (Input.GetKeyDown(KeyCode.Space) && _arrow)
19.         {
20.             _arrow.transform.LookAt(aimPoint);
21.             Rigidbody rb = _arrow.GetComponent<Rigidbody>();
22.             rb.isKinematic = false;
23.             rb.AddRelativeForce(new Vector3(0, 0, power), ForceMode.Impulse);
24.             _arrow = null;
25.         }
26.         else
27.         {
28.             if (_arrow == null)
29.                 _arrow = GameObject.Instantiate(arrow);
30.             _arrow.transform.position = firePoint.position;
31.             _arrow.transform.rotation = firePoint.rotation;
32.         }
33.  
34.     }
35. }

 

ok, to me they said i was wrong, but good u got it to the attention.
tnx

 

Good thing I found this thread. I was going crazy thinking I accidentally changed a collider somewhere while upgrading from 2017.1 to 2017.3, but no, of course, Unity just fundamentally broke the entire physics engine in a point update and didn't bother to put it in the release notes.

 

You just need to...

Code (CSharp):

1. rig.AddForce(transform.forward * speed * deltaTime);

use the transform forward or other direction instead.

 

You don't need to do that; just inserting Physics.SyncTransforms() anywhere you use physics on a new object will fix it. I'm just mad because that seems like the sort of thing you absolutely need to put in the Upgrade Guide, or at least have a warning in the release notes that it will break existing physics for lots of people.

 

Good point, even a warning in code or console " You are using AddRelative make sure you are Syncing Transforms!"