Coroutines inside action nodes

Muse
, ,
1

What is the proper syntax to run a coroutine from inside an action node? I cannot seem to use startCoroutine (mycoroutine()) as it shows up as a red line under it.

2

StartCoroutine is a Monobehavior API. You need a Gameobject to work from.

So you could use Node.GameObject to get a component from which you can call StartCoroutine: Class Node | Behavior | 1.0.6

However I would recommend following what the package do in some built-in nodes, using Awaitable API instead.

i.e. PlayParticleSystemAction.cs calls Awaitable_ReleaseParticleSystem(vfx) in OnStart. And the function signature is private async void Awaitable_ReleaseParticleSystem(ParticleSystem system).

From that function you can use Awaitable API to create delays just like in coroutine (Awaitable.WaitForSecondsAsync(...))

1 Like
3

Could be useful to have that documented in the Behavior doc.

4

Hi @purnabratarobo,

Like @Nobuna-no said, you can use the Node.GameObject component, or use Awaitable.

@Nobuna-no , is the request to document the GameObject property, or how to access co-routines?

Thank you!

5

Hi Shanee,

Node.GameObject is only documented in the scripting API and don’t provide more information than “game object associated with the behavior graph.”. This can be a bit confusing as a Behavior Graph is just an asset and this is not saying much if you don’t already have an understanding of how a behavior graph is associated to a gameObject by a Behavior Agent component.

Furthermore, we never inherit from the Node class, but from the Action class, so it can make it a bit hard to find as you need to look into the parent property.

In comparison, MonoBehavior doc provide the inherited property on the same page. There is also a lot of insight and references to other related topics: Unity - Scripting API: MonoBehaviour

Not saying that there is a need for a brand new page, but adding more info on the most used class detailing their lifecycle, reminding that Node.GameObject is a thing and recommending best practices for implementing nodes would be very useful.

Note: seems like some documentation page still refer to the Muse naming.

6

Hi @Nobuna-no

Thank you for this! I’ll work with our tech writer to fix the Muse references and add documentation related to the GameObject. We should probably also add something about the lifecycle for sure :slight_smile: