Make Blink spell that respects caster's pathing

[Voljin]

Hello Hive,

I am trying to make a custom form of Blink that works similar to the Blink in WOW. The major difference between the WOW blink and the wc3 blink is that the WOW blink respects unit boundaries. For example, in wc3 you can teleport to the top of a small hill with a +1 to cliff elevation (even if there is no path allowing you to otherwise get there if the unit lacks the blink ability), but in WOW blink is just used as a means of moving forward rapidly and escapes (my desired blink spell).

I like this design better because it forces the hero to have to move through the map as the designer intended, but still utilizes the interesting concept of the blink ability for combat and quick travel.

Essentially, I'll need to make some kind of trigger that demands that the blink ability cannot pass through walls or make the hero move to a different elevation level than where they begin casting the ability at. Problem is, I'm not even sure where to start or if that's possible. It would be a shame to exclude the blink ability from my map, but given its dimensions, that might be best to prevent shortcuts.

 

[Dr Super Good]

What you are asking is not trivial. It involves executing a path search from the units current position to the target location, functionality not available in Warcraft III. StarCraft II has inbuilt mechanics just to support this type of blink.

I would suggest not having blink spells in your map as that is by far the easiest solution. If you want rapid mobility then you can try implementing dash or charge spells which use triggers to move the unit in a line over some distance. The triggers can check pathability along the way and stop moving the unit when unpathable terrain is reached. This may have issues with buildings and destructables, unless alternative path testing means are used.

 

[Voljin]

Hello Dr.

So I was playing around with it a bit and noticed the Position Z triggers in the game which, at the very least gave me hope that I could accomplish half of my blink ability's goals by making the casting unit incapable of teleporting to any point that is of a different elevation than the point they started on. I was not able to specifically forbid the unit from going to a different elevation... but I was able to quickly teleport them back should they disobey the rule (granted it took 1 more variable than I would have liked it to). However, using Point and Real variables I was able to force a backtrack to my unit's starting point and it seems to work so far...

I was thinking of sticking with it, but it does still have some inherent weaknesses such as: It does not address passing through walls (though I was considering just nerfing the range at how far a unit could teleport to deal with this and make it a simple escape ability), and it also doesn't stop the unit from getting to peak over the hill temporarily which may or may not become disappointing later (Though I'm debating going without fog of war for my maps)

I was also considering adding actions to reset ability CD and mana if the ability wasn't used as intended, but I can already picture someone taking advantage of that to stall enemy units from killing the caster by intentionally blinking into a mountain over and over again.

Anyway, not perfect but here is my blink ability so far. I understand why you might not use it, but I think that it could work like this. Thanks!

 

[Dr Super Good]

I would recommend not using that. The reliance on TriggerSleepAction (wait) is reason enough but it also uses the leaky game-time variant, is not MUI, leaks locations, clearly does not work as it never moves the unit, does not solve the initial problem and even is prone to Out of Sync errors.

Ignoring that it is missing a move unit action and that TriggerSleepAction has a timeout of at best 0.1 + ping delay then one could still use it to teleport down off cliffs onto isolated pathing islands. Assuming one does not desync in the process because unit Z is likely a client local value and so not network safe for logic (intended for visuals).

 

[Wrda]

I would recommend not using that. The reliance on TriggerSleepAction (wait) is reason enough but it also uses the leaky game-time variant, is not MUI

You know very well that just because there is a wait doesn't mean it won't be MUI. He just needs to put his variables after the wait and it's 100% MUI, and the delay is pretty much irrelevant in this context.
Also, this is the 6th time I see someone use game-time seconds. Reallly, why use it? It's literally the worst choice possible ever you could make. NEVER USE IT, use the other one instead.

 

[Uncle]

I'm confused. So the unit can only blink to higher cliff levels IF that cliff could be reached on foot (Is Pathable)? So an inaccessible cliff would be unblinkable, however, a cliff with a ramp could be blinked on (even if that ramp is a mile away).
I attached a picture to clarify

If that's the case, then I can't think of a simple and efficient way of doing it. It's possible, but it probably won't look very good.

My first idea was something along the lines of this:

• Untitled Trigger 001
  • Events
    • Unit - A unit Starts the effect of an ability
  • Conditions
    • (Ability being cast) Equal to Blink
  • Actions
    • Set tempPoint[0] = (Position of (Triggering unit))
    • Set Angle = (Facing of (Triggering unit))
    • For each (Integer A) from 1 to 10, do (Actions)
      • Loop - Actions
        • Set tempPoint[(Integer A)] = (tempPoint[0] offset by (60.00 x (Real((Integer A)))) towards Angle degrees)
        • Unit - Create 1 Dummy for Neutral Passive at tempPoint[((Integer A) - 1)] facing Angle degrees
        • Unit - Order (Last created unit) to Move To tempPoint[(Integer A)]
        • Set ReachedDestination[(Integer A)] = False

