with active-on-active collision
FILE TO SHOWCASE
long story short collision is screwed
how has this not been fixed yet
Printable View
with active-on-active collision
FILE TO SHOWCASE
long story short collision is screwed
how has this not been fixed yet
Lots of bugs original to MMF2's release have not been fixed yet.
Don't hold your breath.
I think its more of the way MMF works and its object selection routines.
To work around this issue you could use a turn on a flag of the object when it collides with the other object and only move the instances of the object where the flag is on. Let me know if you need the example file.
but I am sure how to work around the issue wasn't the point of the thread but thought I would just mention that.
It's not at all an issue with the collisions, it's just the way the object selection works. Francois will probably explain why.Quote:
MMF2's Collision is obviously BROKEN
Personally, I dont call that a collision because it does not use the collide function AND as far as MMF2 cares, if one object is overlapping, they all stop. Try giving obejcts values and stuff...
Im no expert.
Replace the condition with "negated (object is overlapping backdrop)" and add a backdrop with obstacle selected.
negation is confusing because it seems to be too aggressive with its selection sometimes
basically it's acting like "if ANY object is not overlapping then move all of them" instead of "if THIS instance is not overlapping then move it"
the non-negated event behaves as the latter case which is more intuitive, so i don't know
I really hope for that to be fixed in MMF3 - I often had problems with that.
http://www.mediafire.com/download.php?jjuy52onxhm
Hopefully that will help...?
//edit//
Using your event with an obstacle backdrop in place of "active 2" does work. I assume that MMF2 prioritizes the behavior of an active object over the non-behavior of a backdrop... but I digress.
that's why I posted "with active-on-active collision".Quote:
Originally Posted by Pkeod
I know there are plenty of work-arounds but should there really be a need for that for something this basic?
This issue is a real pain and I don't see why it can't be solved
I have a a solution, but i don't know how to upload files yet since i'm new to the forums.
Here is what i did:
¬(Active) Flag 1 off=(Active) Y+3
¬(Active) Overlaps (Active 2)=(Active) Flag 1 on
Hope this helps.
All I did when I had this problem I think was add "if blah is visible". I think it works.
MechaBowser,
It's similar to the bug with object selecting and object creation in that people will say it's a feature instead of a bug.
If you have an event that is like "create object and then do something to it" but then reach the object limit, when the event fires and tries to create an object but fails instead of selecting the single object that was supposed to be created, MMF selects ALL objects and the event affects all of them. People say this is a feature and just how MMF works, but to me it's a bug, and should have had some code in place to prevent it from happening.
Okay why are these people saying it's just the way MMF2 works? THIS DID NOT HAPPEN IN BUILD 248
I know for a fact it did not happen, because patching MMF2 caused an event that used it and used to work NOT TO WORK.
This is a bug and it's annoying and I'd love to see it fixed soon.
dustingunn,
I'm using 248, and it still bugs out. Someone test with the retail version?
Installing 249 broke my game in only one way, and that way was that negated overlapping events no longer worked in any useful capacity. It had to be true for all objects or it worked for no objects.
This is a years old game and that code had always worked for it.
This is not a bug.
Your condition is "when the object does NOT collide with the background".
As soon as one of the objects collides with the background, the condition becomes false, and this is justified because on of the two objects of the kind IS colliding.
If the condition is false, then the action is not executed (which is normal) and both objects stop.
You should use a fast loop to make it work (I think)
So it's a feature that makes the condition (a much needed condition) nonfunctional? And I know it's a new thing.
From what I understand, it doesn't make it unfunctionnal, it makes it global to all objects.
If you need it to be specific to one object, you'll have to use loops, it's always been this way in MMF : if you only want to deal with one of many duplicates, you'll have to loop through them. I'm not suprised with this behaviour
What I always do is use fast loops in situations like this so that you can essentially do a foreach loop on the collection and test/action each individually.
Here's an example in case you haven't seen this before.
Would be nice if we could have some tools added to MMF2 to make doing this easier, as there's three events required.
EG: what we need is a condition that we can add to any event in which we pick an active object and MMF will do a fast loop going through all instances of that object.
How about it Yves/Francois?
* ForEach "Active" condition!
This would mean just one event and one condition to add to any events that you want to step through all instances to be able to treat them separately.
(note it would have to work like a fastloop in that if you have ForEach against an "Active" on more than one event, it would test all those events in the same ForEach loop, not run a seperate foreach loop for each event- too slow)
I kind of agree with Mecha, shouldn't "Object A is not overlapping Object B" pass for the Object As which aren't overlapping any Object Bs?
Or is the negate applied by MMF afterwards?
I'm pretty sure negating an overlap condition negates the result and not the collision check. Thus it will only work if no objects overlap.
AndyH, I know there are several workarounds for this, but that's not my point. "Object A not overlapping Object B" shouldn't be global on all objects like it is, and its a really annoying flaw, though that doesn't mean you can't work around it. My point is that you shouldn't have to.
Werbad, I remember you having problems with that in Box2D... :P
As I said, it would be nice if there were more possibilites in MMF3, including negation of the actual selection, event nesting etc.
Yes, the for each object loop is in the list of things to do.
I've noticed some conditions will return true for a selection of instances of an object while others will just return a global true/false and looking at this I wonder if it's been when I've been using the negate option?
I tried doing this:
1) Active and Background overlap collision
a) Create an active, and a large background object with obstacle flag on.
b) create an event where Active is overlapping backdrop --> Move Y pos of Active down
c) create an event where Active is Not overlapping backdrop --> Move X pos of Active across
When run above, the Active objects overlapping a backdrop move down those not overlapping move across. This works for each individual Active, all are moving as expected.
2) Active and Active2 overlap collision
a) Create two active objects, where the second is large to cover the screen and is a solid colour.
b) create an event where Active is overlapping Active2 --> Move Y pos of Active down
c) create an event where Active is Not overlapping Active2 --> Move X pos of Active across
When run above, the behaviour is different. First any objects overlapping will move down but those that are not overlapping stay still. Once ALL Actives are no longer overlapping Active2, all Active objects will start moving across including those that have been stationary.
It seems that Active1 overlaps Active2 conditions work differently to Active overlaps backdrop. The latter works as I think we would want it to. The former with collisions with actives does not.
It looks like Active1 overlaps Active2 will return TRUE if one or more Active1's overlaps Active2 but then will return the list of those objects that DO overlap, hence they move down.
Then the Active1 DOES NOT overlap Active2 will always return FALSE while one or more Active1's overlaps Active2, so these do not move across. Once all Active1's are no longer overlapping, this DOES NOT condition is true and all start to move across.
The same conditions for overlap collisions with backdrops return TRUE if one or more Actives overlaps a backdrop, and passes all instances of those objects to the actions.
However when negated the condition for overlap collisions with backdrops return TRUE if one or more Actives DOES NOT overlap a backdrop, and passes all instances of those objects to the actions.
So I believe MechaBowser is correct, the Active Overlaps Active condition does exhibit a bug or at the very least not the desired behaviour and not consistent with the same conditions with Active overlap Backdrops.
I've put an example file here.
I'm sorry, but that's what we have been discussing since the first page of this thread?
The point raised above is suggesting collisions are not working, which as said above is not the actual problem, collisions are working correctly. It's how the object selection works and the condition returning true or false.
While there are workarounds that will make this behave as we all expect it to, the example I've posted quite clearly demonstrates that overlap collisions between other actives and between backdrops give different results and that it's the backdrop collisions that are working as we expect it to.
The other difference with Active1 overlaps Active2 is that we would expect two lists of objects returned, Active1 and Active2's that mutually overlap with each other at least once. Active overlaps backdrops are a little simpler, but I'm guessing at how MMF works with this data internally.
Nope. I've asked around. No one remembers the negated overlapping events being useless before.Quote:
Originally Posted by Corentin
It works properly in MMF1.5...
It's not what I meant, sorry if I wasn't clear : What I meant is that in MMF, if you want to test a specific instance, you have to loop through them.Quote:
Originally Posted by dustingunn
I don't think it's useless either
Isn't using fastloops for everything overkill? Here's how to do it without fastloops using 3 events.
Then, of course, I agree with AndyH. The "overlapping with backdrop" and "overlapping with another object" conditions aren't really consistent in the way they work, and I'd prefer if the negated "overlapping with another object" worked the same way as for the background.
...but then again, this workaround is so simple that it doesn't matter. Almost all of the cases where I feel I'm using more events than I should have to are situations where I need "else", "for each" or sub-conditions, not when I need to negate an overlap condition.
That's a nice workaround Nifflas, although at the expense of an alterable variable or flag. Imagine having to detect overlap collisions with other actives and it starts getting a little more complicated tracking them all.
Would make it simpler for us if it was consistent with the way Overlap Backdrop works.
I spent all day fixing every event that had negated overlapping events when I updated to build 249. Maybe it's because the game was converted from MMF1.5 originally, but it's been in MMF2 format for a long time now.
Regardless of if build 248 was like that for everyone, it's still a flaw in MMF2's logic, and forces you to have 3 times as many events for what used to take only 1. Not to mention a wasted flag or value, and those still being limited for some reason, it becomes a nuisance.
You should fastloop instead.
Yea I'm having issues too. I've been on the same project for nearly 4 years. Before Build 249, it was fine. But many levels now that I have collision detection btw objects and overlapping won't work since i've updated to build 249. Before, It would work fine. So must be something with this build.
It's extremelly frustrating, as all these bugs are appearing in my game, that did not exist before.
If you have a file that works differently in buid 248 then build 249 please send it into Yves. 249 is still in beta so he can look into it.
The files are huge. I'll see if I can strip one down.
either way, if it's a flaw in the selection or collision, this is a serious bug and I bet many newcomers are confused by it!