Collision lag bug!!!

[UltimateWalrus]

This is a problem that I know was present in MMF 1.5, and I was kind of hoping it would be fixed in MMF 2. Some people think that this is just a peculiarity in the way that MMF handles collisions; however, it seems completely illogical and can (and does) cause problems in larger-scale programs.

I know I'm not the only one who noticed this... I think I remember one other person complaining about it in MMF 1.5. It would be greatly appreciated if this could be fixed in the next patch. If you're afraid of breaking old MMF programs that only worked thanks to the bug, well... then perhaps you could add another Active Object condition, "Is Really Overlapping?"

[UltimateWalrus]

This is a problem that I know was present in MMF 1.5, and I was kind of hoping it would be fixed in MMF 2. Some people think that this is just a peculiarity in the way that MMF handles collisions; however, it seems completely illogical and can (and does) cause problems in larger-scale programs.

I know I'm not the only one who noticed this... I think I remember one other person complaining about it in MMF 1.5. It would be greatly appreciated if this could be fixed in the next patch. If you're afraid of breaking old MMF programs that only worked thanks to the bug, well... then perhaps you could add another Active Object condition, "Is Really Overlapping?"

[xerus]

I think its your order of events. Placing your event that is commented as 3.) at the end of the event editor seems to fix it?

[xerus]

I think its your order of events. Placing your event that is commented as 3.) at the end of the event editor seems to fix it?

[UltimateWalrus]

Yes, but that's not really the point :P
Think of the events in the event editor executing sequentially, one after the other, every cycle (theoretically, this is what is supposed to be happening). Now, let's walk through the events, one by one.

Cycle 1
-------
1.)"Active 2" is overlapping "Active" --> "Active": Set X position to X( "Active" )-32
.....In this first cycle, this event is untrue. Active 2 is not overlapping Active, so the event is not executed.
2.)Upon pressing "Space bar" --> "Active": Set X position to X( "Active" )+32
.....Let's assume that the user pressed the space bar. In this case, Active will be moved 32 pixels to the right, at which point it is overlapping Active 2.
3.)"Active 2" is overlapping "Active" --> "Active 2": Set X position to X( "Active 2" )+32
.....Because Active is now overlapping Active 2, Active 2 will be moved 32 pixels to the right. So far, so good.

Cycle 2
-------
4.)"Active 2" is overlapping "Active" --> "Active": Set X position to X( "Active" )-32
.....At this point, Active 2 has been moved off of Active. We KNOW that they are no longer overlapping. However, MMF still thinks that they are overlapping, and thus Active is pushed back 32 pixels to the left.


Of course in a small example like this one it is easy to reorganize it to get around the bug. But in a larger project with hundreds of events, when you are trying to detect collisions between moving objects, it is a bit more difficult to reorganize the entire program to get around the bug :\

[UltimateWalrus]

Yes, but that's not really the point :P
Think of the events in the event editor executing sequentially, one after the other, every cycle (theoretically, this is what is supposed to be happening). Now, let's walk through the events, one by one.

Cycle 1
-------
1.)"Active 2" is overlapping "Active" --> "Active": Set X position to X( "Active" )-32
.....In this first cycle, this event is untrue. Active 2 is not overlapping Active, so the event is not executed.
2.)Upon pressing "Space bar" --> "Active": Set X position to X( "Active" )+32
.....Let's assume that the user pressed the space bar. In this case, Active will be moved 32 pixels to the right, at which point it is overlapping Active 2.
3.)"Active 2" is overlapping "Active" --> "Active 2": Set X position to X( "Active 2" )+32
.....Because Active is now overlapping Active 2, Active 2 will be moved 32 pixels to the right. So far, so good.

Cycle 2
-------
4.)"Active 2" is overlapping "Active" --> "Active": Set X position to X( "Active" )-32
.....At this point, Active 2 has been moved off of Active. We KNOW that they are no longer overlapping. However, MMF still thinks that they are overlapping, and thus Active is pushed back 32 pixels to the left.


Of course in a small example like this one it is easy to reorganize it to get around the bug. But in a larger project with hundreds of events, when you are trying to detect collisions between moving objects, it is a bit more difficult to reorganize the entire program to get around the bug :\

[UltimateWalrus]

That's a good idea, but I still don't think that's what's going on. Even if the spacebar was at the top of the event list, only one of the overlapping events should ever execute. Whether Active is moved to the left, or Active 2 is moved to the right, afterwards they should never be overlapping. However, you can clearly see that both events execute when the objects overlap. I'm convinced that this is a bug...

[UltimateWalrus]

That's a good idea, but I still don't think that's what's going on. Even if the spacebar was at the top of the event list, only one of the overlapping events should ever execute. Whether Active is moved to the left, or Active 2 is moved to the right, afterwards they should never be overlapping. However, you can clearly see that both events execute when the objects overlap. I'm convinced that this is a bug...

[Pixalatio]

most interestingly if you place the event labelled three as the second last event the problem is still there... how odd

[Pixalatio]

most interestingly if you place the event labelled three as the second last event the problem is still there... how odd