• 🏆 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!

"Add the event" bugs when dealing with arrays

Level 6
Joined
Jan 12, 2014
Messages
56
Hey;

I was trying to make events like "A unit comes within range of UNIT" but i couldn't choose a variable.
So i created triggers with "time elapsed 0.01s" and put this :
Trigger - Add to JavelinPickUp1 <gen> the event (Unit - A unit comes within 350.00 of JavelinWardArray[1])

However, it doesn't seem to work. The JavelinPickUp1 trigger doesn't ... well trigger... I checked the JavelinWard unit with a Special effect when i type "1" in the chat : this is the right one, no doubt, and the editor CAN detect it.
I also tryed to change the unit, instead of JaveWardArray i picked a random unit on the map, and JavelinPickUp1 triggered !!!

Everything seems fine but i can't work i don't know why.
is it a bug ?

____
In a nutshell i want to have a unit throwing a javelin somewhere. I create a unit at this point, and when the Hero go near it, he "picks it up" and something is triggered (Cooldown reduction).
But i need this to work for multiple "awaiting" javelin in the ground at the same time. And the best is if enemy Heroes of the same type can pick up MY javelin.

I tryed to give the javelin an automatic spell without effect which target allies, so when someone is hit by the AI, i check if it's the hero, if yes > actions. But i couldn't find a spell without drawbacks. The heal needs the hero to be damaged, bloodlust to be in battle, same for enemy spells. Moreover, enemy spells make the unit run away AND invulnerable units don't want to cast any spell.
 
Level 39
Joined
Feb 27, 2007
Messages
5,026
You cannot choose a variable because that is a specific unit event (not a generic event like most events you will use). It requires a specific unit that the trigger will check, and that specific unit is baked-in to the trigger at the moment the event is added to it. Using a variable there will not make it work for whatever unit is assigned to that variable through the game; it will grab the one specific unit that the variable happens to point to when the event is added.

At the time you added the event the variable probably hadn't been assigned to anything yet, so had the value of null. Thus the unit to check in the trigger was null and no rangefinding was occurring. To achieve the functionality you want, you have three options:
  1. Add the event to the trigger dynamically (during the game) whenever a javelin is created whose closeness needs to be checked. Since you cannot manually remove events from a trigger, over time this will end up with many useless/unnecessary events on that trigger and will likely become a performance issue. That particular event is very resource-intensive, which is why there isn't a generic version of it. Consider how the update frequency of auras is actually quite low (~2 seconds I believe) because that also gets to be very resource intensive (but is done natively), and this is just a less direct version of aura ranging.

    As these events build up, you can destroy the trigger and re-build it from scratch... but there is no way to know which presently-existing javelins will need to have their events re-added unless you're keeping track of them. Rebuilding it will require some rudimentary JASS/Lua, as GUI cannot natively do that. Wc3 used to really not like trigger handles (or maybe it was triggerevent/triggeraction/triggercondition handles?) being destroyed, and there were some potential issues with doing this. (A problem that many early damage detection systems struggled with.) This may no longer be an issue; I am unsure.

  2. Instead of dynamically creating and then destroying/removing javelin units as they are needed, decide on either some total number of javelins that the map will never exceed or some maximum number per player/per unit. Then re-use that many javelins as necessary for the trigger with an event for each one. The unnecessary ones will still do range checking which might be a resource drain, but it's probably better than having 55 events from dead units.

  3. Instead of using that event at all, decide on some other method to identify when a unit comes near a javelin. The three I can think of are:
    • Give the javelins two auras (one affecting only player-owned heroes, the other only affecting enemy heroes), then periodically check all the heroes for either of these buffs. If you find the first buff it's by its own javelin, and if you find the second buff it's by a hostile javelin. Then you do have to perform some logic/math to figure out which specific javelin it is closest to and what to do about that. Finally, aura update frequency is bad so this solution is probably not a good one. But maybe?

    • Give the javelins a permanent immolation abilitie that deals some small but nonzero amount of damage, affecting only player-owned heroes and enemy heroes. (The Stats - Duration - Hero/Normal fields control how quickly permanent immolation ticks damage on nearby targets.) Use a damage detection system to detect damage dealt by this ability, prevent that damage (so it will never harm anything or cause AI to behave weird), and then check the relationship between the damage source and target to act accordingly (pick up or destroy javelin). Damage Detection on older patches is possible but annoying.

    • Use a periodic trigger with a low but not excessively-low timeout (say, 0.25s) and do your own manual check of the units nearby each javelin and act accordingly with whatever you find there. This will be easiest if you put the javelins in a unit array or a unit group to loop over. This will give you full control and won't involve any funky events, but is likely to be the most resource intensive.
Note that for options 1 and 2, you still have no direct way to figure out which javelin the nearby unit actually came near. There is no response to get "the source unit that a unit came in range of". The only ways around this are to have a separate trigger for each javelin event (something you'll need a bit of JASS/Lua to do but is ultimately not that hard, with the caveat that destroying triggers might still be bad) or to manually check the unit's distance to every javelin once it has triggered the event, then choosing the one it's closest to.

IMO Option 3.B is the best solution, but 3.C is okay too.
 
Level 6
Joined
Jan 12, 2014
Messages
56
What a response ! Thanks A LOT !

I worked on it during the night, and i tried to add the trigger dynamicly too, but it didn't work either. But i quickly ran into unit checking issues anyways.

Clever the immo !
"prevent that damage (so it will never harm anything or cause AI to behave weird)"
Is it possible to prevent the damages without the linked Damage Detection System ?
With "is about to take damages" and makes him full hp, or some shenanigans ?

I ended using an item with an ability like runes/tomes to pick up. Like that i check, if it's not the right type of hero, i spawn another.
To make it disappear, i pick the items of type and damage them every seconds.
But i would like to store the remaing hit points of the item picked to set the same amount to the newly spawned one, to avoid resetting the timer each time.
 

Uncle

Warcraft Moderator
Level 64
Joined
Aug 10, 2018
Messages
6,577
Here's a triggered Javelin system. Not sure if it's exactly what you wanted or if you can even open the map. I used Chopinski's missile system to create the triggered missile, it's currently setup to damage the first enemy unit that the javelin impacts.

Also, any unit that has cast the Throw Javelin ability at least once will be able to pick them up. You can add a unit to the Javelin_Hero_Group to make them able to pick-up Javelins.

Also, I think patch 1.36 broke cooldown reduction, so I had to take extra steps to fix it. Trying to set a cooldown to a negative value used to default to 0.00 seconds but now it simply has no effect, so I had to account for this in the cooldown math.
 

Attachments

  • Throw Javelin 1.w3m
    83.4 KB · Views: 1
Top