playMaker

Author Topic: Subroutine RETURN FSM[SOLVED]  (Read 4476 times)

wheretheidivides

  • Sr. Member
  • ****
  • Posts: 496
Subroutine RETURN FSM[SOLVED]
« on: April 23, 2015, 03:09:08 PM »
I haven't found this one so here goes.

I'd like a FSM to send event to another FSM to act as a subroutine.  Call the action 'FSM Subroutine'.  Then in the 2nd FSM, the last state would be a RETURN. The return then goes back to the 1st FSM to pick off where it left off.  There are tricks to do this like breaking a chain of states, but this would be cooler.  That way the subroutine FSM could be called by any FSM as a subroutine and at the end of it the return takes it back to where it left off.  This way any FSM can be a subroutine, it just has to end with a return



« Last Edit: April 24, 2015, 04:37:57 AM by jeanfabre »

Lane

  • Administrator
  • Hero Member
  • *****
  • Posts: 2511
  • Mender of the past
    • Cleverous
Re: Subroutine RETURN FSM
« Reply #1 on: April 23, 2015, 04:18:35 PM »
You can use RunFsm for this sort of thing.

Make a template and check "Inspector" on the variables you want exposed as input, then use Finish Fsm on the template to send the finished event back to the Host Fsm that ran it.

You can do a lot with Sub Fsm's (as they're called), but they're largely undocumented and hard to debug.
Products by Cleverous
|| Vault Core : Database
|| Vault Inventory : Multiplayer Inventory
|| Vault Attributes : Character Stats
|| That Hurt! : Dmg Floaties
|| Quinn : 3D

jeanfabre

  • Administrator
  • Hero Member
  • *****
  • Posts: 15500
  • Official Playmaker Support
Re: Subroutine RETURN FSM
« Reply #2 on: April 24, 2015, 01:07:22 AM »
Hi,

 yep, Lane is right. The latest sample I have put on the ecosystem will show how sub fsm works in a fairly complex scenario, it's using a custom version of RunFsm which allows you to define the template to run at runtime, so, this has even more flexibility.


and for you, this sample will also have several other interesting features, I recall you where asking for design patterns without global variables when complex communication between various elements of your game is needed. This sample also goes a long way on that front, mimicing IOS own coding patterns and communication proptocoles

 Bye,

 Jean

wheretheidivides

  • Sr. Member
  • ****
  • Posts: 496
Re: Subroutine RETURN FSM[SOLVED]
« Reply #3 on: April 24, 2015, 08:02:20 AM »
Cool. 

So the template FSM is just saved as a template?  So it would not be saved on a game object them?  I would create the FSM, save as a template and call the template when needed?  Is that correct?

So how would you view or modify this template FSM?

Also, will this pause the 1st FSM that sends the request to the template FSM until the template FSM is done running?  That was the main point of my question.
« Last Edit: April 24, 2015, 08:17:34 AM by wheretheidivides »

jeanfabre

  • Administrator
  • Hero Member
  • *****
  • Posts: 15500
  • Official Playmaker Support
Re: Subroutine RETURN FSM[SOLVED]
« Reply #4 on: April 24, 2015, 08:34:50 AM »
Hi,

Yes, this is one of the purpose of Fsm Templates, to be used inside the RunFsm action.

you can modify the template from the dedicated PlayMaker template browser ( you can show it from the PlayMaker menu/Editor windows/Templates Browser).

the runFsm is an action and as such only works while the state is active. IT will not "Pause" it, instead it will just behave like any other actions. use the "Finish Fsm" action within the fsm template to inform the state that the RunFsm action is finished.

Bye,

 Jean

wheretheidivides

  • Sr. Member
  • ****
  • Posts: 496
Re: Subroutine RETURN FSM[SOLVED]
« Reply #5 on: April 24, 2015, 03:47:54 PM »
So its not a real subroutine.  That being the case, what I'd like to see is a FSM called 'subFSM'  The start state would be 'StartStateSUB' and after the last state it would have a 'EndStateSUB'.  That way you call a action called 'FSMSub' and that FSM pauses.  the new FSM runs and when it is done sends action back to the first one to continue.

One idea would be to have a dedicated game object prefab in the hierarchy.  Any FSM inside it would be a 'subFSM'.  So if you call any FSM in that game object, it must be a subroutine with a start and end.