Search Unity

  1. Megacity Metro Demo now available. Download now.
    Dismiss Notice
  2. Unity support for visionOS is now available. Learn more in our blog post.
    Dismiss Notice

Unity 5. WheelCollider component is unusable.

Discussion in 'Physics' started by SeriouSerg, Mar 4, 2015.

?

What do you think about new WheelCollider component?

Poll closed Apr 3, 2015.
  1. It is unusable and needs reingeenering.

    59 vote(s)
    80.8%
  2. It is suitable for use

    14 vote(s)
    19.2%
  1. RLin

    RLin

    Joined:
    May 10, 2015
    Posts:
    133
    I guess it's okay if you find it a reasonable trade off, but shouldn't the AI be affected by the car they drive?
     
  2. DrivingSim

    DrivingSim

    Joined:
    May 28, 2013
    Posts:
    32
    We have a G27 for player input. But yeah the AI needs to know where to go so we use nodes. Also, I use the nodes for traffic lights and stop sign notification...so the car knows when the light is red/green or there's a stop sign ahead. They can also see cars in front of them and will slow to match their speed.

    Also, the player vehicle behaves great with basic input (except the shimmy when stopped). It's the AI tuning that is tricky.
     
  3. RLin

    RLin

    Joined:
    May 10, 2015
    Posts:
    133
    Center of mass helps adjust handling.
     
  4. DrivingSim

    DrivingSim

    Joined:
    May 28, 2013
    Posts:
    32
    You must be thinking that the player can drive any of the cars? No, we only have one "Player" car at the moment. Since we have to model the interior dash for each player car their are two sets of vehicle models, one for AI and one for the Player. Yes, those are tuned differently for the player since they don't effect the AI.
     
  5. RLin

    RLin

    Joined:
    May 10, 2015
    Posts:
    133
    Are the ai racing, or are they traffic? I can't tell which.
     
  6. DrivingSim

    DrivingSim

    Joined:
    May 28, 2013
    Posts:
    32
    Yeah, I know it's hard to explain in a forum the details. The AI are traffic that a "Player" can drive around in. We then record violations like running red lights, stop signs, etc. It's meant to teach the basics for teen drivers. We had an older product that did this made in Torque Engine way back before my involvement. It's run it's course so we're updating it.
     
  7. JamesLeeNZ

    JamesLeeNZ

    Joined:
    Nov 15, 2011
    Posts:
    5,616
    How are you determining your speed btw? Just wanting to check, because the value provided from rigidbody is M/S

    I find the cars want to roll and slide out quite easily, but then you realise youre actually doing 200 Km/hr and they seem less un-realistic.
     
  8. RLin

    RLin

    Joined:
    May 10, 2015
    Posts:
    133
    Oh, I thought this was racing. I guess that collisions physics at 100 mph shouldn't be that important. Personally, I stay away from wheelcolliders in traffic cars because they're a pain to set up, but that's just my preference.
     
  9. DrivingSim

    DrivingSim

    Joined:
    May 28, 2013
    Posts:
    32
    Believe me I've been fantasizing about spinning my Vehicle physics engine.
     
  10. DrivingSim

    DrivingSim

    Joined:
    May 28, 2013
    Posts:
    32
    I clamp them to whatever the speed limit is for the path their on...each path lane has a "biome" enum setting like FREEWAY or RESIDENTIAL that sets a general limit then each path can be customized down to the node level. If they exceed the limit they gently brake with something like this:

    Code (CSharp):
    1. _brakeTorque =  Mathf.MoveTowards( _brakeTorque, _brakeForce, (brakeMax/_brakeSpeed) * Time.fixedDeltaTime );
    2.  
    Before that though this code runs to get latest speeds. I use both MS and MPH in various locations so I have a conversion utility script.

    Code (CSharp):
    1.         private void calculateSpeed()
    2.         {
    3.             _myVelocity = _rigidbody.velocity;
    4.             _mySpeedMS = _myVelocity.magnitude;
    5.  
    6.             _currentSpeedMPH = _mySpeedMS * VDIUtils.MStoMPH;
    7.             _closestEntitySpeedMS = _closestEntity.AI_SpeedMPH * VDIUtils.MPHtoMS;
    8.             _currentMaxSpeedAllowedMS = _currentMaxSpeedAllowedMPH * VDIUtils.MPHtoMS;
    9.         }
    [UPDATE]
    I should have noted the converstion multipliers. You can find them on google but I'll add them here for convenience: Here's part of my utility class
    Code (csharp):
    1.  
    2. public static class VDIUtils
    3. {
    4.         public static float MStoMPH = 2.237f;
    5.         public static float MPHtoMS = 0.45f;
    6.         public static float MStoKPH = 3.6f;
    7.         public static float FeetToMeters = 0.3048f;
    8.         public static float MetersToFeet = 3.28084f;
    9. }
    10.  
     
    Last edited: Feb 26, 2016
  11. LastLance

    LastLance

    Joined:
    Feb 22, 2015
    Posts:
    52
    nice "stable" function - u can't rotate wheel. So, if u want some wheels look littlebit forward\left\right - nope, only -up of rigidbody... So, u can set any params of transform, but suspension only vertical of main RB... Nice fix, nice stability...

    *UPD It's like
    Unity + Nvidia(UN) - We give u NEXTGENNNN Physic! Love it! Hug it! Use it!
    me - ok, nice, i want make..
    un - Nope!
    me - ok, i'll fix it by
    un - nope
    me -ok... i'll reset some gameplay, reset some main parts of progect, but, it'll work nice!
    un - u can't do this simple thing with NEXTGEEEENNN physic. So, nope.
     
    Last edited: Jul 26, 2015
  12. RLin

    RLin

    Joined:
    May 10, 2015
    Posts:
    133
    Dat grammar skills iz offa da chartez

    I have no idea what either of us just said.
     
    JamesLeeNZ likes this.
  13. LastLance

    LastLance

    Joined:
    Feb 22, 2015
    Posts:
    52
    I can also speak on my native language, but, u don't look too smart for understand it, so, i've discuss physics problems in physics theme, on english, as i can.
     
  14. RLin

    RLin

    Joined:
    May 10, 2015
    Posts:
    133
    This is the internet, so you can't judge how smart I am simply by what I say or do, unlike if I was standing in front of you.

    If I offended you, I apologize. It was intended to be a joke, because some people are not native English speakers, so it's understandable, but some people are and just choose to be lazy. I can't tell the difference, because after all, this is the internet.
     
  15. DrivingSim

    DrivingSim

    Joined:
    May 28, 2013
    Posts:
    32
    See my post on previous page for context...

    Here is some potentially useful (general) information I got from the Unity support team after I sent them my project.
    • WheelCollider::forceAppPointDistance is not expected to be at 0, for a stable simulation you should set it somewhere a little bit below the car’s centre of mass (Nvidia recommends 30cm below CoM)
    • make sure suspension distance is not 0, that’s very unhealthy for WheelCollider
    • be informed that once the user sets a custom centre of mass for a Rigidbody, the inertia tensor is never ever updated (this is what we want to solve soon)

    The forceAppPointDistance seems to be more important than I realized. I just seen this in the docs.

    Please note that having this parameter equal to zero could be undesirable as it contributes to simulation instability in certain configurations. Once you observe your vehicle failing to go asleep resting on flat surface, exhibiting jittering behavior or drifting along the surface when no user input is applied, check the forceAppPointDistance values. In the editor, when a WheelCollider game object is selected, there is a green spherical gizmo displayed to show where the force application point is at the moment. Try increasing forceAppPointDistance value gradually, until you're satisfied with the result.

    I noticed that the the jittering or shimmy only occurs when motorTorque is being updated even if the value is zero. And gets slightly worse when driving. Haven't found the magic values to prevent this in my rig yet.
     
  16. RLin

    RLin

    Joined:
    May 10, 2015
    Posts:
    133
    I've noticed this jittering too, I guess I should play around with forceAppPointDistance. While my car doesn't skid unnaturally at low speeds, the bouncing causes enough sideways slip that my skid marks script leaves an on and off trail of skid marks, even when the throttle is zero. However, this problem disappears at higher speeds ( > 30 mph). @DrivingSim, my center of mass is set once and only once in Awake, is that before the inertia tensor is calculated?
     
  17. DrivingSim

    DrivingSim

    Joined:
    May 28, 2013
    Posts:
    32
    My understanding is that it is calculated once when the center of mass is custom assigned to the ridgidbody but never updated after that. It seems to imply that if you don't set a custom center of mass, the ridgidbody recalulates inertia tensor every update. I custom assign CoM at the start too, so I am testing with not setting CoM to see if what happens.
     
  18. busterb

    busterb

    Joined:
    Jul 29, 2015
    Posts:
    2
    What's the status on wheelcolliders recently? I have 5.1.2f1, I am trying to upgrade to 5 from 4 for the graphics features. Everything went fine except for the car I have in the game. The car does not have to be realistic at all, and at this point I'm willing to do anything to get this to work even slightly.

    I have tried:
    • Re-doing the whole car from scratch using the most basic, stock configuration with Unity 5 wheel colliders. It flips out all over the place. I have spent hours trying to modify settings with no luck. The wheel colliders are not inside any other object.
    • Re-doing the whole car using wheelcollidersource. Better, but it still flips out when even trying to go over the smallest slope.
    1. Would it be possible to get by with vectors or adding force to the rigidbody? It doesn't have to be realistic.
    2. Is there a way to pick the old PhysX 2.x anywhere, or forcibly replace it.
    3. Is there any way to steal the old wheel collider script from Unity 4, because that's what I inadvertently did for the FPS controller which I didn't have to do anything which just worked. Or will that not work because it is the same script and the physics backend has been switched?

    This is extremely frustrating. What am I doing wrong?

    Any help on this would be appreciated, the car in my project is necessary for the game. I have been at this for days and only recently looked up that there were all these problems with the wheel colliders in 5. As much as I want the graphics features which are working great I am going to have to go back to Unity 4 if the most basic wheel collider can't work.
     
  19. JamesLeeNZ

    JamesLeeNZ

    Joined:
    Nov 15, 2011
    Posts:
    5,616
    I can confirm wheel colliders work pretty well when configured properly. Its hard to debug wheel collider problems over the interwebs though.

    I have a script which does a bunch of automatic setting up of wheel colliders ive been meaning to post. Maybe ill get on to that at some point. Wanted to expand its functionality, but I keep getting side tracked
     
  20. busterb

    busterb

    Joined:
    Jul 29, 2015
    Posts:
    2
    I just started a new project to test this out. I followed http://docs.unity3d.com/Manual/WheelColliderTutorial.html to the letter. The car is still bumpy and jittery.

    Better question is if you spend the money for the Pro License will it work for Unity 4? I'm interested in having the good graphics that the pro plugins offer without having to spend 4-8 months trying to get a unity tutorial working.
     
  21. SnakeTheRipper

    SnakeTheRipper

    Joined:
    Dec 31, 2014
    Posts:
    136
  22. JamesLeeNZ

    JamesLeeNZ

    Joined:
    Nov 15, 2011
    Posts:
    5,616
    U4 wheels worked fine.
     
    LastLance likes this.
  23. RLin

    RLin

    Joined:
    May 10, 2015
    Posts:
    133
    Unity and PhysX be like:
    You get a glitch!
    And you get a glitch!
    Everybody gets a glitch!
     
  24. djarcas

    djarcas

    Joined:
    Nov 15, 2012
    Posts:
    245
    Quite surprisingly, I went to use the Wheel Colliders today, and it seems that they still absolutely blow up if their parent is scaled to anything other than 1... Are the Unity guys actually actively fixing bugs? >_<
     
  25. JamesLeeNZ

    JamesLeeNZ

    Joined:
    Nov 15, 2011
    Posts:
    5,616
    You should avoid ever scaling your gameobjects if they are gonna be physics driven anyway.

    At least make sure the root object that has the rb is scaled at 1,1,1
     
  26. RLin

    RLin

    Joined:
    May 10, 2015
    Posts:
    133
    Why do you want it scaled, anyways? This causes issues with positioning and other calculations, so the only thing that should be scaled, if anything, is the visual mesh. The mesh shouldn't have anything else.
     
  27. JamesLeeNZ

    JamesLeeNZ

    Joined:
    Nov 15, 2011
    Posts:
    5,616
    sometimes its easier to scale a gameobject than fix it properly.
     
  28. Dantus

    Dantus

    Joined:
    Oct 21, 2009
    Posts:
    5,667
    They can only resolve issues that are known. If you were someone who took the time to report issues, you would know that there is an issue tracker where you can check whether the bug was already reported. If the bug was known, you could vote for it, to increase its priority for Unity.
    Your rhetorical question can easily be turned around: Are you reporting bugs or just complaining in the forum?

    http://issuetracker.unity3d.com/issues/wheelcollider-is-broken-on-a-scaled-game-object
     
  29. JamesLeeNZ

    JamesLeeNZ

    Joined:
    Nov 15, 2011
    Posts:
    5,616
    But complaining in the forum is so effective :p
     
  30. kloogens

    kloogens

    Joined:
    Jul 1, 2015
    Posts:
    109
    Can anyone tell me how to capture any events from the wheel colliders?
    My vehicle works just fine, I just can't figure out why the rigid body for the car doesn't report any events from it's child wheel colliders.
    I have two other colliders attached to the cars rigid body, one as a child ,and added a few more to test, and the rigid body fires the collision events for said objects. But never the wheel colliders.

    I created a tunnel in my terrain, because the rigid body never reports wheel collider events I can't tell the wheels to ignore the terrain collision using Physics.IgnoreCollison (obj1,obj2). All other attached colliders will ignore the terrain using that method. If I call Physics.Ignore and pass a wheel collider and the terrain collider, I get a runtime error saying both colliders must be active.



    My FPS character can walk through without any problems. All other types of objects work as well.
    I've tried all kinds of configurations. Made sure the rigid body didn't fall asleep. I've tried using triggers. I've tried using the Collision.Contacts array but the wheel colliders are never found in it. Made sure the wheels are attached to the rigid body and they are. I change the Collision Detection on the rigid body, nothing..... Like I said the car runs just fine.
    I'm on day three and I haven't found anyone else with this problem so I must be missing something.



    Can anyone please help me? I would really appreciate it.
     
  31. RLin

    RLin

    Joined:
    May 10, 2015
    Posts:
    133

    Wheelcolliders are not true colliders in the sense that they cannot be detected by raycast, because the wheelcollider itself is also a raycast. Because of this, ignore collision and onCollisionEnter and other related events will not function on the wheelcolliders. If you want collision data from wheelcolliders, you want to use wheelcollider.GetGroundHit. For ignoring collisions, you need to place the wheelcolliders and other objects on certain layers and use the layer collision matrix to make them ignore collisions.
     
  32. MT3

    MT3

    Joined:
    Nov 14, 2013
    Posts:
    12
    Greetings...

    I started posting in this thread in the midst of shock and fear. When we attempted to move our project to U5, we were paralyzed when we saw the results. In a near state of panic, I posted here and waited. It took a little time, but Unity has come through in ways I could have only hoped for. After the most recent update we were able to migrate the project in a mostly painless manner. Only a few tweaks (less than 10 hrs.) to script were required and once adjusted we found better behavior on the components than previously, spring and motor in particular, but other physics based functions as well.

    I am glad and grateful that my initial fears were unfounded, Unity has proven to me that they are in it to win it. I will never again doubt Unity's dedication or ability. To every Unity employee thanks again for the work you do, it exemplifies what a company CAN stand for if it's employees care enough. Well done.

    Looking forward to the things yet to come...

    M T Miles III
     
  33. Edy

    Edy

    Joined:
    Jun 3, 2010
    Posts:
    2,497
    I disagree. forceAppPointDistance is an useful value for fine-tunning the vehicle stability (I emphasize vehicle stability, not physic engine stability nor vehicle simulation stability). It can be used, for example, for emulating the actual effects of anti-roll bars.

    The true physically realistic value for the force application point is the actual contact point (WheelHit.point). That's how it worked in Unity 4 / PhysX 2 (thus, anti-roll bars in Unity 4 had to be implemented by scripting). In Unity 5 the application point is a fixed distance relative to the wheelcollider, so the behavior of Unity 4 (realistic) is not possible. However, Unity 5.2 will support negative values at forceAppPointDistance, so I'll be able to bring back the correct behavior by scripting.

    The reason it's given some importance is because setting it to even more unrealistic values (close to the CoM) might in some cases mitigate the actual fails of the PhysX simulation when WheelColliders are configured to some values. In some cases.

    Eventually you can reach a combination of settings that do the work. The real problem is that any trivial modification of a single parameter (i.e. moving the center of mass, increasing spring strength) is a chance to the entire vehicle to become unstable and jittery again, and you have to re-start configuring all of it in order to accommodate that single change. The cause of this situation is the design of the PhysX Vehicle SDK.
     
    Last edited: Aug 18, 2015
  34. LastLance

    LastLance

    Joined:
    Feb 22, 2015
    Posts:
    52
    so, wheel collider stay gets hitpoint only from -RB.up, or, somehow direction can be changed? (rotating by x angle), coz for one type of vehicle, i'v need +-45 deg by x angle for suspension, but it's allways looks only -up direction of RB.
     
  35. Edy

    Edy

    Joined:
    Jun 3, 2010
    Posts:
    2,497
    Actually the WheelCollider raycast direction is always -rigidbody.up. Unity team is aware of this limitation and they're studying a fix. It's not trivial because of the way this is implemented in PhysX Vehicle SDK.
     
    LastLance likes this.
  36. kloogens

    kloogens

    Joined:
    Jul 1, 2015
    Posts:
    109

    I tried using the ground hit to ignore the collision but I get an error saying something to the effect that both colliders must be active in order for ignore collisions to work. After some testing "active" seems to mean actively colliding rather than being "enabled" or "actively" working. It was a couple weeks ago so I could be wrong, but pretty sure its accurate.


    I did find a work around, but I would like to figure this out for the future.

    Am I missing something?
    Have you gotten this to work yourself?

    Thanks for responding RLin
     
  37. RLin

    RLin

    Joined:
    May 10, 2015
    Posts:
    133
    You should use the layer collision matrix and place the wheelcolliders and the other colliders on the corresponding layers, then set the collisions.
     
  38. Foxxis

    Foxxis

    Joined:
    Jun 27, 2006
    Posts:
    1,108
    I am seeing very weird behaviour from the WheelCollider. We ported over a 4.6.x project and everything works as expected, except the wheel colliders.
    The wheels simply refuse to rotate. We had a custom system set up where we would apply forces to the rigidbody to simulate wheel physics (since applying motor torque to the wheelcolliders did not work well enough). It worked great.

    However, if we now apply a force to the vehicle rigidbody, the wheels resists the motion even though they have no braketorque applied. The suspension will bow under force and the wheels will start to rotate very slightly until the forces cease. It looks as if the wheels are having brakes applied, but they have not. This only ceases if the force app point distance is set to below ground (-0.5 or so).

    I have spent a few hours trying to find the cause of this to no avail. If someone knows where to look I would be very grateful. Thanks in advance!
     
  39. Dantus

    Dantus

    Joined:
    Oct 21, 2009
    Posts:
    5,667
  40. Foxxis

    Foxxis

    Joined:
    Jun 27, 2006
    Posts:
    1,108
    Thanks for the reply. But that was not helpful at all.
    I have read the docs and I know about the inner workings of the new Wheel Collider. None of the documentation explains the behaviour we are seeing. The wheels appear not to freely rotate until the external force reach a threshold. This resistance threshold seems to be determined by the force app point. After the threshold is crossed, the wheels very suddenly rotate freely and without resistance.

    I was hoping someone else had stumbled upon this problem and might offer some insight other than "read the docs".
     
  41. Foxxis

    Foxxis

    Joined:
    Jun 27, 2006
    Posts:
    1,108
    I found the problem. In this case, setting WheelCollider.suspensionDistance at runtime (start) will cause this behaviour. No idea why yet.
    Can anyone else set the suspensionDistance at runtime with predictable results...?
     
  42. Dantus

    Dantus

    Joined:
    Oct 21, 2009
    Posts:
    5,667
    I expected that you were having not just this "small" issue as you have posted in a thread with a title that says the WheelCollider is unusable. Simply got you wrong.
     
  43. Foxxis

    Foxxis

    Joined:
    Jun 27, 2006
    Posts:
    1,108
    I could have added to my post the fact that I do agree with the thread. It is still relatively worthless considering the amount of time that has passed since the first physx version was included with Unity. One would have thought that they either augmented the Physx wheel collider functionality or replaced it with another solution. I am quite disappointed with what the new "advanced" wheel collider actually turned out to be.

    To continue, my initial impression is that the physx code (despite what is written in the Unity docs) does expect to have a certain range of inputs. Ie. it will expect masses and forces in a certain range and if you venture outside of that, the result is unpredictable. And that "comfortable range" is neither documented nor static. In Unity 4.x we had elected to scale down our mass and force values as it returned better results. Those values now seem to not be optimal for the new wheel collider, so we might be looking at rescaling all values.

    I might be wrong about the value size issue as I have some work yet to do on the code, but by some simple testing this afternoon it definitely seems to be rigged towards a certain, expected value range.

    All in all, Unitys implementation of PhysX and the PhysX implementation itself leaves a lot to be desired...
     
  44. Foxxis

    Foxxis

    Joined:
    Jun 27, 2006
    Posts:
    1,108
    Despite what some people claim in this thread, the component is broken.

    If not, I challenge someone to explain the following:
    - New scene
    - Cube with rigidbody, mass 80
    - 4 empties with wheel colliders oriented as car wheels around the cube, stock settings

    Now, this will slide around a bit but the wheels will rotate. The rig will move. The spring settings are obviously too stiff, no suspension action to speak of.

    - Lower the springs/damper to 350/40 or whatever suits you (but much lower than stock settings).

    = Soft suspension that is starting to act like it is working. However, the wheel collider has now ceased to function properly. The colliders will not rotate if you incline the surface below.

    So, what is the deal here? The wheelcollider spring/Damper settings must be in a certain region and the rigidbody mass settings much be adjusted to match? So much for the unit-less physics system then...
     
  45. JamesLeeNZ

    JamesLeeNZ

    Joined:
    Nov 15, 2011
    Posts:
    5,616
  46. Foxxis

    Foxxis

    Joined:
    Jun 27, 2006
    Posts:
    1,108
    Actually, no. And you are ignoring the question. I understand how to set up wheel colliders. The problem here seems to be that the wheel collider requires a certain range of settings to work predictably. Lower the mass and spring/damper values and it all seem to fall apart...

    Edit: That is, in Unity 5. There were no problems in Unity 4.6. And yes, I have rebuilt the rig. Look at my join date, we have been through major version changes a few times before... ;)
     
  47. Foxxis

    Foxxis

    Joined:
    Jun 27, 2006
    Posts:
    1,108
    Actually, tracked down the real problem. Turns out I was wrong. Setting spring or suspensiondistance at runtime is fine.

    Recap of the problem: The wheels acting as if a brake is applied. And they will not "wake up" by adding force to the rigidbody, they will resist rotation. The suspension will work though.

    Cause: The wheelcollider physics code does seem to go to sleep in certain situations.

    In my case, one line of code "freed" the non-rotating wheels:
    So, the wheelcollider will act as if it has a brake applied, unless you apply motortorque. And yes, braketorque was set to 0.

    Sure, this might not happen in all cases. It will obviously not happen if you actually use motortorque for propulsion (which we do not, since it is not good enough).

    But if you expect a wheelcollider without brake or torque applied to roll freely regardless of spring and mass settings, then you are in for a surprise. (It will roll with the unity-supplied settings and a rigidbody mass in the 1000s, but if you are not in that unit range, then you will have problems.)

    Now I am just waiting for someone to tell me the wheel colliders are fine again. Or not. I am filing a but report, right now. ;)
     
  48. JamesLeeNZ

    JamesLeeNZ

    Joined:
    Nov 15, 2011
    Posts:
    5,616
    If youre having wheel problems I feel bad for you son, I got 99 problems, but wheel colliders aint one.

    Im not not ignoring the question. If you bothered to try the script you would see you can adjust all the settings you talk about while running, and it works fine. The free wheeling wheels is a minor problem that doesnt occur if you use them properly.
     
  49. Foxxis

    Foxxis

    Joined:
    Jun 27, 2006
    Posts:
    1,108
    I disagree. It is a symptom of the problem: The PhysX system is supposed to be multi-purpose and unit-less. However, this is not always true and it is poorly documented.

    Under the hood it makes all kinds of assumptions regarding rigidbody mass / spring + damper settings and so on. So while this works if you do use it *exactly* as intended and are fine with the results, it will blow up fairly rapidly if you venture off the beaten path.

    Given the talk about improvements in PhysX and an entirely new wheel collider, I had (as I said previously) expected more. It is relatively poorly documented, clearly not tested enough, and only fit for certain situations.
     
  50. JamesLeeNZ

    JamesLeeNZ

    Joined:
    Nov 15, 2011
    Posts:
    5,616
    I dont have that problem anyway thinking about it. Not sure why you do.

    The wheels that aren't setup as powered wheels rotate as I would expect (via ground friction) without doing anything with motor torque.

    I've tried a handful of variations of configurations with that script and have had no problems creating vehicles that handle very differently (from racecar to monster truck), so your comment about using it 'exactly as intended' is rubbish. What do you even consider 'exactly as intended'?