Advanced maths: Z-angle for projectile. Smooth curve.

[Wietlol]

Hi all.

I am writing a missile system that allows easy control over collision filtering, allows you to give a maximum distance or duration to the missile, use an existing unit as the missile, allows multiple collision types, uses 3d distance rather than 2d distance and thus allowing to shoot straight in the air (flawless).
And you are all free to give more suggestions ofcourse.

The problem is that I lost my sense of logic when I want a perfect smooth curve.

Missiles can be fired with a startoff arc. Then the missile must determine how much it should decrease it's arcing (every 0.03 seconds) to land with the same impact Z-angle as the startoff Z-angle.
So I figured that the missile should have dropped to 0 degree by the time it reaches half the distance.
So I know the starting location (x,y,z) and the targeted location (x,y,z) and know the startoff Z-angle and the speed (over the curve not over the ground).
How do I calculate how much degree the missile should drop in one second (so I can do *0.03)

Yes my MS Paint skills show off again :D

This will be a autocalculator for physical objects like arrows... except that they still have yet to gain gravity effects.
So this calculation will be made at the creation of the missile and if someone decreases the missile speed, the arrow would hit the ground before it reaches it's target point and if someone would increase the missile speed, the arrow would reach further.

 

[rulerofiron99]

It's much easier if you use components:

x = x + dx (move along x)
y = y + dy (move along y, combine with x to give you cartesian movement)
z = z + dz (move height)
dz = dz + ddz (apply gravity)

sqrt(dx^2 + dy^2) gives you your cartesian speed

tan(dz/speed) gives you your vertical angle

Use your xy speed to calculate the time (number of ticks) to the target location, and from there use d = v*t + 0.5*a*t^2 to get what your initial dz should be.

Take a look at the attached map, it's got a bit of added fluff but it shows the basic method.

sqrt(dx^2 + dy^2 + dz^2) gives you your missiles "real" speed. Use trig to change one of the component speeds from an altered real speed.

 

[Wietlol]

I use Cos and Sin to calculate distance rather than cartesian... because that is how it is done in the nice example of PolarProjectionBJ()

set horizontalShare = Cos(udg_CMS_Param_Arc * bj_DEGTORAD)
set verticalShare = Sin(udg_CMS_Param_Arc * bj_DEGTORAD)
set oldLocation = GetUnitLoc(udg_CMS_Param_Missile)
set newLocation = PolarProjectionBJ(oldLocation, distance * horizontalShare, udg_CMS_Param_Angle)
call SetUnitX(udg_CMS_Param_Missile, GetLocationX(newLocation))
call SetUnitY(udg_CMS_Param_Missile, GetLocationY(newLocation))
call SetUnitFlyHeight(udg_CMS_Param_Missile, height + distance * verticalShare, 999)
call RemoveLocation(oldLocation)

I have not tested it so I might have a miscalculation but I think that it is right.
arc being the degree to Z with 0 being horizontal (parralel to flat ground) and 90 being straight to the top.

I want that the distance (travelled, maximum, etc) is the distance over the curve rather than over the ground.
So a unit that fires an arrow with very high arc towards a point with 500 distance from the caster, will make an arrow that fires way longer than 500 units distance.

Don't ask me why but trust me I want it. I do not make systems myself because I just want to ignore other people... actually I do but that is another story

Anyway there are a few different types of missiles.
One being magical missiles that will just change their angle and arc towards the target as much as they are allowed and travel the remaining distance straight towards their target.
That one is easy to implement.

I do see that my method of physical objects is a bit broken unless I implement simple gravity from the start.
Increase speed according to arc. If arc is below 0 the speed will be increased. If arc is above 0 the speed is decreased.

I think that on that way I can add one arc-chage value and make it land on the exact right spot.

However the targeted location is lost when the missile is created... at least it cannot be used any more. Because if someone would increase the missile speed it would not land on that location any more.
So I need that arc-decrease value to make it fly properly.

So we have
- Starting arc
- Starting location
- Targeted location (also distance from Point(x,y,z) to Point(x,y,z)
- Speed
- Speed increase/decrease according to arc. (decreasing speed by (0.03 * arc(in degree) * factor) That factor will be somewhere between 0.5 and 1.5... depending on how it would fit.)
We/I need
- Arc decrease so the missile will hit the target location if no alternative factors take effect.

Be aware that the stating and targeted location can have height difference.
For example flying height when either the attacker or defender is flying or ground height.

I know that this is hard but if it was simple... I would not have made a thread about it.
I lost my sense of logic in this and I am ussually the one who would solve these things.

About the KingsOfTheMountain... I assume that I need the "Projectile Looping".
As I mentioned above... It is a bit more complicated than that :\
I took a look at the missile systems that I have seen so far and they all have XY_Distance instead of XYZ_Distance.
So I cannot fire arrows straight up in the sky and I cannot make perfect use of no-target-flying (where the missile will not be homing and just see where it wil end up.)

 

[GhostWolf]

Your question is malformed.

If you have both starting and ending positions, you are only left with three things you can parametrize: the height of the arc, the time it will take to complete it, or the angle and speed. Each one derives the others, so you can choose to use either of them.

Once you define one of them, you can drive from that the velocity needed to fire the projectile, using this elementary equations:

x` = x + vt
y` = y0 + v0*t + 0.5*a*t^2

I use Cos and Sin to calculate distance rather than cartesian... because that is how it is done in the nice example of PolarProjectionBJ()

Not only are those the same thing, you are also using the function incorrectly. All PolarProjectionBJ does is use sin and cos to derive the coordinates:

x` = x + distance * cos(angle)
y` = y + distance * sin(angle)

 

[Wietlol]

If you have both starting and ending positions, you are only left with three things you can parametrize: the height of the arc, the time it will take to complete it, or the angle and speed. Each one derives the others, so you can choose to use either of them.

I got he angle and speed so I should be able to define the duration of the flight.

Once you define one of them, you can drive from that the velocity needed to fire the projectile, using this elementary equations:

x` = x + vt
y` = y0 + v0*t + 0.5*a*t^2

Except that I do not know what "v", "t" and "a" are.
I don't have the velocity needed but I have a raw velocity value.

Not only are those the same thing, you are also using the function incorrectly. All PolarProjectionBJ does is use sin and cos to derive the coordinates:

x` = x + distance * cos(angle)
y` = y + distance * sin(angle)

I must respectfully decline.
They are different because Cartesian uses length of 2 of the 3 edges while Cos and Sin uses the angle between the lines to determine how much one small edge is according to the other.
It is the exact opposite or Cartesian.

Also the calculations are right... I guess.

set x = GetLocationX(source) + dist * Cos(angle * bj_DEGTORAD)
set y = GetLocationY(source) + dist * Sin(angle * bj_DEGTORAD)

That is PolarPojectionBJ()
So if I turn it 90 degrees. X axis is 0 degrees and 180 and Y axis is 90 and 270.
So X = Vertical and Y is Horizontal if I rotate it 90 degree.

Then I use degrees in the variable "Arc" and use that one instead of angle.
So I have a factor for Horizontal and Vertical distance.

set horizontalShare = Cos(udg_CMS_Param_Arc * bj_DEGTORAD)
set verticalShare = Sin(udg_CMS_Param_Arc * bj_DEGTORAD)

So Now I know how much distance is traveled over X-Y grid which is (distance * horizontalShare)
And I know how much height difference the missile has. Which is (distance * verticalShare)
Those have to be added to the current X-Y location and current height. (For height it could be possible that it has to be removed from instead of added to.)

 

[rulerofiron99]

As I mentioned above... It is a bit more complicated than that :\

Isn't simplicity with the same capability the preferred option when comparing two methods?

All of your variables and convert to and back from component form.
Starting arc can be calculated using XY speed and Z speed.

If a missile's speed, angle, position or anything is every changed, you just calculate what it should be to land at the new location by plugging known values into one of your UVATS equations (e.g. in GhostWolf's post)

