• 🏆 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!
  • 🏆 Hive's 6th HD Modeling Contest: Mechanical is now open! Design and model a mechanical creature, mechanized animal, a futuristic robotic being, or anything else your imagination can tinker with! 📅 Submissions close on June 30, 2024. Don't miss this opportunity to let your creativity shine! Enter now and show us your mechanical masterpiece! 🔗 Click here to enter!

[Trigger] Help with auto ensnare

Status
Not open for further replies.
Level 6
Joined
Sep 19, 2006
Messages
179
  • Auto ensnare
    • Events
      • Unit - A unit Starts the effect of an ability
    • Conditions
      • (Ability being cast) Equal to Ensnare Power (Casting)
    • Actions
      • Set Loc2 = (Position of (Triggering unit))
      • Unit - Create 1 Sample for (Triggering player) at Loc2 facing Default building facing degrees
      • Custom script: call RemoveLocation(udg_Loc2)
      • Unit - Add a 1.00 second Generic expiration timer to (Last created unit)
      • Unit - Add Ensnare Power (Effect) to (Last created unit)
      • Unit - Order (Last created unit) to Orc Raider - Ensnare (Target unit of ability being cast)
Don't get me wrong. The code does its job.
It makes the raider auto ensnare its opponent.
The problem is that if I run away, the enemies follow me and the net doesn't disappear. Any way to fix this?
 
Level 12
Joined
Nov 3, 2013
Messages
989
  • Auto ensnare
    • Events
      • Unit - A unit Starts the effect of an ability
    • Conditions
      • (Ability being cast) Equal to Ensnare Power (Casting)
    • Actions
      • Set Loc2 = (Position of (Triggering unit))
      • Unit - Create 1 Sample for (Triggering player) at Loc2 facing Default building facing degrees
      • Custom script: call RemoveLocation(udg_Loc2)
      • Unit - Add a 1.00 second Generic expiration timer to (Last created unit)
      • Unit - Add Ensnare Power (Effect) to (Last created unit)
      • Unit - Order (Last created unit) to Orc Raider - Ensnare (Target unit of ability being cast)
Don't get me wrong. The code does its job.
It makes the raider auto ensnare its opponent.
The problem is that if I run away, the enemies follow me and the net doesn't disappear. Any way to fix this?
Exactly what happens when a raider runs away? (What happens if the raider stays, does it usually work as it should?) Is the problem something with fog of war? (Maybe the dummy unit loses sight of the target cause you run away.)

_______________________________________________________________________


Anyway, my impression of what you're saying happens:
  1. Your unit uses some dummy autocast ability on an enemy unit.
  2. An invisible dummy unit appears & uses the 'real' ensnare on the target unit.
  3. The target unit is ensnared by the net.
  4. you run away, and somehow, the unit *that's supposed to be ensnared* can still move and follow you even though they're netted...
Or exactly what's going?


By the way, you might already know this, but I'll advise you to change the "Art - Animation - Cast Point" and "Cast Backswing" to 0.00 for the dummy caster, if you haven't already. Also, you might want to increase the "Art - Propulsion Window Degrees" from 60.00 or make the dummy unit face the same angle as the original caster unit.

