They finally fixed "Item Attack Lightning Bonus (new)"

[Wing-Span]

Blizzard has fixed this bug — now abilities trigger correctly even when a unit automatically attacks an enemy that appears nearby.


So, now that this is actually usable, I have a question: is there any theoretical way to detect the attacking unit?


I know about the global “Unit is Attacked” trigger.
The problem is, it doesn’t tell you when the projectile actually hits the target — and what I need is to detect the exact moment when the ability procs.


The global “Unit Takes Damage” event causes massive lag if there are 1000 units on the map.


The ideal solution would be something like a “Unit finishes casting an ability” global event, but the “Item Attack Lightning Bonus (new)” ability never fires that event.


So, as I understand it, there’s no standard legal way to detect this.
Please tell me — is there any clever ability that, once triggered on a unit, will fire any kind of global event (other than “unit takes damage” or “unit about to take damage”)?
Any workaround would do!

 

[Uncle]

Well first I would check to see if using 1000 of these Abilities causes a "massive lag" as well. It'd be surprising if this ability does something different "under the hood" than a standard Damage event. In other words, why would they give us modders an inefficient "damage event" while keeping an efficient version to themselves? That being said, who knows what kind of jank is going on under the hood especially when it comes to this game.

Second I would confirm that your Damage Event triggers aren't causing performance issues due to inefficient Conditions/Actions. We talked about this before so I assume you've already tried those fixes without any luck.

Third, just to be clear, "Finishes casting" is a pretty unreliable event that can be skipped. "Starts the effect" is always the ideal option.

Anyway, to answer your question. Any ability that Summons come to mind using the "A unit Spawns a summoned unit" Event, but they lack a (Target unit of ability being cast) which would work as your (Damage target). If you don't need the target then those should work fine, just spawn in a unique Dummy unit and detect that. Each Dummy can represent a different ability.

Edit: Using the Item Illusion ability with modified Targets Allowed works:

• Example
  • Events
    • Unit - A unit Spawns a summoned unit
  • Conditions
    • ((Summoned unit) is an illusion) Equal to True
  • Actions
    • Game - Display to (All players) for 30.00 seconds the text: (Name of (Summoning unit))
    • Unit - Remove (Summoned unit) from the game

Assuming you don't use this ability elsewhere the trigger is pretty clean. Mind you there's overhead in creating units.

 

[Wing-Span]

Well first I would check to see if using 1000 of these Abilities causes a "massive lag" as well. It'd be surprising if this ability does something different "under the hood" than a standard Damage event. In other words, why would they give us modders an inefficient "damage event" while keeping an efficient version to themselves? That being said, who knows what kind of jank is going on under the hood especially when it comes to this game.

Second I would confirm that your Damage Event triggers aren't causing performance issues due to inefficient Conditions/Actions. We talked about this before so I assume you've already tried those fixes without any luck.

Third, just to be clear, "Finishes casting" is a pretty unreliable event that can be skipped. "Starts the effect" is always the ideal option.

Anyway, to answer your question. Any ability that Summons come to mind using the "A unit Spawns a summoned unit" Event, but they lack a (Target unit of ability being cast) which would work as your (Damage target). If you don't need the target then those should work fine, just spawn in a unique Dummy unit and detect that. Each Dummy can represent a different ability.

Edit: Using the Item Illusion ability with modified Targets Allowed works:

• Example
  • Events
    • Unit - A unit Spawns a summoned unit
  • Conditions
    • ((Summoned unit) is an illusion) Equal to True
  • Actions
    • Game - Display to (All players) for 30.00 seconds the text: (Name of (Summoning unit))
    • Unit - Remove (Summoned unit) from the game

Assuming you don't use this ability elsewhere the trigger is pretty clean. Mind you there's overhead in creating units.

This item only works with targeted abilities, so things like Stomp or Blademaster’s Mirror Image won’t trigger it.
However, your example with illusions fits perfectly for the Wand of Illusions. I’ll try to implement that — thanks!


