Make a unit "jump"?

I'm working on a update of my soccer map. Someone suggested that there should be a hero able to kick the ball to the air for a short time. I think this is a very good idea and is working on it.

If you haven't played my game yet, (too bad you missed it :nono: ) the ball is actually a sheep. I'm considering changing the movement height of it. But I find the action can only change the height instantly, so it looks really odd. The action does have a "rate" variable, but I have no idea how to make it work. Anyone got idea?

Any other ideas to make a unit "jump"??? Thanks for any suggestions!

I haven't actually played the map, so this might not be all that practical (all the more so if the players use attacks already), and I'm not 100% sure you can even do this as of 1.03, but perhaps make the sheep a projectile of a unit. To make him jump, make him disappear, have the kicking unit "fire" him to the jump destination, and upon landing, create a "real" sheep unit. I'm not sure how smooth you could make that, in any event, but it's at least a quick n dirty way to simulate jumps.

ps, though I haven't played around with heights yet, I'd think that rate was literally the rate at which a unit changed height. If so, you could make a flying unit look like it was following a parabola if you divided its flight into multiple segments using a -1/2at^2 formula for your rate (that is, start off fast upwards, decelerate to zero, and then accelerate downwards). It would look a bit "logowriter"-ish, but it might work.

Ari I have no idea what you just said in your P.S. man. Just thought I should let you know we aren't all well aquainted with phsyics. If its possible to lay that down in lamens terms I'd love to know what you were saying :D

i have only used the change flying height trigger once (its in the animation category in case you cant find it) but i think it had an "over x seconds" so you could make a trigger: order ball to move to X location. set flying height of ball to 200 over 3 seconds. wait 0.5 seconds. set flying height of ball to 0 over 2 seconds.

Honestly ive got no idea whether this would work but i guess its worth a try.

Doh, super sorry. All the more so since I shouldn't have even used the word "rate" in there, which muddied the waters even further. That's the last time I dabble in the black arts after midnight. Oops, I meant physics :) Not to mention, upon reconsidering, you wouldn't even want to use that formula in the first place.

This is probaby overkill for this problem, but I was just giving the falling-body formula. Intuitively, you know that to mimic a real ball, you want a system where the ball climbs in segments, each one slower than the last until the ball is at its highest point. Then you want the ball to fall in segments, each one faster than the last until it hits the ground. You'd want it to do this whether the ball was shot stright up OR if it was kicked in an arc.
Basically, "a" is the acceleration of gravity downwards. In real life it would be ~10; in WC3 it would be something else (you'd have to play around a bit to see what strength "gravity" you want in the game). "t" simply represents time. So you'd want something like a trigger that changed a given distance upwards at an ever decreasing rate (10, 9, 8, 7, 6, etc) and then increased a fall rate at the same ever-increasing rate.

You'd need custom text for this, since there's multiple actions in the for loop, but it's "gentle" custom text, not "hardcore" custom text.

Let's imagine you want the ball to travel in 5 steps upward a distance of 100 in each step, with speed starting at "100" with gravity of "20"

For the rise, you want:
for a = 1 to 5 do:
change flying height of sheep from ((a-1) * 100) to (a*100) over (100 / (100-((a-1)*20)) ) seconds
wait (100 / (100-((a-1)*20)) ) seconds

(height = 100
speed = 100
gravity = -20)

So to keep score:
segment 1 = 100/100 = 1 second
segment 2 = 100/ 80 = 1.25 seconds
segment 3 = 100/60 = 1.666 seconds
segment 4 = 100/40 = 2.5 seconds
segment 5 = 100/20 = 5 seconds

Looking at the numbers, though, this is crazy, like moon gravity, so instead of 100 on the far left, you'd want something smaller, like 10 (which would give you a total hang time of about a second).

You'd want to then hover the ball for a split second, and then reverse the whole thing, gradually accelerating the ball downwards.

For lower or higher kicks, you would adjust your initial speed (lower speed = lower final height) and the number of cycles of the loop. Or you could simply scale down the height changes if segments of 100 are way too big.
Also, the more segments you do, the smoother this will look (because there will be less abrupt changes in speed between segments)

Anyway, this is probably way, way overkill for this (though maybe I'll use it somehow. Hmm....) and the "unit as artillery" is far easier to do. Thinking some more, this also is a bit inferior because you can't control pitch, so the sheep willl always be facing horizontally, even if falling down.

PS - physics is not at all my strong suit so if any engineering backgrounded person (I know there are some here) sees any obvious mistakes, feel free to call me on it :)

Aww yeah its all so clear now :D . You sure know your stuff Ari. Even though its not my post thanks for the excellent feedback.

Eh, I had the projectile idea, but it won't work: Once the fired unit hits its mark it plays its death animation, and there's no way to stop it that I can find, so you'd end up with alot of dead sheep sprites hangin' around....

Thanks for all the reply, especially Ari's detail description! :)

So the projectile idea is out.

I'm testing Ari's method. It seems that changing the movement height of unit over X seconds doesn't work for me. Is this a bug? Can someone test it to confirm it is working or not? Thanks!

The rate is simply how fast the height will change from what I know. I'm not sure exactly what the formula is, but I believe that it works like: Desired Height/Rate = Time for Implementation ( in seconds).

So if you wanted your sheep to rise in the air to a height of 100 and then drop in the course of 10 seconds, make it Animation - Change Unit Height to 100 at Rate 20 (Wait 5 sec) Animation - Change Unit Height to 0 at Rate 20. Your problem will be that the sheep will still be considered a ground unit... I believe. To get around that you could make the ball invuln for a short time.

Tell me if that works.

Ground unit? Could be the reason, though I think I had changed it as I know only air or hover units can change movement height. I think this may be a bug as it's ok if I set the rate to 0 but not any other number. I can't test this until Friday night I'm back home. Can anyone test this for me?

Do you have it as a hover unit or a flying unit? Because despite what WE says, I've only ever had it work with flying units. Maybe they only work with 0 rate, haven't tried that.

I tried both. I can change height only if the "rate" is 0, but not any other numbers. I think this is probably a bug.

(chagrinned)

I'm sorry - I'd never actually played with height, so this was all theoretical for me. Hope that bug gets fixed. Has anyone found a way to change height gradually (besides changing it repeatedly in small increments)?

No bug at all. Mine works fine with hieght rate set to 80. Herei s what I have learned:
[list=a][*]Hovering units can't change hieght[*]ONLY flying units can change hieght[*]The rate must be around 80-120 to really see a change[*]If the rate is too slow, the unit will stutter while chnaging[/list=a]

ATTATCHED IS A TEST MAP FOR TESTING FLYING UNITS:

Ah, thanks. Very good tidbit to know. And of course, good to see that this is working as expected. I played around with that map, and modified it a bit so you can change the rate of climbing in the map itself, by typing in a rate.

A rate of 50 translates into a very slow climb. 400, for example, will give a rate that's about the same as unit movement (leading me to suspect that the rate of a climb is calculated exactly as normal movement is calculated). Interstingly, unlike unit movement, this number can be set as high as you wish. 4000 produces an extremely fast, but still observable climb, while 10000 is faster still.

One thing I learned is that telling a unit to change heights cancels a move order. This means that you have to order a unit to move *after* a climb order. For multiple height changes in a trajectory, presumably, mutiple move orders would be needed.

One other tidbit I observed is that projectiles aimed at very high units will still function properly, and still climb exactly as expected to get to their target (try ordering the sorceress to attack the gyrocoptor when he's at the top of the screen).