Unfortunately (and at least right now), Tasks only work with Component or of course Component derived types. Everything in Tasks in regards to “Agent” is made with the agent being a Component derived type and thus Component is the lowest hierarchy type a Task agent can be assigned.
This might change in the future, but right now at least is unfortunately not possible to use ScriptableObject for a Task agent.
For your particular case, I would suggest to please create a custom condition task which will have a public fied of your ScriptableObject type, subscribe to your event and use it accordingly. It is very easy to create such a task. Here is an example:
Thanks Gavalakis. On Discord aFoolsDuty offered me a similar solution which is working, so no problem at all with the reply time. 🙂
On a related note (ConditionTasks + events), if a ConditionTask is attached to an FSM state as an ‘exiting’ transition (ie the condition is checked when in that state and, if met, will result in a transition to another state), is the ConditionTask’s OnEnable guaranteed to be called before any of the states ActionTasks are executed?
With your example above (or even Check CSharp Event) the OnEnable subscribes to an event, but I’m curious if that’s 100% safe if one of the ActionTasks in the state could result in the event being raised before the event has been subscribed to by the ConditionTask.
Is the timing of OnEnable execution affected if I have the state’s transition set to ‘Check Continuously‘ vs ‘Check After State Finished‘? Or do those setting only affect when the check of the condition is performed?
Out of interest, if I had ‘Check After State Finished’ set, and the subscribed event fired during execution of the state’s ActionTasks, would the condition be met once the state finished ie NC ‘remembers’ the event has fired? Or would the event have to fire after the state started checking the ConditionTask?
Sorry if this is a lot of questions, just trying to get things sorted in my mind!
Indeed aFoolsDuty is super helpful on discord 🙂
Yes, ConditionTask.OnEnable is always called before State.Enter (and thus before assigned ActionTask Execute as well).
The OnEnable is not affected by any option (like “Check Contiously” or “Check After State Finished”) at all. These only affect the check, yes.
With “Check After State Finished”, and in respects to CheckCSharpEvent and other similar conditions, the event has to be raised after the state has finished (or at the same frame). The way these conditions are implemented does no latch/remember the event being raised and the conditions only return “TRUE” for 1 frame after the said event has been raised. This has purely to do with the way the conditions are implemented and them using the ‘YieldReturn’ function (which makes the condition return true for one frame then resets back to false). You could of course implement your custom condition in a way that it latch/remembers the event being raised (by setting some boolean flag for example).