Reflection Description Suggestion

[Async0x42]

I noticed that some of the descriptions when I’m using reflected methods aren’t very descriptive, such as owner.set_enabled = false, when it’s setting a specific component enabled to false (which I suppose it the owner, but I’m of the understanding that the owner is the gameobject with the BT/FSM

I changed it so rather than owner.set_enabled = false, it’ll display as owner.splineMove.set_enabled = false;

I attached a screenshot demonstrating what I mean. I don’t know if there’s somewhere else this descriptiveness would cause issues, but if not, I think it might be a nice change for appearances and quickly glancing at the descriptions. In the photo, the first image is the default description, then the bottom two images are the two code changes I tried. Personally I like the one that results in owner.splineMove.set_enabled = False, the owner.SWS.splineMove.set_enabled doesn’t really need the SWS, I think.

Added agentType.Name, that’s all, there’s probably a few things that could use this change, such as ExecuteFunction’s and whatnot, ->

return string.Format("{0}.{1}.{2} = {3}", agentInfo, agentType.Name, targetMethod.Name, functionWrapper.GetVariables()[0] );

[Async0x42]

Oh, it might look terrible on mine in the screenshot because of that UI issue I’m having haha…

[Async0x42]

Thinking on that, there’ve been many cases where this change would be great for clarity, but there’s definitely sometimes where it would just at clutter, so I’m not really sure about how to resolve that…

And while on the topic of reflection… The dropdown list for reflection can get really huge at times, is there any way for it to be coded so that it only shows top-level items, then inherited components (say from a base class, and then from a monobehavior) get put into sub-dropdowns, rather than everything thrown into a huge list. Attached is a screenshot with the issue

i.e., What I mean is the following:

1 2 3 4 5 6 7

EnemyComponent ->    -> Function A    -> Function B    BaseEnemyComponent ->                  -> BaseEnemy Functions                  -> MonoBehaviour ->                          -> MonoBehaviour Functions

Thoughts about that, if it’s even possible to do with reflection?

[Async0x42]

(Really wish there was an edit!)

I forgot to attach the screenshot, here you go.

Found the edit… Wasn’t loading on my slow vacation connection all this week!

[Gavalakis]

Hey,

Regarding the description, I just think it can get quite looong if the component type is also shown. Of course it’s more descriptive, but it just may get a bit cluttered in some cases. I will have to think this a bit more 🙂

I like your idea for subcategorizing inherited members in the context menu. Though I think I will go with just one subcategory “Inherited”, that will list all inherited members instead of a very deep tree for each base type from where a member is inherited. I will add it in the next version.

( so many TODO stuff now 🙂 )

Thanks again for your suggestions!
Cheers!

Join us on Discord: https://discord.gg/97q2Rjh

[Async0x42]

Yeah, for the cases where it wasn’t descriptive enough, having it made it look really nice, but there definitely are a few places where the description is making the line so long that it looks bad, I don’t have any ideas off the top of my head for a resolution to both issues.

Thanks! Your way would be good, and as you said, avoids deep nesting. Perhaps we could have inherited MonoBehaviour stuff in it’s own nested folder though, since there are so many and (I think) people would be more likely to access their components/inherited components, but even if not, it keeps Unity’s built in methods separate from user-written things.

i.e

1 2 3 4 5 6 7

EnemyComponent ->    -> Function A    -> Function B    Inherited ->        -> BaseEnemy Functions    MonoBehaviour (or Unity Inherited, or something) ->        > MonoBehaviour Functions

No problem, I’m glad you are open to listening to so many ideas!

[Gavalakis]

Hey,

So, I’ve added this now. In the end I went with having everything MonoBehaviour and back inherited, in a subcategory and everything else as normal. So Enemt and BaseEnemy members show up together, while everything else Unity related into the subcategory.

Cheers!

Join us on Discord: https://discord.gg/97q2Rjh

[Async0x42]

Awesome, that’ll work really nice, thanks!

[Author]

Posts