User Tag List

Results 1 to 9 of 9

Thread: Simple Fast loop and Collision not working as expected

  1. #1
    Clicker Multimedia Fusion 2

    Join Date
    Jun 2008
    Posts
    20
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Simple Fast loop and Collision not working as expected

    I found a weird behavior when working with fast loops and collisions that I've managed to isolate to a simple demo. The collision only works depending on the order of the objects in the event. Download my demo and press Space. I expect both objects to be destroyed. The events should be simple enough to follow.

    I like having as good an understanding as possible of how the events in MMF work. This is certainly a case where I want to know why this behaves as it does.

    testcase.mfa

  2. #2
    Clicker Fusion 2.5 (Steam)Fusion 2.5 Developer (Steam)Android Export Module (Steam)HTML5 Export Module (Steam)iOS Export Module (Steam)Universal Windows Platform Export Module (Steam)
    anatol's Avatar
    Join Date
    Jun 2016
    Posts
    116
    Mentioned
    4 Post(s)
    Tagged
    0 Thread(s)
    That's because you're moving a green object. And you need to check this object for collision

  3. #3
    Clicker Multimedia Fusion 2

    Join Date
    Jun 2008
    Posts
    20
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by anatol View Post
    That's because you're moving a green object. And you need to check this object for collision
    Why, though? I want to understand how this works under the hood. Intuitively, if Active1 collides with Active2, then the other way around is surely the case? What if in my game I'm not certain whether Active 1 or Active 2 is going to move. It's not good enough just leaving it up to chance.

    You have to agree that it's counter-intuitive. Regardless of which object moved, Active2 still collided with Active1. Also, the overlap-event should trigger. Active2 clearly overlapping Active1.

    I want more than just "It's like that because it is like that".

  4. #4
    Clicker Fusion 2.5 (Steam)Fusion 2.5 Developer (Steam)Android Export Module (Steam)HTML5 Export Module (Steam)iOS Export Module (Steam)Universal Windows Platform Export Module (Steam)
    anatol's Avatar
    Join Date
    Jun 2016
    Posts
    116
    Mentioned
    4 Post(s)
    Tagged
    0 Thread(s)
    I think it's because the object is not moving, and there are no conditions to check the collision for the RED object.

    http://www.diybandits.com.au/MMF/art...jectscope.html

  5. #5
    Clicker Multimedia Fusion 2

    Join Date
    Jun 2008
    Posts
    20
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by anatol View Post
    I think it's because the object is not moving, and there are no conditions to check the collision for the RED object.

    http://www.diybandits.com.au/MMF/art...jectscope.html
    You're saying it like it's something completely obvious. In my head, the definition of a collision is: "These two objects wasn't in contact the previous frame, but now are".

    Can you point to where this is defined as the intended behavior? Like a documentation, or something, that state that a collision is defined as the first object having to move. It seems to me like a unintended effect of some collision optimization done under the hood.

    Regarding your link, this has nothing to do with scoping. I know the resulting scope of the collision event will be different depending on the order, but the event itself should behave the same. If I were to add additional events, the scope would have an impact.
    One interesting thing your link tells me though is:
    exception.png
    Which is clearly not the case in my example.


    Edit:
    Also, by your logic, the collision should not evaluate to true outside the loop either, since the red object never moved. But it does, and both objects are destroyed.

  6. #6
    Clicker Fusion 2.5 DeveloperFusion 2.5+ DLCAndroid Export ModuleHTML5 Export ModuleiOS Export ModuleSWF Export ModuleXNA Export ModuleUnicode Add-on
    mobichan's Avatar
    Join Date
    Oct 2007
    Location
    Buffalo, NY
    Posts
    3,248
    Mentioned
    25 Post(s)
    Tagged
    0 Thread(s)
    I believe Anatol is correct. Fusion is doing overlap checks when the first object in the argument (A is overlapping B) has a position change. If the first object in the argument has not moved, then Fusion essentially ignores it to save processing time. This is generally why you have unique code for objects to test against collision surfaces or other objects. One line won't be a catch all for all collision cases. One solution for this would be to have a OR(logical) condition here:

    * On loop "m"
    + Active is overlapping Active 2
    OR (logical)
    * On loop "m"
    + Active 2 is overlapping Active
    Active : Destroy
    Active 2 : Destroy

    This will handle both situations.

  7. #7
    Clicker Fusion 2.5 DeveloperFusion 2.5+ DLCAndroid Export ModuleMac Export Module
    dsilvers's Avatar
    Join Date
    Jun 2008
    Location
    Boston, MA
    Posts
    493
    Mentioned
    9 Post(s)
    Tagged
    0 Thread(s)
    The "Collision" event is immediate, much like a fast loop. Conditionals under it are reliant on it being the only top-level conditional, and will trigger as soon as it happens. This goes for any immediate conditional (displayed in green) such as On Collision, On Fast Loop, on mouse click, etc. The "overlap" event happens whenever it's true, regardless of how long it's been true. So in your case, if we Deactivate line 6, and hit space, first the green diamond will move 230 pixels to the right. Because this immediate conditional is true, but the "overlap" version of it is not, the green diamond moves to the red diamond and does nothing else. Upon hitting space again, because the overlap conditional is true, both objects get destroyed, as you have specified.

    Why line 4 does what it does versus line 8 is because of object referencing. Because the initial "Loop M" makes a reference to the green diamond, and because Fast Loops execute before anything else in an individual frame (out of 60 per second), the green diamond is then treated as the A object, while the red diamond is treated as the B object. Therefore, anything that is true specifically for the green diamond will execute while the loop is active. If you want to see this in action, switch the object references around. Make the red diamond move left on the loop, and look for the red object A colliding with the green object B. Since overlaps are still one-directional, if on the fast loop itself, if the A object is not overlapping the B object, they will not get destroyed. If you want overlaps to be two-directional, you'll need both overlap conditions to be activated.

  8. #8
    Clicker Multimedia Fusion 2

    Join Date
    Jun 2008
    Posts
    20
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by dsilvers View Post
    Why line 4 does what it does versus line 8 is because of object referencing. Because the initial "Loop M" makes a reference to the green diamond [...]
    This is not true. Loops don't remember references or scopes between events (If they do, I'd like to see a simple example of that). If you want to see what I mean, add an "On Loop M: RED: Set Flag 0 On" above the first loop event in my example. The red diamond should now be referenced, yes? This will not make a difference.

  9. #9
    Clicker Multimedia Fusion 2

    Join Date
    Jun 2008
    Posts
    20
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by mobichan View Post
    Fusion is doing overlap checks when the first object in the argument (A is overlapping B) has a position change. If the first object in the argument has not moved, then Fusion essentially ignores it to save processing time.
    As long as we're inside the loop, this seems to be the case. Once we pop out of the loop, they collide fine even without Red moving.

    My guess is the collision quadtree that MMF maintains won't get updated inside a loop, but they've implemented a specific update for the Collide event for object on the left side. But this is only speculation, but the kind of in-depth understanding I want to have. If this is the case, adding an update for the object on the right side should be trivial. But maybe deemed too performance heavy? It would be nice, if only to have the event behave the same inside and outside of a loop.

Similar Threads

  1. Fast Loop Not Stopping As Expected
    By joshlindsey1 in forum Fusion 2.5
    Replies: 12
    Last Post: 10th September 2017, 09:25 PM
  2. Using a fast loop for collision detection
    By Jinxtengu in forum Fusion 2.5
    Replies: 4
    Last Post: 3rd February 2017, 11:59 AM
  3. Fast loop suddenly stopped working
    By Zvoc47 in forum Fusion 2.5
    Replies: 1
    Last Post: 1st November 2016, 09:37 PM
  4. Replies: 3
    Last Post: 8th April 2016, 08:11 PM

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •