A Unity ID allows you to buy and/or subscribe to Unity products and services, shop in the Asset Store and participate
in the Unity community.
Discussion in 'Physics' started by SeriouSerg, Mar 4, 2015.
Bring back the legacy wheel collider!
Will not fix problem. Problems not only in wheel collider, we've got "new" PhysX, it's more fast, but crippled for a life. It's like making someone lighter, by cutting 2 legs and 1 arm - win in weight, lose in productivity. Non-convex meshes, triggers, joints, wheel collider - lots of broken parts. Wait for fix, still work with u4.6.
If you're looking functionality closer to Version 4 wheel collider, you should check out WheelColliderSource
It's a good start, and far less restrained than the new WheelCollider, although interestingly it produces a somewhat different behavior in Unity 5 than in version 4.
I hope Unity one day considers open sourcing their Physics components, especially as NVIDIA is providing full source access to the PhysX CPU SDK, albeit for Unreal Engine users.
Yeah thanks I have seen that before and may look into it.
What I don't get is why Unity decided to go with this new PhyX 3.3 without testing it thoroughly. One of the reasons I moved to Unity is because of the simplicity with physics based anything, but now the WheelCollider is a complete mess and it takes multiple people just to attempt to get it to work the way it used to.
I'm not attacking you directly Dantus, but you have to agree that changing something to the point of being unusable for the majority of Unity customers you would think would be a stupid idea.
It is just the wheel collider from what I have seen. That doesn't make PhysX in general worse. I don't know whether Unity plans to improve it, but you can be sure some better solutions will become available in the Asset Store. The basis is PhysX is good enough to allow you to create your own WheelCollider.
New wc is not unusable. I made properly behaving car in like 10 minutes from sample asset's car. Then tested it with 100kgs rigidbody mass, was bouncy, adjusted spring to match weight, and it behaved properly again. Then to the mass distribution: I added 200kgs cube on the one side with fixed joint and it affected car absolutely properly again. So idk what ya ppl talking about, imo you just cant configure it properly. Its not rocket science, really, just adjust the fuc**** spring and damping rates to cars mass. Its not harder than it was in unity4, I would even say its easier, because friction model is fixed now.
After playing around with the wheelcolliders for hours non-stop, i managed to get a stable car but wheels spin too fast compared to the speed of the car. As soon as i hit the gas the wheels spin like crazy but car moves slow. This is the only issue i'm struggling to resolve.
just saw this,
"This is how the Unity 5.0 WheelCollider works"
Thats interesting, turns out, now that if you set more mass to your car's rigidbody, you dont need to readjust springs. Turns out that springs means nothing right now, because suspension will drop to designated point anyway. I dont like shorcuts and physics "cheats", because you cant predict its behaviour. If spring automatically adjust themself to rigidbody's mass, then how can I know how it will react with rest of physicall world? I mean, my car can have 12 000kgs of mass, and springs set to 2, and what, 10kgs cube dropped on that car will drop suspension totally, when 12 000kgs car affects it only to designed by dev point? Pretty stupid, but I have to test it more. I dont know what to think about this new wc now honestly.
Nope, car and its suspension react properly with worlds masses. Turns out that spring setting is now just to adjust dampening, I mean its work like ratio now: 10 spring with 5 damper will work the same like 100 spring with 50 damper. Also fixed time step must be 0.02 to wc work correctly. It is definitely bug. Other that that wc works, it just works in it's "own, special" kind of way xd. For me looks like all this 3.3 fancy performance is achieved just by little "cheats" and simplifications like this. We have little better performance, but much more limits. I will miss non-convex dynamic rigidbodies, it really make my production harder, and force to use ugly hax.
edit: spring and damper works like ratio, but not exactly. Tested 2/2, 20/20 and 200/200 and have a little different effects, but I dont see any logic in it's behavior. new WC is still mystery for me. I dont know if I want to know how this illogical shi*t works at all. No logic in way it works, they had to use really ugly hax to make it. Seriously, unpredictable.
edit2: documentation seems to confirm my words:
Spring Spring force attempts to reach the Target Position. A larger value makes the suspension reach the Target Position faster.
Damper Dampens the suspension velocity. A larger value makes the Suspension Spring move slower.
Well it makes my production easier as I don't have to hack like crazy to get performance physics. Just saying. Anyway, edy will solve any car issues.
Sure, if you dont need non-convex dynamic rigidbodies, gains from new physx are undeniable.
And despite my rant, I still think that new wc is absolutely usable, and properly configured will give much better results than old.
I'm still getting super jittery performance in Unity 5 even with values that "should" be OK for the new system. I'm fully prepared to believe that it's something dumb I'm doing in code somewhere that I've forgotten about (since this is being tested in my main project), especially since the standard assets test car does seem to work OK. But even if I try to copy the test car and make my own simple car, without any extra scripting, I seem to get the same jitteryness - and I don't seem to be the only one.
Example values that I'm still getting crazy jitter from:
Mostly copied from the example car, though I've tried changing the values around (more damper, different force app distance etc) and always seem to get jittery results. The actual suspension values seem OK - the car moves and sits on the suspension in what looks like a correct way apart from all the random bouncing around. Vehicle weights about 2500kg (it's more like a tank). Unity 5 version 5.0.0f4.
Question is what are some of us doing that's giving us this jitter, that others are doing differently to have it work fine?
AAA, you are the guy that makes Scraps then I can post here my test scene with properly working car if it is any help?
I am. Though apparently I can't make a basic wheel collider work!
A test scene could be useful, not just for me but for everyone having problems. Or even just settings for a wheel collider that should work, on a rigidbody with x mass. Though I'm thinking maybe it's not just the settings and something to do with the heirarchy setup or something as well.
Yes post a test scene please, I have only just come across the wheel collider update and I thought my transition to 5 was going just great... Obviously not!
Finding heavy stuff doesn't work :/
I have the same issues here, no amount of settings gives me something that feels good.
The single biggest issue for me is the amount of torque you need to get a car accelerating quickly.
A 1 ton vehicle should accelerate very quickly on 300nm of torque, however with the default settings it barely moves. It looks like this is caused by a burnout, which is firstly hard to verify because the wheel RPM values are reading incorrectly (wheels without any torque applied don't even match the ground)
To fix the burnout I should be able to increase the forward friction on the wheels, but doing this to any value about around 10 (where the car still ice skates) causes the wheels to start jittering out, sometimes sending it into space.
Looking at the example car, its such a flakey example, simply change the drive type to be rear wheel drive and see what happens.
Anyone who is having success, don't bother posting a project, all we need is a screenshot of your wheel collider settings, mass and amount of wheel torque being applied.
If I can get a decent setup I will post it, everyone else please do the same
I was struggling with the same issue for hours. And I thought it was my code. That's for sure a real shame, I'm surprised that there's no UT person to answer this questions
Even if they did it'd probably be something along the lines of this...
Re: Torque and skidding, you can always ignore wheel motorTorque and just AddForce or AddForceAtPosition directly instead. It's less "realistic" but none of this is particularly realistic anyway. You'll obviously need to check if the wheels are grounded before applying force, you maybe some other stuff (like if you accelerate while in the air, you might want to make the wheels spin etc).
Some of us must be missing something because I just tried the exact wheel and rigidbody weight settings I posted above on the Standard Assets car with the built-in car control script, and it drives without any jitter.
I'm assuming Unity doesn't have some hidden (If (vehicle == standardAssetsCar) UseBetterPhysics()) code hidden somewhere.
See if you can get something that's 10000kg to move...
If so then post a screenshot of your WheelCollider.
The standard assets car is already very slippy. Making it 10,000kg has it wheel-spinning constantly and hardly moving (even with "traction control" on). Increasing friction enough to make it move brings out the crazy jitter.
Someone else should replicate the problem to confirm for sure, but this really looks fundamentally broken. I can't make a 10,000kg vehicle that has enough friction to use motorTorque to drive normally.
Has anyone tested this??
Calm down ppl, we just need to figure out why some ppl have those jitter problems. I have thought that maybe upgraded from unity4 projects had these problems.
The 10,000kg vehicle test was in a new project. Could be that there are settings I should have tweaked better, but using a heavy rigidbody weight does really seem to bring out the issues. Want to try making your test vehicle much heavier and see how it goes?
Yes, I have. WheelColliderSource works somewhat differently under Unity 5, but it's not as cumbersome to configure as the Unity 5 WheelCollider.
Here ya have my working example. It is absolutely properly working, driveable car(I would say even kind of semi-realistic). With attached by breakable hinge joint heavy cube, to show that weight distribution works, and that breakable hinge joints works, too(someone said theyre not...). Dynamic object GI lightning via light probes is gratis
Thanks, nice test scene. Still has the example car-type settings though where the car is light and very slippy, which seems to be the magic formula needed to eliminate physics jitter. I still couldn't create a heavy vehicle with enough friction to drive at a reasonable speed without excessive wheel-spin.
Thank you @Roin92 by the way I am laughing hard at your avatar picture ... ahahah very nice.
I can confirm, for anyone willing to shell out for it that Edy's new vehicle physics pro early access (not the old unity 4 one) has some workarounds to these issues. The vehicle settings work as expected now and I could get what I was trying to achieve.
Beyond the fixes, the asset has some really cool and well written car simulation logic for engine, transmission, wheel friction curve editors, differentials etc. It's already saved me more than the high price tag
Here is a test video, keep in mind I am going for quite forgiving GTA style physics
Yeah, he commented earlier in the thread that though the wheel colliders are weird by default he's worked out an "ugly hack" to sort it out, including getting heavy vehicles working.
Is PhysX (nVidia) who states their wheel component is how it is supposed to work. Looking at the official PhysX documentation I can see many inconsistencies, doubtful design decisions, and just arbitrary tricks that supposedly makes their concept of vehicle simulation.
Personally, I'd better stay far, far away of that thing.
I've already done so, in many ways The wheel really needed to be reinvented.
This is, I think because their whole vehicle sdk wasn't developed by physics experts, just normal nvidia devs/programmers that did some research on this topic(not too much as we can see xd). But its just my theory
While it might be a bit inaccurate how the wheel collider works, we should not forget that it's maybe targeted to a certain style of driving physics. It's just not clear which one, does anybody know of any games that use the physx wheel collider with good (and maybe not realistic) driving physics?
Not everybody needs or wants a physically realistic car in their game. A lot of very fun games with physical behaviour are not at all realistic, so I wouldn't say it's in general wrong to approximate and simplify some things and not try to simulate everything in a physically correct way. I don't think a correct simulation is the only way to go, as long as it's clear in which context the component is supposed to work well.
All that said, I'm curious to try Edy's vehicle physics pro – does it work in Unity 5?
Bull's eye again.
Try discarding motorTorque / brakeToque and applying forces to a vehicle that is at rest.
(Spoiler: WheelCollider keeps the vehicle "glued" to the ground and it won't move at all)
"But wait -you'd say-, there's a sample aircraft at the Standard Assets. That's made out of external forces and the undercarriage is made with WheelColliders. How they solve it?"
wheel.motorTorque = 0.18f;
Yet another cheat. They force a constant motor torque value for preventing the wheel to enter the "forcefully glued" mode. Comment that line in the aircraft controller script, and you'll see how funny the take-off can be.
Also, this April 1st I'll be releasing a new version of Edy's Vehicle Physics for Unity 5. This package will feature rather realistic vehicles but the component focuses mainly at gameplay and easy behavior customization.
Great! Is there a demo somewhere of a car that is easier to drive than the offroad-style car you have on the site? I'm curious to see if it's possible to simulate a more stable and forgiving car with your system. I find the one in the demo almost impossible to drive.
I've switched to WheelSourceCollider, it works.
That vehicle is for development purposes. It implements all the features in a "raw" mode for testing them to work correctly. For instance, the vehicle just weights 1000 kg but has a rather powerful engine (140 HP) and no driving aids at all. For instance, switching gears (mostly from first to second) "pushes" the rear drive wheels quite a lot and the vehicle is likely to oversteer at that point. Try using the throttle gently, specially during gear changes and maneuvers.
Thank you all for spending time raising attention to the PhysX 3 integration we have in Unity 5.
This is going to be a pretty lengthy post where I cover questions as well as explain some of the technical decisions made.
I can see that I'm joining this thread a bit late, when there are so many different posts and opinions that I'm in doubt it's possible to address all of those in one post. I've read everything here, felt your pain, and I'm posting this so ease it somehow.
To start with, I wanted to say that I can't really comment properly on Unity choosing PhysX over something else, as I'm afraid I'm not feeling like defending any particular engine. There are plenty of physics engines out there in the wild indeed, all shiny, and as far as I could conclude from my prior experience the devil still hides in the details. There are some special concerns or edge cases with all of those. A pure perfectionist would have had a hard time living nowadays. Nor can I really estimate how long would it take to write a modern full featured physics engine from scratch. I believe that would be tens of man-years at least.
Next, I would encourage devs to file bugs, or at least get in touch via email. Often I'm able to provide more information specific to your project than is available publicly at the moment. Don't hesitate to ask!
An important consideration is that with pre Unity 5 WheelColliders, as far as I could figure out, the majority of devs adopted one of the two popular vehicle packages. Since PhysX changed behaviour, WheelCollider, that is built on top, also had to change. That caused incompatibility with packages: Unity 4.x vehicle package is unlikely to work with Unity 5.x. You should really ask the package authors to provide you with the updated package. As far as I'm aware, popular vehicle packages are either being updated for Unity 5 right now, or already have been updated and available up on request.
You got it right that the default WheelCollider settings work best for a simple 4 wheeled car of 1.5 tons. Suspension settings are carefully selected especially for that case. We had to do that because suspension spring's stiffness and damper depend on how much mass is supported by the wheel. A heavier vehicle would need stiffer springs, and vise versa. Stiff springs require higher damper values. Just because of the fact that we use absolute values of stiffness and damper, we can't really provide a combination that work equally well for all masses. A configuration that works for a car of 1.5 tons won't work with a default Rigidbody mass of 1 kg obviously. I had to choose between making it work somehow with 1 kg cars and misbehave with the typical 1.5 ton car or the opposite. Due to the way PhysX suspension works (will be explained later on), stiff springs required for 1.5 ton car would propell the light 1 kg car into the blue sky.
It's fair enough that one could argue such issues should be ideally solved by Unity including a full-functional vehicle package. Unfortunately, we were short on resources and had to follow the way of exposing what PhysX exposes to Unity and making the input parameters as familiar as possible by following the pre Unity 5 conventions where possible. Of course that had a downside of having to deal with the changed units of measure, and the overall changed behaviour. So, for instance, we still have suspension settings with stiffness and damper that everyone seems to understand. Although there is a better way of describing suspension springs, that feels a bit academic at the first glance, but pays off later. I believe Edy switched to using natural frequency and damping ratio after I had exposed WheelCollider.sprungMass to scripts and sent him a project showing the difference. The project is attached to this post, please check it out and let me know what you think. That said, future versions of Unity will contain improvements for vehicles. The current state of WheelCollider is not set in stone yet.
I did a post on twitter about how the WheelCollider works internally. I think it is a good source of initial knowledge to get started, please make sure you've checked it out: https://twitter.com/AnthonyYakovlev/status/579977974772039680. There was a vector PDF version uploaded as well as a huge image.
Now that you are familiar with the overall process of configuring WheelColliders I thought it still makes sense to reiterate on the suspension spring and rest pose, as that still causes questions and speculations.
I agree that the whole concept of rest pose might appear questionnable to some devs. The point where you want just pure springs without any added complexity of the rest pose is a fair point. But I also think PhysX model makes sense. Configuring cars relative to the rest pose seems to be quite natural to non-technical people. That way, when you change stiffness of suspension springs to improve handling, you don't need to cope with the fact that the car lifts up because of the increase in stiffness. I see that as a strong point as well. On the other hand, I've seen people misunderstand the concept of the rest pose, so let me quickly explain what it is actually. You will see it has nothing to do with unrealism, fakes, or hacks people are talking about on the forums.
Imagine a spring of length L that is positioned vertically with one end connected to the ground and the other end supporting a box with mass m. The mass pushes down the spring due to gravity with the force mass * gravity while the spring pushes back with the force compression * stiffness. For every spring there is a specific height above the ground where the mass would stop moving downwards because the weight was compensated by the spring force due to compression. This position is called the rest pose of the spring. Now we can describe such mass-spring pair in several ways. One straightforward way would be to say we have a spring with specific stiffness and with mass on top of it. The downside of doing that would be that once we change the stiffness, the rest pose would be automatically changed because of a different compression required to comprensate for the weight on top. If you generalise this case up to a car with 4 wheels and 4 suspension springs, you can see that if car needs retweaking for a different handling, you would have to change the springs' stiffness values, get different springs elongation, and as a consequence, a different car body height above the ground. This can be quite painful as one would need to move the anchor points (points where springs are attached to the body) to lower the car back as it was supposed. This is exactly what PhysX addresses with configuring an explicit rest pose.
So another way of configuring a spring-mass system that is better suited for cars is to specify mass, stiffness and a rest pose. Let's understand how this works. We've just seen that the rest pose is a derivative parameter that can be deduced from mass and stiffness, so how could it be we specify all of those? The key is that we could say that at length L, the spring is pre-compressed already rather than freely elongated as previously. Playing with pre-compressed spring lets us satisfy any rest pose we wish for any given stiffness and mass. The benefit here, again, is that once we change stiffness we don't need to retweak a car to remain at certain level above the ground.
In real cars, springs are always pre-compressed in the suspension strut, so we are not moving anywhere from being realistic.
Now that you've seen both models make perfect physical sense and there are no hacks introduced, let's take a quick tour over how the spring force is calculated. In the twitter post I showed that the force is computed using this equation: F = sprungMass * g + jounce * stiffness - jounceSpeed * damper. If we ignore the damper for a while, we get two components of force: sprungMass * g which is the force produced by the spring at rest pose, where it perfectly balances the load, and the signed component jounce * stiffness that comes from the Hooke's law. That last component reflects the force difference that is produced by compressing or elongating the spring from it's rest pose and can quite dramatically affect the total force F. You can see that this is a perfectly equivalent model to one that would calculate the total force by directly applying the Hooke's law to compression from the initial uncompressed state since in our new model, the sprung weight component is adjusted by the spring change relative to the rest pose. I hope this is a clear explanation of why the force equation is physically correct.
Now that we know the spring force equation, I wanted to explain why you see a 4 wheel car jump to the sky on the default colliders when Rigidbody's mass is super small, say 4 kg for example. Default spring setting for a WheelCollider are: stiffness = 35000, damper = 4500. The sprungMass for a symmetrical car with 4 wheels and 4 kg total mass would be just 1 kg for all wheels. Thus, at rest, the spring would provide F = 1 * g + 0 * 35000 - 0 * 4500 = 10 N of force. Now, when you drop such a car on top of a surface, the will unavoidably be spring compression introduced. Why? Imagine a car falling down. We process cars in FixedUpdate, with a set frequency (by default, 50Hz). Each frame PhysX puts wheels on surface when suspension travel length allows. It's clear that with discreet simulation we can never perfectly land on wheels at rest position. We would always simulate right after wheels at rest would have gone inside the surface just a bit. That small value would result in a small spring compression, and thus, total force growth. Imagine a small penetration of only 0.05 m, that gives force 1 * g + 0.05 * 35000 = 1760 N which is a weight of 176 kg body. Now multiply that by 4, because all of the wheels penetrate surface. This will led to the understanding of why the wrongly specified spring parameters would work quite badly. One last note is that this explosive behavious does not depend on which way we treat spring-mass system. Both with and without rest pose modification the explosive behaviour would be there. Explosions come from the fact we place the wheel on the ground and then figure out the force.
You might have got an idea that WheelCollider settings should be carefully selected for a stable and nice simulation. I will be showing you a demo project that outlines how one can greatly simplify tweaking WheelColliders, but I just wanted to take another opportunity to explain one more aspect.
The WheelCollider's sprung mass is actually updated, it's totally not a pre-determined value as some guessed. We update the sprung mass whenever the body's mass distribution changed. This happens when you change Rigidbody's mass, add\remove colliders, move\rotate\scale colliders and so on. One important thing to know though is that once you set a custom center of mass of a Rigidbody, the inertia tensor is marked as set explicitely. This is an inherited behaviour from Unity 4, and I'm committed to changing it in the future releases. What it affects actually is that the inertia tensor of a car would go out of sync with the physical body. This can result in jittery simulation. Currently, one possible workaround is to somehow set the correct inertia tensor for such a car, or, alternatively, avoid changing car's center of mass manually. This is quite unphysical action, and is not properly supported, but future versions would deal with that in a nicer way.
Finally, I wanted to share a project with you where I demo the concept of natural frequency and damping ratio. You can see how the WheelCollider settings are being worked out from these two parameters. Yes, only two parameters per whole vehicle, regardless of how many wheels it has. I created a really minimalistic wizard to create different cars with up to 20 wheels. Find it in Vehicles -> Create boxy car. Once a car is created, just lift it above the ground and hit play. EasySuspension script updates WheelCollider settings online. You can see how easy it is to create cars of any mass with that wizard. I think this post has already grown too long, so I will stop now and let you download the project and ask questions if you have any. Just open the scene playground, focus on car (select carRoot in hierarchy, and press F two times), then click in game view to give focus to controls. This is really a super minimalistic project and I believe it has a great customisation potential.
If needed, I can provide more information about how the project works internally. I can also capture a video explaining anything about WheelCollider. Let me know your needs.
Thank you for your attention, I hope the post was useful for someone.
@Edy Did you already implement driving aids or is this still to be done? So, if I get the early access version, I could already configure a behaviour which is easier to control? Did you already make test cars like this or is it still too early?
Thanks heaps for all that information yant. That EasySuspension project is nice and useful too.
Using it I could create a heavy vehicle that seems to drive OK. The friction values are still very low (and hence preventing jitter), but driving using motorTorque with that script still seems to work OK. I didn't have much luck making a heavy and fast vehicle - the amount of power you can apply to the road tops out at some point, but maybe increasing grip a little would fix it... anyway I can see that, although it might take some serious threading a needle through the right holes, most people can probably get a working simulation somehow in the new system.
If I upgrade to Unity 5 personally I should probably just stop using wheelcolliders and switch to a custom solution. In my game, players build a vehicle from parts that can be anywhere from ~1000kg to infinity, and they can adjust the suspension spring on-the-fly, which should also raise and lower the rest pose as a basic spring would:
This all works pretty well in Unity 4 but I suspect would be a nightmare with Unity 5's wheels.
Since the vehicles are open-wheel designs as well, I also have another collider inside the wheel collider to handle side collisions. In Unity 4 it's fine but in Unity 5 having another collider inside a wheel collider caused the vehicles to just totally fly away into the sky. Since wheel colliders still don't have true volume I probably need something for that as well.
This was already the case to some extent in Unity 4, right? Just because I found that wheel collider behaviour changes depending on the order of setting rigidbody centre of mass and mass.
Well, or you may be expecting that to actually happen, as in real cars. Different springs or mass > different body height > different handling accordingly.
While I can see the logic of the PhysX approach, I think that the problem is the vehicle physics simulation being designed and conditioned around solving that particular specific situation. Some users might find the solution useful, but other users not affected by it will most likely encounter difficulties trying to configure the suspension in a standard way (20% vs. 80% according to actual poll results).
Having a generic suspension and including utility methods such as WheelCollider.CalculateCenterForTargetPositionAtRest would have been a better solution than artificially constraining the entire suspension simulation to a specific situation IMHO.
Good point. Then I think there is a fault with the physics simulation here, as obviously a real pre-compressed spring won't throw lightweight objects into the sky.
Instead, if there is not enough force (weight) applied against the minimum pre-compressed force, the suspension should behave just like a regular collider-collider collision, keeping the body stable over the surface. In PhysX this doesn't actually happen, and this fault is the cause for the "bumping / shaking" effects users exposed earlier in this thread.
This is still to be done. I want the main features to be completed first, as some of them will still have some influence in the vehicle's behavior.
You can configure the vehicles as you want with all components available. You can even write your own vehicle controller with the components connected and configured as your choice. A base controller class is provided for this. The main Vehicle Controller component is also derived from this class.
@yant thanks for posting. I'm curious, what would be an ideal wheel mass / rigidbody mass ratio? Like @Nition I'm concerned with vehicles of drastically varied masses.
@yant please tell me why the new wheel collider does not support scaling & rotation? I filled a bug (678395 - Wheel colllider does not take into account the parent position) that was closed with no explanation, Unity QA who closed the bug just said it is not supported.
HOW SO? Why we file bugs if no one listen???
It seems you guys have gone out of the way to mess up every ones code? For example, I have planes with retractable wheels - and now the wheel collider would NEVER work for that exact reason. Please provide estimated time when this will be fixed. I can understand having problems with migrating to newer Physics version, but can't understand sloppy implementation and missing base functions that EXISTED before and are not related to physics. Let see if I get response or no one cares.
It would have been closed because if it's officially not supported then it's not a bug, even if it is a missing feature. Having said that, removing a feature that was there before is pretty lame.