1. Updated Resource Submission Rules: All model & skin resource submissions must now include an in-game screenshot. This is to help speed up the moderation process and to show how the model and/or texture looks like from the in-game camera.
    Dismiss Notice
  2. DID YOU KNOW - That you can unlock new rank icons by posting on the forums or winning contests? Click here to customize your rank or read our User Rank Policy to see a list of ranks that you can unlock. Have you won a contest and still havn't received your rank award? Then please contact the administration.
    Dismiss Notice
  3. The poll for Hive's 12th Concept Art Contest is up! Go cast your vote for your favourite genie!
    Dismiss Notice
  4. Travel to distant realms and encounter scenes unknown to the common folk. The Greatest of Adventures is upon us with the 8th Cinematic Contest. Join in on a fun ride.
    Dismiss Notice
  5. The 18th Icon Contest is ON! Choose any ingame unit and give him/her Hero abilities. Good luck to all.
    Dismiss Notice
  6. Contestants are to create a scene set in the Stone Age. Come and see what you can come up with. We wish you the best of luck!
    Dismiss Notice
  7. Colour outside the lines! Techtree Contest #13 is a go. The contest is optionally paired.
    Dismiss Notice
  8. Greetings cerebrates, our Swarm needs new spawners that will have numerous children. Join the HIVE's 31st Modeling Contest - Spawners and Spawned! The contest is optionally paired.
    Dismiss Notice
  9. Check out the Staff job openings thread.
    Dismiss Notice
Dismiss Notice
60,000 passwords have been reset on July 8, 2019. If you cannot login, read this.

[Snippet] Buff Field

Discussion in 'Graveyard' started by Krogoth, Aug 8, 2013.

  1. Krogoth

    Krogoth

    Joined:
    Apr 5, 2011
    Messages:
    247
    Resources:
    0
    Resources:
    0
    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:
    Buff field should be inited before gets used

    Code (vJASS):
    //-=-=-=-=-=-=-=-=-=-=-=-=-=-
    //-=-=-=-] 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
     
    Last edited: Aug 8, 2013
  2. Nestharus

    Nestharus

    Joined:
    Jul 10, 2007
    Messages:
    6,149
    Resources:
    8
    Spells:
    3
    Tutorials:
    4
    JASS:
    1
    Resources:
    8
    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
    Code (vJASS):

        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
    Code (vJASS):

            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
    Code (vJASS):

            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
    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 : )
     
  3. Krogoth

    Krogoth

    Joined:
    Apr 5, 2011
    Messages:
    247
    Resources:
    0
    Resources:
    0
    ???
    Buff count is defined depending on heroes picked
    Though I can do it optional
    Why?
    This is intuitive at least
    Isn't this private / who cares?
    Will be, just knew this would be not single criticism :D
    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.
    For what if list is ... worse?
    Array faster, simpler. This lists fassion is just ridiculous. :S

    Edit:
    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
    Edit:
    Updated op description
     
  4. Nestharus

    Nestharus

    Joined:
    Jul 10, 2007
    Messages:
    6,149
    Resources:
    8
    Spells:
    3
    Tutorials:
    4
    JASS:
    1
    Resources:
    8
    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.
     
  5. Krogoth

    Krogoth

    Joined:
    Apr 5, 2011
    Messages:
    247
    Resources:
    0
    Resources:
    0
    There is no sense in it as well
    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 )
     
  6. edo494

    edo494

    Joined:
    Apr 16, 2012
    Messages:
    3,855
    Resources:
    5
    Spells:
    1
    JASS:
    4
    Resources:
    5
    Im honestly suprised this came out of your mouth...
    if its not acceptable, why your Unit Indexer is still approved?

    but by who it was enforced?
     
  7. Nestharus

    Nestharus

    Joined:
    Jul 10, 2007
    Messages:
    6,149
    Resources:
    8
    Spells:
    3
    Tutorials:
    4
    JASS:
    1
    Resources:
    8
    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

    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 =)
     
  8. Krogoth

    Krogoth

    Joined:
    Apr 5, 2011
    Messages:
    247
    Resources:
    0
    Resources:
    0
    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]?
     
  9. Nestharus

    Nestharus

    Joined:
    Jul 10, 2007
    Messages:
    6,149
    Resources:
    8
    Spells:
    3
    Tutorials:
    4
    JASS:
    1
    Resources:
    8
    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 ;).
     
  10. TriggerHappy

    TriggerHappy

    Code Moderator

    Joined:
    Jun 23, 2007
    Messages:
    3,659
    Resources:
    22
    Spells:
    11
    Tutorials:
    2
    JASS:
    9
    Resources:
    22
    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.