Legacy GM Recognising multiple objects as instance to avoid

Spam1985

Member
Hi all. I have my enemies navigating with
Code:
 mp_potential_step_object(obj_player1.x, obj_player1.y, movespd, obs);

The variable "obs" being what they must avoid, of course. The problem is, I need "obs" to be many different things, depending on the situation.

First of all, any most annoyingly, they need to avoid other enemies, rather than just clip through each other. If I set them as a child of the wall object, say, then they collide with themselves and cannot move at all.

Secondly, what they perceive to be a wall must change based on their perceived "ground level" value. Walls higher than them are considered obstacles, and walls below them are not. What I've currently got works OK, but for only 2 different wall heights. (I tried more and then problems arose).

floor_z is the relative "ground level" of the enemy. wall32 is a wall with a height value of 32, and obj_wall is a child of wall32 with an infinite height value and thus, should be avoided in every case. Even though wall32 is slightly higher than the enemy's "floor_z" they are able to jump onto it and get a new floor_z.
Code:
 if floor_z > 14 then { obs = obj_wall; } else { obs = obj_wall32; }
So all in all what I really need is to be able to say something like:
obs = this and this and obj_enemy (but not yourself!)


Maybe I'm just ignorant and there is a simple way to do this. If not then the answer is probably some really smart use of parent objects, but right now I can't wrap my head around it.

Sorry for the long-winded post. Hopefully I explained the problem clearly enough and many thanks to anyone who reads and responds.
 

samspade

Member
Hi all. I have my enemies navigating with
Code:
 mp_potential_step_object(obj_player1.x, obj_player1.y, movespd, obs);
The variable "obs" being what they must avoid, of course. The problem is, I need "obs" to be many different things, depending on the situation.

First of all, any most annoyingly, they need to avoid other enemies, rather than just clip through each other. If I set them as a child of the wall object, say, then they collide with themselves and cannot move at all.

Secondly, what they perceive to be a wall must change based on their perceived "ground level" value. Walls higher than them are considered obstacles, and walls below them are not. What I've currently got works OK, but for only 2 different wall heights. (I tried more and then problems arose).

floor_z is the relative "ground level" of the enemy. wall32 is a wall with a height value of 32, and obj_wall is a child of wall32 with an infinite height value and thus, should be avoided in every case. Even though wall32 is slightly higher than the enemy's "floor_z" they are able to jump onto it and get a new floor_z.
Code:
 if floor_z > 14 then { obs = obj_wall; } else { obs = obj_wall32; }
So all in all what I really need is to be able to say something like:
obs = this and this and obj_enemy (but not yourself!)


Maybe I'm just ignorant and there is a simple way to do this. If not then the answer is probably some really smart use of parent objects, but right now I can't wrap my head around it.

Sorry for the long-winded post. Hopefully I explained the problem clearly enough and many thanks to anyone who reads and responds.
Look up parents and inheritance. Make a parent object such as obj_solid, and then make all objects that you want to be treated in the same way (whether for collision, avoidance, or anything really) children of that object. Then use the parent object.

Code:
mp_potential_step_object(obj_player1.x, obj_player1.y, movespd, obj_solid);
 

roozilla

Member
I think that solves one of his problems but he wants the obj_enemy to not pass obj_wall and jump over obj_wall32. You could try and do it by collision detection of your obj_wall32 as obj_enemy moves but you will need to make obj_wall32 not inherit from obj_solid(could rename as obj_impassable). Store the x and y points that the first call to mp_potential_step_object needs to head to. Then in your step event If it will collide with an obj_wall32 change the obj_enemies floor_z by performing your "jump" then call mp_potential_step_object() with the last stored x and y coordinates. I say recall it because I don't know what will happen when you perform your jump/animation and if it makes it register the first call as unsuccessful. Again take into account cancelled movements etc. I don't know the behavior of your enemies
 

Spam1985

Member
Thanks for your input, guys. Really the most important thing to solve is that enemies need to avoid each other. If I set them to have walls as parents then they cannot move because they collide with themselves and get stuck. If they have no parent then they clip through each other, eventually seemingly merging into one entity.

So the enemies are looking to avoid var obs

var obs is sometimes obj_wall32 (height of 32) and always obj_wall(ultimate impassable wall).

There is also obj_wall16 but the enemy never considers them as obstacles because they can be jumped upon. When they jump onto obj_wall16 they no longer consider obj_wall32 as obstacles because that height is now reachable by jumping. So it goes like this:
Code:
  if floor_z > 14 then { obs = obj_wall; } else { obs = obj_wall32; }
This works just fine for these two different walls ^
Basically it translates to: "if I'm standing on something high enough then ultimate walls are my only obstacle.
If not, then obj_wall32 is my obstacle, but since it is a parent of the ultimate wall, then those are also obstacles."

It was only when I tried to set up a third wall height that I had problems with hierarchy and whatnot. I think I set an obj_wall48 as a parent of obj_wall32 which was a parent of obj_wall.
Couldn't get that to work for whatever reason.

But all in all, it's the enemies avoiding each other that I care about fixing more than adding in more possible walls.
 

samspade

Member
Thanks for your input, guys. Really the most important thing to solve is that enemies need to avoid each other. If I set them to have walls as parents then they cannot move because they collide with themselves and get stuck. If they have no parent then they clip through each other, eventually seemingly merging into one entity.

So the enemies are looking to avoid var obs

var obs is sometimes obj_wall32 (height of 32) and always obj_wall(ultimate impassable wall).

There is also obj_wall16 but the enemy never considers them as obstacles because they can be jumped upon. When they jump onto obj_wall16 they no longer consider obj_wall32 as obstacles because that height is now reachable by jumping. So it goes like this:
Code:
  if floor_z > 14 then { obs = obj_wall; } else { obs = obj_wall32; }
This works just fine for these two different walls ^
Basically it translates to: "if I'm standing on something high enough then ultimate walls are my only obstacle.
If not, then obj_wall32 is my obstacle, but since it is a parent of the ultimate wall, then those are also obstacles."

It was only when I tried to set up a third wall height that I had problems with hierarchy and whatnot. I think I set an obj_wall48 as a parent of obj_wall32 which was a parent of obj_wall.
Couldn't get that to work for whatever reason.

But all in all, it's the enemies avoiding each other that I care about fixing more than adding in more possible walls.
Inheritance is the way to go. Unless you mean you don't actually have code for enemies avoiding each other?
 

roozilla

Member
Samspade answered the enemies colliding by the generalized obj_solid being the parent of all solid objects, walls, enemies, etc. I think the wall portion then would need to be handled in the step event(don't inherit from obj_solid) using a gm built in collision detection function or a script. You would need to account for hitting any obj_wall check a property it contains such as height, 16, 32 or whatever. If the objs current floor_z is jumpable, then perform the jump, then reset your mp_potential_step_object call. I said to store the initial value because it migjt return unsuccessful for the first time you call and your step event collision check found a wall you need to jump. If it cant jump, that is another matter. You might need to handle this yourself or there might be a function in gm that I'm unaware of.
 

Spam1985

Member
Well thanks for your time, chaps. I'll have a good long look at it and rethink it tomorrow and might give it a serious rework.
 
Top