koobas.hobune.stream
Unity 5.0, ambiguous component reference?
Unity 5.0 onward, all the component variables except "gameObject", "transform" and "tag" have been deprecated (See script reference "UnityEngine.Component"), which is alright.
So when one has to access a component,e.g. Rigidbody, as advised, they must use the method GetComponent.Rigidbody(). (Apparently the angle brackets can't be shown here on the web.)
Instead of using this method every time, one could cache a variable, assign it in the Start() method using GetComponent() and then use that variable to reference the component each time, which is also fine.
THE PROBLEM: If Component.rigidbody has been deprecated, why does Unity send an ambiguous component reference error when I assign the variable as "rigidbody"?
This is the message I get: Ambiguous reference 'rigidbody' : CharacterControl.rigidbody, UnityEngine.Component.rigidbody. (Here, CharacterControl is my class.) Well, if there is no variable "rigidbody" in the Component class, why does it send this error?
Yes, I could assign a different name like "myRigidBody" or simply "r" for the variable. But I'd like to know what is happening here. Is it a compiler issue? Is it because MonoDevelop hasn't been updated?
Just post this to say you are not the only one feeling confused, and I totally agree with you. Just have installed the new version, thousands of errors 999+ filled up the console window, and i have no idea how many relieving works have actually been taken up by the API Updater? Anyway, after 20 $$anonymous$$utes of getting frustration, in order to get through to the test of the new version, sarcastically just like what you choose to do, i also started to use the "myXxx" notation to replace all those names that marked ambiguous errors, for me this is the best only way to keep the basic simplicity and comprehensible for a variable name, but it's really awkward, just like "rigidbody", for every gameObject you are actually allowed to have one rigidbody attached to, and Rigidbody is an officially built-in class, so what's the point to force a user to name it in a customized way? On one hand they have discarded the idea of quick reference, on the other hand they don't allow you to use the proper name to represent the original class。If those "quick reference" already became unnecessary, why would such deprecation is still needed?
@cyuxi- There is an explanation for this given by the people at Unity through this blog: http://blogs.unity3d.com/2014/06/23/unity5-api-changes-automatic-script-updating/
It didn't entirely convince me at first but I think it does make sense when you're looking at Unity as a system. Before 5.0, as mentioned, some components had built in references while others didn't which lead to arbitration. For a well defined system, arbitration is bad. So it makes sense to have only those component references built in that are available in ALL of the game objects from the beginning, "transform", "tag" and the "gameObject" reference. Also, if the debugger doesn't pick up that a component is missing, and the application is run, it may lead to errors. So I think this convention is more systematic and defined.
Just to add to this, rigidbody (and collider, audio, etc.) were never variables to begin with! They were actually doing a look-up similar to GetComponent, added in as a "shortcut" for the user.
The new restriction of having to use GetComponent removes this lack of clarity (rigidbody did look like a variable!), which is another good reason to explicitly use GetComponent.
Note that with $$anonymous$$onoBehaviour.rigidbody you really should have been storing a reference anyway, since it was finding the Component every time you accessed it. All Unity 5 is doing is making sure you make this explicit, which will ultimately only help you since it's clear what's going on!
You can still use gameObject and transform because all $$anonymous$$onoBehaviours belong to a GameObject and have a Transform. As far as I'm aware these are both cached now as well, so you should be able to use e.g. transform without worry (you shouldn't need to store a reference yourself to avoid extra look-ups).
@PushkarSawant97, @Johot, Ok, I see. Thank you for further explanations. I do agree with unity to remove the old way of handling with those quick accessor. But what still confused me is why the deprecations are still bound on those names, shouldn't the deprecation be gone with the old convention? I wish unity can entirely free those "shortcut" names for good, and I'm happy to add two nice explicit lines to define a rigidbody reference and assign it a GetComponent(Rigidbody) in the Start or Awake.
A method or variable being deprecated is like telling the programmers that they should stop using a variable or method because it will not be available in the future. However it is still available so programs will still work while the programmers transition to the new version. This is why using a deprecated variable gives a warning and not an error and why attempting to declare a new variable with the same name as the deprecated variable is ambiguous. I mean the compiler has no idea whether you are talking about the still implemented (but deprecated) variable or your declared variable.
Thanks. I didn't know the meaning of deprecated in the program$$anonymous$$g context. So in the future, when everyone has updated to the new convention, we could expect the guys at Unity to drop those deprecated components entirely and then I could name my variable as"rigidbody"? Anyway, it doesn't bother me that much since it doesn't get in the path of my workflow. I guess for now, I'll have to make do with "myRigidbody" or something like that.
http://en.wikipedia.org/wiki/Deprecation
The internet is really good at explaining standard computer terms. Probably since it was created and is still run by computer-types.
