Does anybody have a guide or know what each of the qualifer objects in MMF2 mean? I figured out a couple of obvious ones by myself like "breakable", but it would be cool to have a definitive guide or something. Can someone help me out?
Printable View
Does anybody have a guide or know what each of the qualifer objects in MMF2 mean? I figured out a couple of obvious ones by myself like "breakable", but it would be cool to have a definitive guide or something. Can someone help me out?
Each qualifer does nothing its own. There are merely things into which you can group objects.
So for example, putting a tree into the "Obstacle" qualifier or the "Breakable" qualifier or the "Generic 0" qualifier does nothingers.
Qualifiers offer no extension of code. There are merely there to group large amounts of objects. Think of it as giving each object a type. The tree is a plant and the dog is an animal. Without other code, these types are useless.
Yeah there is no special logic attached to any of the qualifiers, they are simply names that have been chosen out of a hat to be more useful to developers, since due to a restriction qualifiers could not be renamed- CT took suggestions to fill out the qualifiers with as many disparate ideas to try to have helpful ones instead.
It *would* be helpful, however, if someone could ever catalogue all the esoteric scoping issues with qualifiers. Qualifiers can do some pretty nonobvious things when using them in conditions in the event editor, in terms of what objects it selects, like letting you select objects from one qualifier and still scope them if you compare another qualifier
Good explanations, thanks!Quote:
Originally Posted by ProdigyX
Second that big-time!Quote:
Originally Posted by Pixelthief
They seem a little unstable to me at times, with similar events creating very different results - would be nice to know exactly what happens, and how to get the exact result I want.
From reading the one page PDF in the manual, here is what I get about Qualifiers:
It's like you can create Functions/"lines of code" for use with something you might have lots of, or lots of instances of.
So. instead of writing the same behavior/function over and over again for each instance of something, you use a "qualifier".
That's what I get out of it, but what I just wrote just seems like Behaviors.
So, for me, I'm confused... :o
It's just an easy way to group more than one object together. So instead of writing conditions/actions for each individual object you can do it in less events by referencing the qualifier instead.
That's correct - but certain things behave in a strange way when you use them. I.e. working one minute, not working the next. It really does throw up some curve balls.Quote:
Originally Posted by OldSchool80s
There is a logic to how qualifiers work that you can learn. I used to use them all the time, but nowadays I almost never do since the can't be used in behaviours and global events, and I make everything global now to save having to go around pasting last minute changes into hundreds of frames.
Qualifiers indeed were more useful before behaviours were added.
But even today you could do, for example, lets say you have multiple types of enemy and you want to count up how many enemies there are left, you could use a qualifier for that. Sure, you can just add up Number of Enemy 1 + Number of Enemy 2 + Number of Enemy 3 and so-on, but every time you add a new type of enemy you would have to modify this line, whilst with a qualifier it'd be a simple matter of adding each new enemy type to a qualifier.
As I said, I try not to use them because I try to put everything not specific to the current level/frame in behaviours and global events, but there are occasions where I wish I could use them.
Ok, well it makes more sense knowing that behaviors came (were added) after qualifiers, as my thinking (being new to MMF), was that they were in there at the same time (release date .. More or less)...
So it makes more sense that it's (almost) like behaviors replaces them.
I too agree that the global idea makes a lot of sense. Not only for original coding, but for having to go back in the future.
* I believe in efficient coding, but sometimes the time it takes to create the efficiency, it's not worth the few micro-seconds you shave off. Now, if you are coding a piece of medical equipment, I'd hope you'd use machine code and not an interpreted language. :)
I've been into Object-Oriented Programming lately as well so the behaviours method just makes more sense to me than scripting the whole thing in the frame anyways. :-)
Of course, a one-frame game/app can be done quicker with the old style, but behaviours also have the advantage of simple copy/pasting, importing and dragging between different projects, which is always nice.
on the subject of Qualifiers... I've got a bit of an issue.
forgive the Pseudo code While/Wend to follow:
WHILE Group.Good is overlapping Group.Friend and Alterable Value A("Group.Good") = 0
Set Alterable Value A("Group.Good") = Alterable Value A("Group.Friend)
WEND
I can't get this to work and it's driving me nuts. I'm sure there's an easier way but i can't seem to find a way to pull it off.
The point is, when a Tile (friend) is dropped on another active (good) I need to pass the value of the Friend to the Good.
I have to use qualifiers because there are 81 GOOD and 81 Friends so the combinations are horrific without qualifiers. :)
Yes this can raise slight issues. The best way here is to loop through all the objects on this condition with a unique ID. If you're using Fusion 2.5, you can use the built-in ForEach Loops, highly optimised and fast!