System ABC - Struct Attachment System

[Cohadar]

Wait, what? ABC is using gamecache as a backup now? (You may want to add it to the list of features, if that is true )

It showed best on the tests, at least for now.
Note that ABC use of gamecache(or any backup type) is very different from that in other systems.

Collision is still independent of how many leaks you have in your map so ABC will still own any other system when it comes to map safety.

Collision chance is X/8191 where X is number of attachments at one point of time with one type of function.
So for example if you have 30 triggers using hash A, the chance of them colliding is theoretically 30/8191 = ~0.004

I say theoretically because chance is a lot smaller since wc3 allocates handles linearly.

Shouldn't these be constant functions, so that they are inlined into the code during preprocessing?

They will get inlined anyway.

I like the new organization of the textmacros, it's easier to see the actual function calls and the create/get/clear textmacros.

It is also harder for noobs to abuse ABC

Just curious, were the

call InitTimerHashB()

type functions removed solely because the textmacros no longer contain the globals block and the Init$NAME$Hash$X$ function, or was there another reason behind it?

Because it was less code in using one big Init than in making 12 small inits that will be called from main init...

 

[cr4xzZz]

Woah, new version! Is the speed still the same/improved with this gamecache stuff? :s

 

[Forty]

got a question:

    local integer i = H2I(key)
    set i = i - (i / HASH) * HASH

this is always 0 for me, what am i doing wrong?

 

[Cohadar]

Woah, new version! Is the speed still the same/improved with this gamecache stuff? :s

Get function is a bit faster when there are collisions in the system but that happens rarely.
So in 99.99% of cases speed is same as before.

Main improvement is actually the fact that collision has 8 times less chance to happen than i previous version.

got a question:

    local integer i = H2I(key)
    set i = i - (i / HASH) * HASH

this is always 0 for me, what am i doing wrong?

Your key is null.

 

[Forty]

no i mean:


if i is 100

and hash was... 10 (as example)

it was:

100- (100/10) * 10
= 100 - 100
= 0

 

[Cohadar]

no i mean:


if i is 100

and hash was... 10 (as example)

it was:

100- (100/10) * 10
= 100 - 100
= 0

It is zero when ever hash is dividable by key value, but in other cases:
HASH = 117
KEY = 1024
i = 1024 - (1024/117)*117 = 1024 - 8 * 117 = 88

Remember integer division has round-off errors, that is what makes hashing possible.

 

[Forty]

ah now i see. silly me didnt notice the integer-type

 

[Joker(Div)]

In the textmacro what is x?

 

[Forty]

its the A, B or C

 

[Darthfett]

After finding a few problems in my map, (and forgetting about a few warnings in ABC v 5.2), I found a(nother) reason why you shouldn't attach to units. Unless you used ABC to attach a struct to every unit, it will cause major lag, and possibly thread crashing.

I was trying to exploit something that is different with CSData and Gamecache, which do not use a loop method, and return 0 just as fast as they return an actual stored integer. I disabled debug mode so I could host the game online, and found that I could no longer use a feature in my map. In my opinion, only the BJDebugMsg should have the debug prefix, so that things will still work the same without debug mode, but this is an outdated version.

Long story short, ABC was reaching the op limit because I was giving it a unit which had no struct attached, which caused the thread to crash. With debug on, it would return 0 before the op limit was reached, but this does defeat the purpose.

Lesson Learned: Stay away from ABC for unit attachment.

I'll be using either GameCache or PUI now.

 

[Cohadar]

Just use PUI and save yourself more of this kind of trouble..

PS: You can host games that have been compiled in debug mode.

 

[Darthfett]

PS: You can host games that have been compiled in debug mode.

Yes, but then you get the ugly debug Messages (IMO, a game should only have those inside debug tags, so that the game works the same way except for the visible errors to the programmer).

One last thing, just to make sure, PUI doesn't destroy a struct if the unit dies/is removed, correct? (I don't want my sliding triggers to be sliding a dead unit, but I also am trying to find a way around doing an if-then to see if a unit's health is less than 0.405 hp or if the unit is null).

Thanks for answering my strange questions, it's been a learning experience for me.

 

[Cohadar]

Yes, but then you get the ugly debug Messages (IMO, a game should only have those inside debug tags, so that the game works the same way except for the visible errors to the programmer).

Actually debug messages are very good because people can say to you:
hay I got ERROR: WitchCurse Unable to create dummy caster...
and you know exactly where error is and can fix it at once.

The fact players see a warning or error message will not make them stop playing.

One last thing, just to make sure, PUI doesn't destroy a struct if the unit dies/is removed, correct? (I don't want my sliding triggers to be sliding a dead unit, but I also am trying to find a way around doing an if-then to see if a unit's health is less than 0.405 hp or if the unit is null).

PUI does destroy a struct when unit is removed from game.
Dead units will be sliding, but removed units will not.
And doing if 0.405 is a very good thing, GetWidgetLife is the fastest wc3 native function.

 

[Tyrande_ma3x]

In 6.0 when does ABC refer to Game Cache? When you're over 8191 handles?

 

[Trollvottel]

Looks like it stores it in game cache if you haven't flushed the space before. so if you do

SetTimerStructA(t, d1)
SetTimerStructA(t, d2)

the second call should store it in gamecache. i could be wrong though.

BUT DONT DO IT LIKE THIS.

I think it is made for collision, if 2 handles get the same place in the "hash-table"

 

[Romek]

> In 6.0 when does ABC refer to Game Cache? When you're over 8191 handles?
I believe it's when there's a collision.
ABC isn't really affected by the amount of handles in-game.

 

[Tyrande_ma3x]

> BUT DONT DO IT LIKE THIS.
I know, I know, I've used it many times (the system, not the double Set). I'm just asking because I couldn't understand when it uses GC for backup. Thanks for clearing it up.

 

[Cohadar]

In 6.0 when does ABC refer to Game Cache? When you're over 8191 handles?

This statistically means never.
(Unless you do something crazy like have 4000 timers and 4000 triggers all run at the same time)

Looks like it stores it in game cache if you haven't flushed the space before. so if you do

SetTimerStructA(t, d1)
SetTimerStructA(t, d2)

the second call should store it in gamecache. i could be wrong though.

BUT DONT DO IT LIKE THIS.

I think it is made for collision, if 2 handles get the same place in the "hash-table"

This is correct.

 

[kingkingyyk3]

Hehe, I had used to before to attach unit before i know struct.

local unit caster = GetTriggerUnit()
local timer t = CreateTimer()
call SetTimerStructA(t,H2I(caster))

 

[Cohadar]

v6.1 (compatibility release for patch 1.23b)