playMaker

Author Topic: Blocking/ignoring events, rendering a FSM deaf[SOLVED]  (Read 4972 times)

Broken Stylus

  • Beta Group
  • Hero Member
  • *
  • Posts: 772
Re: Blocking/ignoring events, rendering a FSM deaf
« Reply #15 on: December 23, 2018, 01:15:01 PM »
Hi,

 Visually it works like this:

- any global transition ( black transition sitting on top of a state), will be caught regardless of the current active state in that fsm.

- any transition (grey transition sitting below the state), will ONLY be caught if the state is active.


so it's not a hack nor dirty, it's by design and in purpose, and I strongly encourage this kind of pattern.

I understand that but I find it not visually obvious, since as in your example, one needs to actually open the state and check what it does in detail in order to know if the exit transitions are sent by actions in that state or if they're hidden global transitions.
There's simply to know just by looking at the state itself.
There should be no disruption of the visual clues and rules used for transitions. For example, such a transition could appear in almost pure black too (well actually very dark grey); which is not possible by using the color palette as transitions are of a lighter hue than the state's color so even a pure black will appear grey.

On the plus side, aside from what you revealed, this transition listening to outer events conveniently avoids having to do the usual "Get Last Event" + "String Compare" combo.
Let's just add, btw, that these two actions could really come under one new fused action.

Thore

  • Sr. Member
  • ****
  • Posts: 480
Re: Blocking/ignoring events, rendering a FSM deaf[SOLVED]
« Reply #16 on: December 23, 2018, 02:55:33 PM »
Perhaps, global events should be visually distinct in some way, since Playmaker strives to be a visual scripting solution, but nobody’s stopping you from following the convention used by Playmaker, namely writing global events in ALLCAPS—then you see at glance what is global and local. The other rule is perfectly clear, events underneath are only triggerable during that state, and the events coming in from the top (global or start) always listen.

Broken Stylus

  • Beta Group
  • Hero Member
  • *
  • Posts: 772
Re: Blocking/ignoring events, rendering a FSM deaf[SOLVED]
« Reply #17 on: March 01, 2019, 04:41:08 PM »
Perhaps, global events should be visually distinct in some way, since Playmaker strives to be a visual scripting solution

Absolutely! I think the whole UI could need a little refreshing plus an improved UX but that will wait until I find time to post a proper thread. I've got plenty of ideas I'd love to share.

Quote
but nobody’s stopping you from following the convention used by Playmaker, namely writing global events in ALLCAPS—then you see at glance what is global and local.

I'd greatly advise against this solution because of these two reasons:
1. PlayMaker has a mind of its own and decides to turn certain events global without asking and once it has decided that an event is global, to deglobalize it is a very troublesome endeavor.
2. I personally found it better to use small caps for all custom events to precisely make them distinct from all the default/system events. Swinging back to all caps for global events would prevent from knowing from a quick glance if the event in question is custom or not.

Quote
The other rule is perfectly clear, events underneath are only triggerable during that state, and the events coming in from the top (global or start) always listen.

That, yes, it is clear. What is not in the current shape of the tool though is to know if the transitive event is waiting for a global event or will be launched by an action inside the state.

Thore

  • Sr. Member
  • ****
  • Posts: 480
Re: Blocking/ignoring events, rendering a FSM deaf[SOLVED]
« Reply #18 on: March 01, 2019, 07:13:51 PM »
1. if events are global which you didn’t switch to global, it’s either a bug, you accidentally switched them on, or you created events that already exist as global events. I can’t confirm this “mind on its own”.

2. If you do not distinguish global from local events in some way, you might have an answer why the problem in (1) occurs. You can use any rule you like (camelCase, _globalevent etc), but all caps is simply consistent. I never needed to distinguish between default system events and custom global events. The system ones that are relevant to me are easy to remember too (ON...etc COLLISION TRIGGER). Also, there is no need to switch them around. I design with a global event in mind, and then use all caps. If I use another approch, I create a local event in lowercase.

3. It’s a rather specific case to use local events that are not used by any action of a state. But I agree such events could be made distinct somehow, though so far, I never needed that case, and not even sure what currently happens.

Broken Stylus

  • Beta Group
  • Hero Member
  • *
  • Posts: 772
Re: Blocking/ignoring events, rendering a FSM deaf[SOLVED]
« Reply #19 on: March 08, 2019, 09:25:22 AM »
1. if events are global which you didn’t switch to global, it’s either a bug, you accidentally switched them on, or you created events that already exist as global events. I can’t confirm this “mind on its own”.

