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?
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!Originally Posted by ProdigyX
Second that big-time!
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...
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.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...
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.
Posting Permissions
Reply With Quote