As for the lag — no, it’s minimal. It’s just that before, we had to create a dummy caster, but now we can do without it, which is much better for performance.

As for the damage event trigger — even if it’s completely empty, the map still loses around 5 FPS by the late game, since 500 splash towers and 500 units inevitably trigger this event about a thousand times per second.


In any case, thanks for trying to optimize it.

 

[Uncle]

Alternative idea, if your Towers don't need or use mana, you could have them always sit at 0/1 mana, then use something like the Mana Steal or Absorb Mana ability to steal some mana from the enemy unit and detect the change like so:

• Untitled Trigger 004
  • Events
    • Unit - Tower 0005 <gen>'s mana becomes Equal to 1.00
  • Conditions
  • Actions
    • Game - Display to (All players) for 30.00 seconds the text: trigger your ability
    • Unit - Set mana of Tower 0005 <gen> to 0.00

This would require a system for registering units to the Event, but that's not difficult to setup. No idea if this is more efficient but I'd assume that there's much less overhead with simple mana manipulation than creating/removing a unit. It might also help avoid the weirdness that comes with creating a unit (collision, pathing, displacement, etc).

You may even be able to register the enemy units in a separate trigger, tracking which enemy unit lost mana recently. Then you could reference it in the above trigger. That would give you both the (Casting unit) and (Target unit of ability being cast) assuming that mana loss occurs before mana gain.

Note that dead units become memory leaks in these types of "registered unit" triggers (afaik). That might not matter at all though since memory is abundant these days and the leaks are relatively small. I've seen people in the past use multiple triggers, each with a limited set of allowed registrations, and manage them in a way where a trigger whose registered units are all dead gets destroyed and cleaned up. That could be useful when tracking waves of enemy units that die all of the time. But it could also cause more performance problems than solve, tough to say.

 

[Wing-Span]

Alternative idea, if your Towers don't need or use mana, you could have them always sit at 0/1 mana, then use something like the Mana Steal or Absorb Mana ability to steal some mana from the enemy unit and detect the change like so:

• Untitled Trigger 004
  • Events
    • Unit - Tower 0005 <gen>'s mana becomes Equal to 1.00
  • Conditions
  • Actions
    • Game - Display to (All players) for 30.00 seconds the text: trigger your ability
    • Unit - Set mana of Tower 0005 <gen> to 0.00

This would require a system for registering units to the Event, but that's not difficult to setup. No idea if this is more efficient but I'd assume that there's much less overhead with simple mana manipulation than creating/removing a unit. It might also help avoid the weirdness that comes with creating a unit (collision, pathing, displacement, etc).

You may even be able to register the enemy units in a separate trigger, tracking which enemy unit lost mana recently. Then you could reference it in the above trigger. That would give you both the (Casting unit) and (Target unit of ability being cast) assuming that mana loss occurs before mana gain.

Note that dead units become memory leaks in these types of "registered unit" triggers (afaik). That might not matter at all though since memory is abundant these days and the leaks are relatively small. I've seen people in the past use multiple triggers, each with a limited set of allowed registrations, and manage them in a way where a trigger whose registered units are all dead gets destroyed and cleaned up. That could be useful when tracking waves of enemy units that die all of the time. But it could also cause more performance problems than solve, tough to say.

Great idea. It can be used to track both the attacker and the one being attacked. What's the best Unit Registration System?

 

[Uncle]

There isn't really a "best Unit Registration System" since it all depends on how your map works. But I attached a map with a working example that was designed with a Tower Defense in mind. Note that I didn't bother to clean up memory leaks related to dead registered units.

The fix to that potential issue:
Assuming enemy units come in controlled waves that are guaranteed to die, you could optimize their registration by creating and using a new trigger at the start of each wave.