Of course, if the problem turns out to be that the dummy unit simply dies before it finishes casting the ability, then increasing the "expiration timer" duration might solve your problem. (But there's still going to be a delay for the dummy unit compared to the original caster.)
 
Level 6
Joined
Sep 19, 2006
Messages
179
...you run away, and somehow, the unit *that's supposed to be ensnared* can still move and follow you even though they're netted...
That's what happens. I changed the expiration timer to 4 seconds and it didn't solve it. As for the dummy called "sample", I based it on the 'dummie" unit used for the auto entangling effect. The "Art - Propulsion Window Degrees" was 60.00 and the "Art - Animation - Cast Point" and "Cast Backswing" were both set to 0.00.
 
Level 39
Joined
Feb 27, 2007
Messages
5,034
My Guess is that the dummy unit fired the net which did hit the target but the dummy expired right before the missile land or after, but blizzard engine did not managed to find a caster and render the buff useless due to net caster being removed from game.
No, not the problem:
That's what happens. I changed the expiration timer to 4 seconds and it didn't solve it.
 
Level 15
Joined
Aug 14, 2007
Messages
936
Let me try this again, I have used Hero that uses Ensnare befor so I may be able to help out, there are two kinds of ensnare in blizzard engine, one allows you to ensnare land targets and another is on air, my Guess is that you used the sub ability instead of the main ensnare. Other than that you will have to use entangling roots, I got nothing, *drinks wine*
 
Level 12
Joined
Nov 3, 2013
Messages
989
As for the dummy called "sample", I based it on the 'dummie" unit used for the auto entangling effect.
What is this?

But anyway, I've never seen or heard of anything like what happens for you so I'm not sure what the problem is. Attaching a test map would probably be a good idea.


For the meantime though, try and see what happens if you replace the ensnare ability with another single target CC one. e.g. storm bolt, entangle, firebolt, etc.

Just so you know that the problem lies with ensnare. I wouldn't recommend using anything other than web or entangle for the actual ability though since entangle does prevent units from auto attacking.



Wait... Can't you just use the crypt fiend "web" ability? It has autocast. I'm pretty sure that it works just about the same as entangle.
 
Level 6
Joined
Sep 19, 2006
Messages
179
@Pyrogasm: Here is the map:
(6)Andorhal.w3x (7.77MB) - SendSpace.com
It's the Andorhal map, but edited. To test it, after opening the map, press Ctrl+F9 and once you're on the map, select the 3 raiders next to the to the other test units and head to the 3 enemies at the top. It should ensnare them automatically.
Very rarely, the enemies are completely ensnared and most of the time, they move while being netted.
I noticed there is no net animation that head towards the enemies.
 
Level 39
Joined
Feb 27, 2007
Messages
5,034
Wow this is super weird. I've found a few things so far you need to change and with all of them fixed I have resolved the error... most of the time. For some reason it still seems to produce this error occasionally with no real rhyme or reason. It's errored via manual cast and by autocast, on air units and ground units, heroes and regular units. The one thing I have found to be consistent is that the projectile art does not show up if the unit will be able to move, so it has to be something with the dummy unit not actually casting it properly.
  • 0.30 seconds might be too short of an expiration timer. I changed it to 1.
  • Triggering Player on the second line should be Owner of Triggering Unit. This affects Auto Entangle as well.
  • Ensnare Power (Effect) has its Ensnare tech requirement still and "check dependencies" set to true... yet somehow the dummy unit is casting it even with this requirement. I confirmed this by making the dummy selectable with a 10s timed life; I could see the ability on its command card but it was greyed out and the tooltip listed "Requires: Ensnare"
  • You switched the order of the Ensnare (Air) and Ensnare (Ground) buffs in the Ensnare Power (Effect) ability, though I am not sure if this matters at all since they're likely identical buffs internally just with different mouseover text.
I didn't take the time to do this but your next step to trying to resolve this is to make a copy of your map and then delete every trigger from it except the 2 ensnare triggers. See if you can reproduce the bug like that. If no, some other trigger is messing with the Ensnare Power (Effect) cast, and if yes then I'm baffled.


Edit: Turns out there was another source of the buff I was too tired to notice and I am totally wrong about this possibility. Please ignore.
@Kyrbi0 and other people who extensively fuck with the Object Editor: have you ever seen anything like this? The dummy unit (partially) casts the spell even when the spell is disabled by a techtree requirement! I'm also on 1.29, so this isn't a 1.30 bug. I was experiencing the same bug/symptoms as the OP when opening the map without saving and also after saving using my 1.29 WE.
 

Attachments

  • (6)Andorhal - Fixed.w3x
    7.8 MB · Views: 60
Last edited:
Level 15
Joined
Aug 14, 2007
Messages
936
Alright the main problem is Target Unit of Ability Being Cast, this target will be gone after the first three actions of the Trigger, which means it will never work, to solve this you need to first store Target Unit of Ability Being Cast into a variable. Download the edited map and see if it works.
Another Error I saw, you used
Triggering Player instead of Owner of Casting Unit, I fixed that, next time please remember to use Owner of Casting Unit. There is one last step though, I already fix that too, when you remove the Requirement for Ensnare Research, it will allow the sample caster to cast Ensnare. I am guessing that @Pyrogasm had already fixed a few things but he might still be confused about how the whole structure works, if you are worried about his codes then you can use mine :)

There is one thing though, why does the game crash everytime I exit Warcraft? This map does have some issue after all.
 

Attachments

  • (6)Andorhal.w3x
    7.8 MB · Views: 62
