does still anyone use kattana's system?

[13lade619]

random question..

is there anyone here who still uses kattana's local handle vars system?

if not.. why? is it inefficient or something?
and what are the advantages of the system you're using now?

IMO, it's still good since it's an all around attachment system that can attach any data to any handle.. especially structs..

i'm just interested 'cause i'm still using it and maybe there's a better one out there.

 

[wraithseeker]

It is old and weak since it uses game cache I believed.

 

[Viikuna]

Not because of gamecache, but because of I2H.

If you need gamecache, you should use Vexorians Table, it has nicer interface.

 

[13lade619]

, but because of I2H.

what is I2H exactly and what's bad about it?

 

[Trollvottel]

Actually there are no problems with kattanas if you use it correctly. Its fast enough for the most things. And if you use it for struct attachment there will be no bugs at all.

 

[wraithseeker]

But it's interface isn't really nice and like Viikuna said, I2H is bad. I seen one of the debating of I2H in a thread in WC3C where Vex talked about Icefrog using I2H and got some debug messages sometimes.

 

[Flare]

what is I2H exactly and what's bad about it?

This should be informative, particularly this post.

Heres how the bug works:

Suppose you have a unit, a footman

You set FootmanIndex = H2I(Footman)
you call RemoveUnit(Footman).
you set Footman = null

Now the game recycles the Footman unit index that you have stored in FootmanIndex, and the next handle (or one of the many next) that is created gets the SAME handle index that the Footman has. This will also happen if the footman dies, decays, and gets recycled by the Wc3 engine as well.

Now lets say you set Footman = I2U(FootmanIndex). You now have a unit variable that isn't actually a unit, it is a Location! Uh oh! Call GetWidgetLife(Footman). Now you called GetWidgetLife on a Location! This is very bad, and is really unknown to what it specifically does, but it may crash (i never tried it).

So the act of calling I2H isnt actually bugged, its a reliable function, but the integer value you pass to I2H being corrupted causes the problems.

This problem is easily seen when storing H2I values in gamecache then nulling the handle variable. Then there is no guarantee that the I2H(gamecachevariable) call will give back the correct handle.

Theres one method that I know of that prevents this issue. When using H2I, make sure that you store not only the integer value it returns, but also store the handle variable. These must be stored in global variables, not gamecache. This will prevent the Wc3 engine from ever recycling the handle index until you null the handle variable.

Although, there are more problems supposedly associated with it, that's the first one I found with a good explanation

 

[Trollvottel]

you dont have to use I2H for struct attachment

 

[wraithseeker]

And if you use it for struct attachment there will be no bugs at all.

Lulz

 

[Trollvottel]

library LHV
 
globals
    gamecache LOCAL_HANDLE_CACHE = InitGameCache("localhandles.w3v")
endglobals
 
// ===========================
private function H2I takes handle h returns integer
    return h
    return 0
endfunction
 
// ===========================
function LV takes nothing returns gamecache
    return LOCAL_HANDLE_CACHE
endfunction
 

 
function SetHandleInt takes handle subject, string name, integer value returns nothing
        call StoreInteger(LV(), I2S(H2I(subject)), name, value)
endfunction
 
 
function GetHandleInt takes handle subject, string name returns integer
    return GetStoredInteger(LV(), I2S(H2I(subject)), name)
endfunction
 
endlibrary

show me the I2H here.

 

[Romek]

It's still slow.

And there are faster systems, with nicer interfaces and more 'features' available too.

 

[Trollvottel]

 	 It's still slow.

I've heard that GameCache is about 4 times slower than an array. Not very slow, is it?
and doesnt HSAS or HAIL (dont know which system) use Game Cache?

And there are faster systems, with nicer interfaces and more 'features' available too.

I agree.

 

[SFilip]

> Not very slow, is it?
It is. Why use something slower when you don't have to?

 

[Trollvottel]

I didnt say i use it... I just said its not too slow to use it. And it is 1 call per timer run - can it be that bad?

 

[Romek]

> and doesnt HSAS or HAIL (dont know which system) use Game Cache
Maybe as a backup or something, incase something goes wrong.
But otherwise, It's very unlikely.

I'm pretty sure ABC uses gamecache when there's a collision.

 

[Trollvottel]

Maybe as a backup or something, incase something goes wrong.
But otherwise, It's very unlikely.

oh i think 1 of the system just stores values like H2I(h) - 0x10000000... in an array and if the value is above 8192 it just stores it in gamecache. but.... look a big map has about 5000 handles minimum at map initialization. look at the doodads etc. And everytime i tested a spell which used HSAS it lagged me to death -.-.

 

[Azlier]

Doodads are handles, now? I must test this, someday...

 

[Trollvottel]

destructables are. i used the wrong word. but there are some maps which have thousands of trees, why do you think there is a destructable limit?

 

[Viikuna]

I would still rather use Table.
Why?
Because it looks nicer.
And because most of recources in these days use it and not Handle vars.

And you dont really need gamecache too often anyways.

I use struct arrays and timer stacks for attaching timers.
I use UnitUserData for indexing units.

So I only rarely need Table for something.

 

[Romek]

Also, take into consideration that most current attachment systems were actually created to replace LHV, because it was slow and unsafe. So going back to using that because there's "nothing wrong with it", is a bit silly.

As Viikuna said, if you insist on gamecache, then at least go for Table.

Though the only time I need to use that is to attach structs to ID's or similar.

I use a static timer for attaching to timers.
PUI for unit attaching.