Skip to main content
15 events
when toggle format what by license comment
May 9, 2023 at 23:39 history edited galacticninja CC BY-SA 4.0
formatting tweaks; converted non–SE Imgur image to ≤ 2 MiB to be compatible with SE Imgur, context: https://meta.stackexchange.com/questions/388556/imgur-tos-change-could-cause-the-loss-of-thousands-of-se-images (resized width to 650px and reduced colors to 128)
Apr 13, 2017 at 12:09 history edited CommunityBot
replaced http://gaming.stackexchange.com/ with https://gaming.stackexchange.com/
Apr 14, 2015 at 3:18 vote accept iceman
Apr 14, 2015 at 3:13 comment added Aequitas It works in that video because your first move command is closer to the wall so even at the max unit grouping distance they would all still be able to make it up. 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 being outside the max blink range) (closer to the wall is the same as it increases the chances that when it tries to blink it will be within range)
Apr 14, 2015 at 3:08 answer added Aequitas timeline score: 2
Apr 14, 2015 at 3:00 comment added iceman yep, confirmed that (shift) blinking avoids an unnecessary blink if the unit is unable to blink to the desired destination. i was able to get it to work by chaining together a move command, a (shift) blink command and a (release and shift) attack move command - you can see the resulting green/red pathing lines in the video (youtube.com/watch?v=2azY3s0wj80).
Apr 14, 2015 at 1:11 comment added Aequitas did you confirm my theory through testing?
Apr 14, 2015 at 0:42 comment added iceman 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.
Apr 14, 2015 at 0:40 answer added Sorean timeline score: 1
Apr 14, 2015 at 0:04 comment added Aequitas 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.
Apr 13, 2015 at 23:59 comment added Aequitas 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.
Apr 13, 2015 at 23:50 comment added iceman 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?
Apr 13, 2015 at 23:46 history edited deutschZuid CC BY-SA 3.0
that's what the tag is for
Apr 13, 2015 at 23:45 comment added Robotnik 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
Apr 13, 2015 at 23:42 history asked iceman CC BY-SA 3.0