The overlapping test seems to be false when player press a button and if one of the two object tested has been destroyed...
Try the example...







The overlapping test seems to be false when player press a button and if one of the two object tested has been destroyed...
Try the example...

I don't really see anything when I run the application ecept a terqoise square that doesn't move... and what do you have fire 4 set to?
Edit: Nevermind, wierd...
Working as fast as I can on Fusion 3
I found out (after several years of clicking) that at least one duplicate of each object you're testing for collisions/overlaps must exist in the frame.
Otherwise the events involving those objects (collision/overlapping conditions) seem to be ignored by MMF.







But what is strange here is that if we test overlapping without "player press button 4", it works well...

This does not seem to happen in TGF2... so maybe it's a glitch in MMF2...
Working as fast as I can on Fusion 3
Yes you're right Sphax.
The "isn't overlapping" condition is always TRUE when one of the actives is destroyed, whether they're overlapping or not at startup. Seems somewhat logical, doesn't it?
But when the objects overlap at startup, the "is overlapping" condition stays TRUE even after one of the actives has been destroyed.
This might have something to do with the engine's event ordering. I don't really know.
Anyway to avoid such issues, a duplicate of the objects involved in collisions and overlaps testing should always exist somewhere in the frame.







But it could be difficult to keep one instance of each object involved in htis test...
It's bug which should be corrected in the next build.![]()

Agreed, but just make separate copys of the objects and put them in cells tha they cannot breack out of. (outside of the frame)Originally Posted by Sphax
Working as fast as I can on Fusion 3



Well, the condition is always FALSE regardless of the NEGATE, if one the second object is not defined. This is a bug, and it will be corrected for the next build.
If you remove the press fire condition it works as the object is destroyed in the start of frame, but not actually destroyed (just marked destroyed) in the list when the collision is called for the first time. So it does not go by the faulty lines of the routine.







I think you should correct it since, it's a false positive test.
Thanks Francois to look at it.![]()