Syntax Error, on TimerStart line :S

[Komaqtion]

Hi!

I don't know if there is a system that adds a buff to a unit, which has an "expiration-time" on it (The buff I mean, not the unit ), and being MUI, and customizeable ?

If so, or if it isn't possible, or if there's an easier way... Please notify me XD

But, anyways, I get a single "Syntax Error", on the "call TimerStart(......)" line here, why ?:

    struct Expire
        
        private method remove takes nothing returns nothing
            
        endmethod
    
        static method create takes integer buffid, real duration, unit target returns Expire
            local Expire e = Expire.allocate()
            local timer t = CreateTimer()
            call UnitAddAbility(target, buffid)
            call TimerStart(t, duration, false, function .remove)
            
            return e
        endmethod
        
    endstruct

 

[TriggerHappy]

You can use methods inside callbacks because functions cannot have argurments.

And methods are compiled like this;

//
method remove takes nothing returns nothing
        
endmethod

function structname__remove takes integer this returns nothing

endmethod

Either use a function or a static method.

 

[Komaqtion]

You can use methods inside callbacks because functions cannot have argurments.

Huh ?! :S
Don't really understand what you mean there XD

Either use a function or a static method.

I tried a static method, like this:

    private static method remove takes nothing returns nothing
    endmethod

But still the same error

 

[Azlier]

When referencing static methods, you use: function thistype.method

 

[Komaqtion]

Ok... Like this then:

    static method create takes integer buffid, real duration, unit target returns Expire
    local Expire e = Expire.allocate()
    local timer t = CreateTimer()
    call UnitAddAbility(target, buffid)
    call TimerStart(t, duration, false, function Expire.remove)
 
    return e
endmethod

 

[Azlier]

Sure. You can really just use thistype. though.

 

[Komaqtion]

Well, why ? :S
Is it better, or just for the look of it ?

 

[Azlier]

Because you CAN!

 

[Komaqtion]

Ok then :S Really good answer

But, I gotta ask something else now, which might crash this whole snippet/system...

Is it possible to simply just add a buff to a unit, and then just remove it ? :S

Because, I'm currently testing this:

library ExpireBuff

    struct Expire
        
        integer buffid
        unit target
        unit source
        real damage
        
        private static method remove takes nothing returns nothing
            local Expire e = Expire.allocate()
            
            call PauseTimer(GetExpiredTimer())
            call DestroyTimer(GetExpiredTimer())
            call UnitRemoveAbility(e.target, e.buffid)
        endmethod
    
        static method create takes integer buffid, integer level, real duration, unit target returns Expire
            local Expire e = Expire.allocate()
            local timer t = CreateTimer()
            
            set e.buffid = buffid
            set e.target = target
            
            call UnitAddAbility(e.target, e.buffid)
            call SetUnitAbilityLevel(e.target, e.buffid, level)
            call TimerStart(t, duration, false, function Expire.remove)
            
            return e
        endmethod
        
    endstruct
    
    function AddExpiringBuff takes integer buffid, integer level, real duration, unit target returns boolean
        local Expire e
        local boolean b = false
        
        if target != null and buffid != 0 and level != 0 then
            set e = Expire.create(buffid, level, duration, target)
            set b = true
        endif
        
        return b
    endfunction

endlibrary

Using this:

• Test Buff
  • Events
    • Player - Player 1 (Red) types a chat message containing buff as An exact match
  • Conditions
  • Actions
    • Custom script: call AddExpiringBuff('B000', 1, 5, gg_unit_Hpal_0002)
    • Custom script: call BJDebugMsg(I2S(GetUnitAbilityLevel(gg_unit_Hpal_0002, 'B000')))

And the debug msg is showing 0

Why ?!

 

[Azlier]

You can remove buffs just fine, but you cannot add them without a dummy and a spell. Systems like ABuff abuse the Tornado (Slow Aura) ability to just "apply" buffs magically.

 

[Komaqtion]

How is it used then ? :S

(Btw, is it even of any use that I make this snippet/system ? Since there's already 1 out there (At least :S))

 

[Flare]

            local Expire e = Expire.allocate()
            
            call PauseTimer(GetExpiredTimer())
            call DestroyTimer(GetExpiredTimer())
            call UnitRemoveAbility(e.target, e.buffid)

That's not going to work - instead of acquiring the struct instance created in the create method, you are creating a new one (which won't have the data you need, or any data at all, depending on previous struct instance allocations for the Expire struct)

You're going to need to attach the data to the timer, and retrieve it in the callback. There's the option of using TimerUtils (which will add timer recycling functionality too) or DIY

DIY approach:

library ExpireBuff

globals
//Relatively straight-forward way of attaching - chuck the data into a hashtable, using the timer as the primary identifier
  private hashtable HT = InitHashtable ()
endglobals

    struct Expire
        
        integer buffid
        unit target
        unit source
        real damage
        
        private static method remove takes nothing returns nothing
            local timer t = GetExpiredTimer ()
            local integer id = GetHandleId (t)
//now we load the data attached to the timer - each instance will have its own unique timer, so there should never be a situation where data will overlap
            local Expire e = LoadInteger (HT, id, 0)
            
            call PauseTimer(t)
            call DestroyTimer(t)
            call UnitRemoveAbility(e.target, e.buffid)
//and, finally, cleaunup - we no longer need the data for this instance, so we can safely flush it from the hashtable
            call FlushChildHashtable (HT, id)
        endmethod
    
        static method create takes integer buffid, integer level, real duration, unit target returns Expire
            local Expire e = Expire.allocate()
            local timer t = CreateTimer()
            call SaveInteger (HT, GetHandleId (t), 0, e)
//There's no real point to having a second unique identifier (since the timer's ID should be unique to each instance)
//As such, the second identifier can be 0 (or whatever you want) as long as the same number is used for Save and Load calls
            set e.buffid = buffid
            set e.target = target
            
            call UnitAddAbility(e.target, e.buffid)
            call SetUnitAbilityLevel(e.target, e.buffid, level)
            call TimerStart(t, duration, false, function Expire.remove)
            
            return e
        endmethod
        
    endstruct
    
    function AddExpiringBuff takes integer buffid, integer level, real duration, unit target returns boolean
        local Expire e
        local boolean b = false
        
        if target != null and buffid != 0 and level != 0 then
            set e = Expire.create(buffid, level, duration, target)
            set b = true
        endif
        
        return b
    endfunction

endlibrary

 

[Komaqtion]

Yeah XD Silly me ...
But what is best, hastables or timer attachment ?

And still:

You can remove buffs just fine, but you cannot add them without a dummy and a spell. Systems like ABuff abuse the Tornado (Slow Aura) ability to just "apply" buffs magically.

How is it used then ? :S

 

[Flare]

But what is best, hastables or timer attachment ?

The hashtable usage in my example is timer attachment :

To answer the question (assuming you're asking which is better between hashtables and TimerUtils), it's not a big thing to be honest. To my knowledge, the latest version of TimerUtils Blue uses hashtables. In the end, it's purely a personal preference thing (although the timer recycling from TimerUtils is very handy).

 

[Komaqtion]

Ok, changed that now then So uses TU

But, my other question ?

 

[kingkingyyk3]

Eh, not using KT2? :O

 

[RaiJin]

Eh, not using KT2? :O

eh not using T32? i think T32 for this would be best

 

[Komaqtion]

Ok, which one do I use then... T32 or KT2 ? :S

And, again to my other question:
How do I add a custom buff to a unit ?

 

[Komaqtion]

Bump ?!

 

[kingkingyyk3]

Kt2 is better choice. T32 fires too frequently, in this situation imo.