So I cannot fire arrows straight up in the sky and I cannot make perfect use of no-target-flying (where the missile will not be homing and just see where it wil end up.)

You absolutely can.

A missile flying straight up has
dx = 0
dy = 0
dz = something, e.g. 20

Every tick, gravity (ddz) reduces its dz, making it go up slower and slower until eventually coming down.

If we aren't being helpful, it's because we don't quite understand what the issue is.

What exactly are you trying to do, what exactly is the problem?

 

[Wietlol]

Isn't simplicity with the same capability the preferred option when comparing two methods?

Sorry I misunderstood cartesian... when I read your first post, I thought you meant pythagoras... I am not english and this is the first time that I use maths in english

Anyway to get on the same level.
I know the 3D-distance that the missile has to travel and I know the angle and pitch/arc.
So I can convert those to the X-distance, Y-distance and Z-distance with sin and cos.
If I have the X-distance, Y-distance and Z-distance, I can convert that to the 3D-distance with pythagoras.
What cartesian has to do with this... I don't know but he seems unnecessary.

If a missile's speed, angle, position or anything is every changed, you just calculate what it should be to land at the new location by plugging known values into one of your UVATS equations (e.g. in GhostWolf's post)

Well what I want to have is a missile system that calculates what it has to do when it creates so it will land on the requested spot.
After that, the missile should move and land on that location(x, y, z) without the reference to that location.
The route must be saved in speed, arc, arc-decrease, angle and not in targeted_location.

That is what I want.

A missile flying straight up has
dx = 0
dy = 0
dz = something, e.g. 20

Every tick, gravity (ddz) reduces its dz, making it go up slower and slower until eventually coming down.

Yes but all missile systems that I have seen so far neither support Z-location of starting-location nor Z-location of targeted-location.

 

[GhostWolf]

I got he angle and speed so I should be able to define the duration of the flight.

...now stop for a second and actually think about what you wrote.
You have the angle and the speed, who together form a velocity vector.
If you already defined a velocity, how on earth can you "define" the duration of the flight? does time suddenly slow down? speed up?
It is derived from your already defined parameters.

Except that I do not know what "v", "t" and "a" are.
I don't have the velocity needed but I have a raw velocity value.

You can play around with those equations to get the variables, using your known values.
I don't know what "raw velocity" means.
Since you have the angle and speed, you have the velocity.

I must respectfully decline.
They are different because Cartesian uses length of 2 of the 3 edges while Cos and Sin uses the angle between the lines to determine how much one small edge is according to the other.
It is the exact opposite or Cartesian.

Ok, let me rephrase that, you don't get "distance" from "Cartesian", it's a coordinate system.
Neither are you getting a distance using trigonometry functions, since they return ratios.

Also the calculations are right... I guess.

set x = GetLocationX(source) + dist * Cos(angle * bj_DEGTORAD)
set y = GetLocationY(source) + dist * Sin(angle * bj_DEGTORAD)

That is PolarPojectionBJ()
So if I turn it 90 degrees. X axis is 0 degrees and 180 and Y axis is 90 and 270.
So X = Vertical and Y is Horizontal if I rotate it 90 degree.

Then I use degrees in the variable "Arc" and use that one instead of angle.
So I have a factor for Horizontal and Vertical distance.

set horizontalShare = Cos(udg_CMS_Param_Arc * bj_DEGTORAD)
set verticalShare = Sin(udg_CMS_Param_Arc * bj_DEGTORAD)

So Now I know how much distance is traveled over X-Y grid which is (distance * horizontalShare)
And I know how much height difference the missile has. Which is (distance * verticalShare)
Those have to be added to the current X-Y location and current height. (For height it could be possible that it has to be removed from instead of added to.)

That one is ok, didn't notice you are calculating the velocity, becuase your 4 lines of Jass are messier than a pile of poo.

 

[Wietlol]

...now stop for a second and actually think about what you wrote.
You have the angle and the speed, who together form a velocity vector.
If you already defined a velocity, how on earth can you "define" the duration of the flight? does time suddenly slow down? speed up?
It is derived from your already defined parameters.

Calculate*
When I have angle and speed, I can calculate the duration.
Sorry.

You can play around with those equations to get the variables, using your known values.
I don't know what "raw velocity" means.

Since you have the speed, you have the velocity... because those are the same.
The velocity is a raw value rather than a dynamic value dependant on the angle and speed.

Same as normal WC3 abilities. If you make the missile have 10000 speed and 0.15 arc it will land properly and if you have 0.01 arc it will land properly as well.

Ok, let me rephrase that, you don't get "distance" from "Cartesian", it's a coordinate system.
Neither are you getting a distance using trigonometry functions, since they return ratios.

And I use those ratios * distance to calculate the new location of the missile.

That one is ok, didn't notice you are calculating the velocity, becuase your 4 lines of Jass are messier than a pile of poo.

... I didn't calculate the velocity. I calculate the new location of the missile.
I use velocity to move the missile (0.03*velocity) (aka distance) towards the new location.
I move the missile (distance * horizontalShare (which is the ratio)) towards the angle of the missile.
And I move the missile (distance * verticalShare) up so it will gain/lose height.

 

[Cokemonkey11]

Missile arc in wc3 does not obey conventional laws of physics for game design and performance reasons.

All of your arguments boil down to one simple explanation: cosine and sine calculations are not free, and the cosine of a constant is also a constant.

 

[GhostWolf]

CSince you have the speed, you have the velocity... because those are the same.
The velocity is a raw value rather than a dynamic value dependant on the angle and speed.

That's called speed, which is a number. Velocity is a vector (unless you work in a one dimensional space).

... I didn't calculate the velocity. I calculate the new location of the missile.
I use velocity to move the missile (0.03*velocity) (aka distance) towards the new location.
I move the missile (distance * horizontalShare (which is the ratio)) towards the angle of the missile.
And I move the missile (distance * verticalShare) up so it will gain/lose height.

And...that's called velocity. The rate of change in position over time, or dx/dt in nerd.

 

[Wietlol]

Ok... so we know the starting location, starting angle, velocity and targeted location.
I think that I won't do gravity though.

So that would leave us with a formula to calculate the arc decrease wouldn't it?

 

[Cokemonkey11]

Velocity is a vector (unless you work in a one dimensional space)

Still a vector

 

[GhostWolf]

Ok... so we know the starting location, starting angle, velocity and targeted location.
I think that I won't do gravity though.

So that would leave us with a formula to calculate the arc decrease wouldn't it?

And that's still called gravity.
Why are you trying to make it hard for yourself...

Still a vector

Bah, semantics.

 

[rulerofiron99]

Well what I want to have is a missile system that calculates what it has to do when it creates so it will land on the requested spot.
After that, the missile should move and land on that location(x, y, z) without the reference to that location.
The route must be saved in speed, arc, arc-decrease, angle and not in targeted_location.

That is what I want.

The method I used does this, the only difference being that it saves the data in easy-to-work-with components.

You mentioned in a post you move by the HorizontalShare and height by the VerticalShare, those are the XY speed (horizontal) and dz that I describe.
Now take that a step further and divide your HorizontalShare into the X and Y components, and you have:
dx
dy
dz
These are the only three variables your missile needs - it does not need to remember the launch location or the target location.

The looping trigger does:
set unit x = unit x + dx
set unit y = unit y + dy
set unit height = unit height + dz
set dz = dz - ddz (gravity)

You set them at launch:
dx = (horizontal speed) * cos(angle)
dy = (horizontal speed) * sin(angle)

Use horizontal speed to determine number of ticks (time) to target point. Since the XY/horizontal speed is constant, dividing distance by speed gives you exactly how many ticks the missile will move until it reaches its target.

Next, use the number of ticks (time) and your gravity constant to determine what the starting dz (and thus launch angle) will be. If you aren't taking terrain height into account, dz = gravity * time * 0.5. At the apex of the trajectory (half way), the missile's dz will be exactly 0, so you just need to give it enough dz to lose all of it by the time it reaches halfway.
If you want to use a fixed starting arc, you could instead change the gravity (aka ddz, save a different value for every missile).

