[JASS] Get Leaderboard Item Value?

[Teelo]

Leaderboard item level; hero revive; group enum conditions...

Hmmm, is there really no function to get the item value on a leaderboard?

Next question: Does EVENT_PLAYER_HERO_REVIVE_FINISH include initially training a hero?

Question 3: GroupEnumUnitsOfPlayer(g, Player(playerIndex), Condition(function filter)) will that leak? In blizzards code they destroy the boolexpr part with DestroyBoolexpr(filter).

 

[Berb]

Hmmm, is there really no function to get the item value on a leaderboard?

No, there is no native that does that for you. These are the only two natives that are associated with the item value of a leaderboard.

native LeaderboardSetItemValue takes leaderboard lb, integer whichItem, integer val returns nothing
native LeaderboardAddItem takes leaderboard lb, string label, integer value, player p returns nothing

Next question: Does EVENT_PLAYER_HERO_REVIVE_FINISH include initially training a hero?

I'm quite certain that it does not. The event the corresponds to a hero finishing training is the same that corresponds to a unit finishing training.

Question 3: GroupEnumUnitsOfPlayer(g, Player(playerIndex), Condition(function filter)) will that leak? In blizzards code they destroy the boolexpr part with DestroyBoolexpr(filter) .

The type boolexpr does not leak. They have a static implementation, similar to players. In fact, I think that destroying boolean expressions can lead to problems in certain circumstances.

function GetUnitsInRectMatching takes rect r, boolexpr filter returns group
    local group g = CreateGroup()
    call GroupEnumUnitsInRect(g, r, filter)
    call DestroyBoolExpr(filter)
    return g
endfunction

Is this the code you're talking about? If you're always referencing boolean expressions as Filter(function someFunc) or Condition(function someFunc) then it doesn't matter, since you're always going to be passing a proper reference to the expression, however when you have boolean expression variables (for performance) and you destroy them it can be a lot more tedious. I think that in blizzard-generated code they always use Condition( ) on boolean expressions.

function ForYouToLearn takes nothing returns nothing
    local integer id
    local boolexpr b0 = Filter(function someFuncFromBefore)
    local boolexpr b1 = Filter(function someFuncFromBefore)

    set id = GetHandleId(b0)
    call BJDebugMsg(I2S(id))

    set id  = GetHandleId(b1)
    call BJDebugMsg(I2S(id))
endfunction

Both values that are printed should be identical in this function, both b0 and b1 point to the same handle.

 

[Teelo]

So how about timers, do they leak?
If I call this: call TimerStart(CreateTimer(), 10, false, function SDIntroSpam_display), is the CreateTimer() going to leak if I don't destroy the timer in the callback function?

 

[Berb]

Yes, or at least elsewhere in the code. It doesn't have to be in the timer callback function.

 

[Teelo]

function doFirstMenu takes nothing returns nothing
    call DestroyTimer(GetExpiredTimer())
//...
endfunction

private function init takes nothing returns nothing
    call TimerStart(CreateTimer(), 1, false, function doFirstMenu)
endfunction

Is that safe to use?
Is there a better way to write that?

 

[Dr Super Good]

Destroying timers leaks far less than not destroying them and personally I have had no problems doing so. However you still might wish to consider timer recycling systems. These systems are garunteed not to leak and will also lead the handle allocation / deallocation system much less as it turns timers from a dynamically created object into pretty much a stack of references to static objects.

I am pretty much of mixed opinions about timer creation and destruction or recycling but I came to these conclusions.
1. Destroying a timer will always be better than letting one leak, however there is a slight chance a little bit leaks and also if the timer was set to perodic you will have to pause it or have its called code be robust enough to handle a null timer running it once more.
2. Recycling timers is best used when you have a lot of timer use in your map and need to allocate or deallocate them regually as this prevents stress on the handle index system and also might be faster.
3. Systems which only ever use 1 timer (eithor running or not) should use a constant global timer. Especially if the system is always in use it will be pointless having functionality linked to it for dealing with deallocating or recycling the timer.