Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Turreted units do not target enemy units while moving #16540

Open
Punsho opened this issue May 14, 2019 · 7 comments

Comments

Projects
None yet
4 participants
@Punsho
Copy link
Contributor

commented May 14, 2019

It's difficult to reproduce the bug by your self. He's the steps:

  1. Open 2 clients
  2. On one build a light tank. On the other build 2 apc's
  3. Attack one apc with the light tank while moving (you have to click on the apc). Key here is to never stop turning/moving
  4. Go away from the apc until it's under fow
  5. Engage the light tank with the second apc
  6. The light tank will not target it nor it will target anything else you send his way apart the the original apc.
    I'm repeating again, once the light tank stops. The bug goes away.

OpportunityBug

@abcdefg30 abcdefg30 added the Bug label May 14, 2019

@Punsho Punsho changed the title Opportunity fire + fow bug A turreted unit does not target enemy units while on the move May 18, 2019

@Punsho Punsho changed the title A turreted unit does not target enemy units while on the move Turreted units do not target enemy units while on moving May 18, 2019

@Punsho Punsho changed the title Turreted units do not target enemy units while on moving Turreted units do not target enemy units while moving May 18, 2019

@matjaeck

This comment has been minimized.

Copy link
Contributor

commented May 18, 2019

It looks like the tank is not dropping the target correctly. With this setup it is easy to reproduce:

Note the facing of the light tank. Give an attack order, then spam normal move orders.

Peek 2019-05-18 22-14

@Punsho

This comment has been minimized.

Copy link
Contributor Author

commented May 18, 2019

move orders don't need to be spammed

@matjaeck

This comment has been minimized.

Copy link
Contributor

commented May 18, 2019

@Punsho can you reproduce this on bleed? I can not.

@Punsho

This comment has been minimized.

Copy link
Contributor Author

commented May 18, 2019

I can reproduce it easily on bleed

@pchote

This comment has been minimized.

Copy link
Member

commented May 19, 2019

Can you please upload a replay based on bleed (you'll also need to mention which commit it is based on) demonstrating the bug?

@Punsho

This comment has been minimized.

Copy link
Contributor Author

commented May 19, 2019

Here's a replay in skirmish. Last merged pr #16561. Just rename the ending .zip to .orarep
TurretBug.zip

@pchote

This comment has been minimized.

Copy link
Member

commented May 19, 2019

Thanks.

This happens when

public override void OnQueueAttackActivity(Actor self, Target target, bool queued, bool allowMove, bool forceAttack)
{
// If not queued we know that the attack activity will run next
// We can improve responsiveness for turreted actors by preempting
// the last order (usually a move) and set the target immediately
if (!queued)
{
RequestedTarget = target;
RequestedForceAttack = forceAttack;
RequestedTargetLastTick = self.World.WorldTick;
}
}
sets RequestedTarget while the actor is still moving, and the queued attack activity is cancelled before it has a chance to tick. The RequestedTarget therefore stays set, blocking the opportunity fire logic from working.

I have a workaround in mind for this, so adding to the milestone.

@pchote pchote added this to the Next Release milestone May 19, 2019

@pchote pchote self-assigned this May 19, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.