The remaining issue with the method I've described here is that your missile's real speed (XYZ speed) will not be the same at launch if you launch missiles at different distances.

It's do-able with a bit of calculus (sadly I'm out of practice so it would take me a while to assist here), but is it really needed?

 

[GhostWolf]

The remaining issue with the method I've described here is that your missile's real speed (XYZ speed) will not be the same at launch if you launch missiles at different distances.

It's do-able with a bit of calculus (sadly I'm out of practice so it would take me a while to assist here), but is it really needed?

Actually that's not physically possible...you need more speed to travel greater distances.

 

[Kazeon]

I'm not sure if this helps, but movement in this realm is only composed by two velocities (I'm not science people so dunno what should it's called), they are horizontal and vertical velocity. In 2D movement, vertical is represented as (commonly) y coordinate, while horizontal is x coordinate. In 3D dimensional movement, horizontal velocity is formed by two other velocities: x velocity and y velocity:

xVelocity: horizontalVelocity * Cos(angle)
yVelocity: horizontalVelocity * Sin(angle)

While vertical velocity is only composed by one, I used to call it zVelocity.

Horizontal-ish factors such as friction and the others are applied to horizontal velocity. While other vertical-ish factors such as gravity, unit mass, etc. are applied to vertical velocity.

By understanding the basic concept of movement physics will help you a lot on making these kind of stuffs. You won't need such complicated formulas, but with helps of trigonometry, a very complex and advanced movement can be achieved easily.

I want to explain by pictures but I have no time atm, it's really hard to explain this since I'm not a scientific people. Perhaps it's not understandable. Sorry for that.

EDIT:
I will try to explain further of course, but not now.

 

[Wietlol]

And that's still called gravity.
Why are you trying to make it hard for yourself...

Yea... some kind of.
But if I would add gravity, the gravity would not increase or decrease that amount. It will increase or decrease the missile speed instead.
I know it sounds crazy but it actually works... on paper. So I need the formula that will calculate how much the arcing should be at start.

You mentioned in a post you move by the HorizontalShare and height by the VerticalShare, those are the XY speed (horizontal) and dz that I describe.
Now take that a step further and divide your HorizontalShare into the X and Y components, and you have:
dx
dy
dz
These are the only three variables your missile needs - it does not need to remember the launch location or the target location.

Everything that the missile has to remember is
- Missile Speed
- Current Angle
- Current Arc
- Arc Decrease
When I create a missile, I give Missile Speed, Current Angle and Current Arc.
Arc Decrease has to be made with a formula at the creation of the missile.
That formula requires
- Missile Speed
- Horizontal Distance
- Starting Arc (which is Current Arc)
- Vertical Distance
- Weight of the missile (I think that the speed reduction is pretty much required)... however there must be an option to disable gravity for magical projectiles for example.

With a formula that uses those variables, it will return the required arc decrease to reach the targeted location without re-calculation to target.

The looping trigger does:
set unit x = unit x + dx
set unit y = unit y + dy
set unit height = unit height + dz
set dz = dz - ddz (gravity)

You set them at launch:
dx = (horizontal speed) * cos(angle)
dy = (horizontal speed) * sin(angle)

Use horizontal speed to determine number of ticks (time) to target point. Since the XY/horizontal speed is constant, dividing distance by speed gives you exactly how many ticks the missile will move until it reaches its target.

I think you forgot the part where I mentioned that the speed of the missile is 3D-Speed... Horizontal Speed changes depending on arc.
That is why that stuff above is required to make proper calculations.
If I fire a missile with 90 degree arc... it will have 0 horizontal speed...
So according to you... I use horizontal speed (0) to determine the time that the missile has to fly...
Time in Seconds = Total Distance / Missile Speed (per second)
(Ticks = Time in Seconds / 0.03)
Time in Seconds = 900 / 0 ... Divided by zero... BY ZERO!!!
I assume that I don't have to explain further.

It's do-able with a bit of calculus (sadly I'm out of practice so it would take me a while to assist here), but is it really needed?

Well... yes I need this system to fit in my map.
I have searched for good missile systems but couldn't find one.
No offense, but they do not do what I want.

I'm not sure if this helps, but movement in this realm is only composed by two velocities (I'm not science people so dunno what should it's called), they are horizontal and vertical velocity. In 2D movement, vertical is represented as (commonly) y coordinate, while horizontal is x coordinate. In 3D dimensional movement, horizontal velocity is formed by two other velocities: x velocity and y velocity:

xVelocity: horizontalVelocity * Cos(angle)
yVelocity: horizontalVelocity * Sin(angle)

While vertical velocity is only composed by one, I used to call it zVelocity.

Horizontal-ish factors such as friction and the others are applied to horizontal velocity. While other vertical-ish factors such as gravity, unit mass, etc. are applied to vertical velocity.

Yes but we already had that... did we?

By understanding the basic concept of movement physics will help you a lot on making these kind of stuffs. You won't need such complicated formulas, but with helps of trigonometry, a very complex and advanced movement can be achieved easily.

The point is that I need an autocalculator for starting arc.
If I know the starting arc... I can handle the remaining things...

I will try to finish the movement asap and then post the map.
It might explain a bit better what I need.
Or I might see what I cannot see what you all are tryin to tell me.

 

[GhostWolf]

Oh my god........................

Your projectile needs to store exactly one 3D vector - its velocity. If you want weird projectiles, you can add a gravity modifier.

What the hell is "arc decrease"............
You shoot at some velocity, every step the projectile moves with said velocity, while the up velocity (Z) decreases by the gravity (or you can have 3D gravity, or whatever you want).
That's all there is to it.

The actual problem is how to calculate the starting velocity, so that at the end it will reach the target.

When you stop writing nonsense, and want to solve that problem, you'll see you can solve it in a few different ways, depending on what you want to parametrize.
E.g.: shorter time leads to a smaller angle, longer time leads to a bigger angle.
OR: lower height leads to shorter time, higher height leads to longer time.
OR: higher gravity leads to shorter time and lower height, lower gravity leads to longer time and higher height.
Etc.
They are all DEPENDENT and are derived from each other.

http://en.wikipedia.org/wiki/Projectile_motion
http://en.wikipedia.org/wiki/Trajectory_of_a_projectile

OR, you can keep using your own terms, unrelated to any actual physics, and make no sense.
Good luck.

 

[Kazeon]

@Wietlol
"Arc" should be a parameter for user. And there is no something called "starting arc", it's just "arc".

However, if only you have already both vertical and horizontal velocity, then you can calculate the arc:



a is initial vertical velocity
b is initial horizontal velocity
and x is your arc, hence:

x = atan(a/b)

But it's still in radian, you can use bj_RADTODEG to convert it to degree.

As GhostWolf said, the arc is not decreasing, but the vertical velocity is. Again, you should understand the basic concept first.

EDIT:

And what's wrong with this formula?

(4.00 x max height / max distance) x (max distance - current distance) x (current distance / max distance)

Since there's no one yet to set the standard value of gravity for wacraft world (which probably will causes inconsistency), I think that formula is the easiest option.

EDIT 2:



Don't ever think that the trajectory would be a perfect curve (pic 1). But it's actually more like pic 2.

