|
Posted By
|
Message
|
Rick Shaw
Registered
30/04/2008
Points
158
|
13th September, 2009 at 15:08:01 -
Here's what I'm trying to do in my isometric game:
On a fastloop, all of my wall objects change direction to left. This is the "footprint" direction, the animation frame is smaller and basically indicates the ground that the wall covers.
Within this loop, I start a sub-loop that loops through all the humanoid characters, and checks if their detector object overlaps the wall's footprint. Depending on whether it does or not, certain things happen.
Then, back in the original loop, the walls are set back to the default direction. Thus, it all happens between screen refreshes and you never see the wall "footprint".
The problem is that this doesn't work as it's supposed to. Even though the collision detection should be occurring when the wall is in footprint mode, a collision is detected when the detector overlaps any of the default animation, not just the footprint.
I think this must have something to do with how MMF does collision detection and animation changes, just like how it only deletes destroyed objects at the end of every main program loop, not on the event. I know I've heard of people using techniques similar to this in MMF, I was wondering if anyone had any input. I think it should be possible to do this, in principle.
n/a
|
Spitznagl
Cabinetmaker
Registered
06/12/2008
Points
4260
   
|
13th September, 2009 at 15:27:52 -
Uh?
I just made a test, and MMF does refresh the image before it checks for collision.
I say, check your events order to make sure the direction is changed to "footprint" in time.
...
|
Rick Shaw
Registered
30/04/2008
Points
158
|
13th September, 2009 at 17:24:34 -
Yeah, I've been up and down the ordering many times, I don't see a problem with it. Here's exactly how it goes:
1. number of humanoids > 0
start loop "humanoid" 1 time
2. on loop "humanoid"
bring group humanoids to back
set group walls direction left (footprint direction)
3. on loop "humanoid"
start loop "humanoid_subloop1"; number of times = number of humanoids
4. on loop "humanoid_subloop1", select the indexed detector, detector overlapping wall?
move indexed humanoid in front of wall
5. on loop "humanoid"
set group walls direction right
Notice how I even tried setting the direction in a separate rule before starting the loop. This excludes some of the stuff like positioning the detector.
I added a debug string to see when the program enters each loop and it seems to also behave properly.
n/a
|
Rick Shaw
Registered
30/04/2008
Points
158
|
13th September, 2009 at 17:26:26 -
Futhermore, if I remove the final rule from loop "humanoid" that sets the walls back to the normal direction, the collision detection behaves properly.
n/a
|
MrMcFlurry
Registered
03/08/2009
Points
89
|
14th September, 2009 at 20:04:05 -
try taking the direction changes out of the loop
like
set direction left
start loop
set direction right
instead of needlessly swapping multiple times in the loop, might solve the bugginess
n/a
|
Klikmaster
Master of all things Klik
Registered
08/07/2002
Points
2599
 
|
14th September, 2009 at 22:54:49 -
Are you using "direction > set direction"? because that doesn't change the animation direction instantly. What you want to use is "Animation > change > direction of animation" 
 Edited by Klikmaster
n/a
|
Rick Shaw
Registered
30/04/2008
Points
158
|
15th September, 2009 at 17:05:27 -
thanks for the suggestions everyone. I tried "change direction of animation" as well as taking the direction changes out of the loop, neither worked. I also removed the loop-within-a-loop, there's no reason to keep that structure after I moved some of the events around.
Something really strange is going on, and now it's behaving extremely buggy. Sometimes I see the walls flicker, the detector objects aren't acting right, and it crashes a lot!
I must be doing something extemely wrong, but I know klik & MMF really well and can't see a problem with any of this.
Back to the drawing board...
n/a
|
MrMcFlurry
Registered
03/08/2009
Points
89
|
15th September, 2009 at 17:20:00 -
can you upload an example? Might help others diagnose the problem.Throw some comments at the difficult spots.
n/a
|
Rick Shaw
Registered
30/04/2008
Points
158
|
15th September, 2009 at 21:05:33 -
At this point my plan is to entirely scrap the ordering code and start over from scratch. I might work up an example (other people might get something out of analyzing this) but this is a large and complex engine so I'd have to cut it down. Maybe when I get home from work.
Anyway, thanks everyone for your suggestions. This doesn't seem to be a run-of-the-mill bug.
n/a
|
Don Luciano
Heavy combat pancake
Registered
25/10/2006
Points
380
|
16th September, 2009 at 12:21:03 -
I have some parts of the code with loop in a loop and it works perfectly, but you must beware of how you are using the condition, if you are comparing x pos of array be sure not to change in the actions the position of x array by just writing to different x pos.
Also make sure if you have a large frame, that the objects you are testing or and the object with whom you are testing have runtime options:
Inactivate when to far: no
Code me a sausage!
|
Sketchy
Cornwall UK
Registered
06/11/2004
Points
1971
|
16th September, 2009 at 12:45:13 -
Originally Posted by KlikmasterAre you using "direction > set direction"? because that doesn't change the animation direction instantly. What you want to use is "Animation > change > direction of animation"
 Noone ever told me that before.
I think you may have just solved a problem I've been having with my detector-less Sokoban game...
Thanks
n/a
|
bigredron
Registered
07/04/2007
Points
299
|
17th September, 2009 at 13:00:09 -
this thread is confusing u both have the same avatar
n/a
|
Rick Shaw
Registered
30/04/2008
Points
158
|
24th September, 2009 at 23:53:10 -
Alright, I don't know if anyone is still following this thread or what, but I uploaded the simplest demo of this behavior to rapidshare:
http://rapidshare.com/files/284571284/Bug_Demo.mfa
I think I might have left some redundant rules in there, but you can see for yourself that this is trying to do what I described:
1. set walls to "footprint" mode
2. detect collisions, set order
3. set walls back to normal mode
You can see that when the red detector object overlaps any part of the wall, not just the footprint, it triggers an overlap event.
Sorry for the rapidshare link, I don't have any other web space at the moment...
n/a
|
Don Luciano
Heavy combat pancake
Registered
25/10/2006
Points
380
|
25th September, 2009 at 00:45:36 -
You want player to be invisible behind a wall?
Code me a sausage!
|
Rick Shaw
Registered
30/04/2008
Points
158
|
25th September, 2009 at 00:54:06 -
no, the player should be visible behind the wall... but if he's above the wall, he's behind it. otherwise he's in front of it.
n/a
|
|
|
|
Advertisement
Post Reply