Bug? FSMOwner as Member/BBParameter of ActionTask

[modernalchemists]

Hi,

we are currently evaluating different approaches of our state design.
We got several nested FSMs in our setup, like so:

* Loading
* Main Menu
* Game
** State 1
*** State 1.1
*** State 1.2
*** State 1.3
** State 2
*** State 2.1
*** State 2.2
** State 3
* Something

So let me get to my main point 🙂

Question 1: I got a an action state, to which I add my custom action “SubFSM”. This class has the following members:

1 2 3 4 5 6 7 8

[RequiredField] public BBParameter<FSMOwner> fsm1;   [RequiredField] public FSMOwner fsm2;   [RequiredField] public BBParameter<FSMOwner> fsm3;

Now test-wise I assign these params with 3 differnt ways:
1) I got a BB Var in the “Variables” window of the state machine.
2) I assign a normal game object reference.
3) I assign a normal game object reference, eventhough my definition says it must be a BBParameter … not sure why that works.

If I start the game, everything works with all 3 types.
As soon as I stop the game, the assigned variables for 2) and 3) are NONE.
If I play again, even though it says NONE, the variables are assigned.
BUT, if I save unity and restart it, the varaibles are NONE and if I then play again, they are really none.

Is this a bug?
Is it because FSMOwner has some custom serialisation code (bound/unbound)? That’s what I think’s going wrong glancing over the code.

Question 2: Why can I assign a normal object reference to a BBParameter-member of my script? Is this converted via runtime to a BBParameter (see notes in 3) of Question 1 ).

PS: I know you have nested FSMs.
We have experimented with them aswell.
We are just not sure yet, what approach to take for our game setup (we got artists and programmers working simultaneously on the scene … sort of).

Ways we want to test:

1) Use the built in nested FSMs + one BB.
2) Use the built in nested FSMs + Global BBs (one per SubFSM).
3) Use our own SubFSM, like described above. This has the advantage, that each Sub FSM has it’s own BB.

In case you’re interested, this is currently the SubFSM:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49

using System.Collections; using System.Collections.Generic; using UnityEngine; using NodeCanvas.Framework; using ParadoxNotion.Design; using CinemaDirector; using NodeCanvas.StateMachines;   namespace ModernAlchemists {     [Category( "Modern Alchemists" )]     [Name( "Sub FSM" )]     public class SubFSM : ActionTask     {         [RequiredField]         public BBParameter<FSMOwner> fsm;           //Testing - Remove me later         [RequiredField]         public FSMOwner fsm2;           //Testing - Remove me later         [RequiredField]         public BBParameter<FSMOwner> fsm3;           private FSMOwner _fsm;           protected override void OnExecute()         {             _fsm = fsm.value;             _fsm.StartBehaviour();         }           protected override void OnUpdate()         {             Debug.Log( "fsm.running:" + _fsm.isRunning );               if( !_fsm.isRunning )             {                 EndAction( true );             }         }           protected override void OnStop()         {             _fsm.StopBehaviour();         }     } }

[Gavalakis]

Hello,

Regarding the BBParameters resulting to NONE, most probably the reason is that the graph in which your custom SubFSM action is in, is a prefab or an asset reference, but you are referencing an FSMOwner from the scene, in which case and by Unity standards, Asset (in the project) can’t have scene object references. Can you confirm that this is indeed the case?

Regarding your 2nd question, a normal GameObject variable can be assigned to any BBParameter<T> where T is a component type (like FSMOwner is). This is done for convenience and in runtime, the actual component is fetched from the assigned gameobject automatically, just like you’ve correctly guessed. 🙂

Your way of utilizing SubFSMs via FSMOwners, can become dirty down the road of the project and result in unintended behavior, because an FSMOwner component is very different than just an FSM asset. An FSMOwner is only meant to be a component which has an FSM assigned and behave by that FSM. It should really not be used as a way of utilizing SubFSMs of the same root “owner” since by definition it is treated as a different owner 🙂

I would strongly recommend using the “official” way of using SubFSMs or SubTrees. 🙂 If the sole reason of looking at an alternative is so that each SubFSM has it’s own blackboard variables, then I would suggest to please be a little patient until the next version, where SubFSMs and SubTrees will be able to use their own local variables and able to map those variables from the root graph variables.
Is this indeed the reason?

Let me know.
Thanks!

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

[modernalchemists]

Hi,

thanks for the indepth answers!

Regarding 1) NONE-isse: Yes, that’s the case, thanks for claifying it.

Regarding 2) Sub FSM: Thanks again for your thoughts. The own BB vars is the main reason. For now, we will go with the official way as you suggested and give the sub-bb-vars a shot as soon as they’re available.

[Author]

Posts