So how to calculate the "current arc" (for dummy's pitch angle) is the same as above:



But,
a is current vertical velocity
b is current horizontal velocity

But again, the arc is not decreasing, but it should be based (calculated) from those two variables above.

EDIT 3:

In case (the standard case) the arc and vertical speed become parameters for user then you should calculate the initial vertical velocity:



a = tan(x)*b

But again, you should apply "gravity" to the vertical velocity in this case, which is not the best solution.

 

[Xonok]

Firstly, forget the arc nonsense. A projectile system should not do anything with arcs except during launch. It will slow down the system, make it more complicated and still not actually solve anything.

The method that I use works with a static constant velocity for horizontal(makes sense really) and a variable vertical launch velocity, which is based on the horizontal.
Trying to do "true speeds" is suicide in WC3, as it completely rules out any kind of accurate interception algorithm, which is needed for me.

You need a few variables.
Velocities:
Vx
Vy
VZ
and accelerations:
Ax
Ay
Az

For launching a projectile you need a few things:
Starting position
Final position
Speed of the projectile(horizontal)
Gravity(positive;variable on a per-projectile basis)

From those you can calculate all other relevant variables.

Calculating Vx and Vy is trivial:
Vx = speed * Cos(angle*bj_DEGTORAD)
Vy = speed * Sin(angle*bj_DEGTORAD)

The formula for Vz is more elaborate:
((targetZ-sourceZ)+((gravity*time*time)/2))/time

and for gravity:
Vz = -gravity

This gives you a clean arc, no matter the distance. Longer distances produce higher arcs, with the height increase based on gravity. The more gravity there is, the higher the starting vertical velocity has to be, thus the higher arcs.

For calculating the height that the projectile will reach you can use this formula:
(Vz * time)/2
It's essentially the same formula as for calculating the impact speed of a falling object.

 

[Kazeon]

@Xonok:
How can I set dummy's pitch angle using your method?

Arc is not a nonsense. In fact, native wc3 missile does use arc as one of it's parameter.

EDIT:

And my method still wins in term of simpleness (or maybe speed).

It only calculates the vertical velocity at launch event which the formula is very lightweight:

verticalVel = tan(arc)*horizontalVel

Then on every tick you just need to do:

verticalVel = verticalVel - gravity

I'm failed to understand how your formula is "less complicated"

((targetZ-sourceZ)+((gravity*time*time)/2))/time

 

[Wietlol]

The actual problem is how to calculate the starting velocity, so that at the end it will reach the target.

I actually had a different meaning.
I want to find out at what angle the projectile has to be fired.
Look at a gun. You cannot change the velocity of the bullet very easy, so you change the angle at which the bullet is fired. (Maybe use a grenade launcher because it has a greater effect from gravity.)
I know that there will be 2 angles... So I must also have a parameter to tell if I want the highest or lowest angle.
I also know that there will be some angle where the projectile will reach it's maximum distance. In that case that angle should be used.

When you stop writing nonsense, and want to solve that problem, you'll see you can solve it in a few different ways, depending on what you want to parametrize.
E.g.: shorter time leads to a smaller angle, longer time leads to a bigger angle.
OR: lower height leads to shorter time, higher height leads to longer time.
OR: higher gravity leads to shorter time and lower height, lower gravity leads to longer time and higher height.
Etc.
They are all DEPENDENT and are derived from each other.

Ok. The point was that I also wanted to be able to make a magical (non-gravity) projectile fly in an arc... I guess my dream will not come true -_-

@Wietlol
"Arc" should be a parameter for user. And there is no something called "starting arc", it's just "arc".

As I said above, I want to calculate the best possible arc and use 3D-Velocity as a parameter for users.

As GhostWolf said, the arc is not decreasing, but the vertical velocity is. Again, you should understand the basic concept first.

Yes... but the basic concept is not applied on the magical projectiles as I said above... but will remove that feature so we can use the basic calculations.

And what's wrong with this formula?

(4.00 x max height / max distance) x (max distance - current distance) x (current distance / max distance)[/QUOTE]
Since there's no one yet to set the standard value of gravity for wacraft world (which probably will causes inconsistency), I think that formula is the easiest option.[/QUOTE]
Because I do not want to have max distance saved to the missile?
I don't really know what that formula should do but I am afraid that it cannot be applied in my system.

View attachment 143497

Don't ever think that the trajectory would be a perfect curve (pic 1). But it's actually more like pic 2.

Yea I realize that... but if the path would be made in 0.03 second ticks... I think that noone would notice the difference.
Except that the calculations might have a small difference.

But again, the arc is not decreasing, but it should be based (calculated) from those two variables above.

Again it would be if I had a magical projectile with an arc without using gravity... but nvm.

But again, you should apply "gravity" to the vertical velocity in this case, which is not the best solution.

Why is that not the best solution?
I think I said 3 times in this post that I will use that one because it is a better solution than what I intended before.

Also what value should I use in the formula for gravity?
"set Z-Velocity = Z-Velocity - (Weigth of Missile * (...))"

 

[Xonok]

@Xonok:
How can I set dummy's pitch angle using your method?

Arc is not a nonsense. In fact, native wc3 missile does use arc as one of it's parameter.

EDIT:

And my method still wins in term of simpleness (or maybe speed).

It only calculates the vertical velocity at launch event which the formula is very lightweight:


Then on every tick you just need to do:


I'm failed to understand how your formula is "less complicated"

Arc in the sense he appears to have meant it is nonsense, because recalculating these things on every tick is bs.

Your method is essentially the same as mine, except that it doesn't consider the possibility that the initial and final position may have different height.

 

[Kazeon]

As I said above, I want to calculate the best possible arc and use 3D-Velocity as a parameter for users.

Best possible arc? What kind of arc is that? Please, explain.

And 3D velocity is just composed by vertical and horizontal velocity. I have lost your problem now. I thought you want to get the "arc". If you have those velocities as parameter, then just use that formula above. Again, there is no "other arc" or "best arc" or anything, it's just "arc". It's the projectile's launch angle.

because recalculating these things on every tick is bs.

It's not required to do. It's just to determine dummy's pitch angle. Except if there is another formula which doesn't use function call.

 

[Wietlol]

Best possible arc? What kind of arc is that? Please, explain.

Best possible pitch? Angle? Arc?
If the missile cannot reach his target, it must be fired to reach the most distance as possible.
If the missile has 2 different angles that will end at the requested location then use the highest/lowest according to a boolean in the parameters.

And 3D velocity is just composed by vertical and horizontal velocity. I have lost your problem now. I thought you want to get the "arc". If you have those velocities as parameter, then just use that formula above. Again, there is no "other arc" or "best arc" or anything, it's just "arc". It's the projectile's launch angle.

I want to let my gun fire a bullet at 100 speed... 100 velocity.
That velocity is the 3D-Velocity.
Together with the Z-Angle, it can calculate Z-Velocity and HorizontalVelocity (aka sqrt(X-Velocity^2 + Y-Velocity^2))


So I have
- 3D-Velocity (the velocity of the missile)
- Starting location (x,y,z)
- Target location (x,y,z)
- Weight of the missile (that decreases the Z-Velocity after the gravity factor)
I need an autocalculator that calculates:
- HorizontalAngle (easy: PolarProjectionBJ())
- VerticalAngle (too hard for me)

 

[Kazeon]

- VerticalAngle (too hard for me)

It still applies the same formula:

x = atan(a/b)

where x is your VerticalAngle
a is (target loc's z - start loc's z)
b is speed

Give it a try.

- 3D-Velocity (the velocity of the missile)
- Starting location (x,y,z)
- Target location (x,y,z)

In this case, I don't understand why you even need the arc (vertical angle)? What do you use it for?

 

[Wietlol]

It still applies the same formula:

x = atan(a/b)

where x is your VerticalAngle
a is start loc's z
b is (target loc's z - start loc's z)

Give it a try.

I know but that was not what I meant.

What I meant is what Z-Angle does the missile need when it is fired.
I mean if I would do what you said, the missile would move directly to the target location but then the Z-Angle will drop because the Z-Velocity will be decreased through Gravity.

So what Z-Angle does a missile need when it is created if you have:
- Starting location (x,y,z)
- Target location (x,y,z)
- 3D-Velocity (sqrt(Z-Velocity^2 + X-Velocity^2 + Y-Velocity^2))
- Missile Weight

In this case, I don't understand why you even need the arc (vertical angle)? What do you use it for?

For the missile to be affected by gravity?

 

[Kazeon]

For the missile to be affected by gravity?

You don't need vertical angle here, after all ._.

Gravity has nothing to do with arc (vertical angle). Arc is only used to determine vertical velocity. While parabolic trajectory itself is generated by (zVel-gravity).

- 3D-Velocity (sqrt(Z-Velocity^2 + X-Velocity^2 + Y-Velocity^2))

What is that? What you need to do is generate vertical and horizontal trajectory using xVel, yVel, and zVel:

targetX = currentX + xVel
targetY = currentY + yVel

While zVel is added to unit's flying height. But the zVel should be decreased by "bullet's weight" or "gravity" on every tick. But with the presence of another factors like those, I'm not sure is it possible to make it accurately hit the target coordinate. Just keep it trivial, remove the bullet weight thingy.

EDIT:
Or maybe this is your solution:

Firstly, forget the arc nonsense. A projectile system should not do anything with arcs except during launch. It will slow down the system, make it more complicated and still not actually solve anything.

The method that I use works with a static constant velocity for horizontal(makes sense really) and a variable vertical launch velocity, which is based on the horizontal.
Trying to do "true speeds" is suicide in WC3, as it completely rules out any kind of accurate interception algorithm, which is needed for me.

You need a few variables.
Velocities:
Vx
Vy
VZ
and accelerations:
Ax
Ay
Az

For launching a projectile you need a few things:
Starting position
Final position
Speed of the projectile(horizontal)
Gravity(positive;variable on a per-projectile basis)

From those you can calculate all other relevant variables.

Calculating Vx and Vy is trivial:
Vx = speed * Cos(angle*bj_DEGTORAD)
Vy = speed * Sin(angle*bj_DEGTORAD)

The formula for Vz is more elaborate:
((targetZ-sourceZ)+((gravity*time*time)/2))/time

and for gravity:
Vz = -gravity

This gives you a clean arc, no matter the distance. Longer distances produce higher arcs, with the height increase based on gravity. The more gravity there is, the higher the starting vertical velocity has to be, thus the higher arcs.

For calculating the height that the projectile will reach you can use this formula:
(Vz * time)/2
It's essentially the same formula as for calculating the impact speed of a falling object.

 

[Wietlol]

You don't need vertical angle here, after all ._.

I want a missile system where I can set 3D-Missile-Velocity, Starting_Location(x,y,z), Target_Location(x,y,z) and Missile_Weigth.
Then a missile is created using those values.
Then the missile automatically calculates what Horizontal-Angle it should use and what Vertical-Angle it should use to do the best it can to reach it's target.
After that, Target_Location is removed and I want to see that my missile will move to that location without knowing where it has to land.

With 0 gravity, the Z-Angle should be Atan(HorizontalDifference, VerticalDifference) ... or the other way around but what the hell.

With gravity involved, the Z-Angle should be a bit higher so the missile would still hit it's target.

How do I calculate what angle that should be?!

What is that? What you need to do is generate vertical and horizontal trajectory using xVel, yVel, and zVel:

That is the velocity of the missile.
If the velocity is 100 and the Z-Angle is 45*, the XY-Velocity will be the same as Z-Velocity and will be somewhere near 70... I guess.

 

[Waffle]

Actually that's not physically possible...you need more speed to travel greater distances.

not necessarily.
certainly a low speed limits your maximum range but if you got enuff speed to reach say to the other side of the map then its pretty easy to find a trajectory that gets you to any point on the map with the same initial |v|
so..
how to go about this.. hmm..
what do we need be constant?
gravity? (or time?)
gravity seems more natural as a constant to me...
so..
then your left with 2 points and a curved line connecting them..
(sec while i do some stuff on paper..)

distanceMAX = sqrt(pow2(X1-X2),pow2(Y1-Y2))
now look at it another way
u need go from distance=0 to disttanceMAX
u also need go from Z == Z1 to Z==Z2

now lets take the movement functions..

if i recall correctly..
x = x0 +vt + a*pow2(t)/2
for horisontal movement we get
distanceMAX = 0 + horisontal_speed*t
for vertical we get
Z2 = Z1 + vertival_speed*t -gravity*pow2(t)/2
also
speed = sqrt(pow2(horisontal_speed)+ (pow2(vertical_speed))
so we got 3 equasions with 3 variables (the 2 speeds and time)
u solve this and then you get get the time as well as the initial vertical speed.
then u just need to extract the X and Y components of the horisontal speed and your there.


also..
weight (in reply to another post) has NOTHING to do with how fast the object falls.. like at all. basic physics dude..
u can make a custom gravitational constant for each projectile (type??) i guess but that would just get u nowhere..
just pick 1 global one or ull end up woith weird results, (real one approx 9.81 m/s^2 not that it matters)

 

[Cokemonkey11]

First of all, let's just recap what's going on in this thread so we can minimize misinformation and optimize correctness to the question being asked:

Wietlol wants to use constant gravity and initial projectile speeds (as in real world projectile motion) in a system so that, given a start and end location, a projectile will be launched through the correct trajectory that either (a) satisfies the start and end locations, as well as the fixed initial speed and in the fixed gravity, or (b) optimizes the trajectory to approach the correct start and end locations, given that no trajectory satisfies all of the requirements.

Second of all, some correct terminology is necessary. zAngle means absolutely nothing, except perhaps that it could be interpreted as an angle in the z-plane. This is not useful because (a) the angle on the z-plane changes dynamically in projectile motion, and (b) the dynamic value of the zAngle need not be maintained for projectile motion. Arc is the name of a segment of a curve - note that this is utterly unrelated to any kind of angle. The correct name for the angle you guys are ALL talking about is pitch. Thus, what Wietlol is trying to find, is how to calculate the initial pitch of a projectile that satisfies constant gravity, fixed initial speed (and therefore fixed horizontal velocity), and fixed start and end points.

1: For start location = end location, two pitches satisfy the requirements: a pitch that sets a vertical trajectory (pitch = PI/2), and a pitch which puts the projectile parallel to the launch location, which sets a flight time of 0s (pitch = 0)

2: For distance(start location, end location) > max_distance(projectile_speed, gravity), the optimum trajectory is the one that maximizes distanced traveled. With non-orbital bodies and neglecting air friction, this is (pitch = PI/4)

3: The only thing left is to calculate the pitch when the end location is both (a) not the start location, and (b) within the maximum range of the projectile.

Let me introduce you to the kinematic equations:

In order, these equations mean:

final velocity = initial velocity + acceleration * time
displacement = initial velocity * time + acceleration * time squared / 2
final velocity squared = initial velocity squared + 2 * acceleration * displacement
displacement = time * avg(initial velocity, final velocity)
displacement = final velocity * time - acceleration * time squared / 2

The first thing we need to do with these equations is use them in two different planes. One plane will be the vertical plane (where gravity exists) and the other in the horizontal plane (where gravity does nothing).

In the vertical plane:
displacement is assumed to be 0 (unless your projectiles need to fire up cliffs, which you didn't specify)
initial velocity = -1 * final velocity = speed * sin(pitch)
acceleration = gravity
time is unknown

Note that speed is the fixed speed of the projectile (absolute value of the vector!)

Applying this information to the kinematic equations gives us:

0 = speed * sin(pitch) * t + gravity * time^2 / 2
0 = 0
0 = 0
0 = -speed * sin(pitch) - gravity * time^2 /2

Now to the horizontal plane:

displacement is known to us (the distance between initial location and final location)
final velocity = initial velocity = speed * cos(pitch) (note that we're talking about horizontal velocity which, logically, does not change over the duration of the trajectory)
acceleration = 0
time is unknown

Applying this information to the kinematic equations gives us:

displacement = speed * cos(pitch) * time
0 = 0
displacement = speed * cos(pitch) * time
displacement = speed * cos(pitch) * time

as you can see, only two useful equations have been derived from the pair of kinematic equations:

displacement = speed * cos(pitch) * time
0 = speed * sin(pitch) * time + gravity * time squared / 2

we have two equations, and two unknown variables (pitch and time)

starting with the equation derived in the vertical plane:

0 = speed * sin(pitch) * time + gravity * time squared /2

we can get:

speed * sin(pitch) * time) = gravity * time squared / 2

thus:

time = -2 * speed * sin(pitch) / gravity

since time is matching in the two equation sets, we can apply this to the horizontal plane equations:

displacement = speed * cos(pitch) * time

therefore

cos(pitch) = displacement / (speed * time)

then, taking the equation for time into this one:

cos(pitch) = displacement * gravity / (-2 * speed squared * sin(pitch))

therefore:

cos(pitch) * sin(pitch) = displacement * gravity / (-2 * speed squared)

Now, applying the trigonometric identiy for cos(u) * sin(v):

We get:

sin(2 * pitch) = -1 * displacement * gravity / (speed squared)

and hence:

pitch = 1/2 * asin(-1 * displacement * gravity / (speed squared))

This is the final answer to your question. If you want a fixed start and end location, fixed initial projectile speed, and fixed gravity, then the "initial z angle" (pitch) will be as given above.

I just derived this on mobile, so please forgive me if there's a mistake.

 

[Waffle]

I'm rather surprised that even tho u got an nice big image with like 5 equations
they are all special cases of the generic form and that is missing

e.g.
x = x0 + v0*t + (a*t^2)/2
also . if you write THAT much u might as well bother solve that 3 equation system and give the 3 equations that get the initial components of the velocity vector..

 

[Cokemonkey11]

Because I derived mine on paper in 5 minutes without a calculator and using the kinematic equations that I memorized. The fact that my post contains a lot of text is purely due to detailed exposition.

I'd you'd like to derive all the components, be my guest, but I think this suffices to answer the question posed by Wietlol

 

[Wietlol]

First of all, let's just recap what's going on in this thread so we can minimize misinformation and optimize correctness to the question being asked:

Wietlol wants to use constant gravity and initial projectile speeds (as in real world projectile motion) in a system so that, given a start and end location, a projectile will be launched through the correct trajectory that either (a) satisfies the start and end locations, as well as the fixed initial speed and in the fixed gravity, or (b) optimizes the trajectory to approach the correct start and end locations, given that no trajectory satisfies all of the requirements.

Exacly.

Second of all, some correct terminology is necessary. zAngle means absolutely nothing, except perhaps that it could be interpreted as an angle in the z-plane. This is not useful because (a) the angle on the z-plane changes dynamically in projectile motion, and (b) the dynamic value of the zAngle need not be maintained for projectile motion. Arc is the name of a segment of a curve - note that this is utterly unrelated to any kind of angle. The correct name for the angle you guys are ALL talking about is pitch.

Sorry for that. I am not english and so don't know the exact words that should be used. I make some mistakes in words that are used for almost the same thing.
Well lets use the right terms from now on.

Thus, what Wietlol is trying to find, is how to calculate the initial pitch of a projectile that satisfies constant gravity, fixed initial speed (and therefore fixed horizontal velocity), and fixed start and end points.

Not exacly.
There is no fixed Horizontal-Velocity. There is fixed 3D-Velocity.
My brother seems to call 3D-Velocity a Vector...
But we all know him right?
So we know the 3D-Velocity aka Vector3D. (Is Vector3D the correct term?)

The Vector3D = sqrt(Horizontal-Velocity^2 + Vertical-Velocity^2)
Like this for example.
If I aim my gun at a 0 degree pitch, the Horizontal-Velocity will be exacly the Vector3D (at the start).
If I aim my gun at a 90 degree pitch, the Horizontal-Velocity will be exacly 0.
If I aim my gun at a 45 degree pitch, the Horizontal-Velocity and the Vertical-Velocity will both be ~71% of the Vector3D.
The pitch however is not known yet... that is why this one is so hard.

1: For start location = end location, two pitches satisfy the requirements: a pitch that sets a vertical trajectory (pitch = PI/2), and a pitch which puts the projectile parallel to the launch location, which sets a flight time of 0s (pitch = 0)

Start-Location never is the same as End-Location.
I have to have the pitch for Start-Location (0, 0, 0) and End-Location (0, 0, 100) In that case the pitch is 0 indeed.
I can filter "Start-Location-X == End-Location-X and Start-Location-Y == End-Location-Y".
So that would not be a problem.

2: For distance(start location, end location) > max_distance(projectile_speed, gravity), the optimum trajectory is the one that maximizes distanced traveled. With non-orbital bodies and neglecting air friction, this is (pitch = PI/4)

PI/4 = ~0.785... Neither 0.785 nor 78.5 in neither degree nor percentage are the best pitches... I think.
I assume it is somewhere between 30 and 40 degree.
I could have understood this one wrong and in that case please tell me what I am missing.
Anyway the one for Start-Z and End-Z as the same value can be used for now but it should be changed to one that also includes Height Difference.
In which case, PI/4 will not look like the formula.

3: The only thing left is to calculate the pitch when the end location is both (a) not the start location, and (b) within the maximum range of the projectile.

So... lets do it.

Let me introduce you to the kinematic equations:

final velocity = initial velocity + acceleration * time
displacement = initial velocity * time + acceleration * time squared / 2
final velocity squared = initial velocity squared + 2 * acceleration * displacement
displacement = time * avg(initial velocity, final velocity)
displacement = final velocity * time - acceleration * time squared / 2

Well... you might not believe it but I tried to make it simple to you guys.
I do not have to have missiles that accelerate.
I do not have to avoid unmoveable/undestroyable obstacles.
I do not have to know the moment when the missile would hit it's target if the target keeps moving in it's current direction with it's current speed.
(That second one would make it even more difficult than it already is.)

The first thing we need to do with these equations is use them in two different planes. One plane will be the vertical plane (where gravity exists) and the other in the horizontal plane (where gravity does nothing).

In the vertical plane:
displacement is assumed to be 0 (unless your projectiles need to fire up cliffs, which you didn't specify)

Hold it for one second... I lost count of how many times I said "Location (x,y,z)" or "Vertical Difference" (Actually I said it 18 times excluding the ones in this post.)
Cliffs are included in vertical difference you know.

Vertical-Velocity
= sqrt(Vector3D^2 - Horizontal-Velocity^2)
= Vector3D * sin(pitch)

Now we get to an interesting one:
sin(pitch) = Vertical-Velocity / Vector3D.
At least that is if I read it right and if you have that formula right.
So pitch = Asin(Vertical-Velocity / Vector3D) ... Is that right or is asin() not the reversed type of sin()?

Note that speed is the fixed speed of the projectile (absolute value of the vector!)

Note that every time I said speed is also the speed of the projectile (absolute value of the vector!).

Applying this information to the kinematic equations gives us:

0 = speed * sin(pitch) * t + gravity * time^2 / 2
0 = 0
0 = 0
0 = -speed * sin(pitch) - gravity * time^2 /2

That leaves us with 2 variables. As speed and gravity are given.
The remaining variables are "pitch" and "time"

Now to the horizontal plane:

displacement is known to us (the distance between initial location and final location)
final velocity = initial velocity = speed * cos(pitch) (note that we're talking about horizontal velocity which, logically, does not change over the duration of the trajectory)

Yes it does!
By now I said that enough times I suppose.
The user gives 3D-Velocity (Vector3D) rather than Horizontal-Velocity (Vector2D)

Applying this information to the kinematic equations gives us:

So it doesn't give us the required data.

Sorry to say but the maths you did after that do not use the right parameters so they are not right.

You helped a lot but not enough... yet.
I really appreciate the help on this thing... I really do.

To explain again:
The map maker gives these parameters:
Starting Location (X, Y, Z)
Target Location (X, Y, Z)
Missile Speed (3D-Velocity or Vector3D)
Missile Weight (a raw value)
Priorize High Trajectory (a boolean)

With those values there are 3 solutions:
1) The missile cannot hit the requested target.
-> Use the pitch that will bring the missile as close as possible.
2) The missile can hit the target with 2 different pitches.
-> Use the highest pitch if priorized on high trajectory.
-> Use the lowest pitch if not priorized on high trajectory.
3) The missile has one possible pitch that would bring the missile to it's target.
However this one is the optimized pitch... I think that this one is both included in the formula ánd will never actually be seen.

The problem in 1 is:
How do you know if a missile cannot hit it's target?
And how do you know what pitch will bring the target the closest to it's target?

The problem in 2 is:

• You neither know Vertical-Velocity nor Horizontal-Velocity because they change depending on the pitch.
• You do not know the duration of the flight, as the distance grows depending on the pitch.
• You do not know the pitch.

However, there is no possible way that the pitch can be different from the 2 pitches (as mentioned above) while having those same values as the map maker defines.

If you want to know it, yes, all my archers have a big A++ for maths.
That is why they became archers.
Sometimes they also write down the mistakes in the questions in their exams.

 

[Cokemonkey11]

There is no fixed Horizontal-Velocity. There is fixed 3D-Velocity.

These are both incorrect statements. For non-orbital bodies without air friction, horizontal velocity is fixed for projectile motion. Perhaps it doesn't seem that way, but it is factual.

There also is not fixed 3D velocity. Here's a simple example: You throw a rock directly upwards at 10 m/s. When the rock comes back down and reaches your hand, its velocity is -10 m/s.

Q: What's its velocity right at the top of its trajectory?

A: 0 m/s

Hence, the rock's velocity was not fixed.

That being said, the rock's horizontal velocity (i.e. the horizonal components of the rock's 3D trajectory) were fixed.

The rock also began with fixed initial 3D velocity, that is when the rock leaves your hand at 10 m/s, it's 3D velocity is precisely (0, 0, 10) and nothing different.

(Is Vector3D the correct term?)

Not really but for all intents and purposes I at least unambiguously know what you're trying to say.

The Vector3D = sqrt(Horizontal-Velocity^2 + Vertical-Velocity^2)

No, that is incorrect. the sqrt(Horizontal_velocity^2 + vertical_velocity^2) would be the SPEED of the projectile. For projectile motion, the absolute value of a vector is its speed.

A vector is a tuple. A vector3 is like this: (0, 0, 10)

The modulus of that vector would be sqrt(0*0 + 0*0 + 10*10) = 10 m/s - aka its speed

I can filter "Start-Location-X == End-Location-X and Start-Location-Y == End-Location-Y".
So that would not be a problem.

That would be stupid. You would be taking a general form solution to a simple problem and introducing loads of potential bugs

PI/4 = ~0.785... Neither 0.785 nor 78.5 in neither degree nor percentage are the best pitches... I think.

NEVER USE FUCKING DEGREES.

PI/4 is in radians. PI/4 * 180 / PI = 45 degrees, if you must know.

I assume it is somewhere between 30 and 40 degree.

It's 45.

I do not have to have missiles that accelerate.

Okay, here's a pop quiz question:

Q: You throw a rock high into the air and across the river. Along the way, the rock falls towards the ground until it strikes it, stopping in place. Was the rock being affected by:

a) Gravity
b) A force
c) A source of acceleration
d) All of the above

A) The correct answer is D. If you have projectile motion, you also have acceleration.

Hold it for one second... I lost count of how many times I said "Location (x,y,z)" or "Vertical Difference" (Actually I said it 18 times excluding the ones in this post.)
Cliffs are included in vertical difference you know.

It makes no difference. The same kinematic equations are used to derive pitch for difference of height as well. Why don't you implement the basics first and add those details later?

The user gives 3D-Velocity (Vector3D) rather than Horizontal-Velocity (Vector2D)

Split the input vector into components, and solve in two planes to isolate acceleration.

Missile Weight (a raw value)

Why?

Priorize High Trajectory (a boolean)

PI/2 - pitch

1) The missile cannot hit the requested target.
-> Use the pitch that will bring the missile as close as possible.

Pi/4

2) The missile can hit the target with 2 different pitches.
-> Use the highest pitch if priorized on high trajectory.
-> Use the lowest pitch if not priorized on high trajectory.

PI/2 - pitch

or

pitch

3) The missile has one possible pitch that would bring the missile to it's target.
However this one is the optimized pitch... I think that this one is both included in the formula ánd will never actually be seen.

Indeed PI/2 - PI/4 = PI/4

How do you know if a missile cannot hit it's target?

asin(x) is real for x on [-1, 1]

So, if -1 * displacement * gravity / speed squared is less than -1 or greater than 1, the target is unreachable.

