I have the exact same problem. Anyone experienced with this extension that can explain what's going on?
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.
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.
-
-
Bump. I can't figure this feature out either. From my testing, it doesn't do what the name implies. It just seems to give me random pairs of the two selected object types.
-
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 realize now that you don't even need the ForEach-loop. It is only necessary if you intend to have more than 1 object at a time with Flag 1 on.
Please login to see this link.
-
I guess it goes crazy because of the redirect. Your browser doesn't always know best
Mfa repository? Never used it, but I'll give it a try:
Please login to see this link. -
I fiddled around a bit with this.
Please login to see this link.
Drag and drop the objects. The overlay should be working as you wanted it to.
-
You will need:
1) A value or flag indicating whether or not a chest holds a treasure
2) A fast loop*At start of frame
-> Start loop "populateChests" 25 times
*On loop populateChests
+Chests flag 0 off (does not contain treasure)
+Pick chest at random
->Set Flag 0 on -
How's work progressing on the next beta?
-
Did you disable blast again in this release? It was working fine in beta #4
Edit: Perhaps not. I must have screwed up somewhere.
-
You are doing fantastic job Jamie. Lacewing has sparked my MMF2-urges once again. Keep up the good work and keep the updates coming!
-
Server crashes when a client changes name to an empty string.
-
I unchecked Compress Runtime, which was indeed enabled, but the error persists.
-
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.
-
When I build my application as stand-alone and run it, it crashes immediately after it connects. I have disabled all my other events and only have the "Start of frame: Connect to xxx" event left. The application connects without a problem and does not crash when I run it from MMF2.
-
Is blasting disabled in this beta? If it's not disabled, is it bugged? Because I can't get it to work at all.
-
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.