[vJass] Buff System

[Moderator]

12:36, 11th Jul 2015
IcemanBo: So we wait for an update for now.

 

[btdonald]

GUI version will coming soon.

 

[Kazeon]

You should get this approved first before moving to the GUI version and upload it here.

 

[btdonald]

You should get this approved first before moving to the GUI version and upload it here.

Gaga I'm waiting for the review

Have you tested it Quilnez ^^!

 

[Wietlol]

Cant you "CREATE_BUFF_OBJECT" and "CREATE_BUFF" inside the Init function of Rage?

Also, (couldnt test the map) do you use an Aura as actual buff?

 

[btdonald]

Cant you "CREATE_BUFF_OBJECT" and "CREATE_BUFF" inside the Init function of Rage?

Also, (couldnt test the map) do you use an Aura as actual buff?

Hmmm put outside Init Function.

I use tornado aura

 

[Wietlol]

The problem of using an aura is simply that you cannot dispell the buff.
At least not by default.
Via triggers on the other hand it is... however this doesnt have any effect in your system.
It does not necessarily have to be added because it cost a lot of performance to do so, but you should mention it.
It might be a good idea to have a function that dispells. (one that loops through all buffs on each unit and checks if they pass a certain filter.)

Also, it would be cool if you can tell the game to make a positive aura instead.
I mean, Tornado Aura is a negative aura which results in a red buff aka debuff.
A positive aura like Devotion Aura leaves a green buff which should be used for positive effects.
The only problem is that I do not know of a positive aura that hides the icon just like tornado... maybe an item ability could do it though.

 

[btdonald]

The problem of using an aura is simply that you cannot dispell the buff.
At least not by default.
Via triggers on the other hand it is... however this doesnt have any effect in your system.
It does not necessarily have to be added because it cost a lot of performance to do so, but you should mention it.
It might be a good idea to have a function that dispells. (one that loops through all buffs on each unit and checks if they pass a certain filter.)

Also, it would be cool if you can tell the game to make a positive aura instead.
I mean, Tornado Aura is a negative aura which results in a red buff aka debuff.
A positive aura like Devotion Aura leaves a green buff which should be used for positive effects.
The only problem is that I do not know of a positive aura that hides the icon just like tornado... maybe an item ability could do it though.

Dispell buff ~ hmmm ..I think I will update it soon (something like Buff List).
Red buff can easily change color by color tag (I think)

The effect of buff, you must code. This system support you create buff, register apply/remove buff event.

If use positive aura we must create a spellbook. I think it's useless.

 

[Wietlol]

Red buff means negative buff.
Negative buff is removed when you remove negative buffs through triggers.
Positive buff is also negative buff in your system.

Anyway, how I do it in my system is to add and remove the aura to the targeted unit on intervals.
That way, the normal action "Remove buffs from unit" also removes the custom buff and it will get detected.
Because the ability is never on the unit, it doesnt matter if it is visible because you never see it.

I think that adding and removing it every 4 seconds (until the remaining duration is less than 4 seconds) can work out well enough.
I am not quite sure if that is worth the making though because, yes you can change the buff's red or green name in the tooltip using color codes and you wont be using the buffs that much like normal buffs.

 

[btdonald]

Red buff means negative buff.
Negative buff is removed when you remove negative buffs through triggers.
Positive buff is also negative buff in your system.

Anyway, how I do it in my system is to add and remove the aura to the targeted unit on intervals.
That way, the normal action "Remove buffs from unit" also removes the custom buff and it will get detected.
Because the ability is never on the unit, it doesnt matter if it is visible because you never see it.

I think that adding and removing it every 4 seconds (until the remaining duration is less than 4 seconds) can work out well enough.
I am not quite sure if that is worth the making though because, yes you can change the buff's red or green name in the tooltip using color codes and you wont be using the buffs that much like normal buffs.

