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.
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?W133Transition 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).
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.
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.