The Daily Click ::. Forums ::. Klik Coding Help ::. detector objects in fastloops
 

Post Reply  Post Oekaki 
 

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

The SpinsterVIP MemberHas Donated, Thank You!Picture Me This Round 29 Winner!Picture Me This Round 31 Winner!Picture Me This Round 36 Winner!
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

360 Owner
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

Has Donated, Thank You!You've Been Circy'd!VIP MemberPS3 Owner
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

360 Owner
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

VIP Member
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
  1970

VIP MemberWeekly Picture Me This Round 43 Winner!Weekly Picture Me This Round 47 WinnerPicture Me This Round 49 Winner!
16th September, 2009 at 12:45:13 -


Originally Posted by Klikmaster
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"



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

VIP Member
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
   

Post Reply



 



Advertisement

Worth A Click