Playmaker Forum

PlayMaker Help & Tips => PlayMaker Help => Topic started by: krakov73 on October 26, 2012, 11:24:13 AM

Title: GetFsmFloat vs GetEventInfo/SetEventData
Post by: krakov73 on October 26, 2012, 11:24:13 AM
Getting some weird results so I thought i'd ask :)
 
On one game obj I'm trying to send a float on one fsm to another fsm on the same object. This float is changing every frame, and when I use set event data/get event info the receiving fsm receives zero (what the float starts as) while I can see the float changing in the set event data debug. If the float is static it sends just fine so it only seems to send what the float is set for on the first frame of the state even though the send event every frame is ticked.
To get round this I'm using GetFsmFloat on the receiver instead that works fine but adds to the ever growing stack of actions in a single state (more on that later).
 
So if you can follow what I've been saying (this stuff is hard to describe) I need to know the right way of sending changing data between fsms, there are lots ways of doing this in playmaker but there seems to be no guide to best practise in different contexts yet playmaker seems to be all about sharing data between fsms's & objects.
 
Related to this (but maybe it needs a new thread) is my problems with actions stacking up in single states. I'm having trouble keeping my states legible particularly every frame states where I cant seem to split them up as they are reliant on things happening within that state (mouse up event/every frame bool checks for instance) I've read some threads on this but I'm not finding good examples of splitting states into more manageable sizes so any help on that would be super nice ;)

Edit: Sorry if this was a bit rambling, i've added an example & i'll just ask if it is correct/expected behaviour - I was thinking both mouse buttons would do the same thing in this case.
Title: Re: GetFsmFloat vs GetEventInfo/SetEventData
Post by: krakov73 on October 28, 2012, 07:47:00 AM
Well excuse me for not having esp because when the manual is so tight lipped on when & where to use seemingly duplicate actions (and pretty much everything else) I have no choice but to ask in the forums - i'll be bumping this thread regularly.
Title: Re: GetFsmFloat vs GetEventInfo/SetEventData
Post by: jeanfabre on October 29, 2012, 01:18:32 AM
Hi,

Sending data with events works in 99% of the case and I think you fall in that case. I think it's simply a matter of wrong state or logic set up.

 the only case where event data do not work reliably is the following:

 if two objects have colliders and for example trigger enter or collision enter is fired and both object have Fsm implementing a send event with data in the state then the data is mixed up. I have a repro case that I need to clean up. I bumped into this problem only twice since the beginning of playmaker.

In this case, the best option is to manually set a variable in the target Fsm and then fire the event. Event data should not be used in that case. In the mix comes Prefab instantiation and Start state that also should be avoided. Don't rely on the start state when you know the Fsm is on a prefab amd relies on early set up when instantiated, instead do as above as well, set variables manually using set Fsm xxx actions and then either wait for a frame or send a "INIT event to that FSM at a later time.

 So:
-- are your fsm attached to a physics gameObject using colliders?
.. Are you within the START state and its flow?


I do have a lot of fsm that relies on others indeed, and for this the best approach I found was to maintain a "META" fsm only holding them shared variables, they do not implement any logic or receive any events, they are simply repositories. Other Fsm get and set what they need there, so I know that I NEVER rely on a variable within a Fsm, but actually always rely on the "META" variable value instead. So when I enter a certain logic, I first make I get all the variable I need and then proceed. It doesn't have to be bad Fsm with twisted logic, I think mine are very organized and flows very well actually. The Get / set fsm variable dance is annoying for sure, and the way to go about that is to split States indeed.

splitting states that should work everyframe can be sometime a challenge, and for this, it's not about splitting the state, but actually splitting the Fsm all together.

EveryFrame bool states and similar technics is not very nice. I do use them, but only very occasionnally, when I can't be ask to do it proper to be honest... :) and then I know I will have to re do them cause they are a pain to maintain and not flexible. When you switch a boolean variable state, you should fire a global event for other Fsm to listen and avoid too much "every frame states" this way everything flows much better, you visually see and understand when a state cane exit and why.

Do you have particular examples? that would help base this discussion on fact and provides tangible alternartives for users to understand these design patterns.

Bye,

 Jean
