My suspicions have finally been confirmed.
Our team has several hundreds of U.S. dollars (> $500.00 USD) worth of vehicle scripts and assets, and almost every single one of them is completely useless in Unity 5.
A number of these assets are in DLL format, and others are a few years old and unsupported.
This is not good news at all.
It’s simple, if that is so important to you, don’t upgrade to Unity 5. The PhysX upgrade had to be done, the performance sucked. This is one of the downsides…
closed source assets can be a dangerous gamble.
That ignores the fact that UnityCar and even Unity’s own Car Tutorial (before the Sample Assets version) work with both Unity 4 and 5. As well as the fact that Unity 4 is no longer supported.
An even bigger gamble moving forward with IL2CPP.
I don’t think it’s a waste… It’s like saying I bought a game on Xbox 360, and then someone gave me an Xbox One for free. I still have the 360, so just because my game doesn’t play on the new system, doesn’t mean I can’t continue using it on the old system.
It doesn’t matter why it doesn’t work, you can’t change the code of the assets and there is nothing that can be done.
The issue here is when an amateur developer starts spending a lot of money she or he assumes wrongly that technology won’t change. For a start, only buy assets which do have source. Or invest in your own solutions. You can mimic the behaviour of the original wheel colliders if you have source or the interest to do so. If that isn’t happening, shouldn’t you blame the asset authors? it’s their responsibility after all to remain current.
I’m sorry your having such struggles but as suggested, maybe it’s not a good idea to update your project to Unity 5.
Having custom built DLL’s especially if they’re old is risky to try and upgrade, we try and make upgrading relatively painless but we can’t account for absolutely everything. This goes triple for major releases and the fact that we have upgraded our physics and so much more.
What makes you think so? If it wasn’t supported they wouldn’t be continuing with new 4.6 releases.
–Eric
Wrong. The issue is that WheelCollider dates back to at least 2008 (when I started using Unity). Was the older WheelCollider perfect? Far from it. But it would’ve been fair to assume that it wouldn’t change its fundamental behavior anymore than a BoxCollider or Capsule Collider.
Except where did I indicate I’m “struggling”? I’ve only raised attention to an issue that only seems to affect one or two physics components, and the many projects (not just my own) that depend on such components working as they’ve worked for several years.
I stand corrected. I wasn’t aware of Unity 4 continuing past 4.6.3.
They do what they can to avoid it, but occasionally stuff has to break in order to make progress. It’s happened before and I’m sure it will happen again. (Not with the .x releases, but the big X.0 releases…that’s the time to expect it.) The alternative is being chained to old suboptimal stuff forever.
–Eric
Not upgrading is the best solution.
A major version change always introduces breaking changes. Its up to you to judge if 5 is worth more then the value of lost assets and project fixes. Its quite common for studios to stay on the version of Unity they have until a project is complete, then upgrade between projects.
If 5.0 didn’t introduce breaking changes it would be called 4.7
sounds like my rts project will need some work to bring back up to speed. lots of wheelcolliders.
luckily I did all the code using them myself, so only a few hours lost hopefully.
It’s only a waste if you approached it in such a way that you / your programmers can’t translate the logic between versions. What use is something like that anywhere unless UT were to announce that Unity x.x is the final version?
I wish everyone followed this. The only thing blizzard breaks when they label something 2.0 or 3.0 are hopes and dreams.
It’s not a matter of translating logic (at the scripting level). The tire friction model of the new Wheel Collider is completely revamped.
Exactly. I should know. Yet, of the all the DLL’s we have, it had to be one with wheel colliders that break. Interestingly, the one or two closed/compiled shaders and rendering plugins we have are working without problem.
Unity uses PhysX for it’s Physics and Unity 4 uses an old 2.X version. PhysX had a big rewrite for version 3, which included big changes to the vehicle model. The alternative to upgrading PhysX and breaking compatibility was to stay on the old (and slow) PhysX forever.
Yes, there was quite a buzz about the PhysX upgrade. And what would a company like NVIDIA care about backwards compatibility? The preferable approach would’ve been a Wheel Collider implemented in C# using ray casts, rather than the assortment of Nvidia PhysX vehicle APIs.
If some of the assets are more than a year old, hopefully you’ve re-couped their value with sales!
Maybe you can reverse engineer the DLL’s for studying purposes?
Also, here is a good start if you haven’t seen it already
Unity can’t be responsible for other developer’s DLL’s. Those developers are responsible for updating their code & DLL’s to work with future versions. Have you sent them an e-mail, IM or called them to ask them to update their stuff?
I know that isn’t what you want to hear, and I can feel your pain, but taking in assets that you do not have the source code to is a risk.