[Snippet] Buff Field

[Krogoth]

While other resources "under work" I am here again =]

This is extremely simple code that is designed to work with custom buffs

Interface does not use unit argument, but its direct index (to prevent GetUnitUserData() spamming)

There are unit single operation and unit multiple operations interfaces. Last one is recommended if you work with same unit few times.
Example:

Unit single operation:
call Buff.add(GetUnitUserData(u), BUFF_ASTONISHED)

Unit multiple operations:
call Buffy.setup(GetUnitUserData(u))
call Buffy.add(BUFF_HAS_LEG)
call Buffy.add(BUFF_HAS_HAND)
call Buffy.add(BUFF_HAS_HEAD)
call Buffy.add(BUFF_FIGHT_VAMPIRE)

Buff field should be inited before gets used

//-=-=-=-=-=-=-=-=-=-=-=-=-=-
//-=-=-=-] BuffField [-=-=-=-
//-=-=-=-=- v0.900 =-=-=-=-=-

library BuffField
globals
    private integer N
    private boolean array B
endglobals
    function InitBuffField takes integer n returns nothing
        set N = n
    endfunction
    
    //Unit single operation interface
    struct Buff extends array
        static method has takes integer ui, integer buffcode returns boolean
            return B[ui * N + buffcode]
        endmethod
    
        static method add takes integer ui, integer buffcode returns nothing
            set B[ui * N + buffcode] = true
        endmethod
    
        static method remove takes integer ui, integer buffcode returns nothing
            set B[ui * N + buffcode] = false
        endmethod
    endstruct

    //Unit multiple operations interface
    struct Buffy extends array
        private static integer i
        
        static method setup takes integer ui returns nothing
            set i = ui * N
        endmethod

        static method has takes integer buffcode returns boolean
            return B[i + buffcode]
        endmethod
    
        static method add takes integer buffcode returns nothing
            set B[i + buffcode] = true
        endmethod
    
        static method remove takes integer buffcode returns nothing
            set B[i + buffcode] = false
        endmethod
    endstruct
endlibrary

 

[Nestharus]

Ok, rather than making the same mistakes over and over again

Not acceptable, use a module initializer
function InitBuffField takes integer n returns nothing

This isn't an acceptable name
struct Buffy extends array

These aren't acceptable names

    private integer N
    private boolean array B

Not acceptable
private static integer i

No API listing with descriptions

Furthermore, your library doesn't account for possibly stacking buffs, it only handles buffs without stacking, so the entire design is not acceptable.

Also, this isn't acceptable

Use a list if you want to maintain a set of active buffs

        static method setup takes integer ui returns nothing
            set i = ui * N
        endmethod

This is definitely not acceptable, once again use a list or something

        static method has takes integer ui, integer buffcode returns boolean
            return B[ui * N + buffcode]
        endmethod
    
        static method add takes integer ui, integer buffcode returns nothing
            set B[ui * N + buffcode] = true
        endmethod
    
        static method remove takes integer ui, integer buffcode returns nothing
            set B[ui * N + buffcode] = false
        endmethod

This resource description is lacking

This is extremely simple code that is designed to work with custom buffs
Interface does not use unit argument, but its direct index (to prevent GetUnitUserData() spamming)
There are unit single operation and unit multiple operations interfaces. Last one is recommended if you work with same unit few times.

I'm cracking down on you

Try again.

edit
Also need an on destruction event for when buffs are destroyed from internal behavior (buff of higher level being applied to a unit w/ no stacking) and external behavior (when something in the map destroys a buff)

You also need an internal destructor that doesn't run the on destruction event provided by a module so that only the struct defining the specific buff may use it

You should be able to iterate over all buffs on a unit and remove buffs from that unit. I recommend a list of lists, the first being of buff types, and the second specific instances of those buff types (for stacking). If there is no stacking, then you need only the outer list. The list nodes should also be accessible from a table for O(1) access. When a struct implements the module, it registers with the system, thus defining a new buff type.

Ofc, if you have your own ideas, then go for those, but right now, this resource is sorely lacking : )

 

[Krogoth]

Not acceptable, use a module initializer

???
Buff count is defined depending on heroes picked
Though I can do it optional

This isn't an acceptable name
struct Buffy extends array

Why?
This is intuitive at least

These aren't acceptable names

    private integer N
    private boolean array B

Isn't this private / who cares?

No API listing with descriptions

Will be, just knew this would be not single criticism

Furthermore, your library doesn't account for possibly stacking buffs, it only handles buffs without stacking, so the entire design is not acceptable.

Nope, there is no need in such complex library. Most of buffs are non-stackable, what you propose is just waste of memory :O
Note, this is not system, but snippet. Stackable buff - another story, another library.

Use a list if you want to maintain a set of active buffs

For what if list is ... worse?
Array faster, simpler. This lists fassion is just ridiculous. :S

Edit:

