Help me identify this bug.

Hungry Hal is getting rather close to completion and I am squashing some bugs, but this one has me stumped.

They way the code should work is when a box or tire is spawned it spawns an invisible block called humanMove. When an object from the People family is overlapping humanMove, it should move the object depending on a few conditions I have laid out.

Now this works, a lot of the time, however it's not 100 percent accurate as I demonstrate in the screenshots.

This image you can clearly see the two collision boxes overlapping. Not to mention I caught the tail end of it, the People object is moving from left to right, so it ran completely over the entire humanMove object.

<img src="http://www.elf-games.com/bug/combined.jpg" border="0" />

These two screenshots show the properties for the humanMove instance and People instance.

<img src="http://www.elf-games.com/bug/humanmove.png" border="0" />

<img src="http://www.elf-games.com/bug/people.png" border="0" />

Lastly is my code.

<img src="http://www.elf-games.com/bug/code.png" border="0" />

I'm not sure if the collision event is even happening or not. Is there a way in the debugger to determine that?

I have also tried it with on Collision, same results. I have also tried it with humanMove set to visible and it still happens. I'm missing something, and it's probably something little and I am not seeing it :).

Thanks

Ed

Just add a text somewhere in the layout, and append (not add, append) some text to it on collision (like collision names of the objects).

Then simply check the debugger for the content of the text if it gets too wide and no longer visible.

suggestions:

Looking at your layout, seeing the zombie being in the same area as the collision boxes, I can imagine one of its condition perhaps being in the way ?.

You have a trigger once in the first event of the overlaps, perhaps try moving it down to the subbed events. (so overlaps can occur more then once)

Thanks, I'll try all of that.

I don't think Zombie is getting in the way. He is not part of the People family and never checks for collisions on humanMove.

I should also note when using on Collision instead, no trigger once event is used and the problems where still there.

Thanks.

I think just removing the trigger once solved the problem.

I'll keep testing, but it's looking good.

good to hear :)

I believe collision is a one time event as long as its in touch with the colliding object, and overlaps keeps kicking in.

I had something simlair some time back, just had to keep subbed coutners in check with a trigger once :)

Might be an idea to peek at the profiler in the debugger if the subbed events are not firing off every tick.

Hungry hall looking good Ed :D

It's taken me some time to type and things have already moved on, but here goes what I think might be happening. So, as I read the events - and apologies if I've misunderstood - the following could happen:

• People overlaps HumanMove and People is on same layer as HumanMove

     - People var Path = "Top" - do some stuff including put var Path = "Middle"

     - If Path = "Middle" then do some other stuff (it always will be true because of the previous event.

          Next events: half of the time tempY will be set to 465 which will then put People on layer "PathTop", which is the layer we were in at the start (and from the debug 465 is the People y value now).

As there's a trigger once in the first event, at the next tick the People parameters will not have changed so the event won't fire again. The only thing I'm not sure about is what the relevance of the MoveTo target position is - so all of this could be me describing what you already want the code to do!

If you're looking for the human to move in a +y direction to avoid the obstacle, could it be something like the crate's origin is off so that y=465 doesn't look like the human is avoiding it?

The game is based on three paths that the player navigates up and down. The moveTo is telling the People family to moveTo another path. Those target positions are just the location on the path to move them too.

I think if I set it up so each collision check also checks for path, and had 3 collision checks instead of the one, it would work better. I have a feeling some of the events below the triggered event is getting triggered when I change the path. I think that is what you were saying.

In other words, if there was a way to break out of the condition after the true value was found, that would fix it. If People.Path = "Top" --- Do Events. Then break out of the event

Maybe. :)

Yup, I fixed it by doing this. DUH!!

<img src="http://content.screencast.com/users/ArcadEd/folders/Jing/media/8067d23c-e508-4d89-9174-13aff166d48f/2014-02-05_1207.png" border="0" />