Last edited:
Level 39
Joined
Feb 27, 2007
Messages
5,034
the main problem is Target Unit of Ability Being Cast, this target will be gone after the first three actions of the Trigger, which means it will never work
Absolutely false. Target Unit of Ability Being Cast is not wait-safe (can't be used after a wait) but this trigger does not include any waits. Please stop spreading wrong information; I keep quoting you and saying things like this because it is not helpful to the community to have incorrect information posted erroneously. If I post something that is my conjecture I will state that and not report my thoughts as fact; if I'm later proven wrong I will edit my post to make it clear I was incorrect before. In this instance the variable is totally unnecessary and this is not a problem with the spell at all. Try to prove me wrong, please. If you can produce a map that proves the variable is necessary in this instance (your uploaded map is not proof) I'll delete my account and never bother you again.


@Reinhold I kept digging and found there are two more steps to add to my first post to completely resolve the problem:
  • Set the Ensnare Power (Casting)'s buff to 0.01 (not 0.00, that lasts forever) -- this is the thing that's been causing the 2nd buff on the buff bar and the repeated ensnare effect. Turns out I'm real stupid and the duration of Ensnare Power (Casting) was set to 5.00/12.00. This was one of the first things I looked at and I thought I read 0.01 there and never looked again, ugh. @Acutesharpness changed it to 1.00 in his map, but it should be as small as possible if you don't want it to appear doubled briefly (you could also remove the buff from the target unit in the cast trigger but not lower the duration if you want). This also means I was totally wrong before about the spell still being cast when disabled by techtree requirement.
  • Increase the range of Ensnare Power (Effect) to 9999 -- the cases where it randomly fails are because the dummy spell has the same cast range as the raider's spell (usually that's okay though max range on dummy spells is certainly recommended) but your dummy unit also had no movement! If you cast at max range and the target is moving away from you then the dummy can't target it and it can't move to get closer. @Acutesharpness did not do this in his map, and thus it can still fail at max range every time. To test this, target ensnare on a unit that hasn't aggro'd any of your units and let your raider walk up to cast it on them; it will fail every single time.
The white cubes and no enemies are probably a result of my saving your map with a lower-version'd World Editor. Finally, two more suggestions as general mapping practice:
  • Optional: In addition to making all of your dummy abilities have max cast range (9999) they should also cost 0 mana and have 0 cooldown, just in case.
  • Optional: Your dummies should have flying movement and max move speed so they can move over terrain, doodads, and cliffs as well as catch up to units they're trying to target.
 
Last edited:
Level 15
Joined
Aug 14, 2007
Messages
936
@Pyrogasm I am sure your thoughts are not very wrong but certainly flawed, let me explain before your natural instincts take over and make you look like a fool, the key word is "like", it does not mean you are a fool, just a weaker programmer than I am :p

Anyway, I am just better at
teaching (it means passing on knowledge to new people, nothing to do with profession) but I will admit my lack of knowledge in codes since I don't study enough to know more than you but I do know how the fundamental things in the computer works, therefore my codes are perfectly flawlessly free of glitches, if that make any sense. Alright enough of my introduction, what I am getting at is that in my years of experience with the world editor or programming in general, why I insist on Target Unit of Ability Cast being disabled after three actions is as follows:

- Actions do not consistently cost energy, creating units cost more energy to perform.
- When a trigger uses too much energy, world editor will force the other actions to be skipped.
- Which bring me to my next point,
Target Unit of Ability Cast will be totally ignored if editor wants to run the next trigger that handle the event.
- I do understand
JASS solves all of these issues but in GUI it happens and from what I am aware OP uses GUI so I am totally valid.
-
Totally false in this case, only applies to JASS and not GUI.

*YES I AM DRUNK AGAIN*
 
