#### Archived

This topic is now archived and is closed to further replies.

# Homing Missile AI in 3space with momentum (hard!)

This topic is 5708 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

Hi all, Im new to these forums, and forums in general, so please bear with me on this. Some time ago, I had to code a project which was a 3d space combat game. We used a 3d party phyiscs engine for our project. One of the key points about our game was that it had real physics. ie: objects have momentum, and move as such; if your going fairly fast in one way, you have to come to a stop by thrusting in the opposite direction. Objects do not have momentum as they turn, however (ie, an object continues to yaw only as long as its being told to by the player, or AI controlling it, and stops when its tryToYaw value is 0). In the game objects positions are represnted as 3 space vectors, as are their current velocities. Objects rotations are represented by quaternions. A object can be made to roll, pitch, yaw, or thrust by setting its object.tryThrust, object.tryRoll etc. int to a positive % value (clockwise RPY), or a negitve % value to roll pitch or yaw counterclockwise. Same holds for thrust, only it thrusts forward or back. The problem Im having, is to try and code an AI, which has access to the velocity, orientation and location of or the object its controlling, and some target object, and may modify its own tryThrust, tryRoll etc values. I need to make it so that an object can be told to A) move to a certain point in space, B) try hit an enemy ship, based on ships current trajectory. I have coded a method which can turn the ship to face a point (given as a vector3); what I need is to use this, and the other info, to get it to fulfill A and B. The problem lies in the fact that to get a homing missile with momentum, and this rule set, to move somewhere else, it has to deal with where it wants to move to, as well as its current velocity. I know the problem is solvable, because a human player with said info can home on an enemy. Solutions like first stopping completely, then turning to face the enemy, and accelerating are easy, but not much use. Any help towards A or B would be appreciated. I am sure this cannot be an uncommon problem, as something like this must be dealt with in real life, however i cannot find any solutions to this problem in this complex a form easily. Even turning to face the enemy took ages (different ships could have different up vector btw) Thanks for your help... feel free to email feral@iolfree.ie with replies etc if not suitable here.

##### Share on other sites
Does it have to be perfect?
and, are you operating in space or in the air?

For a first try, why not just make it head towards the enemy as much as possible, if it misses, just tunr around and try again

##### Share on other sites
I would imagine in space with all the corrections necessary that even a player-piloted missile would be hard to crash into its target at the same point.

Still, though, it's possible. The problem is that if the missile acquires too much velocity, it doesn't take much for the enemy craft to make a small correction and evade it - the missile would REALLY have to punch its lateral thrusters, maybe even slow down, to successfully make a meaningful correction at high speed.

Your best bet for success is to head for a point that is ahead of the target craft. That, or try to come in behind the target craft and pursue by imitating its movements, instead of going for a meet-the-same-point collision.

[edited by - Waverider on June 28, 2002 5:38:30 PM]

##### Share on other sites
If I understand your problem correctly, you just need ''seek'' and ''pursuit'' steering behavior. Seek is very easy to implement, pursuit not much harder.

This link will give you the details.

http://www.red3d.com/cwr/steer/

Stimulate

##### Share on other sites
Hi all,
thanks for your replies so far.

fup:
Thanks for the link, ive only skimmed it, but will look through it at more detail later.
However, I dont think its really what Im after.
Those seeking/pursuit behavoirs are fine for 2d, when you know the velocities involved.

However, I need the same stuff in 3 space (not hard), but without access to velocities. ie: a ship has an acceleration, not a max velocity.
So if I need to intercept a target using simple linear vector algebra with relative velocities, I need to know my velocity to work out the targets velocity relative to me. However, I dont know my velocity, as it will be some sort of average velocity formed as I accelerate across the distance between my current location and the targets location.
So I could use calculus to work out that velocity, or might even need it, fair enough.
The problem is, I wont know the distance Im flying to intercept until I can work out which direction I should thrust in order to intercept, and this direction itself depends on the distance (coz of velocities).
I cant figure out a way around that.

