9 replies to this topic

[dp99]

I'm using the mp_grid, path creation AI.
I have 2 enemies on separate paths chasing me
as soon as the enemies collide, their path is deleted, path_index =-1 in the debug window
is that supposed to do that? - i can't use path_positionprevious, or any of the path functions because the path has been deleted!

if I don't create an event for enemy vs enemy collisions, they over lap each and eventually merge when chasing the player

what im trying to do is reverse the enemy on the path for a bit when it collides with another enemy

any ideas?
thanks!

Edited by dp99, 03 July 2011 - 07:26 PM.

[Nocturne]

I suggest that you don't follow the paths rigidly. Rather you make the enemy follow the path POINTS using mp_potential_step or move_towards_point, that way you can code your own collisions without worrying about path skipping/jumping or any other errors. To get idea of what I mean check out these two topics...

http://gmc.yoyogames...dpost&p=2958234

http://gmc.yoyogames...howtopic=456948

The first shows a brief outline of the code used, and the second is a working example file.

Hope that helps!

[eyeCube]

I've never used paths. They're unreliable, inefficient... Unless you want something moving along a certain (NON-CURVED) path indefinitely.

Edited by eyeCube, 03 July 2011 - 07:28 PM.

[Nocturne]

I've never used paths. They're unreliable, inefficient... Unless you want something moving along a certain (NON-CURVED) path indefinitely.

What? They can be very efficient and are certainly not un-reliable. Check out some of my AI examples here and see...

http://nocturnegames.webs.com/aiexamples.htm

[eyeCube]

This post proves they can be unreliable.
It depends on what you're using them for, and how you use them, I guess. I've just always found coding without them easy enough. In other words, I've never needed to use paths. But if you want to, go ahead.

Edited by eyeCube, 03 July 2011 - 07:35 PM.

[dp99]

thanks for the gmk file! i never ran into it on a search
i'll digest all this, but it looks like you've spelled it all out!

Edited by dp99, 03 July 2011 - 07:45 PM.

[Nocturne]

This post proves they can be unreliable.
It depends on what you're using them for, and how you use them, I guess. I've just always found coding without them easy enough. In other words, I've never needed to use paths. But if you want to, go ahead.

This post only proves that the OP has a problem that has an easy solution and that has nothing to do with paths being "unreliable". You use flawed logic to cover up your own lack of understanding of how the functions work (you yourself say that you have never needed to use paths)... ALL functions have their problems and limitations, and there is no exception. But that doesn't mean that all functions are unreliable, it just means that you don't know how to work around those limitations and problems.

[dp99]

hey guys as I slowly digest Nocturne's code-
does this sound like it would work:
every step add a small invisible object to each enemy except self, then add these to the mp_grid as obstacles, then remove them from the grid, after the path has been calculated?

[Nocturne]

That may work... BUT I have tried this and it is very error prone. There can be cases where the cell that is blocked is NOT unblocked, or if at the moment of the collision a wall collision is being resolved then the wall mp_grid could be cleared meaning enemies moving through them! try it and see, as that's always the best coyrse of action, but I don't recommend it.

[dp99]

ok, thanks, there's no way i'm gonna try messing with that then