Hero Revival System

06-23-2009, 11:59 PM

Quote:

If you know/think that your spell/system is not of the best quality, but you are new and would like feedback, you should post it as a thread in the Triggers & Scripts forum instead.

Yeah, I feel the quality of this is lacking, and I'm unable to find any necessary improvements myself.

Hero Revival System:

library HeroRevival requires TimerUtils

private function Callback takes nothing returns nothing
    local timer t = GetExpiredTimer()
    local HeroRevival d = GetTimerData(t)
    call ReviveHero(d.hero, d.x, d.y, d.eye_candy)
    if GetLocalPlayer() == GetOwningPlayer(d.hero) then
        call ClearSelection()
        call SelectUnit(d.hero, true)
    endif
    if d.pan_camera then
        if GetLocalPlayer() == GetOwningPlayer(d.hero) then
            call PanCameraToTimed(d.x, d.y, 0)
        endif
    endif
    call SetUnitState(d.hero, UNIT_STATE_LIFE, GetUnitState(d.hero, UNIT_STATE_MAX_LIFE) * d.life)
    call SetUnitState(d.hero, UNIT_STATE_MANA, GetUnitState(d.hero, UNIT_STATE_MAX_MANA) * d.mana)
    call ReleaseTimer(t)
    call d.onRevive()
    call d.destroy()
endfunction

private interface onEvents
    method onRevive takes nothing returns nothing defaults nothing
endinterface

struct HeroRevival extends onEvents

    unit hero
    boolean pan_camera
    boolean eye_candy
    real x
    real y
    real life = 1
    real mana = 1
    //*************************
    timerdialog td
    
    static method create takes unit Hero, boolean ShowWindow, boolean PanCamera, boolean doEyecandy, real x, real y, real time, real newlife, real newmana, string title returns HeroRevival
        local timer t = NewTimer()
        local HeroRevival d = HeroRevival.allocate()
        set d.hero = Hero
        set d.x = x
        set d.y = y
        set d.eye_candy = doEyecandy
        set d.life = newlife
        set d.mana = newmana
        call TimerStart(t, time, false, function Callback)
        if ShowWindow then
            set d.td = CreateTimerDialog(t)
            call TimerDialogSetTitle(d.td, title)
            if GetLocalPlayer() == GetOwningPlayer(d.hero) then
                call TimerDialogDisplay(d.td, true)
            endif
        endif
        call SetTimerData(t, d)
        return d
    endmethod
    
    static method createEx takes unit hero, real x, real y, real time, string title returns HeroRevival
        return HeroRevival.create(hero, false, false, false, x, y, time, 1, 1, title)
    endmethod
    
    method onDestroy takes nothing returns nothing
        call DestroyTimerDialog(.td)
    endmethod
    
endstruct

endlibrary

Sample of Usage:

scope Sample initializer Init

private function Conditions takes nothing returns boolean
    return IsUnitType(GetTriggerUnit(), UNIT_TYPE_HERO) == true
endfunction

struct Data extends HeroRevival
    method onRevive takes nothing returns nothing
        local player p = GetOwningPlayer(.hero)
        call BJDebugMsg(GetPlayerName(GetOwningPlayer(.hero)) + " has been revived.")
        call SetPlayerState(GetOwningPlayer(.hero), PLAYER_STATE_RESOURCE_GOLD, GetPlayerState(p, PLAYER_STATE_RESOURCE_GOLD) - 100)
    endmethod
endstruct

private function Actions takes nothing returns nothing
    local unit u = GetTriggerUnit()
    local Data d = Data.createEx(u, GetUnitX(u), GetUnitY(u), GetHeroLevel(u) * 5, "Your hero will revive in:")
endfunction

private function Init takes nothing returns nothing
    local trigger t = CreateTrigger()
    call TriggerRegisterAnyUnitEventBJ(t, EVENT_PLAYER_UNIT_DEATH)
    call TriggerAddCondition(t, Condition( function Conditions))
    call TriggerAddAction(t, function Actions)