And how do you know what pitch will bring the target the closest to it's target?

PI/4

You neither know Vertical-Velocity nor Horizontal-Velocity because they change depending on the pitch.
You do not know the duration of the flight, as the distance grows depending on the pitch.

So what?

You do not know the pitch.

I just gave it to you.

Regarding the vertical displacement: I will derive a new equation for you.

 

[Wietlol]

These are both incorrect statements. For non-orbital bodies without air friction, horizontal velocity is fixed for projectile motion. Perhaps it doesn't seem that way, but it is factual.

Wow. I feel so dumb now.
On the other hand. The thing about having a pitch decrease and having gravity slow down the 3D-Speed seems to be proper calculated after all.

Not really but for all intents and purposes I at least unambiguously know what you're trying to say.

I will use 3D-Speed from now on.

No, that is incorrect. the sqrt(Horizontal_velocity^2 + vertical_velocity^2) would be the SPEED of the projectile. For projectile motion, the absolute value of a vector is its speed.

I thought you just said that you understood what I was trying to say.
3D-Speed^2 = Horizontal-Velocity^2 + Vertical-Velocity^2 -> so
3D-Speed = sqrt(Horizontal-Velocity^2 + Vertical-Velocity^2) -> so
Horizontal-Velocity = sqrt(3D-Speed^2 - Vertical-Velocity^2)

