Jump System

[Waldbaer]

Hello!
This System is not very complicated or very big, but I think it's nevertheless quite useful. It offers the following features:
- Makes units jump with a single line of code
- Realistic flying curve in all situations (also if you jump e.g. over a canyon)
- Full multiinstanceability
- English and German Tutorials, also for people new to JASS

Have fun and post your comments either here or in the according forum on my site.

EDIT8: Update 12/22/07 Version 2.0.1: Performance improvements; for more information read the included Version History
EDIT7: Update 01/21/07 Version 2.0: Added the function DCJS_Bounce; the Jump functions now also work correctly with a unit starting the jump in the air; major performance improvements; bugfix; detailed Version History included from now on
EDIT6: Update 11/23/06 Version 1.1: Added the functions DCJS_JumpSpeed, IsLocPathable and GetNearestPathableLoc
EDIT5: Update 10/16/06 Version 1.05: Removed a minor configuration possibility that did not work as described
EDIT4: Update 10/14/06 Version 1.04: Again some technical advancements
EDIT3: Update 10/10/06 Version 1.03: Memory leaks fixed, finally I hope.
EDIT2: Update 10/7/06 Version 1.02: Additional performance advancements
EDIT: Update 10/5/06 Version 1.01: Memory leaks fixed.

Note: The old version 1.1 is still available for download because its code is easier to read and to understand

[The)TideHunter(]

Dosent look to bad atall, goodjob on it :).

[Rising_Dusk]

Well, as neat as it is..

We have this testmap and this test map for jumps in jass and gui.
I don't think it does any good to have 3 of the same things in our database.

[Waldbaer]

This is something quite different to the two maps you mentioned:
1. This is not a spell. It's intention is completely different, it's a rough jump you can base spells on or you can use in cinematics. You don't have to edit anything to kill special effects you don't need.
2. Neither the first nor the second map has the feature of parabolic jumping ignoring the terrain between start and finish of the jump. It's impossible to get a parabolic jump over a canyon with one of these spells. My system has this feature implemented, you don't have to care for anything anymore, just write call DCJS_Jump(....) and the unit will jump in a realistic way to whereever you want. I'd suggest the makers of these two spells to implement my system!

[Jazradel]

Adding basic support for terrain is a great idea. I would add it when I get home, but I can't be screwed.

Nice cinematic by the way, and a clever idea using a repeating trigger and a group.

[blu_da_noob]

You should still be setting DCJS_GC() to a local gamecache variable instead of calling it so many times in each function (function calls are slow in jass).

I read about a gamecache limit of 256 some time ago and feared that it was not possible to store more than 256 values and wanted to save gamecache space, so I computed it new every time. But with a simple test (34 units jumping at once) I figured out that this works as well so I'll compute it only once now and then save it in game cache, too. What is this limit about, actually?

That 256 limit is not relevant here. You are still computing Sin/Cos each iteration which is unnecessary and very process expensive. Save the Sin/Cos values.

Thanks also for the tip with destroying the unitialized variable - I didn't know this, too and it did not seem to have any effect. Well, now I initialize it with Location(0,0) and the problem should be solved.

You don't need to create a location for it, just assign it a value of null (it just mustn't be left undeclared).

call FlushStoredMission( DCJS_GC(), I2S(H2I(u))) Could just be:
call FlushStoredMission( DCJS_GC(), s)//you already have the string declared to that value
That should be the last I think.

[Captain Griffen]

Blu - I doubt a GC call will be any more efficient than getting Cos/Sin. Pipe says Cos/Sin are inexpensive (presume it has a list already worked out).

[blu_da_noob]

It's still 3 vs 2 (GC for angle then cos/sin, versus getting cos/sin from GC). *shrug*

[Captain Griffen]

Ahh. That's possible different then. Have to benchmark it to be sure.

[Vexorian]

Originally Posted by blu_da_noob

It's still 3 vs 2 (GC for angle then cos/sin, versus getting cos/sin from GC). *shrug*

sin/cos can't be that slow

[Waldbaer]

Originally Posted by Vexorian

sin/cos can't be that slow

OK, I have corrected it the way blu_da_noob told me. What's faster now, calculating sin/cos every time or reading once more a gamecache value?

I did not update it until now, because I'm still unsure what is better and I don't want to update it more often than necessary - that's annoying especially for those people who already downloaded it - I think you know that.

If I get an answer today I'll update it finally today, too.

[blu_da_noob]

Meh, the difference should be neglible anyway. Just do whichever you feel comfortable with.

[Waldbaer]

OK, again updated. I did it again as it was in the first version concerning the sin/cos thingy. I tested with many units at the same time and there is really no noticeable difference between the two possibilities, but calculating everytime again makes the code easier to read, I think. That's the only advantage!

Update 10/14/06 Version 1.04: Additional technical advancements

[Waldbaer]

Searching for a reason why this still has not been approved, I found the constant function DCJS_GC(), which returned the global gamecache variable. Since this function did not work as it should anyways (more than one edit required to change the variable's name because of the Init_DCJumpSystem function), I removed it completely and replaced it with the direct name of the variable.
This doesn't make a noticeable difference in speed (I don't know why function calls, even constant function calls should be slow - if they are, that's also negligible, I think), but it's one possibility fewer to confuse a user.

Update 10/16/06 Version 1.05: Removed a minor configuration possibility that did not work as described

[Captain Griffen]

Originally Posted by Waldbaer

(I don't know why function calls, even constant function calls should be slow - if they are, that's also negligible, I think)

Because function calls require a few micro-ops. Constant function calls are exactly the same once compiled as non-constant function calls.