to clarify, the only differenec I can notice in vector2D's, and my messed up slopes, is that waht you did was in a seperate class, and it was normalized. I did not know how to normalize. so I was just picking a directoin and firing away.

You don't want to use atan at all and you never want to use the slope at all. Use vectors.

Ok, forget about the slope thing.I dont think that using atan2 is evil (unless you move 1 million missiles).Using atan doesn't prevent you from using vectors. In the case of a homing missile you SHOULD use an angle if you want to have it easy.Here the pseudo code (I did not test it) for a homing missile with a maximum turn speed:

A homing missile is exactly the same as a ballistic missile except that it can constantly adjust its velocity. A ballistic missile only gets fired once using a given velocity, then stays on that course forever.

This will work for an accelerating homing load of mud, don't do that for a homing missile, that will look very unrealistic.

If you fire a missile in the direction (1,0) and want to hit a target in (-1,0):demonpants missile will stay in the same 1-dimensional 'line' and will decelerate until it has speed(0,0), then accelerate again.my missile makes an elliptical turn

I can't see see the y (or in 3D including z) component of speed change with your method, it will always be 0.Maybe I'm wrong, just tell me. Of course you could add some jitter/chaos to prevent that case.

I can't see see the y (or in 3D including z) component of speed change with your method, it will always be 0.Maybe I'm wrong, just tell me. Of course you could add some jitter/chaos to prevent that case.

Yep, you are right. This needs some extra tweak, didn't thought of that - good catch! But otherwise this case also has to be treated special with fixed turn rate (left or right turn)

No, the thing I posted is just fine. I've used that exact code elsewhere. You're not taking into account that it gets called every single time step. Theoretically you make the speed value small (probably < 1) so that it never has too large of an adjustment at one time.

The "velAdjustment" can be seen as the acceleration. If you changed my code to "missilePos += v" as cylab suggested, then it would just move in a straight line towards the target.

This is what happens:1) The missile gets fired at an initial velocity.2) The missile's velocity gets adjusted as per the code below, so now it's flying more in the direction of its target.3) The missile's position gets adjusted by by its velocity (missilePos += missileVel).4) Go back to #2, repeat.

In a ballistic situation, you should never be adjusting the position of something directly. Instead, you adjust the velocity and that in turn gets carried to the position at the update. When you change the velocity, you're doing so with a given acceleration. Logically that makes sense - you can only ever accelerate something, you can never magically teleport its position somewhere.

If you took my exact code and applied gravity to it, the object would not fall at 9.8 meters per second, it would continue to accelerate at 9.8 meters per second. You're adjusting the velocity by the acceleration of gravity.

It's not moving like a "ball of mud," it's moving dynamically like a real object would. Adjusting the velocity so that it's pointing at a given object is exactly the same process.

And as for damping, usually you have a delta involved that does that for you. Like with gravity, you don't want to be updating only once per second. So if you were updating 60 frames per second, your delta would be 1/60 and so you would apply (1/6) * -9.8 for the acceleration to the object.

Obviously the above would work for something that would need directional rockets on the side as well, but really all homing missiles would need to work that way. You can't turn the thing by applying different force from the back. Say the missile is going at (-1000,500) but the target is behind it and below it. Its next velocity might become (-950, 450). As long as you point the image of the rocket the right way (and yes, you'll need atan2 to do that), then it will look like a completely smooth parabolic turn, because although the acceleration is linear the velocity is exponential. If you know your derivatives, this makes sense: x^2' == x^1.

I haven't thoroughly understood everything said here (YET) but i think these alternative suggestions are important and i will try them all because i plan to have MANY MANY MANY MANY types of projectiles with different homing or quasi homing properties that all behave differently. If these alternatives allow me to produce different "looking" behaviors that cannot be (easily) reproduced with the original method then thats very good. The projectiles will often be destroyable, so having a different "approach" and movement behaviors towards their targets can mean a lot in my game. Actually even if the original claim that the missile would move like a ball of mud isn't true thats actually a behavior i might want to try to create... so yeah, thanks a lot for all the extra details, i actually will need it (probably)

I think the ball of mud thing was referring to the missile being able to accelerate in any direction, rather than being constrained by a certain angle around its current velocity. If you wanted to get that, then I would probably use the dot product and cosine rather than atan, but it will all work out the same in the end anyway.

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org