Title: Re: GetFsmFloat vs GetEventInfo/SetEventData
Post by: krakov73 on October 29, 2012, 10:37:32 AM
Hi Jean thanks for taking the time with that explanation, good info in there. I think your right and its a logic problem or structure problem I'm running into.

I'm still confused about get/set event info and how is supposed to work given what its showing me on screen.

In my example in the OP if you hold down left mouse you can see the float changing very frame in its set event data debug window...here is a screenie -

http://imageshack.us/photo/my-images/854/senderr.jpg/ (http://imageshack.us/photo/my-images/854/senderr.jpg/)

Yet in the reciever fsm the get event data does not get updated when this is happening...

http://imageshack.us/photo/my-images/841/recievers.jpg/ (http://imageshack.us/photo/my-images/841/recievers.jpg/)

so I've got to wonder why the send event action has an very frame tick box if its just a switch & can't be used for data transport every frame - however I'm comming round to the fact that transporting data every frame is my structure problem & not playmakers :)

Now when you describe your 'META' fsm I'm reminded of a couple of threads that mentioned using 'broker' fsms (by you I think), this could be where my disconnect is because i'm still thinking to much in scripting terms & making functions inside fsms where I shouldn't hense the communication & stacking issues.

In this context i'm making character objects with player controls or ai, health, energy, shields etc but the all import part is my desire to integrate a playmaker animation graph that keys off of these components. Could I trouble you to sketch a flow chart so I could visualize how or where the META fsm would sit between components like these & typical actions for communication between them.

Also thanks again for your previous help on health bars, thanks to that now my problems are not making things happen with playmaker but doing them the right way :)
Title: Re: GetFsmFloat vs GetEventInfo/SetEventData
Post by: jeanfabre on November 01, 2012, 06:39:43 AM
Hi,

 the everyFrame option do not work on the Send Event action. It's a bug.

 I would actually also not send event everyframe. I don't feel this is appropriate.

rathet, I would send an event to start watching for a variable, and an event to stop watching for it.

and the fsm that was suppose to get the event and it's data, would simply get the variable value either from a global variable, OR using "get Fsm int" or something.

Does that make sense?

bye,

Jean
Title: Re: GetFsmFloat vs GetEventInfo/SetEventData
Post by: krakov73 on November 01, 2012, 05:26:34 PM
I guess i'll think of send event as having a superfluous every frame tick box, colour me suprised.

Thanks for clarifying those things jean, yes it makes lots of sense.

I'm still having 'fun' organising fsm's that would have been one script & subsequently needing to communicate every frame data between them. I might be seeing the usefulness of the meta fsm you described but... to keep things extendable i'm guessing at best practise too much for my liking :)
Title: Re: GetFsmFloat vs GetEventInfo/SetEventData
Post by: krakov73 on November 06, 2012, 11:15:12 AM
After some more slap dash experiments in playmaker I thought the best thing might be to get my work graded by my betters, so i (not so) proudly attach 'turbo meta capsule' for critisism.

Now i'm hoping this catches Jeans eye (he who strides these forums like a collosus) to look at my implementation of a meta fsm - is it anywhere near the mark jean?

There is a 'reactor' fsm that could be seen as a health manager, a force/torque based movement fsm, an animation graph & a turbo feature, it even includes some gui energy bars :)

I seem to learn better by doing stuff wrong so it would be usefull to know how badly screwed up (or not!) these fsm's & they way they communicate are.

 
Title: Re: GetFsmFloat vs GetEventInfo/SetEventData
Post by: jeanfabre on November 06, 2012, 01:16:53 PM
Hi,  ;)

 Will have a proper look tomorrow, and give as much feedback as I can. Your initiative is very much welcome indeed, and I hope others will also have a look to give feedback on their take on them features. That is always interesting to get several opinions.

Meanwhile I just released a package on another thread and mentions that meta data fsm, and actually used that technic. So maybe you can have a look, It's a simple enough example to get the concept of how various Fsms can communicate via this Meta data fsm technic, and what are the obvious advantages:

http://hutonggames.com/playmakerforum/index.php?topic=2534.msg11313#msg11313 (http://hutonggames.com/playmakerforum/index.php?topic=2534.msg11313#msg11313)