endfunction

endscope

06-24-2009, 09:51 AM	#2
Silvenon	It looks flawless to me. Even if you can improve the efficiency of this, I don't think it will matter much because the code is pretty simple.

06-24-2009, 10:04 AM	#3
0zyx0	Use a global timer variable to prevent leaks.

06-24-2009, 01:30 PM	#4
busterkomo	That would require a periodic timer, which is just plain awful for something like this. Edit: Added a few features to the system. The new features made it ideal to switch from a constant location to coordinates.

06-24-2009, 05:54 PM	#5
0zyx0	No, that would not require a periodic timer. I didn't say a global timer, I said a global timer variable.

06-24-2009, 06:12 PM	#6
busterkomo	I'm afraid I don't follow.

06-24-2009, 06:34 PM	#7
0zyx0	Declare a global timer variable, call it tempTimer, or something. Instead of using local timer variables, use that variable: set tempTimer = NewTimer(), call ReleaseTimer(tempTimer)

06-24-2009, 07:41 PM	#8
Viikuna-	Why cant he use local timer variable? o_O It wont leak or anything, since those timers are recycled anyways.

06-25-2009, 06:06 AM

Blubb-Tec

yes, that system looks cool to me. If you want to release the system, I myself would make a function interface like function interface HeroRevives takes unit reviving returns nothing and the user can then write his own function, and set the life and mana all himself. that way, alle the NEW_LIFE and NEW_MANA functions don't need to be in the code no longer, and the user can handle all that stuff for himself("all that stuff" means reviving the hero himself, aswell as setting mana, hp, etc.)
You may then well write a "standard interface", which sets it to predefined values etc, which is used if the user doesn't want to do that stuff himself.

oh yeah, you should also take a look into Vexorian's ARGB script(to replace your Getplayernamecolored stuff)

06-25-2009, 06:58 AM	#10
wraithseeker	It looks similar to my hero revival system that was submitted a while ago except mine has more stuffs.

06-25-2009, 11:00 AM

#11

0zyx0

Quote:

Originally Posted by Viikuna-

Why cant he use local timer variable?

I didn't say he couldn't, I just told him to not do it. If somebody uses a stupid TimerUtils version, there could be leaks. It is really easy to prevent that.

06-28-2009, 10:48 PM	#12
busterkomo	Alright guys, a new version is up. I've completely remade the system to be more of a system (not a sample).

06-29-2009, 12:13 AM

#13

Anitarf

Quote:

Originally Posted by 0zyx0

I didn't say he couldn't, I just told him to not do it. If somebody uses a stupid TimerUtils version, there could be leaks. It is really easy to prevent that.

What "stupid TimerUtils version"? What are you talking about? Using a local variable is perfectly fine.

06-29-2009, 10:29 AM

#14

Blubb-Tec

Quote:

Originally Posted by busterkomo

Alright guys, a new version is up. I've completely remade the system to be more of a system (not a sample).

looks okay, i guess, although setting up all the members of the struct seems annoying... you should probably do that by default, so the user just has to make adjustments if he needs something that differs from the standard... apart from that, I don't like the idea of having to create a struct for a dying hero. atleast not if the user himself has to do it. he should simply call a function, give a function pointer as a callback function(equaling your onRevive method).
Then your start method takes a parameter d, which is completely useless, because d == this.

06-29-2009, 03:20 PM

#15

0zyx0

Quote:

Originally Posted by Anitarf

What "stupid TimerUtils version"?

If someone don't want to use TimerUtils, and creates a TimerUtils version which destroys timers instead of recycling, or something like that, it would be a stupid TimerUtils version.

However, when I think about it, there is no need to add any support to those stupid scripts. In fact, I do now find doing so to be something bad, so I have changed my mind about what I posted earlier.