I was messing around with some of the "Challenge" missions and discovered a Protoss a mechanic that I don't quite understand (Protoss is my least played race by far, so sorry if this is a basic question).

When I attempt to blink stalkers using the shift-queuing method, I usually end up leaving some stalkers behind. It's odd that sometimes all stalkers will properly blink but sometimes I'll end up leaving somewhere between 1-3 stalkers behind. The unpredictability is unsettling...

Mechanically, I'm going through the following 3 steps, which I believe are the correct ones:

  • First, I select the stalkers, right-click on the location from which I want to initiate the blink
  • Then I press Shift + R (R is my blink hotkey) and left-click on the intended destination of the blink
  • Lastly, I release Shift, then press Shift + right-click on a location to which newly blinked stalkers can go (so as to make room for the stalkers which haven't yet blinked).

Note: this is the same series of steps as outlined in this other post: How can I queue up stalker blink?

Here's a GIF showing the result:

animated GIF described above

What am I doing wrong?

Alternatively, if I'm following the right steps, what is causing the unpredictability? I have never seen an instance of a unit simply "skipping" one of the commands in its command-queue and attempting to execute the next one...

  • I would assume it's because you're reaching the blink distance limit, so the tail end of the stalker ball doesn't quite reach the marker before attempting the blink, thus get left behind
    – Robotnik
    Commented Apr 13, 2015 at 23:45
  • 1
    That would imply that some stalkers are attempting to blink before they get to "pre-blink" location that I specified in step 1. Is that the case? Or am I misunderstanding?
    – iceman
    Commented Apr 13, 2015 at 23:50
  • Never seen that before, usually what happens is what Robotnik has alluded to where some stalkers will blink but not quite make it to where you wanted due to the "ball" of stalkers not all blinking from the exact spot where you clicked. It may be an issue with your timing, it seems like some stalkers reach the marker before you give the blink command, but i'm really unsure, as they should still blink. Perhaps try over a longer distance. I will try investigating next time I play.
    – Aequitas
    Commented Apr 13, 2015 at 23:59
  • Another guess here: Maybe the AI was changed such that if a stalker would reach the blink distance limit and not make it to the "blinked to" marker that instead of blinking and missing as they used to do, they would now just ignore the blink command. Keep in mind that this is a guess, I will need to test to be sure.
    – Aequitas
    Commented Apr 14, 2015 at 0:04
  • Interesting. One benefit of shift-queuing (vs. attempting to directly blink from the stalkers' existing location) seems to be that it will never result in a stalker blinking to same the ledge that it started on. Instead, it will just not execute a blink command, which is the better option, because we can just manually blink that stalker (or stalkers) immediately to the correct ledge. If we directly blink, and some stalkers blink onto the same ledge that they started on, we'd have to wait for the cool down.
    – iceman
    Commented Apr 14, 2015 at 0:42

2 Answers 2


It seems that there's been a change to the way queued blinks work. It used to be that while trying to do this that some stalkers blink but do not quite make it to the intended destination whereas some will make it.

It looks like that if they will not make it to the marker that the stalker will instead ignore the blink command. This change is good as you can issue another blink command to the ones that did not make it up instead of having to wait for the cooldown as you needed to previously.

This issue arises because of the grouping of the ball of units, notice how when you queue a series of move commands for a group of units that every unit does not reach the marker but they move as a group. Same thing happens with blinking stalkers, they will try to blink from a position that is close to the marker and for this reason it will not always end up doing what you intended.

Having longer run ups and shorter distance to blink is good practice as it will work more often. The longer run up means that the units are more in a line and less bunched up so there's less chance of them being outside the max blink range and being closer to the wall is the same as it increases the chances that when it tries to blink it will be within range due to the fact that the center of the grouping of units is closer to the wall (so the outermost unit will be closer)


You should be holding the shift key throughout the whole process. Letting go and then Shift queueing another command will overwrite the existing ones. My assumption is that some of the stalkers have already blinked by the time you try to execute the command to shift move to make space.

The entire process should be:

  • Right click under the cliff.
  • Shift + R + Left click destination of blink.
  • Still holding shift, right click where to move the stalkers.
  • Release shift.
  • In theory, either way should work but I'm experiencing the same issue even if I hold shift throughout (sry, I should've mentioned that in my post). From Liquipedia (wiki.teamliquid.net/starcraft2/Blink): "... while holding the Shift key, we order them to Blink to a new location and finally, after letting go of the Shift key, we hold it again and order to move away from the target location of the Blink..."
    – iceman
    Commented Apr 14, 2015 at 0:44
  • I've always done it the holding shift through the whole process and can't say that I've left stalkers behind.
    – Sorean
    Commented Apr 14, 2015 at 0:49
  • you only need to hold shift when you give an actual command, you can push and let go as much as you like as long as you are holding it down when you give a command. You don't even need to push shift+r; you can push r then shift click
    – Aequitas
    Commented Apr 14, 2015 at 1:10
  • 1
    Also, shift + a given command will append that command to a unit's existing command-queue. It doesn't matter whether or not shift is released or held down. In other words, letting go and pressing shift + a command does not erase a unit's existing command-queue, it only adds to it.
    – iceman
    Commented Apr 14, 2015 at 3:14

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .