problem with angle and direction

[zygoth]

Okay, here is my code:

CreateActor---> angle = direction(x,y,target.x,target.y);
directional_velocity = 5;

however, instead of going towards the target, it just goes in the same direction, every time, with just a few degrees of difference when the target moves. I have tried converting to degrees or to radians but either way it doensn't help any. What am i doing wrong???

[DST]

Is this a missile or a bullet?

If its a missile that homes, put it in draw actor instead of create actor.

[zygoth]

it's just supposed to be a bullet

[DST]

Is the target a child of some other actor?

[pyrometal]

You have to set the velocity before the angle. Just inverse both lines of code.

[zygoth]

to DST: yes
to pyrometal: i'll try it... but why does it matter what order they are put in?

[feral]

to pyrometal: i'll try it... but why does it matter what order they are put in?

first think of xvelocity and yvelocity as functions..

when you say xvelocity=10 you are simply telling a function that on each redraw of the actor x should be the current x plus 10

now, when you do directional_velocity you are telling a function that x should equal something and y should equal something BUT, to get the overall directional speed the function needs to know the angle first, so it can calculate how much x is and how much y is in order for the actor to move in that direction at a certain speed.

so you set the angle, then the overall velocity (directional_velocity) , the function then works by basically setting up a separate xvelocity and yvelocity based on the given angle..

if you use the directional velocity first, it will work out the x and y velocitys based on the last angle given ( often defaulting to zero as the angle may not have even been set yet)

so changing the angle variable AFTER the velocity is calculated does not do anything, unless you then recalculate the velocity by issuing another directional_velocity command..

this is why sometimes it seems to work, and other times not, as usually the angle and directional_velocity is set in the Create Actor (only called once, so it MUST be in correct order)

but, if you use it in the Draw Actor it gets called again each draw action, so appears to work regardless of order

this is because you if you set the directional_velocity first , then the angle, on the next Draw Actor the directional_velocity will be called again then it can use the angle set last draw.. if that makes sense .. so in a fashion it will work, but will be glitchy..

this is how I believe it works... but if I am wrong can someone more experienced let me know..

feral

[pyrometal]

I see what you mean feral, but its slightly different in this case... The order it is called in this case is irrelevant since both variables are updated before the next frame is recalculated. For some reason, I had this bug before and this solved it for no apparent reason. BUT I have a theory: setting a direction to a zero vector(the directional velocity in this case) is not accomplishing anything, therefore the angle "may" be reset to its default value because of this fact... I assume that there is in fact, no actual directional velocity variable affecting the engine, but rather, only its 2 components, the x and y velocities... When you call directional_velocity to change it, I imagine some part of the engine convert this data into its component form. Same with the angle value, it would be calculated from the components. So, if you try to get the direction of a vector with all 0 components, there is no result, and the default 0 angle is returned... SO! If the directional velocity is set first, then it creates non-zero components, and from these we can get an angle which can actually be modified. Tell me if I don't make any sense.

[feral]

Tell me if I don't make any sense.

not sure my ears started to bleed about half way thru the post....

I am not sure what comes first now.... the angle of the chicken ? or the directional_velocity of the egg ?

I assumed, as you did, that engine uses only the xvelocity and yvelocity to move an object in a certain direction...

I also see what you mean about all variables being updated at once before the next redraw and therefore the order would not matter..

anyhow to clarify

if i was to write a routine called directional_velocity myself

I would need first the "speed"....... which is how many pixels to move the sprite next turn
and then i would need the angle to move them

the speed ( or amount of pixels next turn) then becomes a the long side of a Pythagorean ( right-angle triangle formula) which would allow me to calculate how many X , and how many Y pixels to move to get the desired result.

the directional velocity, as such, becomes hypotenuse of a right angle triangle, and the new x and y velocities would be calculated from that, but i would need the angle first.

ie:
y=sin(angle)*directional_velocity
x=cos(angle)*directional_velocity

so on the next redraw move X amount sideways... and Y amount up .. and this results in the required directional velocity at the required angle..

in a nutshell.. you need an angle, and how far to move, then the new x,y can be calculated..

you cannot however calculate an angle... knowing only the velocity ??

therefore methinks.. you are right, in that, the variables are both set before the next redraw,

but I think it is the xvelocity and yvelocities that are set, and not the directional velocity

ie: in draw actor i might say

angle=10 //->this variable would updated during this draw session
directional velocity=15 //- >BUT, this is NOT updated as a frame calculation, as it does not exist as a (usable) variable

(IMHO) but instead is used to calculate two new variables, the new xvelocities and yvelocities which are then updated

then on the next frame the recalculated xvelocity and yvelocity are used..not the directional velocity as it stands

in fact i wouldn't be surprised if the new xvelocities and yvelocities were never recalculated again, 'unless' the directional velocity or angle changed - this is how i would do it..

what do you guys think ? sorry if i sound argumentative, but this seems to be an ongoing source of problems for all of us, so if we can nutit out , sort out how it works, or annoy poor makslane enough with our ramblings, t will probably solve a lot of problems in the long run.

good grief.. I hope someone has got a better idea about this cause now my hair is falling out and my eyes are bleeding

feral
ps; sorry pyro, you probably explained it all perfectly in your post, and I just did not get it in the first place

[feral]

sorry to be a nag

but to make what i am thinking a bit clearer i did a demo

dir_demo.zip

(16.1 KiB) Downloaded 109 times

you can see in the demo that once the directional velocity (the var "speed" in this sample ) is passed on to a function it is never needed again unless it changes, and it actually can be passed out of the current frame, recalculated out to the new variables xspeed and yspeed ( what would normally be xvelocity and yvelocity) and passed back to the same frame, in the same calculation..

feral

or if nothing else we can always fix up the function in this demo, because you have to pass angle and velocity at the same time... LOL

[pyrometal]

I agree with what you are saying. I was simply suggesting that if you try modifing the angle of an object with x and y velocities 0, the recalculated x and y velocities are also zero. Let's remind ourselves that this "angle" variable is probably ficticious and only serves to modify the two velocities and nothing else.

THIS MEANS: when you call "angle = 45;" it only changes the velocities to represent this angle, and this 45 degree value IS NOT actually stored anywhere because it doesn't actually exist.

Is this clearer? Sorry if I sound rude, that isn't my intention, I just needed to use emphasis on some key points...

[DST]

OMG! This is way too much!

Children Share Parent Struct! That's why you can't hit it!

You can't access any properties of a child without some formula to deduce its modifier of the parent struct.

That's not what child parent is for, and yes, it'll mess ur xy up every single time!

Unparent, take ur child actor, and tell it

Code: Select all

x=otheractor.x; y=otheractor.y;

You'll be amazed!

[zygoth]

ummmm...

I'm in the middle of a trip to Texas right now, so I can't work on my game...but to me it sounds like DST is right. But what should I do again? I didn't understand your last post. But the actor has to be a child of the view. that is just how my game is. anyway... tell me what to do and I'll try it as soon as I get home.

[pyrometal]

I give up, looks like I can't convince anyone with my logic, maybe too complicated to explain with text... Cast my opinion in oblivion if you wish...

[DST]

Ur moving actor is child of view? why? Sure, score, ammometer, healthbar...they are all children of view. but you don't shoot at them.

Please explain why ur actor is child of view? Is it to preserve him from activation region to activation region? and if he is, then he never moves against view does he?
which means you already know his xy, and using direction command for an xy you already know is just wasting cpu.

Not trying to be a jerk, just trying to help.

Also, to Pyro: Suck it up, buttercup!!!!!!!!!!!!!!!!!!!:D