A state transition uses the same event as a global transition...

[Broken Stylus]

Having moved an entire project onto Playmaker 1.9.6.f1 I now see this kind of error:

A state transition uses the same event as a global transition: [name of event]
The state transition will never be triggered.

There are many FSMs which use global transitions as exit (state) transitions but which are also used by actions within those states.

That is, a transition used in a state to exit said state via an action's output could also be triggered from outside, by another FSM, but ONLY if that specific state was already active (meaning it would be in "hearing" mode since once the flow would move out of this state, said state would be become deaf to global "calls").
This conditional (or contextual) firing of an event is a nice trick that I've been using for a long time now.

I never expected that this rule would be changed in any iteration of PM 1.9x.
But it seems Playmaker is now telling me that I must definitely separate global events from local events IF this event is also used by an action.
I explain that IF with the following reason: I know that there are FMS's within my project with states that use global events as exit transitions too (so, a conditional exit) but where no action uses them at the same time within those states, and no error has been triggered by such cases, so I think it's specifically related to actions using those global events at the same time.

Is that correct?

EDIT: it's even worse than I thought. I found cases where no action was involved at all. It looks like I'm just forbidden to use global events as a way to exit a state. I don't get the point of this. The fact that there is a message error that clearly points to this in clean english tells me it's a choice.
There's an option in "Preferences > Error Checking" titled "Check for Transitions Hidden by Global Transitions". If I tick it off, that specific error as quoted above goes away.

[Christoph]

What is the reason why you would use a global event within an action or a state? Isn't the entire purpose of using global events that they are used as global transitions?

Having said this, I'm still on 1.9.5.f3 so need to update first to really understand the scope of it. I actually didn't even know there was a new version out there.

Looking at https://hutonggames.fogbugz.com/default.asp?W311 it seems that version 1.9.7 is going to move around things even more with the new editor Play Mode options. So might wait until this happens.

[Broken Stylus]

What is the reason why you would use a global event within an action or a state? Isn't the entire purpose of using global events that they are used as global transitions?

Because a long time ago, I was told about a function in Playmaker that wasn't explained in the documentation.
I had a case of a FSM where a global event would interrupt the current flow within that FSM and reroute it to the state this global even pointed at.
A global event carries some kind of "super authority" that precedes that of local events. It just doesn't care what is going in a FSM. If a FSM has a way to receive that global event's "call", it will and that's final.
But it was problematic because I needed that global event to be received only under specific conditions without having to create parallel duplicate FSMs on the same object or use the disgraceful "MoveTo" action.
It turned out that if a global event was actually used as an exit transition (placed under the state) instead of an entry one (placed above the state, in the black box), it could precisely do that, be received, but only if that very state was active.
I have a whole game built exploiting this feature, but now it reports an error because it seems to have been completely deprecated.

Having said this, I'm still on 1.9.5.f3 so need to update first to really understand the scope of it. I actually didn't even know there was a new version out there.

1.9.6.f1 isn't even listed on the release notes!
What the hell did the package manager download?
The manager shows this:

1.9.6 (Current) - released on December 18, 2022

As for the notes, it reads:

Version 1.9.5.f3
Added State Transition Hidden By Global Transition Error Check.
Added Duplicate Global Transitions Error Check.

;_;
If I move back to 1.9.4, these issues will go away. I don't even know if these errors are critical.

P.S.: I have also observed that another type of error, "Duplicate Transition Events", will be fired up by empty black boxes, now that I have migrated the project to this version of Playmaker. These boxes used to host global events but as I modified my FSMs I wasn't sure if I completely wanted to remove them so I merely deleted the events they held (clear transition event), leaving the empty boxes with the three dots as a reminder that there was a global event there. I never went back to delete them entirely.
But to my surprise, I just discovered that these black boxes weren't so empty because they trigger duplicate event errors despite being empty as far as I can tell! In other words, the Graph View tells you it's empty, but Playmaker retains the ID of the last global event that occupied that spot. It runs a comparison and error checking by looking at a piece of data which, for all intents and purposes, was assumed to be deleted by the user (me).

[Christoph]

Interesting. Like if it caches those events until you delete them. Might be an oversight but I do this sometimes too. Will make sure I get rid of them entirely for optimization purposes.

Regarding the feature you mention about the global events triggering under the state you mean that it would get triggered instead of the same global event above the state? Like if the two are competing and in case the state is active it would give priority to the one under the state?

And yeah. I saw that the last update is not listed 🙃

[Broken Stylus]