Then if a dummy reaches it's destination successfully

• Set ReachedDestination[(Integer A)] = True

Not nearly finished, but the general idea is there. You can then loop through the dummys and if you find a dummy that didn't reach it's destination you know that that point is unpathable. After figuring out which points can be reached, move your hero to the furthest point that has ReachedDestination = true.

Now the big glaring issue is that we have to wait for these dummies to move before we can move our hero. This could take a second or two, or 100... and having to wait that long will completely ruin the spell. So... I don't know... maybe have this trigger running periodically so it's constantly testing the pathing around your hero? And maybe put a cutoff distance so that dummys that traveled more than lets say 600 units are considered to have failed to reach their destination.

 

[Dr Super Good]

You know very well that just because there is a wait doesn't mean it won't be MUI. He just needs to put his variables after the wait and it's 100% MUI, and the delay is pretty much irrelevant in this context.

I also know that the trigger posted is not MUI. And no it could not be made MUI by doing what you described because if the logic did what he intended it to then the variables would need to be set before the wait. Why there is a wait I am not sure as I do not see anything preventing this spell from being done instantly.

Also, this is the 6th time I see someone use game-time seconds. Reallly, why use it? It's literally the worst choice possible ever you could make. NEVER USE IT, use the other one instead.

Because it is slightly better than the other one, if only it did not leak a handle index.

TriggerSleepAction approximates real time so the actual number of game update cycles a period lasts depends on the speed the game is set to and does not factor in pauses and lag. The game time version, PolledWait uses a timer which tracks game time and so is effected by game speed, pauses and lag however it has a bug resulting in a handle ID leak.

Now the big glaring issue is that we have to wait for these dummies to move before we can move our hero. This could take a second or two, or 100... and having to wait that long will completely ruin the spell. So... I don't know... maybe have this trigger running periodically so it's constantly testing the pathing around your hero? And maybe put a cutoff distance so that dummys that traveled more than lets say 600 units are considered to have failed to reach their destination.

Now you know why I said...

What you are asking is not trivial. It involves executing a path search from the units current position to the target location, functionality not available in Warcraft III. StarCraft II has inbuilt mechanics just to support this type of blink.

The only way to perform accurate path searches efficiently is by ordering a unit to the point and that is non instant. One could write ones own path finder just for this but that is non-trivial as path finders are notoriously complex, especially when one does not have access to the native path map. The developers of StarCraft II literally implemented special purpose mechanics just to perform this exact kind of task, to prevent abilities from being cast towards points which cannot be pathed to.

There is a limit to the number of moving units per player at any given time. This limit is from the path finder updating every internal frame. As such having hundreds of units sampling pathing around the unit is not good from a path finder performance point of view as well as actual game performance.

What some maps did to prevent this is manually construct regions over cliffs such as shown in the example image. If the blink order targets such a point inside such a "no blink" region then the blink order is cancelled. This is likely a lot easier than writing a custom path finder just to resolve such cases but will still require quite a lot of work depending on how complex your map terrain is.

 

[Uncle]

Yeah, I suppose it's not really possible. Maybe Reforged will introduce something like this.

 

[pleasehelp]

Maybe use a specific terrain type wherever you have unreachable cliffs.
Then implement a trigger like this. The downside is that you are limited to using or avoiding such a terrain.

Otherwise use a dash spell that pushes you forward and cancels when it hits that specific terrain type, then instantly sends you back like 150-200 units to compensate for the cliff spacing.

 

[Voljin]

Thanks for all the advice everybody!

I noticed this forum blew up since I last looked at it, so let me respond to you guys as best I can.

Dr Super Good could you explain to me some of the things you were talking about when you suggested not using that trigger? I'm not super fluent in this and I wasn't sure what you meant by not being MUI and leaking exactly. Could you explain what consequences that entails exactly? Cause so far, it seems to be bearable as a spell from testing it.

Also, the spell is based off of blink and moves the unit on it's own so I didn't need the trigger to do it. The trigger just backtracks the unit if they use the basic blink spell to change elevation of unit.

I saw a lot of people in other posts trashing the regular waiting triggers because they didnt work right if you paused the game or something which is why I chose in-game time. I initially wanted to use wait for condition, but I couldn't find a condition that made the trigger work, so I'll admit I sort of settled there. I haven't noticed any problem with them... is it only a problem if you change game speed?

