Posts by asker

Welcome to our brand new Clickteam Community Hub! We hope you will enjoy using the new features, which we will be further expanding in the coming months.

A few features including Passport are unavailable initially whilst we monitor stability of the new platform, we hope to bring these online very soon. Small issues will crop up following the import from our old system, including some message formatting, translation accuracy and other things.

Thank you for your patience whilst we've worked on this and we look forward to more exciting community developments soon!

Clickteam.

    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.


    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.

    I think it's because the object is not moving, and there are no conditions to check the collision for the RED object.

    Please login to see this link.


    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:
    Please login to see this attachment.
    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.

    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".

    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.

    Please login to see this attachment.

    I'm sorry to bring this up again, but the stand-alone application still crashes in Beta #4, and it runs smoothly from MMF2. I even tried overwriting the Runtime-mfx with the Extension-mfx in case that was still a problem but I get the same error.

    I solved it using a Overlay Redux to paste into instead. I've noticed a few other problems with HWA as well. XOR doesn't work as it should, and Overlay Redux-objects positioned at (0, 0) aren't rendered. I'm sure more things will pop-up as I go along porting my game to MMF2-HWA.