I can already think of out two issues that I had to deal with on several occasions. There's one when sometimes an entire FSM's events are all switched to global. I haven't been able to pin point the origin of this issue. Fortunately it's rare enough not to piss me off too much when I go returning the events to a local state in the FSM, but then it ties into the second issue.
The other is that of an event that is global yet unused, remains stuck in global despite trying to unglobalize it. And this is being aggravated by the fact that some clearly global events are not even reported as used simply because they're only mentioned in actions (like send ---) instead of used as Enter or Exit transitions.
That's another topic about the management of the Events window though.

Quote
2. If you do not distinguish global from local events in some way, you might have an answer why the problem in (1) occurs.

That's now something I'll have to handle manually since the discovery that global events can be used as "conditional" exit points just by being added as exit transitions to a state.
See, since PlayMaker is a visual tool, one quickly considers that entry events are those on top of a state and the ones below are exit events. It doesn't automatically make sense to think that global events could also "enter from below" as some kind of shortcut.

There's an indirect clue to that capacity in the Manual Guide: https://hutonggames.fogbugz.com/default.asp?W133

Transition Event
  • Events trigger transitions to another State.
  • Events can be sent by Unity (collisions, triggers, mouse input, animation events...)
  • Or by Actions (distance checks, timeouts, game logic...)

By explaining what System Events can do, (2) hints at (but does not confirm that) some custom events could also leave a state whilst being triggered by something else than any action inside the state.
Now, (3) doesn't mention this. It says actions can trigger those events and logically you'd think that by default, it means actions inside the state.
But it should be noted that IF these events are global, they can actually be triggered by actions from external FSMs.

I still consider that users shouldn't have to go through this custom nomenclature though, as it's absolutely clear that PlayMaker already evidences a clear distinction in its current UI between Global Transitions and (local) Transitions, doubling with a global tag for events.
I wish they had gone with something differently for the transitions coming from the top considering they can be local too; something like Entry/Incoming transition instead of the misleading Global transition title, or perhaps Main Transitions considering the power they have to steal the flow of a FSM (which was the initial point of my OP because I wanted to control that flow).

Quote
You can use any rule you like (camelCase, _globalevent etc), but all caps is simply consistent. I never needed to distinguish between default system events and custom global events. The system ones that are relevant to me are easy to remember too (ON...etc COLLISION TRIGGER). Also, there is no need to switch them around. I design with a global event in mind, and then use all caps. If I use another approch, I create a local event in lowercase.

Yes, nice. I use a similar nomenclature for global vars. For events when I started PM, I was using all caps but then I preferred to leave that for default events.  :-[
This being said, I see many devs not bothering with a global-centric event-naming convention despite how helpful it may be.

Quote
3. It’s a rather specific case to use local events that are not used by any action of a state. But I agree such events could be made distinct somehow, though so far, I never needed that case, and not even sure what currently happens.

I think that a different hue or something like dashed lines or else, for global events, would be interesting to test out.
Also could be extended to global vars, to make them stick out better without having to come up with a homemade nomenclature.
Let's remember that it's a visual scripting tool, the user is sort of supposed to be taken by the hand when it comes to visual elements and hints.

Local events used as exit transitions cannot be triggered by actions outside of the state. But this isn't true for global events. So a clue would be helpful. I talked of hues or dashed lines but maybe they could go with a kind of small and stylized arrow on the left of the transition block, pointing to the right, to indicate that it's a global event?
Even System Events (ON STUFF, MOUSE, TRIGGER, etc.) that can trigger an exit node should also be indicated as potential shortcuts, just to be coherent.
The idea boiling down to indicating when exit transitions are susceptible to be triggered from outside the state and therefore act as "entry ports" too.

jeanfabre

  • Administrator
  • Hero Member
  • *****
  • Posts: 15500
  • Official Playmaker Support
Re: Blocking/ignoring events, rendering a FSM deaf[SOLVED]
« Reply #20 on: March 18, 2019, 02:42:55 AM »
Hi,

- a global event remains global even if you uncheck it inside an FSM, you must uncheck it in the fsm event browser for it to affect your project.

- global events and events are one thing, transitions are something else. So it's indeed very important to understand that the global transition above a state can accept any event ( local or global), and the same holds true for local transitions. I wish there was a better way to word these concepts like you proposed... tricky. The issue with wording is that it rarely is sufficient to depict a behaviour, and it;'s only after actual experimentation that the concepts are understood.

Bye,

 Jean