Proper autocomplete for MonoBehaviour?

Hi,

I've read that functions like OnCollisionEnter are not actually being overridden but are scanned via reflection and that's why it always works disregarding being set as private/protected/public.

Since those are basicaly "strings" searched by Unity in classes, how to have proper autocomplete for this?

I think this problem is existing in both MonoDevelop and VisualStudio.

Is there any solution for this?

My basic idea is to have concrete class which extends MonoBehaviour with all those methods implemented as empty, and put them in #ifdef tags so that they are visible only in editor. And then extend that class instead of MonoBehaviour.

Is there something like this existing already?

Thanks.

 

There were some ramblings at Unite about wanting to create a less magical monobehaviour. At this point, I think it was mostly just brainstorming. The major problem I see is there are about five dozen magic functions, and most shouldn't just be transplanted to a normal inheritance chain.

A good chunk might be mitigated with interfaces, but there are cases like physics where the better idea might be to retool the stock components to use events. Say that instead of having an automatic OnTriggerEnter, you wire up a modified unity event to call a specific function on the collider that could be named anything (even better if it used interfaces).

 

On thought i heard they wanted to make these use interfaces in the future, so it would act more like stuff like OnPointerEnter, etc. Where you add the interface, and implement it.

But for know, if you are using the Visual Studio Tools for Unity, there is a command in the Right Click menu called "Quick MonoBehaviours" that will add a message at the cursor.

@RockoDyne ya i really like the events idea, could just feed in any method you want with the proper signature or simply write it as a lambda. Seems way more flexiable since at run time you could add more delegates to the event or change which ones it is point to.

Edit: The only issues i see with doing this, is that you would still need Awake/Start or a constructor as a place to define your events. But Awake and Start could just be Virtual Methods of the MB that you override.

Also the one upside to the current system, is that if you are making a class that is meant to be overridden, the current system lets you define the protection level of the unity messages, as well as if they are virtual or abstract.

 

Don't do that, you'll end up taking on the overhead of an event firing that shouldn't have to fire. For example, if 'Update' were in this class, Update will fire every frame for that class, which can be expensive if done on EVERY script.

I hope they do that! That would be awesome!

In the mean time, this actually is a decent way to get the functionality you're looking for. You could in theory have 'IUpdatable' interface, so that way you just add it to the inheritance chain, and then Visual Studio's autocomplete will fill in the implementation for you.

Although, really, in the end. I don't find it to annoying to write any of them by hand. I just keep the docs open with the list of known messages at the ready.

http://docs.unity3d.com/ScriptReference/MonoBehaviour.html

 

@lordofduct what do you think of moving more of this over to events though. I think instead of having my Trigger events, or my update tick be a event instead of a method i implement can be a very powerful idea if done right.

 

Honestly, I like a system based around the interface (may it be explicit with an interface or just reflected from the classes interface). And my reason is less boilerplate code.

If events were used, you'd have to register for the event. This requires some boilerplate at the 'Awake'/'Start' of the script.

Where as with the current reflected interface, or the more explicit interface, unity just determines if those methods exist, and wires them for you.

And for general purpose scripting by your regular designer (rather than engineer), this is easy.


It has it's down sides... you can't unregister an event on a whim at runtime. That's annoying.

But in the same respect, the implementation of an events based system comes with some issues on the unity side. Currently, with the event registration known by the interface of the class (if the class has a method defined), it can preemptively categorize scripts into pools of who is and is not registered for an event. This reduces costs of calling those events... ignore all scripts that don't have an 'update' function.

If it used the .net events, like:
https://msdn.microsoft.com/en-us/library/awbftdfh.aspx

It's a bit more difficult to preemptively know who is registered for what events with out cycling through them. They'd have to long hand implement the events 'add/remove' methods, and insert/remove the classes from the event pool so that it wasn't checking the scripts every frame. This means registering would be heavier.

Furthermore calling these events would be inverse of the event system design. An event system dispatches events from an object to the other. The event can only be called by itself. So behind the scenes, unity would have to have a caller function on each script that calls the event, so the script can receive its own event. Unnecessarily increasing the stack call length.

And a minor quibble could be the object overhead of having to create delegates for every registered method to the event.


Of course they could also use a 'AddListener(someDelegate)' function, but again... we have all the quibbles of the .net event system... with the exception of the increased call stack because the delegate isn't restrained by the call direction of th event.




And of course they could also use a 'AddListener(ICallbackReceiver)' funciton, ala Java-like event messaging systems... but that is really the interface system you said you think unity might be implementing. Just with the added necessity of the actual boilerplate code to add/remove.

This one I could go with... get a best of two worlds.

Have it where if the interface is implemented, the script is registered for the event automatically by the unity system. But the script itself could called 'RemoveListener' or 'AddListener' at runtime to register and unregister. Removing boilerplate code, but giving the runtime swapping.

 

So I see there is no ready solution, except what @passerbycmc has mentioned in Visual Studio. I guess my frustration has grown because of playing with Android Studio recently - there you can ALT+ENTER, or ALT+INSERT everything, and you don't have to look in the docs even once, because even if you require explaination everything is in the source.

 

Well there are 2 things you can do, Use the Quick MonoBehaviours of the VS Tools for Unity Extension, or write your own interfaces like IUpdateable that implement unity messages.

Think your making a non issue into something big persnally since its not that big a deal having to type out a Method here and there.

Also the Alt+Enter corrections and inspections and stuff you explain in Android Studio, is also a feature of ReSharper which is a Visual Studio Plugin. Android Studio is based on the IDE Intellij IDEA which is made by the same people who made ReSharper and PyCharm. So all of the JetBrains Ide's and plugins share that functionality.

 

I see, thanks for clarifying.