|
Hi. I have moved a lot of my scripts into a c# DLL that is in my Assets folder. It opens up just like a folder and I can see most of my scripts there. Except I cant see those scripts that through inheritance uses generics. Example:
AbstractGenericEntity inherits from MonoBehaviour again, so that is not the problem (ofcourse). All other scripts that inherits from other abstract classes work. The funny thing is that if I try to add the components via code by using this example:
... then it appears in the Inspector with no name, but the gameobject that is created gets the correct name. Is this a unity bug? Am I doing something wrong?:
Edit 1: When closing down unity and opening it again, the gameobject in question lists the script as "none" (missing). Edit 2: Answer to the question below about how I set the type:
This is the complete chain of inheritance with one of the scripts: using UnityEngine; using System.Collections; using EseTriggers;
to
to
to
to
to
to
Edit 3: If you have Visual Studio installed then you can take a look at a small test project I uploaded here: http://dl.dropbox.com/u/1972432/Generics_bug.rar
(comments are locked)
|
|
I tried your code, and I can't get it to work with a dll either. I can get it work if I just include the sources right into unity, however dragging out the generic class doesn't work (as expected because we can't define T) but strangely it says the class name doesn't match the file name! I also saw that the generic type in the library had a strange name like MyAwesomeGenericMB`1. Since Unity is very picky about the file name must match the class name, I am wondering if something similar is happening behind the scenes in your dll import. Perhaps it won't find MyAwesomeGenericMB < T > because it mangles the name to MyAwesomeGenericMB`1, and so any further subclasses it can't resolve being derived from MonoBehaviour and is rejected. Clearly not ideal in your scenario. I haven't looked in depth what you're trying to achieve with your inheritance (I must say, it's one of the longest chains I've ever seen!) but perhaps you could either just include the sources into the project or favor composition instead. Users of that library could perhaps declare public fields with your types, that are not derived from monobehaviour but instead use your "custom components" and delegate calls to them? Or make it a bit more specialized and ditch the generics but go with interfaces instead? Something along the lines such: I think you are onto something here. +1 for you :) I came to the same conclusion a couple of days ago and posted it as a bug on their bug tracker but my sources tell me those bugs never gets fixed so I'd be better of just removing the generics from my hierarchy. (Using interfaces wont help me).
Mar 25 '11 at 04:31 PM
Skjalg
Why don't use make a non-generic base class and provide generic methods that act on System.Object instead? Sure, you'd get some boxing with value types (int, float, Vector3 etc) but for reference types (MonoBehavior, Animation, Light) it's just a simple cast.
Mar 29 '11 at 02:29 PM
Statement ♦♦
That is a good idea, but I have already gone ahead and just made the generic scripts into actual scripts.
Mar 29 '11 at 08:42 PM
Skjalg
(comments are locked)
|
|
if it was me with this problem, i would just delete all of it and reinstall unity but first i would make sure the old unity was all erased and also remove the unity folder where it was installed and start again. And of course i would save whatever i wanted to from the old unity folder. It wouldn't solve the problem. The problem isn't a corrupt installation but rather a limitation in Unity with regard to generic types deriving from MonoBehaviour in imported libraries.
Mar 25 '11 at 02:45 PM
Statement ♦♦
(comments are locked)
|