Thats one problem.
Now assuming we dont worry about the whole relative velocity thing, and we just try find a way of moving towards a point first. We could just update very frequently the target location and use our movetopoint(enemy.location) function lots. Not perfect, but would do the trick.

However, a movetopoint function is hard to develop, as it needs to figure out which direction we should thrust in order to cancel our current velocity components away from the target, and simultaneously increase our velocity towards the target.
This is harder than it sounds, again because we dont have access to velocities, just acclerations.
One solution is to simply take our current velocity, face the opposite way, and thrust until velocity == 0. Then go and face the target location, and thrust until you arrive at it. Thats fine, but very inelegant and leads missiles to behave really awfully. Anything else requires some relative velocity math, which is enormously complicated by the changing velocities of the homing missile.
I am confident that theres a way to solve this, but it doesnt seem to be easy to me.
If we could develop a movetopoint function, for use by an object with nonzero velocity, itd be a start. A function where we then tell it to moveto a targets predicted location instead of its current location would be a step up in complexity and efficiency.

Im sure these exist, but I cant find them...

Waverider:
Im not too bothered about that fact (the missile aquiring too much velocity). Assuming missile acceration is high in comparision with ship acceration, and any sort of decent prediction algorithim the missile should be able to hit its target. Well, not neccessarily hit, because as you pointed out, if its approcahing its target orthogonal to its targets velocity (ie, from the side) a small manuveour by the target will cause the missile too shoot by. However, it will pass _quite close by_, close enough to have its AI detonate its payload and do acceptable damage.

SHO_NUFF:
not perfect, no, just close enough to do enough damage.
Its in space - this means no friction, and considerably adds to the problem. With an atmospheric case, you just have to make the missile keep facing the target, and the missile will develop a max velocity (terminal velocity through atmosphere) which you can use for all the relative velocity calculations.

Again, our space game was unusual it that things behaved faily close to a newtonian physics model of space, unlike most games where things have max velocity, no momentum etc.

any further thoughts towards this problem? Again its one i dont need to solve, (the project is finished) but would really like to know the solution to...

feral

##### Share on other sites
You''re confusing me. One second you say you don''t have the velocity, the next you say you do. As an example...

quote:
This is harder than it sounds, again because we dont have access to velocities, just acclerations.
One solution is to simply take our current velocity, face the opposite way, and thrust until velocity == 0. Then go and face the target location, and thrust until you arrive at it.

Also, all Reynold''s steering behaviors work just as well in 3D as in 2D. You just have to be careful of the dreaded gimbal lock, but then I''m sure you''ll have solved that problem already.

Stimulate

##### Share on other sites
What I mean is that while we do have access to an objects velocity at any one time, we do not have access to what will be its average velocity between now and the time it intersects the target.

The latter is what we really need to have access to in order to do the proper relative velocity calculations, imo. However, it also depends on the outcome of said calculations, which is where I get lost.

I dont believe gimbal lock is an issue anymore - all the math was done with quaternions, and the facePoint method does some pretty clever absolute quaternion orientation to desired roll/pitch/yaw thrust values.

##### Share on other sites
neural net maybe? it checks to see whether it is closer or farther away from the object than last time?

##### Share on other sites
All you need is the current velocity. It's this value that's used to do all the calculations...

For example:

//all the info you needstruct moving_object{  3DVector  velocity;  3DVector  position;  double    MaxSpeed;};//the 'seek' steering behavior.3DVector Seek(const 3DVector &target, const moving_object &Player){  3DVector ToTarget =  Normalize(target - Player.position);  return Player.vel - (ToTarget * Player.MaxSpeed);}

forgive any typos - I've only just woken up.

Stimulate

[edited by - fup on June 29, 2002 2:33:52 AM]

##### Share on other sites
Deleted due to repetition.

[edited by - fup on June 29, 2002 2:36:50 AM]

##### Share on other sites
Argh! Can someone tell me how I post code here plz? (I thought it was something like
 blah blah

##### Share on other sites
Argh! Can someone tell me how I post code here plz?

##### Share on other sites
Nooooooooooooooooooooooooooooooooooooo!

I guess this''ll teach me to post at 6.30 am!! :0)

##### Share on other sites
lol

Use open square braket Source close square braket
[ "source" ] - No quotations

        lol good luck, teach ya to post at 6:30...oh yeah and to stop souce go [ "/source" ] - Also cut the sqaure quotations

Lol my third edit, i need to learn how to type... Maybe its to late..
[edited by - HunterTKilla on June 29, 2002 2:53:13 AM]

[edited by - HunterTKilla on June 29, 2002 2:53:28 AM]

[edited by - HunterTKilla on June 29, 2002 2:54:16 AM]

[edited by - HunterTKilla on June 29, 2002 2:55:05 AM]

##### Share on other sites
yep, thanks. I was close (trying ["code"]) but, as they say... no cigar.

##### Share on other sites
Thanks for continuing efforts to help, fup, Im really grateful.
However, Im not sure Ive explained the problem clearly enough (it is complex though).

The solution you give seems to depend on a max speed value for objects; In space they do not have such a value, as theres no friction to provide a terminal velocity due to air resistance.

So you dont have anything to nicely slide into that calculation where you can put max velocity.

Perhaps one thing to do would be that the homing missile controller AI would just decide to accelerate until it reached a "max velocity" which we just decide to give it, for the sake of simplifying the maths.
However, that would hardly be an efficient design of AI, as we''d prefer something that covers distance to target in shortest time, and this is obviously possible only by continuous maximum thrust/acceleration.

But the maths to do that still seem to elude me.

Feral

As an aside, that computation to me seems slightly innaccurate (correct me if Im wrong here, I find this math a bit tricky) because it seems to depend on the time taken to achieve max velocity being much smaller than the time spend at max velocity on the way to the target. Ie, large acceleration compared to speed.
Which is fine, coz your continually updating and revising the estimation though, but perhaps non optimal.

##### Share on other sites
well first off, a missile will have a max velocity due to limited fuel. if you wont have a max velocity because its not true to physics, well not having one is just as bad. though the actual max velocity is dependent upon the start velocity (ie the ship firing the missile).

no matter what the following should always hold true:

1. you know your current velocity
2. you know the targets current position in space
3. you know your position in space
5. you have a max velocity becuase of fuel limitations, you may ignore fuel limitations like most games, but even so you should still have a max velocity based on this, else your physics calculations will come crashing down on you as objects exceed a particular speed (since collision will get funky, overflows will start to occer, etc).

the ai is quite simple in homing missils. first off homing missiles are designed to correct somewhat accurate shots, not to be fired in the opposite direction of the taregt. thats the first mistake you make. secondly a missile should never need to stop to go after the target nor apply thrust to slow itself down significently. missiles will pick there target by selecting the closest target within a particular fov. laser guided missiles are have their target chosen by what the ship is locked on to (though the ship must keep the lock). thus the ship must make its initial shot facing the target.

the missile merely updates its thrust vector each time step to face towards the target. the missile has limited directional thrust, thus again wont be able to stop itself as you suggest. you are giving your missiles too much technology and no limits which makes it more difficult to make it seem correct.

target vector: from your current position to the target position

you dont care about the targets trajectory. instead you will find the delta vector from your vector to the target vector. this vector will represent the exact thrust change required to hit the target the next time step. since the missile has limited acceleration abilities, you would scale this vector to the amount of thrust the missile can use to turn. this is then added to the current missile vector to come up with the new vector in which the missile is now turned towards the target within the limits of the missile acceleration ability. this whole thing gets repeated until the missile collides with something. the missile should have a max velocity similar to a ships max velocity to prevent the ship from escaping the missile if the firing ship is traveling at the same velocity as the target.

if your game has real physics, it should be able to handle the vector math required. it also should be able to handle mulitple vectors per object. since you will have a current vector, desired vector, acceleration vector. the acceleration vector represents the difference of the desired and current vector. which is then normalized and scaled to the acceleration the object can handle. this makes the homing missile ai trivial to implement. since you only need to update the desired vector, and the physics engine should take care of everything else automagically.

##### Share on other sites
Hi.

You say you don''t have a max velocity, but no mather
if you have air-resitance (like in the atmosphere) or
friction less space there is always a maxspeed, the
speed of light which cannot be broken (according to
Einsteins theory of relativity).

And as other replyers have said, even in space you have
some practical issues which determines your maxspeed,
like the amount of fuel carried by the missile.

BR
Marten Svanfeldt
Sweden

##### Share on other sites
quote:
Original post by feral
One of the key points about our game was that it had real physics.
...
A) move to a certain point in space,

AFAIK in real physics, there is no ''certain point in space'' everything is relative

Anyway, I''m no great 3space thinker, but if someone were to ask me to design a missile for combat in space (Yeah, that''s likely to happen ) I don''t think I''d use the missile design used in most of the current space-sims, which look much like our current ''air''-missiles. As we''re in space, aerodynamics aren''t an issue, so we can use any shape we want, I''d choose a simple box, because it allows for easy storage (Hey! easy modelling) . There''ll be no front or back since the missile will have to be higly maneuverable, so it should be able to provide high thrust in any direction, turning is slow and is air-head thinking (air-head referring to a person thinking to much about contemporary aviation). The missile will have to be light since a low mass will require less thrust, I''m thinking an anti-matter payload.

Now, we have a light, fast, maneuverable, computer controlled missile, how do we get it from point A (being it''s current position) to point B (being that ship which contains the tentacle-head who made an offensive remark about your mother), how does one program it to actually make tantacle-soup. Let''s take point B as our ''fixed point in space'', now all we have to do is ''stop'', of course point B has the nasty habit of changing it''s movement vector, so we move the same way, if the tracking computer reacts fast enough, the distance between our missile and point B will remain constant, now if we encapsulate this behavior in a module and add an interface to this module (in programming terms, the module being a class, and the interface being its public methods) which we can give instructions to move in a certain direction (let''s say the direction of Point B) it will combine the vector given with it''s auto-sync to move toward point B while matching it''s movement. Maybe this isn''t the most efficient way, and it depends on how high the level of technology is (scanner equipment for example). And given that I''m suffereing from sleep deprivation and not thinking clearly, it may all be a bunch of BS, so please disregard any stupid parts or all of ''em.

Gyzmo
==============================
"Well is the world standard" - The Alchemist

##### Share on other sites
No offense intended to anyone, but going by what has been written, you all seem to have forgotten something rather basic about this problem! The only (abstract) action required of the missile is to decrease the magnitude of the relative velocity vector each time step.

The relative velocity vector is trivial to compute. If you want to be nasty and not tell the missile what the targets velocity is, then you can have it estimate it using position observations.

Given the missiles current velocity and the relative velocity vector, the problem of finding the correct control commands to reduce the magnitude of the relative velocity vector is a search/optimisation problem. The two actions that will reduce this magnitude are decreasing the angle to target and/or decreasing the distance to target, where the angle to target is the angle between the current trajectory of the missile and the displacement vector from the missile to the target.

Now, here''s a suggestion to simplify the problem: it''s a space-based missile, it doesn''t need roll, only pitch, yaw and thrust (accelerate).

So, you have 3 control variables: pitch, yaw, thrust.

Choose a small increment of these actions and create a search tree that branches on these actions for the small increment. Perform a search to find the smallest set of actions that generates a decrease in the magnitude of the relative velocity vector.

Trigger this search whenever the target changes velocity (speed or direction).

That should be enough to get your system working.

On the other hand, you could create a system that does this via supervised learning (trial and error).

Cheers,

Timkin

##### Share on other sites
Timkin, thats exactly what i suggested. except i suggested using vector math and merely applying adding the scaled difference of the vectors. the yeilds exactly the same result except you dont need to deal with angles thus no need to use any trig functions which can be slow. the actual missle drawing could be done simply be using the current vector. it may not be perfect visually, but it will be close enough and players are not likly to notice. you could also just have it always face the target. though that may cause an undesirable look.

maybe my explaination was not clear enough.

some psudeo code:

    targetVector = shipPos-targetPos;desiredVector = normalize(missleVector-targetVector);newVector = missleVector +(desiredVector*missileAcceleration);

you may want to normalize the target and missle vector before doing the subtraction. not sure which would give a better accuarcy or look that you want. try both ways out. this system uses the idea that there is a three axis thrust system. so actual angles are not required, so there is no gimble lock problem.

being that you are using pecentages of change. you should be able to use the percentage of change in the vectors and apply it for the different angles you require (ie the normalized difference of the target vector from the missile vector).

Gyzmo, good catch. i guess i should have suggested using everything reletive to the origin of the universe (whcih every one knows is at 0,0,0 ), heh.

[edited by - a person on June 30, 2002 7:04:00 PM]

##### Share on other sites
quote:
Original post by a person
maybe my explaination was not clear enough.

some psudeo code:
targetVector = shipPos-targetPos;desiredVector = normalize(missleVector-targetVector);newVector = missleVector +(desiredVector*missileAcceleration);

That''s not what I was suggesting though...

I was talking about the relative velocity vector , which is
target.velocity - missile.velocity

rather than a displacement vector
targetVector = shipPos-targetPos;

Additionally, your method suggests that the missile can turn any finite angle in an infinitesimal time step. That''s not very realistic.

What I was suggesting above was in fact a homing behaviour, based on a proven technique of decreasing angle and/or distance to goal with each action. No need to constrain it any further than that.

You might also need to check your computation. I could be wrong (since you don''t explicity state what each vector is) but it appears that you are subtracting a displacement vector from a velocity vector in your second line. If this is the case, then you need to multiply the missiles velocity vector by the time it would take to travel the displacement distance, or divide the displacement vector by this amount to determine a velocity.

As for the use of trig... you don''t need trig to compare the magnitudes of angles!

Cheers,

Timkin

##### Share on other sites
but you need trig to get the angles.

i think the part you are getting confused on is the defination of a vector. a vector contains two things. a direction and magnitude.

thus:
missleVector is the direction of the missile and its speed.
targetVector is the distance and direction to teh target from the ship.

thus subtracting the missile direction from the target direction gives the required change of thrust in each angle.

now you normalize this so its purley a direction (since the magnitude will be encompass the entire journey). you then multiple this normalized vector by a acceleration value, ie the turning velocity. you then add this to the missiles current vector. this will apply acceleration in that direction. thus the ship will turn only slightly. if the ship is going in the correct direction, it will accelerate the ship as normal.

there is no instant lockon like you suggest since we are scaling the vector required to be in perfect alignment with a smaller value that is less then the current speed. this ensures it takes time for the missle to make turns.

i suggested it may be more accurate to compare the normalize vectors (ie so its only direction and velocity dont matter). i have not tried each method out. i probably should, just to make sure things work 100% correctly.

the nice thing about vectors is that you get the magnitude in there for free so you can use it for nice optimizations of some of the calculations. for instance the desiredVector obtained before normalization is the EXACT thrust required to hit the target instantly. notice, this is thrust that we would add to our missile''s current movement vector. so scaling it to a reasonable value (ie normalize then apply the acceleration constraint) it works out nicly.

even yoru method requires the constraint of limiting the turning speed, just like mine. the only difference is that my method requires no angle calculations and automagically handles normal acceleration/deceleration through the desired vector. for instance you could change the system so that the ship accelerates at x velocity per time unit. you would then calculate the desired vector (ie scaled to the correct velocity and point where you want to go). you then take the difference of this vector and your current vector which you normalize. you multiple that vector by the x/time unit acceleration then add it to the currect vector.
viola the ship now accuartly handles movement in space with slower turning at higher speeds (ie inertia plays a role). though you will have to do a check on the magnitude of the difference between the desired and current vector and make sure its not smaller then your acceleration. if it is, then you should not "dirty" the magnitude through the normalize and and acceleration muitlply. instead use it as is, or have the system slow reduce the thrust gardually. in either case, if the cuurent velocity ever gets greater then the desired vector velocity, the ship will automatically slow down. though it may cause a stutter scenario (ie speed up slow up, then slow down, then repeat).

##### Share on other sites
quote:
Original post by Timkin
No offense intended to anyone, but going by what has been written, you all seem to have forgotten something rather basic about this problem! The only (abstract) action required of the missile is to decrease the magnitude of the relative velocity vector each time step.

Timkin, the OP didn''t ask how to turn the ship, see:

quote:
I have coded a method which can turn the ship to face a point (given as a vector3); what I need is to use this, and the other info, to get it to fulfill A and B.

He asked how to move the ship towards the target. Both myself and ''a person'' have given him simple answers that solve his problem. Furthermore, the Reynolds paper I directed the OP to shows how turning rates may be implemented (if I remember correctly). It doesn''t get any more basic than ''seek''

##### Share on other sites

Thanks for all the responses guys! Wow, its going to take me a long time to reply to them all.

A person:
>well first off, a missile will have a max velocity due to limited fuel
Yes, this is indeed true. However, this max velocity is unlikely to be achieved during the missiles journey from the launching ship to the target, and as such is irrelevant to the calculations in question.

>5. you have a max velocity becuase of fuel limitations, you may ignore fuel limitations
>like most games, but even so you should still have a max velocity based
> on this, else your physics calculations will come crashing down on you as objects
>exceed a particular speed (since collision will get funky, overflows will start
> to occer, etc).

It is true, there is a max velocity due to the physics engine. But again, its so much greater than the velocity that a missile can achieve over the course of a normal flight (espeically when you consider were not much interested in missiles doubling back on thier path to hit a target theyve missed) that it is irrelevent, as it will not occur during the period we''re trying to deal with. Any calculations thus based on it will be erronoius.

>missiles will pick there target by selecting the closest target within a particular fov.
>laser guided missiles are have their target chosen by what the ship is locked
> on to (though the ship must keep the lock). thus the ship must make its initial shot
>facing the target.

Again, Im not sure this is strictly relevent to the question I asked, but anyway ships and missiles have full access to the positions of all other objects in the game state. Sure, you can argue its unrealestic, but thats the way it is. We can also posulate the idea of a targeting laser which is on a pivot, so it doesnt neccessarily have to point in front of you. So the ship doesnt have to shoot facing the target.

>you dont care about the targets trajector
It will be very hard to predict its position otherwise. We could have a missile that always just homes on the targets current position (and indeed, Id be happy if I got the maths to do that) but this would result in missiles always flying curves to their targets in, and would be inefficient. But Ill still be happy with it, so lets continue...

> instead you will find the delta vector from your vector to the target vector. this vector
>will represent the exact thrust
>change required to hit the target the next time step

Im a little confused by exactly what you mean here? when you say "thrust change" do you mean displacment? Ie, that it will give you the difference between your current position and the targets current position, as a vector relative to you? if so, I understand.

>since the missile has limited acceleration abilities, you would scale this vector to the
>amount of thrust the
>missile can use to turn. this is then added to the current missile vector to come up with
>the new vector in which the missile is now turned towards the target
>within the limits of the missile acceleration ability.

Ah, Im afraid youve lost me here? Id be really grateful if youd explain this again somehow, as im totally confused...

> the missile should have a max velocity
>similar to a ships max velocity to prevent the ship from escaping the missile if the firing
>ship is traveling at the same velocity as the target.

Velocity? things dont really have a max velocity in the game, at least none that counts for
interactions like this. As a result, acceleration, not velocity is the key factor.
Missiles have acceralations very much greater than ships to ensure they can hit them.
(smaller mass, higher thrust).

>if your game has real physics, it should be able to handle the vector math required. it
> also should be able to handle mulitple vectors per object. since you will
> have a current vector, desired vector, acceleration vector. the acceleration vector
> represents the difference of the desired and current vector. which is then
>normalized and scaled to the acceleration the object can handle. this makes the homing
> missile ai trivial to implement. since you only need to update the
> desired vector, and the physics engine should take care of everything else automagically.

Its quite seperate to the physics engine, but we do indeed have a vector3 utility class.
Multiple vectors per object are quite easy, the aicontroller class can instantiate them as it needs.
The phyiscs eng does need to know anything about them, apart from the ones that physical objects actually have due to their position/motion in space.

The engine, however, is not responsible for steering things. This is left to their AI. Which has to deal with things like desired vector and stuff. The physics engine is only
told that a given space ship is trying to thrust more or less, or roll pitch or yaw by an
amount.

thebolt00:
>speed of light which cannot be broken (according to
> Einsteins theory of relativity).
This is indeed true. And such an upper limit exists, however as discussed, it is irrelevent to the calculations in question, as it can not be formed before any practical time to target is exceeded.

Gyzmo
>AFAIK in real physics, there is no ''certain point in space'' everything is relative
Thats a big of an abstract comment! Dont see much relevence.. however, I disagree. You can
of course specify certain points in space - you just cant do it in absoulte terms. But you
can specify them relative to other points. So they are certain, given that the other point
is certain. And anything you can point to, if you like, has indeed got a certain point
(lets not go into too much detail here, but you see what I mean. Anyone mentioning heisenberg is in deep trouble.)

Timkin:
>The only (abstract) action required of the missile is to decrease the magnitude of the
>relative velocity vector each time step.

Correct me if Im wrong, and Im not 100% sure what you mean by relative velocity vector, but
assuming I understand, wouldnt trying to decrease it each time just lead to both things
sitting in space? No movement? (relative to one another) I dont see how this leads to
homing behaviour.

You talk a bit more about reducing the RVV, but I dont see how it is supposed to solve the
problem? I imagine youd want a relative velocity vector which always points from
the missile to the target, and try maximise it instead. Which is substaintally more
involved than minimising one, no?

a person:
> the actual missle drawing could be done
> simply be using the current vector. it may not be perfect visually, but it will be close >enough and players are not likly to notice. you could also just have it
> always face the target. though that may cause an undesirable look.

The actual missile is actually drawn by the quaternion representing its orientation,
how else would it be drawn correctly? Anyway, thats a graphics engine issue...

>targetVector = shipPos-targetPos;
> desiredVector = normalize(missleVector-targetVector);
> newVector = missleVector +(desiredVector*missileAcceleration);

When you say ship pos, I am assuming your talking about the vector representing the missiles current location.
surely you mean targetVector = targetPos - shipPos?
That will yield the vector of the target relative to the ship/missile, which I assume
is what your going for? This is important to get right, so please correct me if Im wrong.
Also, when you say Vector, Im going to assume you referring to velocity vectors.

> desiredVector = normalize(missleVector-targetVector);

targetVector is a position vector now. Which you subtract from a velociy vector.
Im assuming your using ship and missile interchangably. (!)
Im not sure exactly what desiredVector now contains, I dont understand the subtraction of
a position vector from a velocity vector well enough. It doesnt make sense to me,
and Id be grateful if youd explain it.
>newVector = missleVector +(desiredVector*missileAcceleration);

Could you also explain this line in a little more depth? You are multiplying the
vector, which is a velocity, times the acceleration. I see what your getting at here
a little bit, but isnt it a bit arbitrary to just multiply by acceleration to make it
bigger??
What am I supposed to do with "newVector"? is this the one I should now turn to face?
Im very confused with this solution.

Timkin:

Again, I still fail to see how attempting to reduce that vector will lead to a homing
behaviour.
I also do not understand fully how you mean to decrease the angle/distance, as you dont
give any method of doing that, or say which way a missile should turn in order to do that.
Obviously, the missile is trying to decrease the distance to its target. What I am seeking
is a _way_ of mathematically determining the vector it should follow in order to best
decrease that distance.
I suppoes it could try turn various ways, and attempt to see which ones give the best
results over time, but this would be difficult, as a missile moving with momentum in
the wrong way could try turn towards the correct vector it should follow, thrust, and be
even further from the target.
I guess you could implement a solution which deals with decreasing momentum/velocity in
an undesirable direction, however there is no advantage to that over just turning to face
the right direction - namely we still have to work out what that direction is, the original

a person:

>but you need trig to get the angles.
what angles, please? Also bear in mind I already _have_ a turn to face vector method,
which Im very proud of, it having taken hours of work. I need an intercept target method,
which relies on discovering which direction to turn and face, based on velocities and positions.

>i think the part you are getting confused on is the defination of a vector. a vector
>contains two things. a direction and magnitude.
>thus:
>missleVector is the direction of the missile and its speed.
>targetVector is the distance and direction to teh target from the ship.

>desiredVector = normalize(missleVector-targetVector);

Yes, but that doesnt mean it makes sense any time you automatically subtract one
vector from another! If I represent population growth as a vector, and
raspberry jam density as a vector, it doesnt mean the resulting quantity makes sense!
And I believe thats a bit like what youve done.
You take a velocity vector, "missileVector" and a position vector (relative to the missile)
and just subtract them... thats fine, but in the context of your method I cannot see
how it leads to a desired vector.
Again, I may be utterly wrong here, I would glady be corrected, as I just want a solution...
I would be indebted if you could please explain it a little more detail so I can understand.

>thus subtracting the missile direction from the target direction gives the required change
>of thrust in each angle.

Change of thrust in each angle? huh? What angles!? where did we get the angles from?
>acceleration value, ie the turning velocity.
I dont understand how acceleration in this context has anything to do with "turning velocty"
In fact I dont even understand "turning velocity" do you mean the angular velocity at which a ship can turn?
Ill be happy to assume that its infinite (as the constant correction of
course neccessary due to finite turning speeds should have a minimal impact on trajectory.
ie, the missile should be facing mostly the rigth way most of the time anyway, and corrections
need be small compared to the disance covered.)

I dont really understand your method; Im not bad at this sort of thing, please bear with
me and explain it in a little more detail.

fup :

> He asked how to move the ship towards the target. Both myself and ''a person'' have given
>him simple answers that solve his problem. Furthermore, the
> Reynolds paper I directed the OP to shows how turning rates may be implemented (if I >remember correctly).
> It doesn''t get any more basic than ''seek''

I still dont think ive seen a solution that deals with my particular problem, for the
reasons stated.
Your right, the problem is just to move towards the target. But a major part of that is dealing with your own intial momentum as you attempt to move towards it. And the optimum vector to reduce your momentum, and
move you towards the target at the same time, will depend on the distance to the target.
Which will depend on the vector. Im still stuck here...

If you always try turn to fact the target, and the target moves _at all_, or you arent point towards it at the start, and you dont have a way of dealing with your own momentum, your going to miss.
Not good homing code.
I still need to solve this problem.

Feral.