That would be stupid. You would be taking a general form solution to a simple problem and introducing loads of potential bugs

WHAT?

if Start-Location-X == End-Location-X and Start-Location-Y == End-Location-Y then
set pitch = 90 * End-Z - Start-Z
else
calculate pitch

You said that it was different from the calculation for the pitch between the optimized angle and 0 deg or 90 deg.

NEVER USE FUCKING DEGREES.

Ow fuck me. I forgot the most used curve thing type in coding.

It's 45.

Yea sorry about that.
I read that the optimized spot was NOT 45 degrees but didn't notice that that was calculated including air resistance.

If you have projectile motion, you also have acceleration.

I meant that I do not have something like a rocket that increases it's own speed over time.

It makes no difference. The same kinematic equations are used to derive pitch for difference of height as well. Why don't you implement the basics first and add those details later?

I think that that is the best thing to do for now.

Split the input vector into components, and solve in two planes to isolate acceleration.

So I must give Horizontal-Velocity and Vertical-Velocity instead of 3D-Speed?
That would be stupid.

Why Missile Weight?

Because I wan't to be able to make the missile have different effect from gravity.
However I will use gravity like this:
set Vertical-Velocity = Vertical-Velocity - Missile-Weight * (Some-Gravity-Factor) * 0.03
The gravity factor is to make the missile weight be more meaningfull.
However it doesn't matter much how much that is.

pitch = 1/2 * asin(-1 * displacement * gravity / (speed squared))

Displacement = sqrt((Start_Location_X - End_Location_X)^2 + (Start_Location_Y - End_Location_Y)^2)?
Gravity = ?
Speed = Horizontal_Speed or 3D_Speed?
Pitch in radians, degrees or percentage?

 

[GhostWolf]

I give up. Life isn't worth it.

Either grow up a little and learn the very basics of classical mechanics, or learn about them now by actually bothering to read what people here say and/or reading on wikipedia/other sources, or leave, because code isn't for you.

 

[Wietlol]

I give up. Life isn't worth it.

Either grow up a little and learn the very basics of classical mechanics, or learn about them now by actually bothering to read what people here say and/or reading on wikipedia/other sources, or leave, because code isn't for you.

Well... actually code is for me.
But this is not about code. This is about maths and physics.

