Homing GM6.1

[Gradient]

This is the code I use for a homing attack:

// Homing attack
   if (PRESS_X) {
   if (homing=0 && action) {
   homing_target=instance_nearest(x,y,obj_enemy_parent);
   homing=1;
   }}

   dist=distance_to_point(homing_target.x,homing_target.y);
   if (dist<100 && homing=1) move_towards_point(homing_target.x,homing_target.y,1;[/CODE]

'Action' means you are jumping. The code sets the homing target, then determines if they are close enough. If so, you move towards the target. I've set code elsewhere that sets 'homing' to 0 if you hit the ground, rails or the target. All of this works as it should.

Problem is, the physics go absolutely insane, and it's all because of those last two lines. Sonic slides along the ground, the accel/decel goes wrong, he starts jumping far too high... And rather than moving towards the enemy with every step, he only does it for one step, even though 'homing' equals 1 until he hits the enemy (or ground).

Removing the last two lines of code clears it up, so they are clearly at fault. i've seen this very code tried and tested in another game, so I know it works. Am I missing something, or is there something about Dami's 360 engine that could be causing it all?

[Kain]

Dami's engine uses it's own speed variables to have better control of movement, so whenever you add speeds that automatically moves the object, the thing goes haywire. Instead of using move_towards_point, you have to act on the existing movement variables. I'm not sure which version you're using, but I believe they're either spd and grav or hspd and vspd.

Anyway, since you can't relly on that function, you have to calculate it for yourself using point_direction and lengthdir_x/y:

// Homing attack
   if (PRESS_X) {
   if (homing=0 && action) {
   homing_target=instance_nearest(x,y,obj_enemy_parent);
   homing=1;
   }}

   dist=distance_to_point(homing_target.x,homing_target.y);
   if (dist<100 && homing=1) 
   {
      dir = point_direction(x,y,homing_target.x,homing_target.y);
      hspd = lengthdir_x( 5 , dir );
      vspd = lengthdir_y( 5 , dir );
   }

Assuming you had the rest of it right, that is.

[Zonar Games]

So if I was to use this code in the new pack the variable dir would be angle and obviously hspd and vspd will be x/y_speed right? I always wanted to know how to do this

// Homing attack

if (key_action) {

if (homing=0 && action_jumping) {

homing_target=instance_nearest(x,y,obj_enemy_parent);

homing=1;

}}

dist=distance_to_point(homing_target.x,homing_target.y);

if (dist<100 && homing=1)

{

dir = point_direction(x,y,homing_target.x,homing_target.y);

x_speed = lengthdir_x( 5 , dir );

y_speed = lengthdir_y( 5 , dir );

}

// If homing 0

if ( place_contact(x,y,objSolid))

{

homing = 0;

}

Would this be right for the new pack Kain?

[Kain]

Yes, I forgot he used those speed variables. If you ever want to check, just look in the first code segment of the creation event for objSonic; it initializes and comments on all the variables he uses.

[Gradient]

I had a feeling it would be something like that. Many thanks, Kain, it works perfectly.

[Tapika]

It's place_meeting, not place_contact. SYNTAX ERROR, btw.

[Zonar Games]

oops my mistake I always to that because in D&D it's place contact.