Regarding the feature you mention about the global events triggering under the state you mean that it would get triggered instead of the same global event above the state? Like if the two are competing and in case the state is active it would give priority to the one under the state?

Not the same because you have to decide how the global event is going to work with the state.
Either you put it above or below, but not both.

How do you use a global event? By adding it above a state. A black box is added above the state with your global event in it, and you can stack several global events that way above the same state.

So this way, it is very authoritative because it forces the entire FSM to always listen to this global event being broadcasted from any other FSM, at any time. And if this happens, then no matter what happens in the FSM, the global event will take precedence and force the flow to go into the state this global event is "installed" on, or plugged into, sitting above it.

But if you add it as a transition, that is, as an exiting event below the state, it works too, but in a restricted way: the FSM will only listen for it if that specific state is active. It's a powerful feature that allows you to control when a FSM should be paying attention to a global event.

This is why I'm baffled at the change. If the error is anything to go by, it seems they have decided that this wasn't acceptable anymore. While I can understand that it might be confusing in terms of readability (which is easily solved with different colors), all they had to do was then to allow the "true" global events (i.e. the entering and state-activating, black boxed events) to be marked as "conditional" with a right-click option on it, which would have required an equally simple but clear icon or some special outline on that global event's box, to know that this global event requires the state to be active for the event to be received (to be "heard").

But that's part of the issues in PM where the UI is not providing enough information.
Which if you allow me a quick digression, is just like for example how in an action an event field isn't shown in a different color or something to highlight it at first glance.
It would make things so much better and easier if one could spot an event field in any action without having to read the descriptor (in fact, the FsmEvent's name) to see if it's written "event" in it.

[Broken Stylus]

I use "entry" and "exit" because of this precisely. Playmaker sets the divide between global and local, but since global events can be used sort of locally by being added in a spot, below a state, where normally local events go, it creates confusion.
I always found that silly naming convention very silly because even local events – and I truly mean strictly local events, as when you go in the Events tab, they're not marked 'Global') – can be used as *cough* "global" events as entering transitions.
Playmaker uses the term "global" to describe two different things and that's potentially confusing:

• In one case, just like for global variables, global events are those events marked "global" that can be sent between FSMs that are residing on either the same game object or different ones.
• In the other case, it's just an (entry) event that sits above a state in a black box, that points to said state. At least officially. But as explained in the posts above, it's not entirely true.

[Broken Stylus]

I created a testing scene with two FSMs to create a similar condition, to see if the error would be triggered by having a global event used as an exit transition would not be accepted.
There's no error, meaning that "Check for Transitions that are Hidden by Global Transitions" got actually triggered by something I'd call residual data of my older project, where two identically structured scenes will or won't trigger the error depending on what version of Playmaker they were created on.

By older, I mean something done on 1.9.2/3, so it's not a big leap.
I wish I could find a text file where I could read the version number though.

Which means that, if I'm lucky, going in a FSM that triggers the error and deleting, then re-adding the same global event, in the same position, as an exiting event, might solve the issue.
But then it means I have to do this for each single FSM where such an error is triggered.
Or I deactivate this specific error checking in Preferences and just cross my fingers that everything works.

I might just as well regress to an older version, but since at Unity these corner cutting geniuses can't even be bothered to add an archive to their asset database, it's literally impossible to download an old asset version from the package manager. >:[

[Christoph]

What you describe I use often in my architecture. For example I have an event called “Continue”. But it never occurred to me to make it global. It’s a local one and I use send event by name to trigger it. I put it below the state. So only if it’s in that particular state it actually gets triggered.

I think there’s indeed a confusion or maybe bad communication of what a global event is and in what it differs. For me it has been mainly the way you access it. Since you can select it directly in the drop down. But otherwise it’s exactly the same. It gets accessed through a string and you can use both as local or global, below or above the state. 🤔

Why don’t you use what you describe as local events? I mean would there be a disadvantage?

[...]

It's very nice that they added the warning. I had to change hundreds of FSM's that had global and local events that had the same name by renaming the with global/local suffix.

A very bad UI oversight.

[Broken Stylus]

Why don’t you use what you describe as local events? I mean would there be a disadvantage?

A typical example would be where a global event sent in broadcast mode can be filtered out by making the same event an exit transition (underneath the state) in a receiving FSM.

Or because I compartmentalize some systems with parallel FSMs and sometimes I want a particular FSM to start listening, in standby mode, to a global event only once I decided whatever that FSM was doing is complete.

Or simply because I'm priming a given state to be ready to receive an event sent to this very FSM that could arrive any time soon.