Approved| Values | Explanation |
| ODHS_Event EQUALS TO 1.00 | Runs 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.00 | Runs 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.50 | Runs when a unit is picked for heal and validated Useful for pre-heal with the ability for validation |
| ODHS_Event EQUALS TO 3.00 | Runs when a unit has been healed Useful for after-heal |
| ODHS_Event EQUALS TO 3.50 | Runs when a unit is not eligible for heal Useful for handling non-eligible units |
| ODHS_Event EQUALS TO 4.00 | Runs 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.00 | Runs 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. |
| Variable | Default Value in the Eligible Events [Type] | Description |
| ODHS_EffectAttachPoint | origin [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_DeadPoint | Point 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_KillingUnit | Killing Unit [Unit] | Self-explanatory. Avoid modifying its value unless you know what you are doing. |
| ODHS_DeadUnit | Killed Unit [Unit] | Self-explanatory. Avoid modifying its value unless you know what you are doing. |
| ODHS_HealingUnit | Healing 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_Group | Healed Unit Group [Unit Group] | This refers to the group of possible healed units PRIOR to filters. You need to manually filter this group. |
| ODHS_UnitTypeLoop | Registration Index of Killed Unit [Integer] | Very advanced usage. With this, you can access the ODHS_RegisteredXXX values properly in ODHS events. |
| ODHS_RegisteredUnitTypes | An 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_RegisteredHealAmount | An 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_RegisteredFilterTrigger | An 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_RegisteredHealSFX | An 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_RegisteredRange | An 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. |
Unit - Kill Unit
Not a heal but it's possible too with some creativity.
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)
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)
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.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_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
