|
Posted By
|
Message
|
Spitznagl
Cabinetmaker
Registered
06/12/2008
Points
4260
   
|
7th April, 2009 at 06:50:13 -
I just started trying to use qualifiers today, and I already hit a wall. As it is, blocks are supposed to slide until they hit a backdrop or another block(Group.0). they correctly stop when they hit a backdrop, but with other blocks, they always get 1 pixel too far.
I've tried a bunch of things, and I found that the underlined condition is the problem for sure.
-1-
+ Horiz("Group.0") <> 0
= Xposition of Group.0 to (X Group.0 + Horiz("Group.0"))
-2-
+ Group.0 is overlapping a backdrop
or logical
+ Group.0 is overlapping Group.0
= Xposition of Group.0 to (X Group.0 - Horiz("Group.0"))
= Set Horiz("Group.0") to 0
Could somebody quickly explain what MMF2 is thinking.
...
|
UrbanMonk
BRING BACK MITCH
Registered
07/07/2008
Points
49567
      
|
7th April, 2009 at 06:55:42 -
you can try making the bit after the "or" a separate condition.
It may just be the fact that mmf is only applying the action to one active at a time, but i doubt it.
I'd really need to play around with your source to be sure.
n/a
|
Spitznagl
Cabinetmaker
Registered
06/12/2008
Points
4260
|
7th April, 2009 at 07:50:09 -
No, that's not it.
But if I replace that underlined condition with different events:
Cube1 overlapps Cube 2 > apply same actions to Cube1
Cube2 overlapps Cube 1 > apply same actions to Cube2
And so on for every cube combination, it works fine.
Group.0 overlapps backdrop work though
It's just the freakin Group.0 overlapps Group.0
...
|
Klikmaster
Master of all things Klik
Registered
08/07/2002
Points
2599
 
|
7th April, 2009 at 07:50:52 -
You can achieve pixel perfect movements using fastloops, have a look for some articles on the subject if you aren't sure.
n/a
|
Spitznagl
Cabinetmaker
Registered
06/12/2008
Points
4260
|
7th April, 2009 at 08:07:27 -
That's not it to.
I should have mentionned that my horiz value can be either 1 or -1, so they move at one pixel per frame and I don't need a fastloop. In the order the events are, positions are already final when the graphics are updated.
My problem really is caused because of that group overlapps group condition.
 Edited by Spitznagl
...
|
aphant
Registered
18/05/2008
Points
1242
|
7th April, 2009 at 09:00:58 -
I'm just guessing here:
The objects aren't checked for overlap until they actually overlap.
|
Sketchy
Cornwall UK
Registered
06/11/2004
Points
1970
|
7th April, 2009 at 12:09:06 -
-1-
+ Horiz("Group.0") <> 0
= Xposition of Group.0 to (X Group.0 + Horiz("Group.0"))
-2-
+ Group.0 is overlapping Group.0
= Xposition of Group.0 to (X Group.0 - (Horiz("Group.0") * 2))
= Set Horiz("Group.0") to 0
-3-
+ Group.0 is overlapping a backdrop
= Xposition of Group.0 to (X Group.0 - Horiz("Group.0"))
= Set Horiz("Group.0") to 0
n/a
|
Spitznagl
Cabinetmaker
Registered
06/12/2008
Points
4260
|
7th April, 2009 at 20:04:50 -
I just quickly put something up for anyone who'd like to check it.
Here: http://www.mediafire.com/?sharekey=6af2cfa8c3b8c970931c7453395df025e04e75f6e8ebb871
I also included a disabled working example, but it doesn't use qualifiers for that problematic condition. It really is basic stuff, but the damn qualifiers just messes everything up.
Sketchy: With your technique, blocks end up in the right place, but only after a second run of all the events. So you get to see the sliding block guetting knocked out of the other one.
...
|
|
|
|
Advertisement
Post Reply