koobas.hobune.stream
A script by that name already exists... so what?
I noticed at some point this message started popping up (I think after 3.0).
A script named 'MyClass.cs' already exists at {some other directory/namespace/MyClass.cs}. Please rename one of the scripts to a unique name.
Why? I understand what the error means ultimately, I am just not sure I understand the rationale behind the additional restriction. It's not a C# "CSxxxx" message so I assume this is a restriction that Unity has placed on top of Mono for some reason. Of course, C# allows this as long as the classes are in different namespaces.
Edit for clarification: It is true that classes extending MonoBehaviours cannot have the same name because of the fact that they are required to be in the default namespace and are thus not allowed to. This is noted in the documentation. That is presumably caused by some problem they have not worked around in the engine I suppose. The classes that I am speaking of are just plain classes and do not have these requirements.
Edit 10/8/11 - After talking with the Unity engineers it seems that this was a bit of overstepping on the code that checks script names that are MonoBehaviours. MonoBehaviours cannot be in a namespace and have to be in a file that's the same name as the class so this makes sense for them but not for other packaged (not Monobehaviour) classes. So I guess at this time it's a feature.
"Unity doesn't support placing your scripts inside of a namespace at the moment. This requirement will be removed in a future version."
Source: Unity Documentation, "5. Don't use namespaces"
So: Namespaces don't work at the moment, and they want to fix that later on. I don't think any user has a definite answer to why it is that way, but it sure explains why you cannot have multiple classes with the same name.
That's true for $$anonymous$$onoBehaviours but not for general classes that do not extend $$anonymous$$onoBehaviour. You can actually have multiple classes with the same name as long as they are in different namespaces, you just can't name a C# file in one directory the same as one in another directory.
Oh, okay. Then sounds like it is just a bug or a limitation based on or similar to the behavoir I wrote about. I don't think the Unity developers check here regularly; the best way might be to submit it as a bug and see what happens.
This applies to the using of namespaces, Joshua. It might not be the reason non-$$anonymous$$onoBehavoirs cannot share a name.
You have to rename it .
Unity does not use namespaces for one, or rather it has everything within a single namespace. I seem to remember reading that somewhere a while back. Also because Unity imposes that all monoBehaviour scripts to have the same filename as the monoBehaviour class this further restricts filenames. I believe some of this is to remain compatible with "javascript" because they don't seem to use classes for monoBehaviour, therefore the filename is the name of the class.
Unity does not support namespaces for $$anonymous$$onoBehaviours (for some reason). Plain old C# classes can be. We have over a thousand classes that currently rest in their own namespaces... no problem. You can use namespaces, and in fact UnityEngine and UnityEditor are namespaces. The issue where $$anonymous$$onoBehaviours cannot be was a self correcting problem because the all have to be in the default namespace and therefore will not compile no matter what the name of the file is.
Its sad thing. I see no particular reasons for that behavior.
Update. Unity 4 now supports it. Logic wins, finally. Hurray. :(
But its implementation still bugged, it wont work if $$anonymous$$onoBehavior children placed inside namespace and has calls with named parameters inside (and some other extended language features make it fail too). But u can override it if you will split class in 2 files, like:
Behaviour.cs { namespace ns1 { public partial class Behaviour{ / empty / } } }
Behaviour.body.cs { namespace ns1 { public partial class Behaviour: $$anonymous$$onoBehaviour { / any code u realy need must be here / } } }