Buff basically is an aura spell (so It can't be removed by Remove buff from unit).

You don't know

 UnitRemoveAbility(whichUnit, buffId)

will remove buff instantly.

You can see my remove() method, you can see that trick.

Don't care about Remove buffs from unit.

Edit:

I create this system through Buff Handler - Muzzel. Tornado Aura is used ^^!~

 

[Wietlol]

• Unit - Remove Positive buffs considered Magic or physical from (Triggering unit) (Exclude expiration timers, Include auras)

I said that they wont be removed by default... that dispel abilities does not remove them.
Via triggers, it is possible though.

There is no way that you can just make a filter without making a trigger and add the filter to that right?
I think it is not even as bad as I think but still.

I actually have no idea how you would be able to loop through all buffs on a specific unit without looping through all buffs and check if the unit is that target.
At first, I thought about using a unit indexer and placing the buffs in an array but then you can only have one buff per unit...

EDIT:
I think about making my personal version cause I dont use structs very well... actually, I just dont use them at all.
One question though... do I see it right that you use 2 triggers per instance of a buff?

Also, those set TriggerUnit = null isnt really necessary on remove and apply...

EDIT2:
Also allow Invulnerable + Vulnerable in targets allowed...
If I understand correctly, you only allow self.

 

[BPower]

As you mention it yourself, what are the advantages of this over Buff Handler.
Basically why should a user chose this over Buff Handler?

When looking at BuffHandler, why didn't you inheritate really essential functionality like
BUFF_POLICITY or onPeriodic. How do I manage custom members for my struct if I need them?

Why not allocate every Buff instance over a parent struct?

 

[btdonald]

• Unit - Remove Positive buffs considered Magic or physical from (Triggering unit) (Exclude expiration timers, Include auras)

I said that they wont be removed by default... that dispel abilities does not remove them.
Via triggers, it is possible though.

There is no way that you can just make a filter without making a trigger and add the filter to that right?
I think it is not even as bad as I think but still.

I actually have no idea how you would be able to loop through all buffs on a specific unit without looping through all buffs and check if the unit is that target.
At first, I thought about using a unit indexer and placing the buffs in an array but then you can only have one buff per unit...

EDIT:
I think about making my personal version cause I dont use structs very well... actually, I just dont use them at all.
One question though... do I see it right that you use 2 triggers per instance of a buff?

Also, those set TriggerUnit = null isnt really necessary on remove and apply...

EDIT2:
Also allow Invulnerable + Vulnerable in targets allowed...
If I understand correctly, you only allow self.

I use 2 triggers per struct not instance, TriggerUnit = null make my code more safety (I think).

Aura is allow target self.

As you mention it yourself, what are the advantages of this over Buff Handler.
Basically why should a user chose this over Buff Handler?

When looking at BuffHandler, why didn't you inheritate really essential functionality like
BUFF_POLICITY or onPeriodic. How do I manage custom members for my struct if I need them?

Why not allocate every Buff instance over a parent struct?

Hmmmm, I used to think like you. But I think some think useless. A parent struct with stub method is good on case you use it in a struct, what about outside Method onApply and onRemove can easily replace by

RegisterApplyBuff$NAME$Event

RegisterRemoveBuff$NAME$Event

Example:

RegisterApplyBuffRageEvent(Filter(thistype.onApply))

I think that's a good solution.

Anyway, thank for your feedbacks

P/s: Wietlol I will test with

• Unit - Remove Positive buffs considered Magic or physical from (Triggering unit) (Exclude expiration timers, Include auras)

anh give you the result!

EDIT:

BUFF_POLICY will be added to this ^^!~

EDIT:

This is easy to create a new buff for anyone include function for both GUI/JASS.

 

[Wietlol]

Targets Allowed is always a bit of a pain imo.

Self means that you can target yourself.
Because everything like Friend, Ally and Enemy are false, it only targets himself.

However, Invulnerable is also invulnerable to targeted spells. Remember that you cant cast Storm Bolt on an invulnerable unit?
That is why you NEED Invulnerable to be true.

However, this means that you are ONLY allowed to target invulnerable units.
So you also have to set Vulnerable to true.
That way, it doesnt matter if your hero is vulnerable or not.


About removing...
If you remove the buff and want to check periodically, you are taking a lot of performance that is not necessary.
I dont care if you tell me that that function does not work for your buffs and I have to use your custom method that loops through all buffs on a certain unit.
But only if you tell me in the top of the system (in the documentation, probably in a bug list) that I have to do it.

 

[BPower]

Hmmmm, I used to think like you. But I think some think useless. A parent struct with stub method is good on case you use it in a struct, what about outside Method onApply and onRemove can easily replace by

And now no longer . Data structure is up to you. It was just an idea.
I think it's really important to compare two code snippets which share the same goal.
Because somehow a user has to decide which one he should import to his map.
I'm curious on the GUI attempt. For this please try to make it
compatible with the normal wc3 world editor.

Yes onApply/onRemove can be replaced by trigger evaluation thats true,
that's why i mentioned an on period function.

You should definitly think of a way users can do UnitHasBuff(unit, buff)

 

[Wietlol]

"For this please try to make it
compatible with the normal wc3 world editor. "

Wow... I actually cannot believe you said that.
But yea, on the other hand, I can.

Ill show you my data structure as soon as I can get it.

 

[btdonald]

And now no longer . Data structure is up to you. It was just an idea.
I think it's really important to compare two code snippets which share the same goal.
Because somehow a user has to decide which one he should import to his map.
I'm curious on the GUI attempt. For this please try to make it
compatible with the normal wc3 world editor.

Yes onApply/onRemove can be replaced by trigger evaluation thats true,
that's why i mentioned an on period function.

You should definitly think of a way users can do UnitHasBuff(unit, buff)

First, I think we must give the user more choices (use external object (easy way but not common) or create object by your self) .
Second, I'll make this work independently with TimerUtils or Unit Indexer (no more requirement).
Third, do u think hook can solve problem with UnitHasBuff hmmm

I'm thinking about combine this with buff handler

 

[BPower]

Go ahead. Let your creativity guide you . I'm not there for a few days,
so I will be curious about the outcome.

 

[btdonald]

Go ahead. Let your creativity guide you . I'm not there for a few days,
so I will be curious about the outcome.

Have a good trip

 

[btdonald]

"For this please try to make it
compatible with the normal wc3 world editor. "

Wow... I actually cannot believe you said that.
But yea, on the other hand, I can.

Ill show you my data structure as soon as I can get it.

Haha GUI version is available but I have to fix something from core code.

 

[Wietlol]

Object Buff
    unit            buff_Target
    unit            buff_Source
    integer         buff_BuffType
    timer           buff_Timer
    real            buff_Duration
    
Object BuffType
    integer         bufftype_AbilityId
    integer         bufftype_BuffId
    real            bufftype_Interval
    trigger         bufftype_TriggerApply
    trigger         bufftype_TriggerInterval
    trigger         bufftype_TriggerRemove
    //User defined:
    boolean         bufftype_Classification_CrowdControl
    boolean         bufftype_Classification_Magical
    boolean         bufftype_Classification_Physical
    //etc
    //etc
    //etc



    function Buff_Expire takes nothing returns nothing
        call Buff_Destroy(GetTimerData(GetExpiredTimer()))
    endfunction
    function Buff_Interval takes nothing returns nothing
        local integer id = GetTimerData(GetExpiredTimer())
        
        call TriggerEvaluate(udg_Bufftype_TriggerInterval[udg_Buff_BuffType[id]])
        
        set udg_Buff_Duration[id] = udg_Buff_Duration[id] - udg_Bufftype_Interval[udg_Buff_BuffType[id]]
        if udg_Buff_Duration[id] > udg_Bufftype_Interval[udg_Buff_BuffType[id]] then
            call TimerStart(udg_Buff_Timer[id], udg_Buff_Duration[id], false, function Buff_Expire)
        endif
        
    endfunction
    function Buff_Apply takes unit source, unit target, integer buffType, real duration returns integer
        local integer id = Buff_Create()
        
        set buff_Source[id] = source
        set buff_Target[id] = target
        set buff_BuffType[id] = buffType
        set buff_Timer[id] = NewTimerEx(id)
        set buff_Duration[id] = duration
        
        if bufftype_Interval[buff_BuffType[id]] > 0. then
            call TimerStart(buff_Timer[id], bufftype_Interval[buff_BuffType[id]], true, function Buff_Interval)
        else
            call TimerStart(buff_Timer[id], duration, false, function Buff_Expire)
        endif
        
        call TriggerEvaluate(bufftype_TriggerApply[buff_BuffType[id]])
        
        return id
    endfunction

As you can see my buff uses almost the same data as yours but the only difference is that it also stores the duration.

Also, each bufftype has an interval which is 0 by default but you can change that.

When a buff starts, it checks if it has an interval (meaning interval is bigger than 0) and then it will run the Interval function instead of the Expire function.

EDIT:
Ow yes, the classifications (which I need for my maps for example) are just an example of how extra variables are created.

EDIT2:

Haha GUI version is available but I have to fix something from core code.

You then have to write it without Struct, without TimerUtils, without TextMacros, and everything else.
You then better create from scratch then

 

[btdonald]

Object Buff
    unit            buff_Target
    unit            buff_Source
    integer         buff_BuffType
    timer           buff_Timer
    real            buff_Duration
    
Object BuffType
    integer         bufftype_AbilityId
    integer         bufftype_BuffId
    real            bufftype_Interval
    trigger         bufftype_TriggerApply
    trigger         bufftype_TriggerInterval
    trigger         bufftype_TriggerRemove
    //User defined:
    boolean         bufftype_Classification_CrowdControl
    boolean         bufftype_Classification_Magical
    boolean         bufftype_Classification_Physical
    //etc
    //etc
    //etc



    function Buff_Expire takes nothing returns nothing
        call Buff_Destroy(GetTimerData(GetExpiredTimer()))
    endfunction
    function Buff_Interval takes nothing returns nothing
        local integer id = GetTimerData(GetExpiredTimer())
        
        call TriggerEvaluate(udg_Bufftype_TriggerInterval[udg_Buff_BuffType[id]])
        
        set udg_Buff_Duration[id] = udg_Buff_Duration[id] - udg_Bufftype_Interval[udg_Buff_BuffType[id]]
        if udg_Buff_Duration[id] > udg_Bufftype_Interval[udg_Buff_BuffType[id]] then
            call TimerStart(udg_Buff_Timer[id], udg_Buff_Duration[id], false, function Buff_Expire)
        endif
        
    endfunction
    function Buff_Apply takes unit source, unit target, integer buffType, real duration returns integer
        local integer id = Buff_Create()
        
        set buff_Source[id] = source
        set buff_Target[id] = target
        set buff_BuffType[id] = buffType
        set buff_Timer[id] = NewTimerEx(id)
        set buff_Duration[id] = duration
        
        if bufftype_Interval[buff_BuffType[id]] > 0. then
            call TimerStart(buff_Timer[id], bufftype_Interval[buff_BuffType[id]], true, function Buff_Interval)
        else
            call TimerStart(buff_Timer[id], duration, false, function Buff_Expire)
        endif
        
        call TriggerEvaluate(bufftype_TriggerApply[buff_BuffType[id]])
        
        return id
    endfunction

As you can see my buff uses almost the same data as yours but the only difference is that it also stores the duration.

Also, each bufftype has an interval which is 0 by default but you can change that.

When a buff starts, it checks if it has an interval (meaning interval is bigger than 0) and then it will run the Interval function instead of the Expire function.

EDIT:
Ow yes, the classifications (which I need for my maps for example) are just an example of how extra variables are created.

EDIT2:

You then have to write it without Struct, without TimerUtils, without TextMacros, and everything else.
You then better create from scratch then

A new struct coming called BuffData ... will store buff information ^^!~

 

[Zwiebelchen]

BuffHandler imho is superior to this, for the following reasons:

- Cleaner API (no use of Textmacros)
- Provides duration and periodic callbacks by default
- differentiates between preDestroy (fires when the buff is actually destroyed) and onRemove (fires when the buff is removed from the unit) ... which is critical for spell-steal or dispel abilities
- Buff icons are actually optional
- Provides two default stacking policies (infinitely stacking buffs and non-stacking buffs) and allows to define custom policies
- Provides a data structure for iterating through buffs and buff-lists (which are like groups just for buffs)
- Having onRemove and onApply as actual events requires extra input of the user, while not really providing any real advantage (Why would you need this on a per-instance basis instead of per-type? Buffs of the same type usually follow the same rules)

MAKE SURE YOU ARE REGISTRY WARCRAFT 3 AND JNGP IN TRUE WAY

Wat?

 

[btdonald]

BuffHandler imho is superior to this, for the following reasons:

- Cleaner API (no use of Textmacros)
- Provides duration and periodic callbacks by default
- differentiates between preDestroy (fires when the buff is actually destroyed) and onRemove (fires when the buff is removed from the unit) ... which is critical for spell-steal or dispel abilities
- Buff icons are actually optional
- Provides two default stacking policies (infinitely stacking buffs and non-stacking buffs) and allows to define custom policies
- Provides a data structure for iterating through buffs and buff-lists (which are like groups just for buffs)
- Having onRemove and onApply as actual events requires extra input of the user, while not really providing any real advantage (Why would you need this on a per-instance basis instead of per-type? Buffs of the same type usually follow the same rules)



Wat?

I'm going to remake this system. Combine buff handler and this, more features.

Now, buff handler must use struct ... extends Buff to use. That isn't convenient.

Buff Handler or this should work through inside/outside struct, GUI/ JASS and more.

But anyway, thanks for your feedback

P/s: a new version coming soon ^^!~

 

[Zwiebelchen]

Now, buff handler must use struct ... extends Buff to use. That isn't convenient.

I don't know how struct extension should be any less convenient than this weird mixture of struct syntax and functions.
It's perfectly logical that a custom buff extends basic buffs, imho.

Buff Handler or this should work through inside/outside struct, GUI/ JASS and more.

Buff Handler was not written with the GUIers in mind, that's true.

But your system lacks core features, that's all I'm saying. If you intend to write a GUI friendly buff system, better remove the struct syntax completely.

 

[btdonald]

Buff Handler was not written with the GUIers in mind, that's true.

Why not

 

[Nestharus]

What happens when two buffs of the same kind are applied to a unit when

1. They are the same level
2. The current one is a lower level than the new one
3. The current one is a higher level than the new one

Will they stack? Will one override the other? Will they refresh? Will nothing happen?

Buffs, in the above regard, have pretty standard behavior across all games. The only difference in buffs is that some stack and some don't. They might also stack up to x number of times or when certain conditions are met. Heck, the amount they stack may change from one moment to another as well.


The reason I did not like Muzzel's buff handler is because he didn't handle the stuff I mentioned above. This system also doesn't handle those things.

If practically all but the absolutely simplest of buffs use the above, you should handle the above : P. I handled it in my AuraStruct resource. Auras are slightly more complicated than buffs too because the lower level auras persist underneath the higher level ones. When the high level ones goes away, the next highest pops up ; ). Auras are really just buffs that constantly refresh.

 

