Pros/Cons of the Global Event Editor

I suspect that you were advised against Global Events because of several limitations that they used to have. For example, I think you couldn't use qualifiers properly in them. They were also tedious to access, since there wasn't a dedicated keyboard shortcut to reach them. But those shortcomings were fixed a few years ago.

Not being able to see the names of AltVals would probably be a deal-breaker if you value your sanity. Thankfully, there's the Base Frame feature for that. Once you assign a Base Frame, Global Events will derive altVal names from any objects in there. So you just need to make sure that any objects whose altVal names you want to see are in that frame. You can choose to use your main game frame as the base frame. Or you could use a frame that isn't even used in your game, but whose sole purpose is to house all of your objects as a sort of reference library. I believe the Base Frame feature requires the 2.5+DLC, but if you don't already own that, you should.

I use global events fairly extensively, and they're great. Most of my game engine is still in Frame Events, because I had already converted my game into a single-frame system many years ago, before the Global Events became properly usable, so I already had the benefit of a single set of events. But I do use Global Events for certain things, and have been doing so without any problems for years.

One thing to be mindful of is that Global Events play after your Frame Events (if the frame has any). Though you can change the order in settings if you need. And as you mentioned, you may need to do a little juggling to ensure that certain events only play for certain frames. One way to do this is with a dedicated 'identifier' object. I place an active object like this into my frame, and check its flag:

Please login to see this picture.

Then in the global events, I can check for this flag via a condition. The resulting event will only trigger if the current frame contains that object (as shown below). You can use this method to fence off entire groups of code for certain frames.

Please login to see this picture.

So it just means that if you have an object in your base frame, your Global Events will automatically be able to see that object's altVal names. In the following example, the global events can't see the altVal name because the object doesn't exist in the Base Frame, which is Frame 2. When we switch the Base Frame to Frame 1 (which does contain the object) then the global events are automatically able to see the name

Please login to see this picture.

I didn't know that. Thank you Volnaiskra !

How do you guys feel about behaviors? Do you use/avoid them? Use them sporadically?

I like the idea of behaviours - of being able to move self-contained code into different frames just by dropping an object into them. Though I'm wary of splitting up my code into too many different spots, as it can quickly become confusing and tedious to manage your code that way.

There's another disadvantage with behaviours, which for me is very significant: they massively slow down the Find All feature. When I search my MFA with "Behaviours" unchecked, it takes about 1 second to show the results. If I perform the same search with Behaviours checked, it takes 15 seconds, which is obviously way too long for something I do 100 times a day. So I always leave it unchecked, which means that I can't see any results from behaviours when I search. So I won't go near behaviours except for special cases, unless Clickteam fix this one day. I imagine it would be fixable: the delay appears to come from Fusion searching through every single object in every single frame to check whether it has any behaviours, even if you only have one object that contains a behaviour. Surely Fusion could manage some sort of internal index that remembers which objects have behaviours, so that it doesn't have to trawl through thousands of objects every time you search.

But there is one feature of behaviours that even I can't live without, and that's the ability to run them before your Frame Events. I have my running order set to the default of Behaviours>Frame Events>Global Events. I like that Global Events run last, which means that they won't miss out on anything that's happened in the Frame Events. But there are some global events that I really want to run before Frame Events (eg. gather the latest keyboard/gamepad inputs and have them ready for the Frame Events to process....gathering them after the Frame Events would cause a 1 frame input lag). So for these cases, I use Behaviours. As long as the code I put in there is stuff that is resolved and I won't need to frequently work on, I can live with them being excluded from Find All.

I am also using Global Events in all of my games as "Engine" and I haven't found a single issue so far.

I usually assign the first several frames as "Menu / UX / UI " and these frames have their own events that I alter in Event List Editor.