The Daily Click

::. ::. ::.

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	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 2072	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	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
Don Luciano Heavy combat pancake Registered 25/10/2006 Points 380	25th September, 2009 at 01:22:47 - http://www.mediafire.com/?mloazwojmcm Here you go... if that what you wanted. You should probably adjust the detetcor Edited by Don Luciano Code me a sausage!
Don Luciano Heavy combat pancake Registered 25/10/2006 Points 380	25th September, 2009 at 01:32:19 - Originally Posted by Rick Shaw 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.</quote You mean he should be invisible when in the wall? Code me a sausage!
Rick Shaw Registered 30/04/2008 Points 158	25th September, 2009 at 01:53:22 - ah, well, it doesn't matter what happens to him in the wall, since he'll never get there in-game. Though I suppose he should be behind it. I took a look at your version. Notice that the detector object is still detecting collisions based on the normal wall directio and not the footprint- this is what I'm trying to fix. I could just move the detector to the top of the player's head, but that wouldn't work for objects like low fences or boxes, or with some windows, etc. Really, if I can check to see if the player's body is overlapping the wall's footprint, then I know he should be in front of the wall. That's what I'm trying to accomplish... n/a
Don Luciano Heavy combat pancake Registered 25/10/2006 Points 380	25th September, 2009 at 02:00:50 - Oh sorry, u have to switch condition from detecotor overlaps wall to: wall overlaps detector then it works properly because when u condition detector it picks any wall to compare it with if any overlaps. This way it compares each wall to the detector Edited by Don Luciano Code me a sausage!
Rick Shaw Registered 30/04/2008 Points 158	25th September, 2009 at 02:04:32 - oh my god. that does it. that's the trick. i can't believe this! i've been trying to stamp out this bug for weeks!!! n/a
Don Luciano Heavy combat pancake Registered 25/10/2006 Points 380	25th September, 2009 at 02:05:52 - Yeah, its always something simple... But it takes ages to find. Thanks for the trophy Edited by Don Luciano Code me a sausage!

Advertisement

Worth A Click