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

Script 'Halo' has the same name as built-in Unity component.

Discussion in 'Editor & General Support' started by cephalo2, Feb 13, 2019.

  1. cephalo2

    cephalo2

    Joined:
    Feb 25, 2016
    Posts:
    262
    When was this built in component introduced? I'm sure mine predates this, and its really messing me up because I have important files serialized with this certain name of the object, so if I change it's name the files all break. .NET serialization cares about the name. I have to create a special process to handle both names and recreate and re-serialize these files.

    GetComponent no longer works on these objects, which means they are broken now also. Is there a way I can exclude the built in Halo component so I don't have to do a week's work?
     
  2. JeffDUnity3D

    JeffDUnity3D

    Joined:
    May 2, 2017
    Posts:
    14,446
  3. cephalo2

    cephalo2

    Joined:
    Feb 25, 2016
    Posts:
    262
    I think I was using 2017.X before, but it's possible I didn't notice the bug I'm dealing with since it's a bit subtle. but the bug did not exist last year. How long has the unity Halo been around? Did it used to be ok for my object to have the same name?
     
  4. JeffDUnity3D

    JeffDUnity3D

    Joined:
    May 2, 2017
    Posts:
    14,446
    The link provided shows it was available since Unity 2017.1
     
  5. cephalo2

    cephalo2

    Joined:
    Feb 25, 2016
    Posts:
    262
    Yeah, this was one of my earliest bits of code when I started in 2015 or so. I didn't notice the problem until now. I don't supposed there's a nice way to resolve this conflict?

    EDIT: The link says 2018.3. If I click on the version 2017.4 at the top it goes to a different page.
     
    Last edited: Feb 13, 2019
  6. JeffDUnity3D

    JeffDUnity3D

    Joined:
    May 2, 2017
    Posts:
    14,446
    Not a nice way that I know of!
     
  7. cephalo2

    cephalo2

    Joined:
    Feb 25, 2016
    Posts:
    262
    It would be nice if in the future we could be insulated from Unity Names somehow. This is going to cause me a world of hurt.
     
  8. JeffDUnity3D

    JeffDUnity3D

    Joined:
    May 2, 2017
    Posts:
    14,446
    I haven't tested, but couldn't you add a namespace? I guess it would still require many changes
     
  9. Joe-Censored

    Joe-Censored

    Joined:
    Mar 26, 2013
    Posts:
    11,847
    PraetorBlue and Vryken like this.
  10. cephalo2

    cephalo2

    Joined:
    Feb 25, 2016
    Posts:
    262
    Thanks everyone. The problem was all me! In life in general, anytime I am convinced that 'The system' is broken, I always end up realizing that I am broken...

    The problem was not the problem, and I don't have to recreate my files. I have reduced my 'Halo' to a container for the enum so that the files can be read, and I don't have to use it as a game object.
     
    mahnoorcodes and MitchStan like this.
  11. hippocoder

    hippocoder

    Digital Ape

    Joined:
    Apr 11, 2010
    Posts:
    29,723
    The correct way is to use namespaces - believe it or not that's exactly what Unity has done too! you don't notice it because at the top of the script you have using UnityEngine etc.... these are the namespaces the code is using!

    When you add your own namespaces to all your files, anything inside the namespace automatically finds the other, so you don't even need to fix anything unless there is a conflict. If there's a conflict you'd use yournamespace.Halo and all would be well, or you'd perhaps use UnityEngine.Halo if you preferred the other.

    When using an engine as large as Unity, conflicts in naming is common, thus it's a builtin feature of the C# language specification.
     
    wujinjindx, Joe-Censored and cephalo2 like this.
  12. Hurri04

    Hurri04

    Joined:
    Nov 27, 2017
    Posts:
    59
    Adding a custom namespace does NOT remove the warning for me (at least on the version I'm currently on which is still 2019.1.1 so please correct me if this has been fixed by now).

    What DOES work for me is renaming the file itself to something different from the Unity class, e.g. "Something.Halo.cs" (which I usually use as a convention for subclasses which I put into their own files using the "partial" keyword on the main class).

    In my opinion this warning message could be made obsolete by removing the overloads of the "AddComponent" and "GetComponent" methods which take in a "Type" parameter so that only the versions which take a generic Type remain.
    This would allow adding a generic constraint "where T : Component" to them, resulting in a proper compiler error being thrown due to ambiguity if the custom class with the same name also derives from "Component". In this case a namespace would actually work to distinguish which version (built-in or custom) is supposed to get added.
    Or in the case that it does not derive from "Component", a compiler error would be thrown, stating that the custom class cannot be implicitly converted to "Component".

    If this isn't fixed yet, is there any chance this could be looked at?

    Edit: It turns out that while renaming the file as suggested above works to prevent the warning message, this also means that if the script derives from "Component" it cannot be added to a GameObject anymore by dragging the script onto it in the inspector. And trying to add it via the "Add Component" button results in a popup window with the message "Script x doesn't exist".
    So if it's a standalone class this works but when deriving from "Component" the script needs to get added via another script, using the "AddComponent" method (which I guess does work when using a custom namespace...?).
     
    Last edited: Oct 3, 2019
  13. oobartez

    oobartez

    Joined:
    Oct 12, 2016
    Posts:
    163
    I second what @Hurri04 says. It is a Unity problem, not a problem with your code. Try to create a MonoBehaviour called Tree, even in your own namespace, and you will get the warning. Seriously? Like, are Unity developers assuming that developers will not want to have scripts such as Tree or Halo in their games? So instead of cleanly naming our classes:
    Tank
    Warehouse
    Enemy
    Tree

    We end up with:
    Tank
    Warehouse
    Enemy
    TreeComponent

    The blame is fully on Unity's side because of some legacy code which nobody has been using for years, and which never really made too much sense. The programming world has solved that problem decades ago by introducing namespaces.

    @JeffDUnity3D Would you be able to convince your team to remove that warning or at least add an option to do that in project settings?
     
    Hurri04 likes this.
  14. Serotonindude

    Serotonindude

    Joined:
    Aug 28, 2015
    Posts:
    8
    I guess nothing happened at this front?
    I just wanted to create a script named 'Grid'... guess what...
    Someone got an alternative name for me? :D

    P.S.: Yes, I use namespaces...
     
  15. fffMalzbier

    fffMalzbier

    Joined:
    Jun 14, 2011
    Posts:
    3,276
    If you use namespace you can just specific witch Grid class you mean.

    myNamspace.Grid
    instead of the implied
    UnityEngine.Grid
     
  16. Serotonindude

    Serotonindude

    Joined:
    Aug 28, 2015
    Posts:
    8
    The point is, that unity complains: "Script 'Grid' has the same name as built-in Unity component. AddComponent and GetComponent will not work with this script."
     
    eMsylf likes this.
  17. PraetorBlue

    PraetorBlue

    Joined:
    Dec 13, 2012
    Posts:
    7,890
    That's super extra annoying because they're obviously referring to the versions of those methods that accept a string parameter, which are "bad" versions of those methods anyway.

    Thing is, I kind of understand why Unity would want to warn a beginner about this. But a more experienced C# or Unity user will not typically be using these string-based methods anyway (except maybe in a rapid prototype). Maybe the warning should be present only if Unity finds a usage of one of those string-based component methods somewhere in your assembly?
     
    Joe-Censored likes this.
  18. fffMalzbier

    fffMalzbier

    Joined:
    Jun 14, 2011
    Posts:
    3,276
    For AddComponent and GetComponent you need to specify your namspace of the class, then it will work.
    instead of
    AddComponent<Grid>();
    you can do
    AddComponent<MyNamespace.Grid>();

    and unity will not complain (at least in 2020.1)

    Code (CSharp):
    1. using UnityEngine;
    2. namespace MyNamespace
    3. {
    4.     public class Grid : MonoBehaviour
    5.     {
    6.         // Start is called before the first frame update
    7.         void Start()
    8.         {
    9.             GetComponent<UnityEngine.Grid>();
    10.             GetComponent<MyNamespace.Grid>();
    11.         }
    12.     }
    13. }
    14.  
     
    Wolfram likes this.
  19. eMsylf

    eMsylf

    Joined:
    Mar 9, 2018
    Posts:
    10
    Just ran into this issue last week. I'm using namespaces, as recommended, but the system still gives off a warning.

    Once I receive a warning on every startup, I assume this warning is given because I need to fix it. However, seeing as I have put the class into a different namespace, I do not think this recurring startup warning message is warranted and should only be given when no namespace is used.

    Is there any way to disable the warning? Or are there plans to stop issuing this warning once the classes are in different namespaces?
     
  20. Hurri04

    Hurri04

    Joined:
    Nov 27, 2017
    Posts:
    59
    I just submitted a bug report (Case 1324045) and asked for an official reply in this thread.
    Probably should've done so much sooner, seeing that only posting in forum threads rarely gets such things resolved...
     
  21. Hurri04

    Hurri04

    Joined:
    Nov 27, 2017
    Posts:
    59
    Got a reply:
    But voting is disabled because it's marked as "WONT FIX"...

    This reminds me of another issue I saw some time ago that was marked as "WONT FIX" for some 5 years or so until another Unity Dev stumbled across it and was like "Oh yeah, I fixed this real quick btw, it was super easy since it turned out some value wasn't passed on further down in the internal code" and everyone was baffled why it took so many years to fix then...
     
    Last edited: Mar 27, 2021
    eMsylf likes this.
  22. Hurri04

    Hurri04

    Joined:
    Nov 27, 2017
    Posts:
    59
    fffMalzbier likes this.
  23. JeffDUnity3D

    JeffDUnity3D

    Joined:
    May 2, 2017
    Posts:
    14,446
    It looks like a full reply was in the bug report, it was considered too risky of a change. Sorry, not really my area.
     
    Joe-Censored likes this.
  24. jRocket

    jRocket

    Joined:
    Jul 12, 2012
    Posts:
    699
    I too wanted to create a "Grid" class but I get this annoying warning all the time. I'm never going to use "AddComponent" or "GetComponent" with it. Is there a way to suppress the warning?
     
  25. oobartez

    oobartez

    Joined:
    Oct 12, 2016
    Posts:
    163
    Yup, the problem is still here. Unity please just mark those overloads of GetComponent and AddComponent as obsolete and delete them in a year or two. Whatever reasons there were to keep them have become invalid years ago.
     
    Last edited: Aug 2, 2021
    Hurri04 likes this.
  26. dan-oak

    dan-oak

    Joined:
    Jul 14, 2020
    Posts:
    9
    This is funny...
    I thank Unity for providing what they already provide for free.
    But such minor details which are not adequately addressed in years are just... funny.

    My console forces me to direct attention to it every time because I have an internal class called Terrain?