Si I have never used MonoDevelop before, always Unitron for scripting. This morning I updated Unity to 3.4, and played my game and it worked fine. So I decided to get back to work after making sure everything was ok. So I open up a script to work on it and MonoDevelop pops up, and Ive never used it before, but it looks similar to Unitron. So I enter 3 lines of code, ctrl + s to save, and BOOM, all of a sudden 7 scripts say they wont work.
“Cannot convert UnityEngine.Transform to UnityEngine.Rigidbody”. What? It has been working all along, why has it decided to stop working now?
The change (if you read the changelog) is that unity js now enforces #pragma strict (as it should have done) - this makes js run a lot faster. This means you need to explicitly tell unity what kind of variable it is.
So instead of stuff thats breaking behind your back that you don’t know about, it is now preventing you from making bad code. To fix it, simply declare all your variables properly:
myThing = transform.position;
becomes:
var myThing:Vector3 = transform.position;
for example.
I’m not at all sure how you can possibly try and make rigidbodies use a transform anyway, but please post code.
Unity 3.4 got the JS compiler finally fixed (or more fixed) than it was before where it had several errors.
You now need to correctly cast stuff if the receiving variable isn’t typed and you need to correctly call the reference out of the object. A rigidbody is no gameobject and never will be, that it worked was just cause JS did many fishy things. The correct way to do it always was to call .gameObject on the rigidbody which returns its game object. And similar.
Instantiate for example returns UnityEngine.Object - you can cast by adding “as GameObject” to a gameObject given the prefab public variable was a GameObject or you can do to cast it to whatever the variable was and then use .rigidBody to get the objects rigidbody component
This is no monodevelop thing btw, would have happened inside of unity as well the next time the scripts were compiled due to a single change in a file.
I just changed saving the variables as a rigidbody, to a Transform. seems to have fixed it. Im curious as to why the FPS tutorial contains that code, yet the code is flawed.
I can understanding making coding a little bit more explicit, what I dont understand is why you did this but didnt update your scripts which are bundled with Unity so that they wouldnt explode with your own restriction changes.
So based on reading everything, my choice to upgrade to 3.4 means I need to then wash through all of your Shipped Base code, and fix the errors. Thats kinda like asking me to add an extra month to my production time to go through and fix all of your shipped base code.
All the errors I receive are for your standard assets code that comes when you start up a project. While I created the project 7 months ago, the errors again, lie in your guys’ code. Meaning you didnt follow your own instructions for writting ThirdPersonContoller (and the 20 other scripts I get errors on with Unity 3.4).
So was it a really good idea? I dont care if its a good idea or not, I would rather work on my project and get it done, than blow an undetermined amount of time trying to fix someone else’s code that I frankly am unsure if my current project even relies upon.
Its kinda like I’m in the position where the car is 97% done on the shipping line, and someone comes along and says “hey we need to strip that puppy down, back past the frame because theres a few new regulations on how these screws go into thier screw slots”.
To be fair, unity is hardly to blame. They haven’t in essence broken anything, but they have enabled the #pragma strict flag. They need to find the time to update old scripts. If they did that before 3.4 shipped, 3.4 would be months away and nobody would be happy.
3.3, project works on all 7 of our test devices and platforms.
3.4, project doesnt work and needs an undetermined amount of time to troubleshoot and fix, the bulk of which isnt code we’ve written but is shipped with Unity. I am guessing this is because the project was built originally with 3.1 so the example code included has never been
updated.
Sorry to me its that simple. Its unfortunate as well as we will need to upgrade because there are several features we need for mobile devices. But we’ve chosen today, to not upgrade and finish the product.
I’m not posting to stir the pot and ‘blame’ people. I am posting because I want folks to know what the issue is.
If you use original unity code that came with packages, just reimport them. thats a thing you should do anyway, as they might have been updated or enhanced in other forms too (pro shaders for example contain this as MUST for each update)
that being said, its not that standard to update an engine mid project normally unless there is a must feature which from what I get isn’t there … unity has no problem being installed in multiple versions, I’ve 3.1, 3.3 and 3.4 for example.
You mention that mobile got things you just need but from what I recall there was no new feature that makes or breaks it or did I miss something? (aside of terrain but that can’t be a must as you started the project prior 3.4 and I wouldn’t use it outside the iPad2 either)
How are those of us with whole projects written in previously accepted JS supposed to work then? Redo all the scripts?
I’m an artist who has learned JS through Unity on the fly and now my game is unplayable.
Is there some reference for those of us who learned the old (and apparently incorrect) method so our scripting knowledge does not have to be completely tossed out the window?
not to continue along a negative path… (but i am going to)
I would have liked more of a heads up then a snippet in line 845 of a press release.
Reminds me of what Apple just pulled with Final Cut Pro.
It could be the best update in the history of the world…
but im still (of course) gonna be bitter that all my “crappy” code is now broken.