Anyway you still not seem to understand what I want.
Either you guys are right... but you still use term without explaining what they are.

However as far as I understand, you all still use a value of an unknown variable.
The variable which you all magically seem to know is the Horizontal_Speed.
However the Horizontal_Speed is not known.

Split the input vector into components, and solve in two planes to isolate acceleration.

So either there is some magical formula inside ^this^ thing that would solve all of my problems... or I got to find a way to explain that Horizontal_Speed = ???
Which I actually believe is possile too now.
According that it took you 31 posts to find out, when Cokemonkey11 joined this thread, that I need to calculate what pitch the missile should be fired at.

 

[Waffle]

i must agree :'(
lost cause..

ehh last hint
learn to add vectors and you might just have a relevation..

also JASS2 reals arent REAL real numbers they are ieee floats that have quirks and that accumulate errors meaning that
sin(33) == sin(33) might be-- true.. or false.. or true or false depending on some weird luck.

really tempted to just spurt out some code atm but you wouldnt rly learn anything from that now would you..

 

[Wietlol]

Well... I don't really know why a real is not really good except for that it has a cap at 1,093,677,312 ... which I had a problem with a few days ago.

But next to that... it is more accurate than a double or a float... which we cannot use in JASS.

Well... back at secondary school we also had something similar to a formula with dynamic unknown variables.

"End_Value = Start_Value * Increase_Rate^Duration"
The problem was that we didn't knew the duration. The duration was a key to Increase_Rate so it was required.
The solution that we did was... trying.
What if I use 2 as duration?
What if I use 3 as duration?
What if I use 4 as duration?
What if I use 3.5 as duration?
etc. etc. etc.

In that case however there is this nice automatic calculation of which I forgot it's name.
Anyway in this case we also are missing a key value.
So we cannot use all known variables.
So the regular calculations cannot be applied.
Either we try... hell no!
Or we find out what that automatic calculation is which we all don't know or just haven't mentioned.

In fact... I do believe that we cannot use Horizontal_Speed and Vertical_Speed anyway.
I think that those will be the variables we can calculate after we have the pitch.

EDIT: I figured that there was noone that would even try to help me if I also would want to include target unit's movement.
If the target unit would move towards you, the distance that you would have to travel would be decreased according to the duration of the flight.
There we have an extra dynamic unknown variable.

 

[Waffle]

its not accuratte because it IS a float
http://en.wikipedia.org/wiki/IEEE_floating_point
its not an actual real. also its a 32 bit binary floating point.. so there's added quirks when u convert between decimal and binary too..

also if you move the unit.. and you want the projectile to follow.. well it can be done i guess (if u give up on having any type of realism..) but i guarantee if you cant even solve the static case..
you will have 0 chance with compensating for target motion.. (the simple case being just calculate where the target unit will be in say half a sec and aim there in stead.. i think war3 does sth like that for many types of non-homing projectiles..)

if your method is just based around trying random things.. u wont get anywhere..

 

[Wietlol]

also if you move the unit.. and you want the projectile to follow.. well it can b3 done i guess (if u give up on having any type of realism..) but i guarantee if you cant even solve the static case..
you will have 0 chance with compensating for target motion.. (the simple case being just calculate where the target unit will be in say half a sec and aim there in stead.. i think war3 does sth like that for many types of non-homing projectiles..)

Well... WC3 does not use 3D-Speed. They use Horizontal_Speed.
So they have a much easier formula.
I think that I have seen the formula for that calculation many times.
However that one increases or decreases Flight_Duration so the Horizontal_Speed changes, so the Pitch changes, so... you get the picture that it makes it extremely difficult.

 

[Waffle]

i give up.. for real this time.

 

[Cokemonkey11]

The thing about having a pitch decrease and having gravity slow down the 3D-Speed seems to be proper calculated after all.

I don't know what you're talking about. Gravity is a constant for non-orbital bodies.

I thought you just said that you understood what I was trying to say.

That was before I realized you don't know what vectors are.

3D-Speed^2 = Horizontal-Velocity^2 + Vertical-Velocity^2 -> so
3D-Speed = sqrt(Horizontal-Velocity^2 + Vertical-Velocity^2) -> so
Horizontal-Velocity = sqrt(3D-Speed^2 - Vertical-Velocity^2)

I have no idea what you're trying to say.

WHAT?

if Start-Location-X == End-Location-X and Start-Location-Y == End-Location-Y then
set pitch = 90 * End-Z - Start-Z
else
calculate pitch

You said that it was different from the calculation for the pitch between the optimized angle and 0 deg or 90 deg.

If you use the same calculation for dx = 0, the solutions will be PI/2 and 0. You don't need to use any logic control here.

I forgot the most used curve thing type in coding.

lol. They're called angles. There are different units of measurement for angles, including degrees, radians, tau, etc

So I must give Horizontal-Velocity and Vertical-Velocity instead of 3D-Speed?

No, to derive the equation you desire, it's necessary to split velocity into horizontal and vertcal velocities. To use the equation you do not need to "use" them.

Because I wan't to be able to make the missile have different effect from gravity.

For non-orbital bodies, weight doesn't affect projectile motion. click

So they have a much easier formula.

No shit. They don't use real projectile motion. Do you want to imitate wc3 projectiles, or do you want to make projectile motion? Make up your mind.

Just use this. It's already derived for you:

pitch = 1/2 * asin(-1 * displacement * gravity / (speed squared))

If you really need difference of elevation factored into the calculation, it's literally on wikipedia.

 

[Wietlol]

I don't know what you're talking about. Gravity is a constant for non-orbital bodies.

Well... it was a different calculation that could have worked (almost) the same but would be harder to use.

For non-orbital bodies, weight doesn't affect projectile motion. click

Well... I neither do I set an Air_Resistance.
I just make myself be able to play with things that are not possible in real world.
However... I didn't count on it that the Missile_Speed would also include Missile_Weight in this calculation.
If declared in power, then it would have but that doesn't matter any more.

If you really need difference of elevation factored into the calculation, it's literally on wikipedia.

TY!!!!

One question though.

Is this formula corrent then?

set Pitch = Atan((Speed^2 +/- SquareRoot(Speed^4 - Gravity (Gravity*Horizontal_Distance^2 + 2*Vertical_Distance*Speed^2)))/Gravity)

Where Gravity is used like this:
set Vertical_Velocity = Vertical_Velocity - Gravity * 0.03

 

[Waffle]

JASS has no ^ operator
i think you mean Pow(a,p)
also most languages that do have an ^ operator it implements exclusive OR rather than exponentiation..

also..
does it have SquareRoot function? i would guess not ..
pow(a,0.5) is so trivial i dont see a reason for a separate square root function..

JNGP has a nice function library where u can look at all the built in functions, i would suggest to use it.

 

[Wietlol]

Yea forgot that Power function...
SquareRoot is a function... but indeed Pow(value, 0.5) works the same.

Is this formula corrent then?

set Pitch = Atan((Pow(Speed, 2) +/- SquareRoot(Pow(Speed, 4) - Gravity (Gravity*Pow(Horizontal_Distance, 2) + 2*Vertical_Distance*Pow(Speed, 2))))/Gravity)

Where Gravity is used like this:
set Vertical_Velocity = Vertical_Velocity - Gravity * 0.03[/QUOTE]

And when is it + and when -?

 

[Waffle]

+/-
im quite sure thats a syntax error
ud need split it in to the 2 equations that it actually represents and then do some logic to pick which solution u want..

 

[Xonok]

EDIT: I figured that there was noone that would even try to help me if I also would want to include target unit's movement.
If the target unit would move towards you, the distance that you would have to travel would be decreased according to the duration of the flight.
There we have an extra dynamic unknown variable.

No one would help you with that because no one can. Since WC3 uses solely horizontal speed for unit movement, then a 3D approach like you have would not be able to accurately track them.
Technically you can use both approaches within the same system, because the vertical acceleration(gravity) should be possible to set when creating a projectile, not as a constant. This thing you had with weight is a poor workaround.