Also, I needed some type of wait for the trigger to work. I tried removing it, but without the wait in the script, the condition on the If-then would check the current position of the unit, and not the end position, making it worthless.

 

[Dr Super Good]

I'm not super fluent in this and I wasn't sure what you meant by not being MUI and leaking exactly. Could you explain what consequences that entails exactly? Cause so far, it seems to be bearable as a spell from testing it.

Not MUI means that if more than 1 unit were to cast it, it may break and not work correctly. In your case it could potentially teleport the unit back to the wrong location.

Leaks effect performance. They start off trivial but as they accumulate performance will decrease. Low frame rate, long exit times, etc are all symptoms of leaks.

I saw a lot of people in other posts trashing the regular waiting triggers because they didnt work right if you paused the game or something which is why I chose in-game time. I initially wanted to use wait for condition, but I couldn't find a condition that made the trigger work, so I'll admit I sort of settled there. I haven't noticed any problem with them... is it only a problem if you change game speed?

The problem is that it is not very accurate with respect to time. For example the delays are longer in multiplayer than single player. Timers and trigger events are accurate.

Wait game time is technically better, but still uses TriggerSleepAction internally and has a leak problem.

Also, I needed some type of wait for the trigger to work. I tried removing it, but without the wait in the script, the condition on the If-then would check the current position of the unit, and not the end position, making it worthless.

You could try triggering the teleport.

My main concern is that you are not getting the cliff height of the ground under the unit, but rather the height of the unit and comparing it with the height of the unit somewhere else. The height of the unit is not network synchronized so this trigger could be prone to OoS issues if cast on walkable destructables like bridges.

 

[Voljin]

Hello Dr,

Would the problems you described affect a single player RPG (with just 1 hero unit capable of using the ability)? Also, would it be better (leak-wise) to use multiple timer variables or an effective wait for condition trigger? I usually try to avoid using a bunch of variables because they can become a nuisance to keep track of...

I hadn't considered bridges... That's a good point. I use invisible platforms a lot in my maps too for imported bridges and after testing the ability it is not compatible with either bridges or platforms it seems.

I will probably take Dr's advice to abandon the ability altogether, but it was a good learning experience. Thanks everyone for your contributions!

 

[Dr Super Good]

Would the problems you described affect a single player RPG (with just 1 hero unit capable of using the ability)?

Depends on cooldown of blink. With cooldown >1 second it should not be a problem. With cooldown <1 second it might be.

Also, would it be better (leak-wise) to use multiple timer variables or an effective wait for condition trigger? I usually try to avoid using a bunch of variables because they can become a nuisance to keep track of...

The solution to the leaks is to remove them with the appropriate custom script. One can use wait game-time but one would need to call a custom implementation which fixes the agent variable reference counter leak on return bug.

 

[Roflan]

You can try creating an invisible dummy that would be thrown in the direction of the blink target point. When the point is reached, move the caster to that dummy.

The idea is that the sliding dummy is not able to move through path blockers like trees and walls when moved at 30meters per 0.04 sec towards the target. Which means as soon as the dummy is stuck in the bath blocker, the caster would move to its position without jumping it over.

 

[Wrda]

So only this hero can cast this ability? Then you can ignore the MUI part, it's pointless to do that if only one hero casts it and if the cooldown is long enough as already described.
Normal waits are not a problem in single player, since you never pause there, and they're also more accurate than in battle.net.

I saw a lot of people in other posts trashing the regular waiting triggers because they didnt work right if you paused the game or something which is why I chose in-game time.

Normal waits are not a problem in single player, since you never pause there, and they're also more accurate than in battle.net.
You see a lot of things. You need to start to think for yourself and figuring things out by yourself, and then you take the results and have better judgement, rather just being a sheep in the flock and following everyone what others said. Watching what others say about stuff might either restrict your creativeness and approaches or make you develop "fears" without fully understanding them.
But of course you're always free to ask stuff when in doubt, while also taking conclusions from your own experiments.
In this case, if you used the normal waits in battle.net you would probably face problems, doesn't mean you'd be 100% guaranteed to have them. In my opinion, the argument to discard these waits on battle.net looks pretty much based on a rare chance to happen. How many times do you see people actually pausing and saving the game while you probably have waits being excecuted? The waits will be excecuted even if you pause, the thing is the actual wait excecution won't also "pause" while game is paused, so the time of the wait will look shorter.
I've played enough games to say that this annoying "bug" happened in 0.5% of my total games played.