[btdonald]

What happens when two buffs of the same kind are applied to a unit when

1. They are the same level
2. The current one is a lower level than the new one
3. The current one is a higher level than the new one

Will they stack? Will one override the other? Will they refresh? Will nothing happen?

Buffs, in the above regard, have pretty standard behavior across all games. The only difference in buffs is that some stack and some don't. They might also stack up to x number of times or when certain conditions are met. Heck, the amount they stack may change from one moment to another as well.


The reason I did not like Muzzel's buff handler is because he didn't handle the stuff I mentioned above. This system also doesn't handle those things.

If practically all but the absolutely simplest of buffs use the above, you should handle the above : P. I handled it in my AuraStruct resource. Auras are slightly more complicated than buffs too because the lower level auras persist underneath the higher level ones. When the high level ones goes away, the next highest pops up ; ). Auras are really just buffs that constantly refresh.

I'm rewritting this but I cause some problem about Table. Have you ever cause this bug

http://www.hiveworkshop.com/forums/lab-715/bug-table-cause-bug-save-handle-267383/

 

[Zwiebelchen]

What happens when two buffs of the same kind are applied to a unit when

1. They are the same level
2. The current one is a lower level than the new one
3. The current one is a higher level than the new one

Will they stack? Will one override the other? Will they refresh? Will nothing happen?