bye,

 Jean
Title: Re: GetFsmFloat vs GetEventInfo/SetEventData
Post by: jeanfabre on November 07, 2012, 04:50:48 AM
Hi,

 Yep :) you got the concept of meta Fsm right for sure. So well done there. Hopefully you can see some benefits of using this kind of technic.

Few things for the sake of arguments:

-- Not all variables you have in the meta are really supposed to be there, for example the "reactor gui max width" and "reactor gui offset Y" are very much internal properties of your visual interface. They do not really describe the player as such, So personnaly I would simply move it where it's needed.

-- Basically, if a variable is only used by one Fsm, no real need to promote it as a meta variable, unless it has a real meaning, for example to conveniently access it. I do that too, having my meta variables showing in the inspectors for a quick glance at how it performs. But Meta Fsm do really start shining when multiple fsm wants to read and write a common property.

Other than that, your implementation of the Meta is very good. I also tend to get meta data within the state I need it, so that I can tweak values and have all fsm reading them properties always up to date. It's not always a wise choice in terms of performances, but you see where I am going with this.

--------

on other features of your game, one thing that you need to be address is the HUD. the "smooth follow action" is unfortunatly not suitable in some cases, and here it's a typical example. It's been a while I meant to provide an update on this action, so now is the time :)

basically, the smooth follow action you use on the camera to follow your player should in your case work on Update so that other fsm have a time to process it, else they will always lag behind and your HUD will not be spot on glued to the player and jitteriness and shaky movements artifacts will be seen.
http://hutonggames.com/playmakerforum/index.php?topic=2536.0 (http://hutonggames.com/playmakerforum/index.php?topic=2536.0)

So in your camera follow state, use that new action instead and your HUD will look perfect.

The rest is fine to me, so congrats. Keep us updated on your progress on that game.

 bye,

 Jean
Title: Re: GetFsmFloat vs GetEventInfo/SetEventData
Post by: krakov73 on November 07, 2012, 11:09:00 AM
Thanks for taking the time to have a look at my stuff jean.

-- I think I did go a little overboard on the variables, i guess my thought process was  - what if i want to add a power up that increases player energy capacity or changes how fast the turbo burns energy etc..but i agree with your guideline & its useful to see it written down.

-- Controlling an animation graph this way with one or two variables just feels 'right' & to me seems more elegant & preferred method to using scripts.

-- The turbo manager & reactor fsms still feel a bit shoe-horned to me. Ive combined gui update where I might have preferred separate fsms with smaller stacks for easier expendability, but this way i'm not using any every frame communication. More official information on fsm communication cost would be helpful - but i'll assume its either the same or better than unity script communication methods.

-- smooth follow2 does indeed smooth out the jaggies (i wasn't too worried as it was just slapped on the camera for speeds sake, but gj all the same!)

These little experiments have lead me to threads that discuss the much drooled over nested fsm's and in your example the use of game object hierarchy reminded me how they might look & work. It seems to me that the more complexity I add the more communication between fsms i'll need - more so than using scripts, i don't know if this will have any real impact on performance but its a concern.
Title: Re: GetFsmFloat vs GetEventInfo/SetEventData
Post by: jeanfabre on November 08, 2012, 05:44:27 AM
Hi,

 Indeed you are correct, as a projects gets more and more complex, the key is communications.

 I would not be concerned about performances, but more about maintainability over time and reliability.

The issue ( and power) with playMaker is that most of it is loose referencing, so if you start with bad Fsm names, you are stuck with them because changing it will break actions that were talking to it. So, the very important and critical point is to keep everything clean and spotless in terms of naming conventions and meaning.

As the projects gets more and more complex, you will find that the performance hit of inter Fsm communicationg is unnoticeable compare to a lot of other arising issues like drawCall, actual feature implementation ( outside optimization, just making it work to begin with...), resources management etc etc. So go for it, you can always optimize your FSm down the road if you have keep everything tidy and well documented ( I create empty states that I label "note" to document my Fsm when they get too complex or so specific and sensitive that I know I will forget in 3 month time when I will ask myself "what on earth is this...")


bye,

 Jean