[G] Shift-click Tip vs. Terran - Page 7

On March 31 2011 01:16 Albrithe wrote:

This is a quote from the OP. If what I bolded is operating as intended by Blizzard, then the shift queuing makes sense (read: isn't a bug). When the SCV moves, the worker attacking it loses whatever command you gave it. So it cancels that attack command, and moves onto the next attack command.

Personally, I am not confident enough in my play to try this worker harass, but if it's as easy as shift queuing then I think I may start. Thanks OP.

On March 31 2011 00:49 TimeSpiral wrote:
The way it works now is such that your attack command is canceled after the SCV wanders. This is purposefully designed to help protect the SCV and give you a chance to respond. Shift clicking the attack command is bugged because you're essentially just issuing the same command multiple times.

On March 31 2011 01:40 Hairy wrote:

Says who? Says you?

The core of this whole debate rests upon whether or not Blizzard is happy with the current SCV targetting behaviour, and there's simply no way of knowing without asking them. Who knows if it's intentional (or desirable, in Blizzard's eyes) or not.

Melee units attacking a SCV building will go attack something else (or idle, in the case of workers) when the SCV moves. Is this intentional? Perhaps. Personally I think it's simply an artifact of the way the AI has been programmed, as melee can't reach the SCV unless it's near the edge; "I can't reach that SCV right now, so I'll cancel my attack command".

Perhaps a way to test if this is intentional would be to tell a RANGED unit to attack a building SCV and see what happens. If this targetting behaviour were really "to help protect the SCV and give you a chance to respond" we'd expect to see the exact same un-targetting behaviour in something like a marine.

On March 30 2011 05:45 lorkac wrote:
The SCV union hates you. You are now right below mutalisks and blueflame hellions as most hated.

On March 31 2011 01:40 Hairy wrote:

Says who? Says you?

The core of this whole debate rests upon whether or not Blizzard is happy with the current SCV targetting behaviour, and there's simply no way of knowing without asking them. Who knows if it's intentional (or desirable, in Blizzard's eyes) or not.

Melee units attacking a SCV building will go attack something else (or idle, in the case of workers) when the SCV moves. Is this intentional? Perhaps. Personally I think it's simply an artifact of the way the AI has been programmed, as melee can't reach the SCV unless it's near the edge; "I can't reach that SCV right now, so I'll cancel my attack command".

Perhaps a way to test if this is intentional would be to tell a RANGED unit to attack a building SCV and see what happens. If this targetting behaviour were really "to help protect the SCV and give you a chance to respond" we'd expect to see the exact same un-targetting behaviour in something like a marine.

On March 31 2011 01:36 TimeSpiral wrote:


The unit doesn't "forget." The attack command is canceled specifically.

Read the logic like this:

• Attack SCV (ID:1)
  
• IF SCV (ID:1) wanders THEN cancel Attack SCV (ID:1) command ELSE satisfy attack command
  

Now, for the bugged logic

• Attack SCV (ID:1)
  
• SHIFT + Attack SCV (ID:1)
  
• SHIFT + Attack SCV (ID:1)
  
• SHIFT + Attack SCV (ID:1)
  
• SHIFT + Attack SCV (ID:1)
  
• IF SCV (ID:1) wanders THEN cancel Attack SCV (ID:1) command ELSE satisfy attack command
  
  • The moment this conditional statement registers as TRUE then all instances of "Attack SCV (ID:1)" should be canceled because they are identical.
    
  
  

The logic is bugged and only the first instance of "Attack SCV (ID:1)" is canceled when in reality those redundant commands should not even be allowed to queue, and even if they are supposed to be allowed, since the command is canceled all identical instances should be canceled.

On March 31 2011 01:40 Hairy wrote:
Personally I think it's simply an artifact of the way the AI has been programmed, as melee can't reach the SCV unless it's near the edge; "I can't reach that SCV right now, so I'll cancel my attack command".

On March 31 2011 01:00 tsuxiit wrote:
Oh my god. Thank you. THANK YOU.

This is going to save me so many broken keyboard ragequits.

On March 31 2011 02:01 abominable wrote:
what's the big deal?

anyone with >20 apm could micro their worker to continue attacking the scv builder.

On March 31 2011 01:56 Albrithe wrote:


Sorry, I don't think I follow. Is this real game code? I don't see how canceling the attack command would cancel all attack commands queued. It may be my understanding of the way the game code works, but let me try an example.
I'm scouting the enemy's base on Steppes of War. I do a bunch of shift movement commands so I can go build a pylon in my base. However, in my hastiness I do one command behind his minerals, one off the map slightly, and the next back onto the map so that he travels along behind the mineral patch. My probe will go to the first command, then not be able to actually go to the location of the second command, so he moves onto the third command. Like I said, I very well may be stepping on my own dick here, but I don't see how these are different.

edit:
yeah, this is what I assumed.

On March 31 2011 01:52 TimeSpiral wrote:
Yes, says me, as I'm stating my argument.

If I'm wrong, then so be it. I have reported to the alleged bug to Blizzard and am awaiting a response.

I like your test, but I think there is a fundamental difference between a ranged unit and a melee unit, and even more so for a worker

so if one of those commands is canceled, by virtue of them being identical, all of them should be canceled.

On March 31 2011 02:07 Synystyr wrote:


Because when a worker comes to stop the harass, you won't be able to kill the building SCV because targetting becomes impossible when the SCV is practically inside the building, not to mention that the attacking worker will most likely die to the defending worker in the process.

Doing this is guarenteed damage. The defender either loses his worker or forces at least two SCVs to deal with the harass, which either loses mining time or construction time. All these little things matter in the early game.

On March 31 2011 02:13 Hairy wrote:

That's fine - the issue I have is that you're stating your opinion as fact. You have no evidence to support your claim that blizzard intentionally coded this to help protect SCVs while building. It's plausable, sure, but there's no way to prove that's the case until we hear something from Blizzard. It may well be the case that ALL of the current behaviour is exactly as they intended.

It would be equally valid to assume that units ceasing their attack on a building SCV when it moves is unintended behaviour, and THAT is the bug. Perhaps what should be happening is that when I tell my zergling/drone to attack your SCV it does so until that SCV dies.

Agreed. However, if a marine were to un-target a building SCV then that would be pretty good evidence in your favour.

On March 31 2011 01:36 TimeSpiral wrote:


The unit doesn't "forget." The attack command is canceled specifically.

Read the logic like this:

• Attack SCV (ID:1)
  
• IF SCV (ID:1) wanders THEN cancel Attack SCV (ID:1) command ELSE satisfy attack command
  

Now, for the bugged logic

• Attack SCV (ID:1)
  
• SHIFT + Attack SCV (ID:1)
  
• SHIFT + Attack SCV (ID:1)
  
• SHIFT + Attack SCV (ID:1)
  
• SHIFT + Attack SCV (ID:1)
  
• IF SCV (ID:1) wanders THEN cancel Attack SCV (ID:1) command ELSE satisfy attack command
  
  • The moment this conditional statement registers as TRUE then all instances of "Attack SCV (ID:1)" should be canceled because they are identical.
    
  
  

The logic is bugged and only the first instance of "Attack SCV (ID:1)" is canceled when in reality those redundant commands should not even be allowed to queue, and even if they are supposed to be allowed, since the command is canceled all identical instances should be canceled.

On March 31 2011 05:42 dAko wrote:
Nice find, just killed my first rax building scv without even looking at it :>