Level 39
Joined
Feb 27, 2007
Messages
5,034
therefore my codes are perfectly flawlessly free of glitches
Please link or direct me to anything in any of my code/triggers in any thread we've both posted in that contains glitches as you see them that are not due to a syntax error, with an explanation of what "glitch" you see and how I should have fixed/avoided it.
- Actions do not consistently cost energy, creating units cost more energy to perform.
- When a trigger uses too much energy, world editor will force the other actions to be skipped.
What the hell are you talking about? There is no such thing as trigger energy or any other finite resource that triggers have to use up before things like Target Unit of Ability Being Cast begin to randomly fail. The only thing I can think you possibly mean is the op (operation) limit, which people sometimes hit in Map Initialization triggers, deeply complex systems using large data structures, or things that pick all destructables in large sized maps. Please explain further what you think you are talking about.
- Which bring me to my next point, Target Unit of Ability Cast will be totally ignored if editor wants to run the next trigger that handle the event.
This is bologna and I absolutely will not believe it until you can show me a test map that confirms this behavior. Even if only <1% of all users ever encountered this behavior it would be wildly posted about on this forum and in the tutorials because people would need to know to avoid it. I've built many, many long and complex spells using just GUI before I learned how to program and not once did this ever come up as something I needed to do. In our 11 years here we would have both heard about it but I have not. Nobody has, because it doesn't happen and you're imagining it. Provide a map.
- I do understand JASS solves all of these issues but in GUI it happens and from what I am aware OP uses GUI so I am totally valid.
What you see in the GUI is literally converted to JASS and compiled into the war3map.j when the map is saved. They are literally the same thing underneath the hood; you should know this if you consider yourself to have "years of experience with the world editor or programming in general." You know what GUI stands for, right...? Graphical User Interface (for JASS). If something applies to JASS it de-facto applies to GUI too unless it is about a feature you can't access in GUI (local variables, TimerStart(), PlayerIds starting at 0 instead of 1, BJ global variables GUI can't refer to, etc.). What you are saying makes no sense.

*YES I AM DRUNK AGAIN*
I was being both comical and serious when I responded to that other ridiculous rambling post of yours from yesterday with only a comment suggesting you not mix drinking and HiveWorkshop-ing. It doesn't make you look good or help anybody.
 
Level 13
Joined
Jul 15, 2007
Messages
763
I have no idea how any of you have overlooked the real problem here. In the original version the dummy doesn't even cast its ensnare because it requires a tech. The auto-cast "fake" ability has its buff set to Ensnare for some really weird reason (hint: use a custom buff) which gives the illusion that it's trying to ensnare. The spell works as the creator made it; it curses an enemy for 12 seconds with a 0% miss chance using the Ensnare buff. The dummy doesn't even do anything.
 
Level 13
Joined
Jul 15, 2007
Messages
763
Yes that was what we did by the way...

Almost but not quite. The way the curse auto-cast works (and most buff auto-casts) is they will only auto-cast on something that doesn't have the auto-cast buff already. Because the duration you set is 1 second, a group of Raiders can potentially auto-cast their Ensnare on the same target every 1 second.
 
Level 39
Joined
Feb 27, 2007
Messages
5,034
I have no idea how any of you have overlooked the real problem here.
I have no idea how you overlooked that two different people in this thread identified that problem12 hours before you posted that. You also did not notice the 5 other things the OP needed to change in their map to get the spell to properly cast. I also included a comment in my post explaining that I thought I read the curse ability had a 0.01s duration for a while.

It happened... :V When multiple players cast spells at the same time, even hash table can be messed up, although I got no proof at the moment but if you go some stress test yourself in multiplayer more often, you might actually break the game :)
This is also complete, unsubstantiated bologna. There are also no hashtables here (I presume you're referring to some other thread where I suggested the use of hashtables to someone else, but again you didn't provide a link or a specific example that I could refer to or test). This spell is perfectly MUI because all of its effects come directly from modified base abilies, not from any triggered effectss. Stop spreading lies and incorrect claims.

You did not adress any of my points, just implied I have made myself look like a fool. You are the fool here. Claiming without any proof that extraordinary and unexpected things will occur that break the spell is ridiculous, but continuing to insist you're right even after I have calmly and respectfully asked for you to provide a test map to back up your extraordinary claims is extremely childish. What do children do when they realize they're wrong? Double down on their own lies, insist the adults are lying or trying to discredit them, and move the goalposts to a different ridiculous claim.

You have not provided any evidence or proof of any of the claims you are making about hashtables, event responses, or trigger "energy". This is unacceptable and I lose more of my tenuous respect for you with each post of yours that ignores my repeated requests. Provide a map that backs up any of your claims with hard evidence and I will thoroughly test it to see if I agree or not, but I will not sit here and tolerate you spreading misinformation that will confuse the people you claim you're trying to help. When I'm wrong or miss something at least I have the balls to admit I fucked up.
 
Level 13
Joined
Jul 15, 2007
Messages
763
Sorry @Pyrogasm but you quite literally had buried the (partial) solution in these wall of arguments between yourself and @Acutesharpness.

This thread is for Reinhold's problem that has been sufficiently solved. I would kindly request you two quit your squabbling so i and everyone else no longer get notifications. Acute has already admitted he has no proof for whatever his bizarre claims are; the argument is over.
 
Status
Not open for further replies.
Top