Buffs, in the above regard, have pretty standard behavior across all games. The only difference in buffs is that some stack and some don't. They might also stack up to x number of times or when certain conditions are met. Heck, the amount they stack may change from one moment to another as well.


The reason I did not like Muzzel's buff handler is because he didn't handle the stuff I mentioned above. This system also doesn't handle those things.

If practically all but the absolutely simplest of buffs use the above, you should handle the above : P. I handled it in my AuraStruct resource. Auras are slightly more complicated than buffs too because the lower level auras persist underneath the higher level ones. When the high level ones goes away, the next highest pops up ; ). Auras are really just buffs that constantly refresh.

This is basicly featuritis all over again.

As long as you have a way to define your own stacking policies (and BuffHandler has that), I don't see a reason why all that should be there by default.
Because in most cases you don't care for these things. 90% of the time you either want buffs to stack infinitely (which is the default) or make the last applied buff overwrite all other buffs of the same type (which is the other selectable default behaviour).

All other policies imho are extremely map-specific. Adding them as defaults is a waste of effort, especially for a system that was clearly made for the vJasser, not the lowlevel GUIer.


I know we have different views on that; you're someone who enjoys feature-complete systems with ultimate flexibility (and high complexity)
On the other end, I prefer simpler frameworks and add the required extra features manually. Because every feature I won't use is a waste of resources. And it's easier to have less, then expand upon that than to have more and slim it.

 

[IcemanBo]

I think it can be also orientated to this buff system: http://www.hiveworkshop.com/forums/submissions-414/snippet-needs-power-time-buff-230697/

It provides several events for buff, and also dispell. (periodic, apply, remove, death, dispell, and more)
You can enum all buffs for a unit, enum all positive buffs, or enum all negative buffs.
Look at the wide API and functionalities, I think it's all one need, for example refreshing the buff completly.

Really not meant as offense, but I'm not really a fan of it if it doesn't provide something more (or even less)
than already existing systems and is (iny my view) written with less readable code and API. (for example macros)

 

[btdonald]

I think it can be also orientated to this buff system: http://www.hiveworkshop.com/forums/submissions-414/snippet-needs-power-time-buff-230697/

It provides several events for buff, and also dispell. (periodic, apply, remove, death, dispell, and more)
You can enum all buffs for a unit, enum all positive buffs, or enum all negative buffs.
Look at the wide API and functionalities, I think it's all one need, for example refreshing the buff completly.

Really not meant as offense, but I'm not really a fan of it if it doesn't provide something more (or even less)
than already existing systems and is (iny my view) written with less readable code and API. (for example macros)

I'm re-writting this. New features and new features and new features ...