• 🏆 Texturing Contest #33 is OPEN! Contestants must re-texture a SD unit model found in-game (Warcraft 3 Classic), recreating the unit into a peaceful NPC version. 🔗Click here to enter!
  • It's time for the first HD Modeling Contest of 2024. Join the theme discussion for Hive's HD Modeling Contest #6! Click here to post your idea!

On Death Heal System v1.0.1

On Death Heal System
IMPORT GUIDE :
  1. Make sure you are using the 1.32 version of Warcraft III (For 1.31 users, you can use compatibility offered by Map Adapter)
  2. Download ODHS from this thread.
  3. Copy the OnDeathHealSystem folder to your map.
  4. Fix the ODHS Config trigger.
  5. The system is ready for use, refer to Testmap folder in the test map to understand how to register units to this system.
SYSTEM INFORMATION :
On Death Heal System (ODHS in short) is a system designed based on Mental Omega's Mantis (Scrap) Tank's ability. The ability in question is to heal nearby allied Mantis Tank when killed. This behavior is what this system aims to replicate.

By using ODHS_Event, users can extend this system to further their need should what this system internally support is insufficient for their personal needs. The system also provides data that can be used to manipulate the system further for users.

ValuesExplanation
ODHS_Event EQUALS TO 1.00Runs when a unit dies and is a unit-type in the system

Useful if you need to make dummy units or something closely tied to the dead unit itself, but not the healed unit (the unit group itself is accessible here though)
ODHS_Event EQUALS TO 2.00Runs when a unit is picked for heal but is yet to be validated

Useful for pre-heal regardless of validity
ODHS_Event EQUALS TO 2.50Runs when a unit is picked for heal and validated

Useful for pre-heal with the ability for validation
ODHS_Event EQUALS TO 3.00Runs when a unit has been healed

Useful for after-heal
ODHS_Event EQUALS TO 3.50Runs when a unit is not eligible for heal

Useful for handling non-eligible units
ODHS_Event EQUALS TO 4.00Runs when a unit type has been registered to the system

Useful if you want to extend this system with your own registration
ODHS_Event EQUALS TO 5.00Runs when the system has been initialized

Useful for Unit Register. Due to something related to Warcraft III internal workings, at least in 1.32, it is recommended to have one registration trigger that specifically uses this event as the reference point. For multiple triggers, only have one trigger use this event and then let that trigger call the other triggers. Refer to Example Codes in the test map.
AVOID THE MAP INITIALIZATION EVENT WHEN REGISTERING UNITS TO THIS SYSTEM!

Useful variable list (only available in 1.00 to 3.50 events unless stated otherwise):

VariableDefault Value in the Eligible Events [Type]Description
ODHS_EffectAttachPointorigin [String]Global variable defining all SFX attachment points. If you need to alter this for a specific SFX, use 2.50 Event then alter it then reset it at 3.00 Event back to origin.

Available in all events.
ODHS_DeadPointPoint of ODHS_DeadUnit [Location]Refers to the point of the killed unit. Unused by the system when the events already commence, so this is mostly for accessibility.
ODHS_KillingUnitKilling Unit [Unit]Self-explanatory. Avoid modifying its value unless you know what you are doing.
ODHS_DeadUnitKilled Unit [Unit]Self-explanatory. Avoid modifying its value unless you know what you are doing.
ODHS_HealingUnitHealing Unit [Unit]This refers to the current unit that is healing. Avoid modification of its value unless you know what you are doing.

Only available in 2.00 onward states.
ODHS_GroupHealed Unit Group [Unit Group]This refers to the group of possible healed units PRIOR to filters. You need to manually filter this group.
ODHS_UnitTypeLoopRegistration Index of Killed Unit [Integer]Very advanced usage. With this, you can access the ODHS_RegisteredXXX values properly in ODHS events.
ODHS_RegisteredUnitTypesAn array of Registered Unit Types [Array Unit Type]Very advanced usage. Access any registered unit types within the system by their registration index. Use UnitTypeLoop to detect the index. Do not modify their value unless you know what you are doing.
ODHS_RegisteredHealAmountAn array of Registered Heal Amount [Array Real]Very advanced usage. Access any registered heal amount within the system by their registration index. Use UnitTypeLoop to detect the index. Do not modify their value unless you know what you are doing.

