How was the Component Name selection implemented in Invoke Method

O

Occuros

New member
I have seen that the `Invoke Method` task has a very smart selection capability in the editor.


It allows to first select a Game Object, and then the Component Name Magically adapts to only show possible component names of the currently selected GO.

In the implementation of the `Invoke Method` the `Component Name` property is a simple `SharedString`.

How is this special behaviour in the editor achieved?

Any advice would be appreciated.
 
Justin said:
This is done behind the scenes within the editor. You can do something similar with object drawers:

https://opsive.com/support/documentation/behavior-designer/object-drawers/
Click to expand...
I have noticed the same behavior and it is very useful. I do have a small question. I created a class that inherits from ComparePropertyValue and all of the sudden, even if the fields are still there in the behavior editor, the magic is broken and the component name sharedstring simply displays none. Any solution to this, or do I need to either avoid creating a subclass? I looked in the editor folder inside Behavior designer and all I see it int and float sliders.
 
Currently subclasses are not recognized but I can look into adding this feature for the next update.
 
Justin said:
Currently subclasses are not recognized but I can look into adding this feature for the next update.
Click to expand...
Hi Justin, I ran further tests and it doesn't seem to be only related to class inheritance. As a case in point, I followed these steps, which amounted to the same issue:

- Duplicated the ComparePropertyValue task in C:\Programming\RTS_prototype\Assets\Behavior Designer\Runtime\Tasks\Conditionals\Reflection (which works with the property drawer and displays the drop down list)
- Renamed the new file to ReftectionTest, which effectively refreshed it into the BD editor as a new task
- Selected this new task in the BH editor, which instantiated it into the graph window
- Clicked the new task, and in the inspector, magic was broken.

So I imagine at this point that this is not only due to inheritance, nor is it a namespace thing, and that the magic occurs in C:\Programming\RTS_prototype\Assets\Behavior Designer\Editor where BehaviorDesigner.Editor.dll operates; somehow only specific task names seem to be referenced in the drawer properties, so if new tasks are created they are not processed.

Am I wrong to assume this?

(See pics below, same code on both sides, only task name differs)
 
Last edited:
Thanks for the note. I haven't had a chance to look into this yet but I'll let you know when I do. I do know that the editor is looking for the specific class and its field names so that likely has something to do with it.
 
You must log in or register to reply here.
Top