So for example:
Wave 1 starts, Create a new "enemy loses mana" trigger, then Register wave units to this trigger as they come into play.
Wave 2 starts, Destroy the last "enemy lose smana" trigger, Create a new trigger, and Register wave units to this trigger as they come into play.
Wave 3 starts, Destroy the last "enemy loses mana" trigger, Create a new trigger, and Register wave units to this trigger as they come into play.

This pattern continues on for the rest of the game.

But this is under the assumption that whenever a new wave starts, ALL of the units from the old wave are already dead. If that's not the case then you could still use this pattern but you'll need to destroy the old trigger at a more ideal time. For example, every 3rd wave you could destroy the trigger that was created two waves ago, ensuring that you only ever have 2 triggers in existence at a time. Or better yet, if you already track when wave units die you could handle the logic once a wave's unit count reaches 0.

The triggers themselves would be stored in a Trigger array so that you can easily reference them by [index]:

• Custom script: call DestroyTrigger(TriggerArray[CurrentWave - 1])

I don't think GUI allows you to create triggers (easily) so you might have to set this up in Jass. ChatGPT could do that for you.

 

[Wing-Span]

There isn't really a "best Unit Registration System" since it all depends on how your map works. But I attached a map with a working example that was designed with a Tower Defense in mind. Note that I didn't bother to clean up memory leaks related to dead registered units.

The fix to that potential issue:
Assuming enemy units come in controlled waves that are guaranteed to die, you could optimize their registration by creating and using a new trigger at the start of each wave.

So for example:
Wave 1 starts, Create a new "enemy loses mana" trigger, then Register wave units to this trigger as they come into play.
Wave 2 starts, Destroy the last "enemy lose smana" trigger, Create a new trigger, and Register wave units to this trigger as they come into play.
Wave 3 starts, Destroy the last "enemy loses mana" trigger, Create a new trigger, and Register wave units to this trigger as they come into play.

This pattern continues on for the rest of the game.

But this is under the assumption that whenever a new wave starts, ALL of the units from the old wave are already dead. If that's not the case then you could still use this pattern but you'll need to destroy the old trigger at a more ideal time. For example, every 3rd wave you could destroy the trigger that was created two waves ago, ensuring that you only ever have 2 triggers in existence at a time. Or better yet, if you already track when wave units die you could handle the logic once a wave's unit count reaches 0.

The triggers themselves would be stored in a Trigger array so that you can easily reference them by [index]:

• Custom script: call DestroyTrigger(TriggerArray[CurrentWave - 1])

I don't think GUI allows you to create triggers (easily) so you might have to set this up in Jass. ChatGPT could do that for you.

I'm swamped at work right now, so I'll write back when I'm free!
I can already see that the system is awesome. The only question is how efficiently it will be processed so the map doesn't lag. This will need to be tested.

 

[Wing-Span]

There isn't really a "best Unit Registration System" since it all depends on how your map works. But I attached a map with a working example that was designed with a Tower Defense in mind. Note that I didn't bother to clean up memory leaks related to dead registered units.

The fix to that potential issue:
Assuming enemy units come in controlled waves that are guaranteed to die, you could optimize their registration by creating and using a new trigger at the start of each wave.

So for example:
Wave 1 starts, Create a new "enemy loses mana" trigger, then Register wave units to this trigger as they come into play.
Wave 2 starts, Destroy the last "enemy lose smana" trigger, Create a new trigger, and Register wave units to this trigger as they come into play.
Wave 3 starts, Destroy the last "enemy loses mana" trigger, Create a new trigger, and Register wave units to this trigger as they come into play.

This pattern continues on for the rest of the game.

But this is under the assumption that whenever a new wave starts, ALL of the units from the old wave are already dead. If that's not the case then you could still use this pattern but you'll need to destroy the old trigger at a more ideal time. For example, every 3rd wave you could destroy the trigger that was created two waves ago, ensuring that you only ever have 2 triggers in existence at a time. Or better yet, if you already track when wave units die you could handle the logic once a wave's unit count reaches 0.

