Can't use qualifiers in behaviours anymore?

[Harvy]

As I see it, the two biggest obstacles in Click programming are Qualifier limitations and Global Event limitations.
1. Frame events work better than Global Events. This has been the case since they were first introduced. But as every programmer knows, it's really annoying to have a huge game engine that must be copied to every frame whenever a change is made. Even if there were a button (or automatic option that is triggered at "compile time") to copy a group of events to all frames (or better, a subset of frames determined by the user), the power of MMF would be increased exponentially.
2. Anyone familiar with Object Oriented programming knows why we need Qualifiers; and most people can see the usefulness intuitively. With all the great upgrades to MMF, it's unfortunate that these haven't received more attention. I'm not just talking about using Qualifiers in Global Events, either. Trying to "pick" objects in conditions can be difficult or impossible. Try to make an action game with the following event:
Group.Bullets is overlapping Group.Players [and] Group.Bullets("Alterable Value A") == Group.Players("Alterable Value A") [then] Destroy Group.Bullets
It's been a while since I messed with them, but even this event would be problematic. Making a complex engine with multiple Qualifiers per condition is nearly impossible.
It's not necessarily a fundamental problem in the Click framework. Events like the above can be hacked by combining "pick a * at random" + fastloop the event a bunch of times, but that's obviously not a good solution. The "Pick objects with value ***" conditions are useful, but not powerful enough. The basic issue is that MMF needs, either in an extension (but preferably in the basic system), a simple + generic way to pick instances of objects. Qualifiers are a good start, but there is plenty of room for improvement.

Sorry for the rant; I've been a fan since KnP, and I appreciate all the hard work CT puts into Click products. This is just my soap box after years of using Click.

[Harvy]

As I see it, the two biggest obstacles in Click programming are Qualifier limitations and Global Event limitations.
1. Frame events work better than Global Events. This has been the case since they were first introduced. But as every programmer knows, it's really annoying to have a huge game engine that must be copied to every frame whenever a change is made. Even if there were a button (or automatic option that is triggered at "compile time") to copy a group of events to all frames (or better, a subset of frames determined by the user), the power of MMF would be increased exponentially.
2. Anyone familiar with Object Oriented programming knows why we need Qualifiers; and most people can see the usefulness intuitively. With all the great upgrades to MMF, it's unfortunate that these haven't received more attention. I'm not just talking about using Qualifiers in Global Events, either. Trying to "pick" objects in conditions can be difficult or impossible. Try to make an action game with the following event:
Group.Bullets is overlapping Group.Players [and] Group.Bullets("Alterable Value A") == Group.Players("Alterable Value A") [then] Destroy Group.Bullets
It's been a while since I messed with them, but even this event would be problematic. Making a complex engine with multiple Qualifiers per condition is nearly impossible.
It's not necessarily a fundamental problem in the Click framework. Events like the above can be hacked by combining "pick a * at random" + fastloop the event a bunch of times, but that's obviously not a good solution. The "Pick objects with value ***" conditions are useful, but not powerful enough. The basic issue is that MMF needs, either in an extension (but preferably in the basic system), a simple + generic way to pick instances of objects. Qualifiers are a good start, but there is plenty of room for improvement.

Sorry for the rant; I've been a fan since KnP, and I appreciate all the hard work CT puts into Click products. This is just my soap box after years of using Click.