• 🏆 Texturing Contest #33 is OPEN! Contestants must re-texture a SD unit model found in-game (Warcraft 3 Classic), recreating the unit into a peaceful NPC version. 🔗Click here to enter!
  • It's time for the first HD Modeling Contest of 2024. Join the theme discussion for Hive's HD Modeling Contest #6! Click here to post your idea!

Moving on 3D coordinates

Status
Not open for further replies.
Level 15
Joined
Aug 14, 2007
Messages
936
Alright first one we have is the famous polar with offset, it changes location from a point toward another point by distance and angle. That will move both X and Z axis if you study 3d space. The Y axis which is Up and Down will be flying height, however there is a 0 fly height limit and the only way is higher than 0.

Back to the point, you can trigger a system that handles flying height globally for all units but take note of how it works. Whenever you use the action to change a flying height, you require Crow Form ability (in-built trick from editors), simply add the ability via trigger and remove the ability immediately after, this will fool the game into thinking that unit is flying. When you set flying height to something by a specified speed, no matter how slow the speed is, the editor takes whatever the ideal end height as the current flying value, therefore it is safer to render the flying height instantly but alter it in such a way it move bit by bit, like how the normal dash system work in X and Z, make it so that it works similar in Y axis, you can see trace of this effect in Dota's impale. League of legends and Dota 2 both have advanced global height system which I had barely scratched on here.
 

Dr Super Good

Spell Reviewer
Level 64
Joined
Jan 18, 2005
Messages
27,198
Target X, Y, and Z of course (with fly height), Angle and Distance to Target, and Speed.
Why are you giving both a target position and angle and distance to target? Surely it would be better to get the start position and target positions?

Anyway the basic approach for linear paths.

  1. Compute delta vector (which means basically X, Y and Z) from start vector to target vector (subtract start from target).
  2. Compute flight time by calculating magnitude of delta vector and dividing it by speed.
  3. Compute velocity vector from delta vector and dividing it by flight time.
  4. Every update tick compute tick displacement vector by multiplying velocity vector by tick period. If period is constant this stage can be pre-computed and stored as the velocity vector.
  5. Every update tick move missile to current position vector added to tick displacement vector.
  6. Impact occurs after flight time or if missile is nearby target vector (it will never be exactly at target vector due to sampling and floating point error).

There is another approach using line segments where instead of specifying a speed you specify a flight time. Every update tick you use line segments maths to break the delta from current position to target at a point based on the tick period and the time left. Basically tick period divided by time remaining gets you a position closer towards the target that if the target remains a certain distance away from the source, then the missile will travel at a constant speed. The distance from source to target changes then the missile speed will also change. This is useful for simple tracking missiles as it allows you to guarantee their impact after a fixed amount of time. It also does not suffer as much from sampling and floating point error and if tick counts are used instead of time it will always eventually impact the target even if floating point error is problematic (does not really apply to WC3 as the maps are so small).
 
Last edited:
Status
Not open for further replies.
Top