EPTPart 1:
+ Show Spoiler [show video] +
Explanation: This is just another variation of the target switch glitch.
Let's go through it step by step.
- The Zealot has the near Marine assigned as target and goes throught its attack loop iscript (iscripts are scripts coding the sequence of sprites and triggered events during animations on a frame-by-frame basis). For a Zealot it follows the rough structure attack1–wait–attack2–(repeat after remaining cooldown).
- The first Marine dies after one attack, the second Marine attacks the Zealot at the same time. The loss of its target and the forced prioritizing of attacking units in target selection lets the Zealot switch target immediately – while still stuck in its attack state.
- The second attack hits (and kills) the second Marine, because range checks are only applied before an attack iscript is initiated, not while it is running.
+ Show Spoiler [Show video (featuring Artosis having n…] +
Note: Also note how Tanks are explicitly exempt from self-damaging!
Part 2:
+ Show Spoiler [show video] +
Explanation: The explanation in this case is rather trivial, let's go through the observable sequence of events:
- The Arbiter moves in and attacks an SCV, so we know it was right-clicked on it and in an attack state
- Right after the projectile is released the Recall animation occurs. The only unit attacking the Arbiter at this point is a Turret right behind it.
- Shortly after the Arbiter starts moving again – in the direction of the Turret, not away from it, or attacking it or the SCV. So even without bothering which orders and order priorities it was on before, we know that it must have been issued a new movement command.
Conclusion: Issuing a new movement command too early canceled the execution of the Recall half-way through – always use shift-commands after issuing a spell cast command.
Additional tip: Make sure there is no unwalkable terrain below the centre of the Arbiter at the end of the Recall – even something like a small doodad will prevent the execution of the placing-units part of it, even though there might be plenty of free space around otherwise.
Part 3:
+ Show Spoiler [show video] +
Explanation: The explanation here is quite clearly that the Tank was issued a siege command while overlapping its collision box with that of the Turret next to it. You can see the Tank move slightly downwards right after it was unsieged, which probably caused the collision, even though the exact mechanism behind this is not so clear. I guess the combination of rotation and forward movement of the Tank means that it did not fail a forward collision check that it should have failed. After that there is probably just not enough time to get it "unstuck" before it gets sieged again.
With the replay files it would be possible to run them through OpwnBW and see exactly frame by frame what happened.
EDIT: Part 5:
+ Show Spoiler [show video] +
So here's everything you never wanted to know about Larvae, graciously compiled by Ankmairdor:
Ankmairdor on SSCAIT discord wrote:
Actually it's more complex.
There is an array of 4 int, one for each side of the hatchery (left, top, right, bottom). Each time a mineral harvest is returned it subtracts 1 (if more than 0) from all values and adds 25 (if less than 100) to the side of the hatchery that it returned the minerals to.
When a larva needs to be spawned, the sides are checked in the order (bottom, left, right, top) for the side with the lowest score(equal scores prefers the current best). A side is disqualified if the larva would spawn out of bounds, off creep, on another building, or on unwalkable tile.
If a best side is chosen, then the larva will spawn in the center of that side of the hatchery with an offset of 10 from center of larva to edge of hatchery.
Otherwise, each side gets two spawn locations, one at each end of that side of the hatchery, and the process repeats with the same order of sides. For each side the left-most or top-most side is checked first.
For larva movement, when they are spawned they are given an order state corresponding to the side they spawned on. They will always prioritized moving towards their connected hatchery so that they are no more than 10 edge-to-edge distance away. Otherwise they will wander randomly along that side.
For each larva wander, the larva gets a random value. They will wander 10 left so long as this value does not have the 8 bit set, otherwise 10 right. They will wander 10 up so long as this value does not have the 128 bit set, otherwise down 10. If the new wander position would take the larva outside of it's designated side of the hatchery, then it will stay where it is.(though it can wander away from the hatchery till next wander)
The larva trick works by setting the order state to 0, which corresponds to the wander designation for the left side of the hatchery. More specifically, the stop command instantly finishes causing an order update, which always resets the order state. Larva wandering never finishes.
Actually it's more complex.
There is an array of 4 int, one for each side of the hatchery (left, top, right, bottom). Each time a mineral harvest is returned it subtracts 1 (if more than 0) from all values and adds 25 (if less than 100) to the side of the hatchery that it returned the minerals to.
When a larva needs to be spawned, the sides are checked in the order (bottom, left, right, top) for the side with the lowest score(equal scores prefers the current best). A side is disqualified if the larva would spawn out of bounds, off creep, on another building, or on unwalkable tile.
If a best side is chosen, then the larva will spawn in the center of that side of the hatchery with an offset of 10 from center of larva to edge of hatchery.
Otherwise, each side gets two spawn locations, one at each end of that side of the hatchery, and the process repeats with the same order of sides. For each side the left-most or top-most side is checked first.
For larva movement, when they are spawned they are given an order state corresponding to the side they spawned on. They will always prioritized moving towards their connected hatchery so that they are no more than 10 edge-to-edge distance away. Otherwise they will wander randomly along that side.
For each larva wander, the larva gets a random value. They will wander 10 left so long as this value does not have the 8 bit set, otherwise 10 right. They will wander 10 up so long as this value does not have the 128 bit set, otherwise down 10. If the new wander position would take the larva outside of it's designated side of the hatchery, then it will stay where it is.(though it can wander away from the hatchery till next wander)
The larva trick works by setting the order state to 0, which corresponds to the wander designation for the left side of the hatchery. More specifically, the stop command instantly finishes causing an order update, which always resets the order state. Larva wandering never finishes.
Ankmairdor on SSCAIT discord wrote:
[…] If they have no move target, larva pick 1 of 4 random diagonal positions to wander towards. If at the end of that wander they are more than 10 distance from the hatchery, then they will return straight back to it. For this glitch the 2 rows/columns(may only happen on bottom) of tiles must be similar to this(Creep, Hatchery, No creep):
C H H H H C
C N N N N C
The larva can partially occupy the H tiles in this example. Thus they can travel diagonally from H to the corner C over a N. Though they only notice the N tile when they are returning to the H tile cause they wandered too far.
[…] If they have no move target, larva pick 1 of 4 random diagonal positions to wander towards. If at the end of that wander they are more than 10 distance from the hatchery, then they will return straight back to it. For this glitch the 2 rows/columns(may only happen on bottom) of tiles must be similar to this(Creep, Hatchery, No creep):
C H H H H C
C N N N N C
The larva can partially occupy the H tiles in this example. Thus they can travel diagonally from H to the corner C over a N. Though they only notice the N tile when they are returning to the H tile cause they wandered too far.
Ankmairdor on SSCAIT discord wrote:line 6246 in bwgame.h is where larva behavior is […]
I sincerely hope all your answers are hereby questioned.
