Bounce Pushback Effect

...
Hmm, I thought vessel was the FirstOfGroup.
Well, as said, you should stick to GroupLooping if you had to use more than like 3 Handle Vars.
But in this case, I only see one.

by the time the handle var gets thru, it generates enuff lag that this whole process becomes effectively useless.

anyways, what would you attach the handle to? the unit? eww...

Hmm, I don't know =.=...it's even very bothersome to attach it to the unit...lol.

I am sure, we can accept, that nether the one nor the other way is ideal. ^^
But vexorian wrote something about a "location stack", which may be a nice alternative...
Unfortunally I have no idea, how it works. ^^

I wrote my own stack structures in Java, but in Jass, I thought, it is impossible to define own objects...
And the functions he used were never seen by me before.

yeah, attaching handlers to static objects is almost as bad as using a global...

anyways, Zsar, #1) "define own objects"? (please explain) and #2) probably custom funcs, those rare funcs, or common.ai funcs, and #3) link?

Oh, well... Hard to explain as Jass is no object-based language...

An "object" is any kind of virtual instance of a definition...
Of course, this explanation tells you nothing. ^^

Let me show some examples:
In "common.j", there are "types" listed in the first few lines.
Take the type "filterfunc".
When calling the function "Filter(code)", this function creates an object.
The filter exists virtually and is handled as you would do with... A net or something similar in Reality.
This special created object has it's own place in memory - that is, why you have to destroy it after usage.

... Now, the filter is an object of type "filterfunc".
This type defines everything to do with an instance of it - you cannot insert a unit into a function, which requires a filter as argument.

Now, in a language, which is not just some cheap script language for a programm, you may define your very own custom type.
Own name, own signature (name + parameters), own attributes...
In an object-based language like Java own functions, which are called by the object rather than on an object as it happens in Jass.

... Just I worry to be not able to explain it properly.
In my mother tongue itself, I am still pretty bad in making somebody understand, what I mean. ^^

However, what I wanted to say is that I have no idea, how this "location stack" may be realized.

aye, ive done a lil bit of java before, so im used to all that

(Class) (instancename).new (Class)();

and (instancename).(method)(Parameters);

kind of stuff ^^

ty for trying to explain tho...

im still wondering what that location stack thing was supposed to be tho

Is one of you two registered to WC3Campaigns?
This one may simply ask Vexorian about how it works...
Or at least, how the function bodies of "GetLocationX_Unit" and "GetLocation_Loc()" look like - then we may figure it out ourselves (or even use it without knowing, how it works ^^).

here is the code, i just looked it up, and basically you are attaching data to the coords of the location. They run about 6.5 times faster, but can only store 2 values, so the "Stack" part comes from the fact you use the Y-Coord of a loc to store another loc, and so on, and so on

anyways, credits to vex for the script, and that B thing was some function he wrote to show how they work. ( i am soooo tempted to replace all my cache stuff with these if i work out how to pass them between funcs )

function CS_i2r takes integer i returns real
    return i
    return 0.
endfunction

function CS_h2r takes handle h returns real
    return h
    return 0.
endfunction

function Stack_First takes location l returns location
    return GetLocationX(l)
    return null
endfunction

function Stack_Next takes location l returns location
    return GetLocationY(l)
    return null
endfunction


function Stack_Empty takes location s returns boolean
    set udg_csloc=Stack_First(s)
    return udg_csloc==null
endfunction

function Stack_Push takes location s, real i returns nothing
 local location F=Stack_First(s)
    if (F==null) then
        set F=Location(i,CS_h2r(null))
    else
        set F=Location(i,CS_h2r(F))
    endif
    call MoveLocation(s,CS_h2r(F),0)
 set F=null
endfunction

function Stack_Pop takes location s returns real
 local location F=Stack_First(s)
 local location q
 local real i
    if (F==null) then
        return 0
    endif
    set i=GetLocationX(F)
    set q=Stack_Next(F)
    call RemoveLocation(F)
    call MoveLocation(s,CS_h2r(q),0)
 set F=null
 set q=null
 return i
endfunction

function NewStack takes nothing returns location
   return Location(CS_h2r(null),0)
endfunction

function Stack_Destroy takes location s returns nothing
 local location t=Stack_First(s)
 local location q
 
   loop
       exitwhen (t==null)
       set q=t
       set t=Stack_Next(t)
       call RemoveLocation(q)
   endloop
   call RemoveLocation(s)
 set t=null
 set q=null
endfunction

function B takes nothing returns nothing
 local location s=NewStack()
 local integer n=100
 local integer i=0
 local real x

    loop
        exitwhen i>=n
        call Stack_Push(s,3.3)
        set i=i+1
    endloop
 set i=0
    loop
        exitwhen Stack_Empty(s)
        call Stack_Pop(s)
        set i=i+1
    endloop
    call Stack_Destroy(s)
    if (i>=n) then
        set udg_log=udg_log+1
    endif
 set s=null
endfunction

Hell, that is mad - mad and brilliant!

Mad it is, as the whole thing bases on a formal mistake done by Blizzard coders,
brilliant it is, as it should work (and seems to have worked)!

yeah, i think in this MAJORLY OT thread, ive learned a helluva lot of JASS... lol

the problem is, it seems the only way to get this location would be through a Gamecache, effectively neutralizing the usefulness unless you are sending massive amounts of data...

ive learned a helluva lot of JASS

Cool

that was random

anyways, where have you been? i noticed you just suddenly came back and posted in like 100 threads

and, back on topic, Zsar, ima try to find the max User Data ( Custom Value ) of a unit, and c if we ( if its big enuff ) store values efficiently in a dummy =D

=.=...
Storing values like that, have its handicaps in contrast to native gamecache, where you can retrieve the values much easier.

*i recall a certain person commenting on using ForGroup cuz it runs faster*

as i said before, locations run 6.5* faster than GCs, according to Vex ( who we can most likely trust ).

also, i cant c why Custom Values would be slow neways