One of the more useful advanced use is it allows users to acquire how much healing ODHS affects for current HealingUnit prior to event 3.00 or 3.50. This allows for flexibility for example accounting for special buffs and such. Make sure to reset the value after change in the 3.00 or 3.50 event.
ODHS_RegisteredFilterTriggerAn array of Registered Filter Trigger [Array Trigger]Very advanced usage. Access any registered filters within the system by their registration index. Use UnitTypeLoop to detect the index. Do not modify their value unless you know what you are doing.
ODHS_RegisteredHealSFXAn array of Registered Heal SFX [Array String]Very advanced usage. Access any registered heal special effect within the system by their registration index. Use UnitTypeLoop to detect the index. Do not modify their value unless you know what you are doing.
ODHS_RegisteredRangeAn array of Registered Grouping Range [Array Real]Very advanced usage. Access any registered range within the system by their registration index. Use UnitTypeLoop to detect the index. Do not modify their value unless you know what you are doing.

One of the more useful advanced use as it allows users to acquire the range ODHS affects for current KilledUnit.
!NEVER USE WAITS OR TIMER WITH ODHS. IF YOU NEED THOSE, PRESERVE THEIR DATA TO YOUR OWN VARIABLES!
!DO NOT USE
  • Unit - Kill Unit
INSIDE ODHS EVENTS UNLESS YOU KNOW HOW TO HANDLE RECURSIONS!

MEDIA SHOWCASE :
CHANGELOG :
Version 1.0.1: HealedUnit changed into HealingUnit. Added notes regarding dangers of recursion. Minor fix to Rifleman example. Changed filename.
Version 1.0: Released
CREDIT :
Mentalmeister - Source Idea
ProxyCakey
Contents

On Death Heal System (Map)

Reviews
Wrda
I feel ODHS_HealedUnit is a bit misleading because the heal doesn't actually have to happen. Perhaps ODHS_HealingUnit would be better. What I'm most concerned about is the current method to find the registered unit type on ODHS Effect trigger. Looping...
Level 22
Joined
Nov 4, 2010
Messages
6,232
Amazing! :O

I like how you expand the Mantis Tank sheningan and even include AoE Revival on Death too, never thought of that.

Would like to use that but too bad I don't have Reforged yet. Maybe I can convert it for pre-Reforged patches too

How about AoE Divine Shield on death too (similar to Judas Artillery in TC14 and Iron Dragon in MO2/MO3)?
 
How about AoE Divine Shield on death too (similar to Judas Artillery in TC14 and Iron Dragon in MO2/MO3)?
Not a heal but it's possible too with some creativity.

By using the 3.00 event (so we pretend the targeted divine shield units are an eligible healed unit with 0 heal value), we can then give the invulnerability to the unit (may it be via buff, invulnerable by armor, or other means). A challenge is a limited duration since the variable reference is lost once the whole healing sequence is done so we need to have something to keep referring to the units to strip their bonus once the duration is over (and expanding the whole system that direction seems overkill for me at the moment, but I can change my mind down the line).

I can wrap a quick sample if that helps too.

EDIT:

  • ODHS Siege Engine Data
    • Events
      • Game - ODHS_Event becomes Equal to 5.00
    • Conditions
    • Actions
      • -------- ------------------------------------------------------------------------------------------------------------------------------ --------
      • -------- TEMPORARY INVULNERABILITY FOR SAME UNIT TYPE --------
      • -------- ------------------------------------------------------------------------------------------------------------------------------ --------
      • -------- Unit Type to register --------
      • Set VariableSet ODHS_UnitType = Siege Engine
      • -------- How much healed for each unit? --------
      • Set VariableSet ODHS_HealAmount = 0.00
      • -------- How much healed for each unit? --------
      • Set VariableSet ODHS_HealSFX = Abilities\Spells\Human\Resurrect\ResurrectTarget.mdl
      • -------- Distance from killed unit? --------
      • Set VariableSet ODHS_Range = 1000.00
      • -------- Personal Filter --------
      • Set VariableSet ODHS_FilterTrigger = ODHS_DefaultFilterTrigger
      • -------- Register to system --------
      • Trigger - Run ODHS_RegisterTrigger (checking conditions)
  • ODHS Siege Engine Shield
    • Events
      • Game - ODHS_Event becomes Equal to 3.00
    • Conditions
      • (Unit-type of ODHS_DeadUnit) Equal to Siege Engine
    • Actions
      • Unit - Make ODHS_HealedUnit Invulnerable
      • Unit Group - Add ODHS_HealedUnit to SiegeEngineGroup
      • If (All Conditions are True) then do (Then Actions) else do (Else Actions)
        • If - Conditions
          • (Number of units in SiegeEngineGroup) Equal to 1
        • Then - Actions
          • Trigger - Turn on ODHS Siege Engine Shield Up <gen>
        • Else - Actions
      • Countdown Timer - Start ShieldTimer as a One-shot timer that will expire in 5.00 seconds
  • ODHS Siege Engine Shield Up (Initially Off)
    • Events
      • Time - ShieldTimer expires
    • Conditions
    • Actions
      • Unit Group - Pick every unit in SiegeEngineGroup and do (Actions)
        • Loop - Actions
          • Unit - Make (Picked unit) Vulnerable
          • Unit Group - Remove (Picked unit) from SiegeEngineGroup.
      • Trigger - Turn off (This trigger)
