I usually do hitboxes for active objects acting as backdrops, but I just noticed that regular collision detection on those hitboxes doesn't work during fastloops, i.e when checking for a collision between a detector(active) and a hitbox(active).
At the top of my events I have my actives set up to change animation direction to the hitbox one, and at the bottom to restore the animation direction. The fastloops being called do all take place during the hitbox animation direction, but collision detection with the actives register using the mask/restored animation direction, how come?
I believe this used to work earlier, am I wrong?
Does anyone have any clue on how to solve it without using invisble doubles for collision detection?
Ok, I made an example with the specific situation and problem, have a look and say what you think. Pixelthief gave a thorough explanation on the root of the problem, but I recall this working earlier. Opinions?
You're doing things backwards from how I was expecting. I always have the player's detector change, but the scenery stay the same, and that always works fine, which is why I know it can be done.
It makes me think that it must make a difference whether you test for A overlapping B, or B overlapping A, and that does seem to be the case (under normal circumstances, if A overlaps B, B must also overlap A).
In theory, you should be able to check if the Hitbox overlaps the Detector, rather than the other way around, but in your specific example that doesn't seem to ever detect an overlap - which is strange.
If we check for the HitBox overlapping the Player, it uses the correct direction.
If we check for the Player overlapping the HitBox, it uses the visible direction (so it changes depending on whether you pressed space).
Basically, MMF2 generates a collision mask just once every frame loop, and tests against that when looking at collisions for objects. The object being tested will use its 'current' collision mask, while it will be tested against an 'old' mask that hasn't been updated since the start of that eval loop. So you can test A against B if A changes, but not B against A