You should be able to iterate over all buffs on a unit and remove buffs from that unit. I recommend a list of lists, the first being of buff types, and the second specific instances of those buff types (for stacking). If there is no stacking, then you need only the outer list. The list nodes should also be accessible from a table for O(1) access. When a struct implements the module, it registers with the system, thus defining a new buff type.

No, thanks, this is just ... a lot of useless code / memory again
Did not even get the purpose

Edit:
Your CTL, enjoy names once more

globals
private integer tgc = 0 //timer group count
private integer array tgr //timer group recycler

private integer ic=0 //instance count
private integer tc=0 //timer count
private integer array rf //root first
private integer array n //next
private integer array p //previous
private integer array th //timer head
private integer array ns //next stack
private trigger t=CreateTrigger()
private timer m=CreateTimer()
private triggercondition array ct
private conditionfunc array rc

private boolean array e32 //enabled
private integer array i32r //ct32 recycler
private integer i32cr = 0 //ct32 count recycler
private boolean array ir32 //is recycling
private boolean array id32 //is destroying
endglobals

Edit:
Updated op description

 

[Nestharus]

CTL was made before the standard on names was enforced, and you can't ask an author with so many resources to update them all at once to adopt new standards. I update them when I can.

Because you are using statically sized arrays, you only support x units and n buffs :\. Assuming that a map may have 2048 units at any given time and up to 12 buffs (realistic numbers and likely maximums), then your array must be size 24576, which it is not, therefore your resource can't support all feasible maps.

 

[Krogoth]

CTL was made before the standard on names was enforced, and you can't ask an author with so many resources to update them all at once to adopt new standards. I update them when I can.

There is no sense in it as well

Because you are using statically sized arrays, you only support x units and n buffs :\. Assuming that a map may have 2048 units at any given time and up to 12 buffs (realistic numbers and likely maximums), then your array must be size 24576, which it is not, therefore your resource can't support all feasible maps.

My array is not limited by units count, and every map has limited count of buffs until you create buffs dynamically (with your own pseudo-compilator)
2048 units - my PC crashes on 300 @ empty map

Edit:
Ok, not crashes, but lags as hell )

 

[edo494]

Ok, rather than making the same mistakes over and over again

Not acceptable, use a module initializer
function InitBuffField takes integer n returns nothing

This isn't an acceptable name
struct Buffy extends array

These aren't acceptable names

    private integer N
    private boolean array B

Not acceptable
private static integer i

Im honestly suprised this came out of your mouth...

    globals
        private trigger q=CreateTrigger()
        private trigger l=CreateTrigger()
        private unit array e
        private integer r=0
        private integer y=0
        private integer o=0
        private boolean a=false
        private integer array n
        private integer array p
        private integer array lc
    endglobals

if its not acceptable, why your Unit Indexer is still approved?

CTL was made before the standard on names was enforced

but by who it was enforced?

 

[Nestharus]

Ahem, given 12 players, it is feasible that each one can have 120 units, 10 squads of 12 units each. I've played plenty of maps where this has been true. This equates to 1440 units. Now, many times, players have more than 120 units. They actually end up having 200-240 units, so this is where I got my number from. In Risk, more like 300-400. This means that the feasible maximum for the map with the most units in it is 4800 units.

For an ORPG, it is very feasible that a unit will have 12 buffs on it. I've played ORPGs where the heroes have had ~12 buffs.

This means that in order to support the worst case scenario with your design, you need an array of size 57600. So my number was actually low : p.

Of course, this number will never happen, but there may be a unit with 12 buffs or there may be 4800 units, some of them having 1-2 buffs.

Because you are completely static, you must assign both 4800 units and 12 buffs per unit. If you were dynamic on a list or something, you could handle it all.

This is the reason why you using arrays is not acceptable, because you aren't supporting all maps : P.

edit
@edo494

Read my response

CTL was made before the standard on names was enforced, and you can't ask an author with so many resources to update them all at once to adopt new standards. I update them when I can.

Yes, good names are enforced now, but they are not enforced on older resources. Any new resources must have good names, but updating old resources is optional. It would be terribly unfair to the authors of older resources if those resources had to be updated as well.

Sadly, this rule was never listed, but it's been in effect since Vex fixed his optimizer, which was a while ago.

All of my new resources follow this rule =)

 

[Krogoth]

So, create more arrays is still better solution than lists :O
Will be back with extension

Edit:
By the way, how many bytes uses boolean array[80]?

 

[Nestharus]

Multiple arrays are slower than a table because of the if statements. You are better off using a dynamic collection. If you are going to go the big supersize route, you should use Table, not multiple arrays linked together. And no, you shouldn't use a hashtable because not all of the entries are going to be filled .

 

[TriggerHappy]

Graveyarding.

I really don't see the point of this. Not to mention it should be utilizing JH's 2D arrays.

If the author has an issue with this he can contact me.