I’m guessing no because I tried that and kept getting a nullref and the error “Can’t add script behaviour . The scripts file name does not match the name of the class defined in the script!” when doing AddComponent, even when the name of the script does match. And I’ve tried various combinations of naming the script and calling AddComponent with both with just the InnerMonoBehaviour’s name and a syntax of OuterClass.InnerMonoBehaviour. I just thought I’d see if anyone’s figured out differently.
I don’t think so. What are you trying to accomplish by making it private inner?
I suppose ideally I’d like a class that can exist outside of the Unity GameObject/Component system, hides all its internal workings from users, and can manage itself with FixedUpdate, but I know that’s impossible, so I’m looking for workarounds. I could have a monobehaviour call a method on all instances of the non-behaviour class on FixedUpdate, but that seems even messier than the private class idea and it’s still exposing a method that shouldn’t be exposed.
You could try creating an internal class that extends System.Object and has a public method called Run() that you can call in your FixedUpdate of the MonoBehaviour class that contains the internal class. Would this work?
I don’t think so, the Object-inheriting class is the one that contains all the methods the user should use. The idea is to abstract away all the nitty-gritty timing and gameobject/component creating and recycling that’s going on, so that any new instance of the Object-inheriting class can take over any dead instance of the related gameobject (and its mass of components) without the user having to think about it. I mean, I can still do that, but the monobehaviour is just hanging out there in “public,” available for use like any other component. I wrote it so that it can tell in Start whether it was created the right way and gets rid of itself if not, but it’d be much better if the restriction was enforced at compile-time.