Qualifiers in Behavior events

[deadeye]

I know that qualifiers are no longer allowed to be used in behavioral events. I've read the threads dealing with this here on the forum. I'm posting this thread to make a case for allowing them.

Reasons against allowing qualifiers in behaviors:
1. The program may become "unstable" if an action being performed on the qualifier is incompatible with the object type that the qualifier is assigned to.

Reasons for allowing qualifiers in behaviors:
1. It allows for better organization of code into logical areas. You don't need to clutter up your frame events with code that isn't necessary to run the frame. You can store all events that pertain to an object in it's behavior.
2. It allows for "drag-and-drop" objects. Since everything that runs the object is located in the object itself, you can easily copy and paste it in it's entirety into a new frame.
3. Problems arising from incorrect use of qualifiers are a user error, not a program error. The exclusion of qualifiers in behaviors should not be made simply because the user might make an error in using them.

I am making a game in which I check my object for collisions against qualifiers. In my code, I need the reference to the qualifier to do this. I'm not taking any action against the qualifier, I'm simply checking to see whether it exists. I can't do this in the behaviors because I can't import a qualifier to check for that collision.

Perhaps you may consider allowing qualifiers in behaviors for reference only, and have the entire action column disabled for any qualifiers. That way you can check for the presence of a qualifier, but not perform any action on it. That way, actions performed on qualifiers could still only be done in the frame events or global events.

Anyway, that's my case. I hope someone takes it under consideration.

[UltimateWalrus]

Actually, you can do this, although you have to go way out of your way to do it. What I did is this:

1.) Go into MMF 1.5.
2.) Create an active object with qualifier "0" (or whatever qualifier it is you want to use.
3.) Go into the event editor, and create the event: "Active" is overlapping "Group.0"
4.) Cut this event and paste it in the behavior of "Active".
5.) Save this file as a *.cca.
6.) Close down MMF1.5 and open up MMF2.
7.) Import the *.cca file.
8.) Your event will now be in the behavior of the object. You can cut and paste this event into any other behavior of an object in MMF2. Once this is done, you can use the "Group.0" qualifier in any other events in that behavior.

I never experience any added "instability" from doing this, although I vaguely remember that using the events in a frame that has no objects with that qualifier can cause problems. In that case you just need a "placeholder" object that sits offscreen and holds every qualifier you plan on using (it can destroy at the start of frame).

If you don't have MMF1.5 I might be able to provide a *.cca for you. It really is something that should be easy to do, and it's very annoying that I have to go through an 8-step process to do something I should be able to do in one step.

Perhaps there's a reason for disallowing this (well, attempting to anyway). I don't see any good reason though, is it possible a Clickteam staff member could explain it?

[deadeye]

Yeah, I thought about doing that. I transfered my program from 1.5 to 2, and the qualifiers in the behavior events came along with the objects just fine. It's just a pain to go through all of that just to get them into MMF2.

And I've never had any problem with it, either. My program runs fine with qualifiers in the behaviors. But then again, I know what each of my qualifiers is doing and I don't mix them up, or have events in behaviors that refer to qualifiers that don't exist.

[waffles]

This has been discussed before. Do a search for "qualifiers" and you will find the threads. I think Yves mentioned the reason for not allowing them in one of those threads.

[MechatheSlag]

[]I think Francois has disabled qualifiers in global events because it was making the program unstable (it was possible in MMF 1.5 due to a bug, they should have been disabled), but I'm not 100% sure. I'll make sure he answers this thread when he's back from the show.

Yves.[/]
This is what was said <img src="/center/images/graemlins/smile.gif" alt="" />

[UltimateWalrus]

That's the part I don't get. What's "unstable?" Seems to work fine to me. You just get that weird ugly broken circle icon, but it's usually nothing to worry about.

[xyzzy]

I think they SHOULD be reenabled in MMF2, but if MMF2 detects you trying to use them, a box pops up saying something like:

"blah blah this is a bug blah blah Clickteam is not responsible for damages caused to your application if you continue."

There would be the OK and Cancel buttons, obviously, and probably a "Do not show this message again" checkbox.

[Francois]

Yes, it is impossible, and I have not yet found a way to make it possible. The problem occurs when the qualifiers point to extension objects.
When I find a way, I'll implement it.

[Nifflas]

If you use the same qualifier for two different object types, they are named example bonus.active and bonus.string

What if you always force the qualifiers to be named like that even if there's just one object of a qualifier in a frame? If you do that, then it would not crash having the same qualifier of another object type in a frame, since it would clearly refer to for example "bonus.active" - thus only active objects of the bonus qualifier are affected.

[Bovril]

Could you perhapse enable it, but with a big warning box? It's very useful to be able to use qualifiers in behaviours, and if the only problem is when extensions are involved, people who know what they're doing should be able to use them safely.
It seems that there are a lot of people that keep trying to work around the restrictions no matter how many are added, so why not turn the restrictions into warnings?