The triggers themselves would be stored in a Trigger array so that you can easily reference them by [index]:

• Custom script: call DestroyTrigger(TriggerArray[CurrentWave - 1])

I don't think GUI allows you to create triggers (easily) so you might have to set this up in Jass. ChatGPT could do that for you.

I tested it. It's a cool system, it works. But unfortunately, a unit can only have one orb ability, and only the one with the highest chance will trigger. Sad...

On the other hand, maybe this will allow us to automate the damage control system without filtering out all the towers. I don't even know... I'll have to check it out.

There isn't really a "best Unit Registration System" since it all depends on how your map works. But I attached a map with a working example that was designed with a Tower Defense in mind. Note that I didn't bother to clean up memory leaks related to dead registered units.

The fix to that potential issue:
Assuming enemy units come in controlled waves that are guaranteed to die, you could optimize their registration by creating and using a new trigger at the start of each wave.

So for example:
Wave 1 starts, Create a new "enemy loses mana" trigger, then Register wave units to this trigger as they come into play.
Wave 2 starts, Destroy the last "enemy lose smana" trigger, Create a new trigger, and Register wave units to this trigger as they come into play.
Wave 3 starts, Destroy the last "enemy loses mana" trigger, Create a new trigger, and Register wave units to this trigger as they come into play.

This pattern continues on for the rest of the game.

But this is under the assumption that whenever a new wave starts, ALL of the units from the old wave are already dead. If that's not the case then you could still use this pattern but you'll need to destroy the old trigger at a more ideal time. For example, every 3rd wave you could destroy the trigger that was created two waves ago, ensuring that you only ever have 2 triggers in existence at a time. Or better yet, if you already track when wave units die you could handle the logic once a wave's unit count reaches 0.

The triggers themselves would be stored in a Trigger array so that you can easily reference them by [index]:

• Custom script: call DestroyTrigger(TriggerArray[CurrentWave - 1])

I don't think GUI allows you to create triggers (easily) so you might have to set this up in Jass. ChatGPT could do that for you.

By the way, I have an idea for how to create the most effective aura system. It's effective because it's based on the standard aura system. The only downside is the delay before the aura disappears.

Simply give a unit a 0.01 health regeneration aura per second, and then, similar to your work, detect when a unit's health regeneration increases by 0.01 and give it a critical hit ability, for example. And when the regeneration drops by 0.01, remove the ability. Do you think this will be effective?

 

[Uncle]

I tested it. It's a cool system, it works. But unfortunately, a unit can only have one orb ability, and only the one with the highest chance will trigger. Sad...

On the other hand, maybe this will allow us to automate the damage control system without filtering out all the towers. I don't even know... I'll have to check it out.

One ability should be able to do everything. Understand that it's only meant to act as a less advanced replacement to the "A unit Takes damage" Event. You're still meant to trigger the rest of the logic yourself, ie: Having the Tower cast an ability or triggering the effects of an ability yourself.

So you'd set the Orb abilities chance to 100%, cooldown to 0, and handle your different "proc effects" using triggers.

By the way, I have an idea for how to create the most effective aura system. It's effective because it's based on the standard aura system. The only downside is the delay before the aura disappears.

Simply give a unit a 0.01 health regeneration aura per second, and then, similar to your work, detect when a unit's health regeneration increases by 0.01 and give it a critical hit ability, for example. And when the regeneration drops by 0.01, remove the ability. Do you think this will be effective?

That wouldn't work. The system I made only works when the units all have very specific settings:
1. All units using the system have the same exact max mana.
2. These units have No mana regeneration.
3. These units have no possibility for these values to change or be influenced by anything besides my triggers and the Mana Steal ability.

