Decluttering Fsm logic with Breakpoint events and more control over transitions.

[Aaron3D]

Hi all,

Me again. 

One more post for now. I have a lot of states that are just used for debugging. For example, I'll have some event like NOT FOUND that will transition to a state that I have put a breakpoint on. (I put my event names in all caps.) I put these kind of event options in a lot of my custom actions, so one can find a lot of such states in my Fsm logic.

Thus, the sole purpose of these states of mine is just to hold a breakpoint. I think it would be great if there was a special purpose event called BREAKPOINT. When this event is triggered, it causes the execution to halt as if a Breakpoint was used. This would declutter my logic quite a bit. I'd love to see such a feature.

Speaking of decluttering logic, I would also like to have additional control of the transition arrows using anchors. The idea being, if the arrow isn't going where you want it (through your desired path between the two states it connects), you could set one or more points that the line has to go through. Actually, just being able to set one such point would be enough in most cases.

I appreciate that there is already a lot of flexibility with how transitions show up. With regards to that, it would be nice to be able to set a default side in addition to default link style. For instance, I typically line up my states up along there left sides, (like lines of text), and have one state transition to the next on the left side, but a lot of times the transitions will show up on the right.

Thank you for your consideration. And for such a great program. I love using PlayMaker! ~ Aaron 

[Aaron3D]

Hi, I made some progress on decluttering Fsm logic using a couple of techniques which I thought I'd post here because they relate to my prior post.

First, I've started using a local level event I named BREAKPOINT. I have a state in the same Fsm with a global transition that catches this event. The state doesn't do anything, but it does have a Breakpoint on it. This way, when the event is fired, it cause the program to stop. I can then use the "Prev" button in the PlayMaker editor to see where the event came from.

Second, I'm connecting more of my states using local events that are caught through global transitions than before, such as with BREAKPOINT. Occasional use of local events this way can keep the logic flow still very visual, while significantly reducing the challenge of keeping transitions from becoming too cluttered.

I hope that's helpful. ~ Aaron3D   

[djaydino]

Hi,
I just learned i nice way also from jean :

instead of naming it Breakpoint or whatever you put in,
just hit spacebar so the state name is empty and add a breakpoint.
for the next one press spacebar 2x and so on.

[jeanfabre]

Hi Aaron

 Thanks for sharing this.

 I would put some screenshots of one of your fsm, or a mock up, just so that people visualy understand how it looks.

 Bye,

 Jean

[Aaron3D]

Hi All,

Here's an image showing an example of how I'm using an event called "BREAKPOINT". I thought this might further clarify how I'm setting this up.



I create one state with no actions which has a breakpoint and a global transition for an event called "BREAKPOINT". (I colored this state red, and named it " ", space.)

Throughout this fsm, I fire the BREAKPOINT event wherever something is known to be wrong. Then when running the fsm, I can find these problems quickly using the PlayMaker debugger's "Prev" button, which changes the focus to the state just prior to the breakpoint, and that will be the state that fired the BREAKPOINT event.

This helps me a lot because I spend less time finding where something went wrong. But it also keeps my Fsm logic from becoming as cluttered as it used to be, before I started using a global transition in this way. Prior to that, I had many states with breakpoints, all connected with links and (non-global) transitions.   

Aaron3D

[dudebxl]

...and Aaron3D, you can also on top of your system use the custom debug action - DebugLogConsole - which will give you the path of the action and you will see the playmaker path info in the unity console.

[Aaron3D]

...and Aaron3D, you can also on top of your system use the custom debug action - DebugLogConsole - which will give you the path of the action and you will see the playmaker path info in the unity console.

Hi dudebxl,

I'm not sure I'm following you, but it sounds interesting. Utilizing PlayMaker's Breakpoint feature already causes a message to appear on Unity's Console. This message indicate the path info for the breakpoint state however, not the state that fired the BREAKPOINT event. Below are images of a simple example Fsm that illustrate what seen in the console when the application is paused by the breakpoint.



This second example illustrates the full path name a little better by not using a space for the state's name that has the breakpoint...



But, again, using the Prev button, (shown when the debugger is paused), it's easy enough to find the state that fired the BREAKPOINT event. However, using Get Previous Sate Name, the Fsm can get this information in order to show it in the console. Here's an example image of that...



I think you are referring to doing something like that with DebugLogConsole, but if you had something else in mind, please go into more detail. I'm interested in doing as much as I can to make debugging easier.

Thanks, Aaron3D

[dudebxl]

Hey man, thanks for all the info. i was just saying in the ecosystem there is a custom action called "DebugLogConsole" which might help you and add value to your 'system'. The path you build in strings is already built into the action. Check out the action in the ecosystem. 

Anyway very cool and interesting...