Objects Overlapping with same Qualifier bug?

[N64Mario]

Lets say you have 2 objects. Both of these 2 objects have qualifier of group.1. 1st object is a moving platform. 2nd object is a floor/backdrop object (necessary for things like animation, which normal backdrops can't do).

If the moving platform overlaps 2nd object, and I have the event '[platform]' overlaps [group.1] = destroy [platform], it doesn't do anything to the platform.

Is this because the platform has the same qualifier as the floor object, so it ignores any actions to the platform? Although I would imagine the collisions would still work despite what qualifiers it had, even if both objects had the same qualifier.

Currently using MMF2 v248

[Retriever2]

There are problems with qualifiers, but I don't know if this is the same problem you're having or not. However it's something I encountered in another person's project and if you check the logic you'll see that something is clearly incorrect with qualifier object selection.

http://hocuspocus.taloncrossing.com/rii/astrobug.png

[N64Mario]

There are problems with qualifiers, but I don't know if this is the same problem you're having or not. However it's something I encountered in another person's project and if you check the logic you'll see that something is clearly incorrect with qualifier object selection.

http://hocuspocus.taloncrossing.com/rii/astrobug.png

I don't think that image is going to help me much unless I know what the names of these are, and/or what the actions inside are doing. Let alone if its the same problem I'm having or not. X_X

[Retriever2]

I wasn't posting a solution, nor do I know if it's the same problem. I'm just posting it as an example that there are bugs with qualifiers and overlap tests.

[Pixelthief]

Yeah that screenshot's last event does not even make sense if the qualifiers are just pointers to objects on the event list, which would explain why the 3rd event would fail (it would first descope all objects not overlapping, then, using the remaining scope of objects, it would descope all objects which *are* overlapping, which is logically always every one of them, so the condition will always return false).

But if thats how it works, then I don't get how the last one can fail. Because the first line would only remove the non-overlapping houses from the scope, so shouldn't this same scope be preserved to the next line, which would then test the exact same objects and return true? (if it was working).


Theres always been something fishy about qualifiers and I've avoided them when possible, but I've never deduced what the exact problem is. It seems like some discrepency in how the Object Scope List descopes objects on conditions referencing that qualifier. Or perhaps its a problem with how qualified units are scoped after members of their set are descoped. Either way, theres definitely some issue with them that makes them go all crazy.

Qualifiers can work OK if you do simplistic events with them from what I've noticed though. I try never to use more than one condition that scopes any of my qualified objects in any event usin em.

[N64Mario]

Oh okay, sorry....

On an unrelated note... No one's ever answered, or posted to my last topic question either... I wonder if its just lack of knowledge, or no solutions, or what. X_X

[Retriever2]

But if thats how it works, then I don't get how the last one can fail. Because the first line would only remove the non-overlapping houses from the scope, so shouldn't this same scope be preserved to the next line, which would then test the exact same objects and return true? (if it was working).

The point exactly is that if events 1 and 2 pass, but event 3 fails, then logically event 5 must pass. You could also say that if event 1 passes and event 4 fails, then again event 5 must logically pass. A condition and its negation should partition the entire selection space into two disjoint spaces without leaving any gaps.

[Pixelthief]

In theory, but not in implementation.
Consider the three events:

Event A:
+Player is overlapping Bad Guy
=True

Event B:
+Player is overlapping Bad Guy
+Player is overlapping Powerup
=True

Event C:
+Player is overlapping Bad Guy
+Player is *NOT* overlapping Powerup
=True


Say event A resolves "True".
Logically, events B & C should partition the selection space into those two disjoint spaces. However, an implementation quickly shows you this is not the case. Why?

Collision events, when "negated", do not actually create an inverse of the condition. In the case that all powerups have been destroyed, both events B & C will return false. This is because a collision check will always fail if it references an object type that has 0 objects in the object scope list... even if its asking if its not overlapping the object. Presumably, this is because it is attempting to run a collision detection on a non-existent class of objects, and thus returns "False"


My guess is there is some trick to how it is handling the object scope list that is causing the "Is not overlapping" even to return false even when it is logically true, whether or not the object really exists, due to the interference of qualifiers.

[Retriever2]

Personally I consider it a bug and another failure of the event/condition system to actually work in a logical and consistent manner. The fact that an object, e.g. "powerup" does not exist, does not change the fact that "player" is not overlapping it.

I also have to partially retract my statement about the sets being disjoint when dealing with multiple objects, as they could both be true by applying to different objects. However they should not both be false