Not MUI/MPI in a proper sense, but should help to give the gist of logic out. Speaking of logic, I think a timer feature would be a helpful addition if I can get the motivation for it.
 
Last edited:

Wrda

Spell Reviewer
Level 25
Joined
Nov 18, 2012
Messages
1,864
I feel ODHS_HealedUnit is a bit misleading because the heal doesn't actually have to happen. Perhaps ODHS_HealingUnit would be better.
What I'm most concerned about is the current method to find the registered unit type on ODHS Effect trigger. Looping through the array while it is short won't be a problem, but when there's a lot of them, let's say, 100, then it might become a hinderance. A hashtable is better for this purpose.
There's possible recursion that leads to overwritten variables in scenarios like this:
  • ODHS Riflemen Revive
    • Events
      • Game - ODHS_Event becomes Equal to 3.00
    • Conditions
      • (Unit-type of ODHS_DeadUnit) Equal to Rifleman
    • Actions
      • Set VariableSet TempLoc = (Position of ODHS_HealedUnit)
      • Unit - Create 1 Footman for Player 1 (Red) at (Center of (Playable map area)) facing Default building facing degrees
      • Unit - Kill (Last created unit)
      • Unit - Create 1 (Unit-type of ODHS_HealedUnit) for (Owner of ODHS_HealedUnit) at TempLoc facing Default building facing degrees
      • Unit - Remove ODHS_HealedUnit from the game
      • Custom script: call RemoveLocation(udg_TempLoc)
ODHS_HealedUnit will be always a footman, unless, of course, the kill or any form of death from damage happens after all the actions that.
Dealing and solving recursion looks very troublesome and nasty, as the user has access to the system variables, and could create his own, and at same time using filters. I think giving a warning on how NOT to do recursion unless they know what they're doing should do it.

Aside from that, it's a pretty nice system, seems like it could also fit for some dark spells regarding necromancy or sacrifices.

Approved
 
I feel ODHS_HealedUnit is a bit misleading because the heal doesn't actually have to happen. Perhaps ODHS_HealingUnit would be better.
What I'm most concerned about is the current method to find the registered unit type on ODHS Effect trigger. Looping through the array while it is short won't be a problem, but when there's a lot of them, let's say, 100, then it might become a hinderance. A hashtable is better for this purpose.
There's possible recursion that leads to overwritten variables in scenarios like this:
  • ODHS Riflemen Revive
    • Events
      • Game - ODHS_Event becomes Equal to 3.00
    • Conditions
      • (Unit-type of ODHS_DeadUnit) Equal to Rifleman
    • Actions
      • Set VariableSet TempLoc = (Position of ODHS_HealedUnit)
      • Unit - Create 1 Footman for Player 1 (Red) at (Center of (Playable map area)) facing Default building facing degrees
      • Unit - Kill (Last created unit)
      • Unit - Create 1 (Unit-type of ODHS_HealedUnit) for (Owner of ODHS_HealedUnit) at TempLoc facing Default building facing degrees
      • Unit - Remove ODHS_HealedUnit from the game
      • Custom script: call RemoveLocation(udg_TempLoc)
ODHS_HealedUnit will be always a footman, unless, of course, the kill or any form of death from damage happens after all the actions that.
Dealing and solving recursion looks very troublesome and nasty, as the user has access to the system variables, and could create his own, and at same time using filters. I think giving a warning on how NOT to do recursion unless they know what they're doing should do it.

Aside from that, it's a pretty nice system, seems like it could also fit for some dark spells regarding necromancy or sacrifices.

Approved
Really overlooked the whole shenanigans of recursion. I think I'll check what other unwanted side effects then list additional notes. Most of the variables are actually mostly act as getters, but I just make note in description for them since maybe someone has something smart and doesn't know inherent dangers in some of the variables.

As for the naming, I think Healing works better as you suggested. Hopefully I can patch this up soon.

About the whole hashtable stuff, I want to avoid Hashtables like plague due to their 256 inherent limit. Larger systems should take precedence than this side system of mine.
 
Tested recursion and confirmed that the variables get overwritten when another kill event is triggered mid-way. Another underlying danger that I found is that if the other killed unit has certain specifics that can trigger additional effect (as in an effect chain) which can complicate things further, it is wise to be very mindful with it.

I'll release an update now.
 
Top