playMaker

Author Topic: [SOLVED] Not sure if scenario is possible in playmaker? (background actions)  (Read 1076 times)

Grofit

  • Junior Playmaker
  • **
  • Posts: 73
    • View Profile
I have a scenario where I want to update a variable every 5-10 seconds or so in playmaker but this needs to happen constantly regardless of what it is currently doing in its states.

So for example I set up an action on PlayerA to listen to when PlayerB moves and refresh the current direction of PlayerB. So the action needs to update a local FSM var and raise an event when it occurs which is can be handled by the user for state changes etc, or just ignored and in the process of the normal updates the updated variable would be used. Lets call the watcher/background action "WatchForUnitChanges".

I can think of a couple of ways but none seem nice, one is to have a custom component which gets attached when the "WatchForUnitChanges" is run and constantly checks the position of the target and updates the internals when it happens, then I have to get the user to manually stop which would remove the component, lets say "StopWatchingForUnitChanges".

Another way would be to have 2 FSMs on a component which would do some global trickery which seems worse than above.

So is there a nicer way to solve this problem, as I kinda want the units to act as normal and do their thing and if something does update when they go round to their normal actions loop they would realise something has changed and action it there.
« Last Edit: March 26, 2014, 02:25:42 AM by Grofit »

jeanfabre

  • Administrator
  • Hero Member
  • *****
  • Posts: 14698
  • Official Playmaker Support
    • View Profile
Re: Not sure if scenario is possible in playmaker? (background actions)
« Reply #1 on: March 25, 2014, 05:10:24 AM »
Hi,

 several Fsm is the way to go. you don't have to use globals ( I rarely use them if at all), I rely on "Get/Set Fsm XXX" to pass infos from one fsm to another, and I also try to create discrete event where appropriate ( like you mention to raise events at some point).

 Bye,

 Jean


Grofit

  • Junior Playmaker
  • **
  • Posts: 73
    • View Profile
Re: Not sure if scenario is possible in playmaker? (background actions)
« Reply #2 on: March 25, 2014, 05:32:12 AM »
Problem I see with this approach is that there would end up being a raft of FSM components applied to a single entity which makes it hard to know whats doing what. I did notice that there is the notion of sub FSM modules or dynamic FSM template assignment which may be more plausable but it still seems a bit hacky... but maybe this is a hacky scenario...

jeanfabre

  • Administrator
  • Hero Member
  • *****
  • Posts: 14698
  • Official Playmaker Support
    • View Profile
Re: Not sure if scenario is possible in playmaker? (background actions)
« Reply #3 on: March 25, 2014, 06:22:51 AM »
Hi,

 this is actually the way Fsm are intended to work. Indeed you need to organize your Fsm properly. But typically, for EVERY single process that must run asynchronously, you need a specific FSM for it. typically, you can't have a mouse listener Fsm coupled with an animation Fsm, they would get in the way of each other, one fsm for each will work.

sub fsm and template: if you are getting lost with several Fsm on a single GameObject, then SubFsm and template might be even worse in your case, cause the whole process becomes even more abstract. BUT, I use this all the time and it's utterly powerful, so I really suggest you try them out, because once you grasp how to work with them, the sky is the limit really, especially with prefab/template combination, incredible potential.

Bye,

 Jean

Grofit

  • Junior Playmaker
  • **
  • Posts: 73
    • View Profile
Re: Not sure if scenario is possible in playmaker? (background actions)
« Reply #4 on: March 25, 2014, 07:04:10 AM »
I guess both solutions give lots of potential and flexibility, in this case I think the sub fsms would be a better solution only because you may only want the sub fsm to be active while watching is active, if it is inactive you want that behaviour to be removed. Whereas if it was a separate FSM component it would always be active regardless of if the watching was active or not (well without it being notified of updates in the other FSM which implicitly links them anyway).