The Mana/Life Events check for specific values, like when a Footman's Life becomes greater than 399.01. That'd mean you'd need 1000's of Events for each Unit, for each difference in Life. At that point you'd be better off using one of the more efficient Aura systems you can find on Hive. Look at how my 'SDP Mana Change Source' and 'SDP Mana Change Target' triggers work.

 

[Wing-Span]

One ability should be able to do everything. Understand that it's only meant to act as a less advanced replacement to the "A unit Takes damage" Event. You're still meant to trigger the rest of the logic yourself, ie: Having the Tower cast an ability or triggering the effects of an ability yourself.

So you'd set it's chance to 100% and cooldown to 0 and handle your different "proc effects" using triggers.


That wouldn't work. The system I made only works when the units all have very specific settings:
1. All units using the system have the same exact max mana.
2. All units have No mana regeneration.
3. All units have no possibility for these values to change or be influenced by anything besides my triggers and the Mana Steal ability.

The Mana/Life Events check for specific values, like when a Footman's Life becomes greater than 399.01. That'd mean you'd need 1000's of Events for each Unit, at that point you'd be better off using one of the more efficient Aura systems. Look at how my 'SDP Mana Change Source' and 'SDP Mana Change Target' triggers work.

I understand. Is it really impossible to track a squad's regeneration rate? I mean, without checking every second.

 

[Uncle]

I understand. Is it really impossible to track the addition of regeneration to a unit? I mean, without checking every second, as in your case...

No, there's no way to detect when a unit's Stat, such as Life Regeneration, changes values. Not without tracking the current/previous yourself and periodically checking for changes (which is inefficient and defeats the purpose).

I can't even promise that my Damage Proc system is efficient. Perhaps those Life/Mana Events are poorly implemented.

 

[Wing-Span]

No, there's no way to detect when a unit's Stat, such as Life Regeneration, changes values. Not without tracking the current/previous yourself and periodically checking for changes (which is inefficient and defeats the purpose).

I can't even promise that my Damage Proc system is efficient. Perhaps those Life/Mana Events are poorly implemented.

That's a shame. I just noticed that if I place a unit in advance and then set a trigger = unit's health drops less, say, to 50%, the trigger fires. I don't think this is checked every second. I thought there was a way to replicate the logic, but with dynamic units, not static ones.

 

[Uncle]

I thought there was a way to replicate the logic, but with dynamic units, not static ones.

It doesn't matter if they're dynamic or static, you can Register a unit to an Event at any time. You just need to use the "Add Event" action which you can see me doing in one of my triggers.

That's a shame. I just noticed that if I place a unit in advance and then set a trigger = unit's health drops less, say, to 50%, the trigger fires. I don't think this is checked every second.

It's not checked every second but it could still be inefficient.

After thinking about it some more, you might be able to detect whenever a unit's Life changes by doing something like "Life becomes Greater than 0.00", then you could compare their current life to a previous value that you had stored in a Hashtable or an Array. If the difference in Life is <= 0.01 then you can assume that it was from a Life Regeneration Aura.

An issue that comes to mind is how other healing effects would function when stacked together. Perhaps two Life Regen Auras would restore 0.02 Life on the same frame which would be larger than 0.01 and thus fail to be detected. I suppose you could increase the check to allow up to say 20 auras or a difference <= 0.20. I believe the smallest Life Regeneration value in the game is 0.25 so staying under that number might allow you to continue detecting these without false alarms. Also, this is all under the assumption that this Aura heals separately from innate Life Regeneration.

Another issue is that you're going to have to check for each Buff to determine which Auras the unit is affected by. So if you have 3 different Life Regen Auras and a unit is affected by all 3, your trigger that detects the change in Life will need to ask the question "Does this unit have X buff?" for every single possible Aura that the system manages. That sounds rather inefficient and might defeat the purpose for all of this.

Oh, and then there's the issue regarding losing a Buff. There's no Event to use here so you'd have to track the affected Units and periodically check for changes in their Buffs. The more I think about this the less practical it becomes.