To make life easier and faster, both Action and Condition Tasks can make use of some attributes for both runtime as well as editor convenience. More specificaly:
Update Notice: [AgentType] attribute has been deprecated as of v2.7.0. You should now instead, use the generic version of tasks ( MyAction<NavMeshAgent> ), to specify the AgentType directly. The generic argument can also be of interface types as well. Thus, now the .agent property is already of that generic type and without any casting required. The following information shown here, still applies the same but instead of using an attribute, usage of the generic versions of Tasks is required.
You can use this attribute on the Action or Condition Task class. This specifies the Component type which is required for the agent game object to have. If no such Component exists, the Task Initialization will fail. If such a Component exists, then the agent property explained earlier, is certain to be of that type, so for example you can cast it if you want. If you don’t care for a specific type of Component, simply do not use this attribute.
Using this attribute will also show the agent field inspector which allow you to override the agent to be used. There are three options for which agent is going to perform the Task as follows.
Use this attribute also on the Task class if you want to use Unity’s messages like OnTriggerEnter, OnTriggerExit etc. Specify The messages you want to listen to and then you can use them in the task as you normaly would. Here are the event messages that can be listened and used right now:
Notice: There already exist Condition Tasks for triggers, collisions and mouse events.
Use this attribute over a Component type field. Whenever a new agent is set (OnInit of the Task), the field will be set by using GetComponent from the agent. If no such component exists, the Task Initialization will fail. This is a helper attribute to save you from doing this manually.
Use this over a nullable public field to make it show red if it is indeed null or empty string in case of a string. Furthermore, if such a field is null when the Task gets executed the Initialization will fail. This saves you from doing null checks all the time.
All public fields of both Action and Condition Tasks will automaticaly be shown within the NodeCanvas Editor Inspector for all inspectable types. There are also some attributes you can use to customize the shown controls as follows.
[SliderField(float min, float max)]
Use this over a public float/int or BBParameter<float/int> field to show a slider instead.
Use this on top of public string or BBParameter<string> field to show it as a text area control instead.
Use this over a public string r BBparameter<string> field to show a TagField control instead.
Use this over a public int r BBParameter<int> field to show a LayerField control instead.
Notice 1: All public inherited fields will show up for inspection as well.
Notice 2: If you really need a very special editor you can override the virtual protected void OnTaskInspectorGUI() and wrap it within an #if UNITY_EDITOR
Use this on the Task class to specify a category to be shown in. Notice that you can use subcategories by using “/”
If your class name is too weird for some reason or you just want to show by a specific name, use this attribute over the Task class.
Using this attribute, will allow you to provide a help description that can be read within the inspector of the task.
To specify the information shown when assigned on a node, you will have to override the ‘virtual string info’ property and return the string you would like to show, meaning what the Task is going to finaly do or check. This is very useful for getting a good overview of what will happen directly when looking at the behaviour in the editor. If the property is not overridden then the Task name will simply show instead.