2019-12-14 22:05 CET

View Issue Details Jump to Notes ] Related Changesets ]
IDProjectCategoryView StatusLast Update
0005825Spring engineGeneralpublic2017-11-04 11:28
ReporterGoogle_Frog 
Assigned Tohokomoko 
PrioritynormalSeverityminorReproducibilityalways
StatusresolvedResolutionfixed 
Product Version104.0 +git 
Target VersionFixed in Version 
Summary0005825: Fight command can bait units on hold position
DescriptionUnits with a fight command and hold position should not chase their automatically assigned target while there are still targets in range. This commit attempted to fix this issue: https://github.com/spring/spring/commit/ab61e51448ce4fd81c34bb465f4eff2296603e3f#diff-2e7bae8df3201d119e7e9009f566e695

This video demonstrates the bug: https://www.youtube.com/watch?v=WG4hbi7bzgg

I think the bug only reproduces when there is an enemy in range of the unit when the fight command is issued.
TagsNo tags attached.
Checked infolog.txt for Errors
Attached Files

-Relationships
+Relationships

-Notes

~0018590

Kloot (developer)

What an informative commit message.

~0018591

Google_Frog (reporter)

It is a shorthand for these two threads:
 * http://zero-k.info/Forum/Thread/22942
 * http://zero-k.info/Forum/Thread/24249

The issue appeared to be fixed. I suspect that the edge case in this ticket was not fixed.

~0018592

Kloot (developer)

Fix fc8f962ecf300a244ca5353a929e51a646495722 committed to develop branch: fix 0005825 (addendum to ab61e514)
reformat and refactor (some of) the pile of garbage that is MobileCAI, repo: spring changeset id: 9156

~0018600

Google_Frog (reporter)

Fight is now broken in a different way. The bug is still triggered by giving a fight command while enemies are in range.

See this video: https://www.youtube.com/watch?v=EwX87L7CPcA. Both fighting units are set to hold position.
 * The working fight behaviour is demonstrated from 0:50 to 1:25. The units assign themselves new targets when their target goes out of range. When all targets leave the units range they remove their target and keep moving towards the location of the fight command.
 * The broken fight behaviour is demonstrated from 1:35. Units never reassign their target after they have one assigned. The change in behaviour is that units never chase their target.

I'll attach my infolog in case you're interested in the weird graphical bugs.

~0018601

Kloot (developer)

the attack command remained because of global LOS.

it seems to me that "units with a fight command and hold position should not chase their automatically assigned target while there are still targets in range" should actually just be "units with a fight command and hold position should not chase their target" or the concept of hold position needs rethinking.

~0018602

Google_Frog (reporter)

The attack command did not remain in the working case. Look at 1:14, one tank left the range of the attacking units so they reassigned their attack command.

I should have been more clear and said "units with a fight command and hold position should not chase their target". The method by which they should not chase their target is that they should remove the attack command on their target when it leaves range (or when there is no free line of fire, being consistent with the working case should be fine). The current bug with fight is that units are not removing the attack command on their target when it leaves range.

~0018608

hokomoko (developer)

Fix 32e99836835f01058acf959b74749cf0b3cd4759 committed to develop branch: Fix 0005825, repo: spring changeset id: 9178

~0018609

hokomoko (developer)

Fix 341c77179e73cc4a2d6061f8e9a291e41816b643 committed to maintenance branch: Fix 0005825

(cherry picked from commit 32e99836835f01058acf959b74749cf0b3cd4759), repo: spring changeset id: 9179

~0018610

hokomoko (developer)

CMD_SET_MAX_WANTED_SPEED should die in fire, but I CBA to do this now
+Notes

+Related Changesets

-Issue History
Date Modified Username Field Change
2017-10-31 12:44 Google_Frog New Issue
2017-10-31 13:07 Kloot Note Added: 0018590
2017-10-31 13:17 Google_Frog Note Added: 0018591
2017-10-31 13:47 Kloot Assigned To => Kloot
2017-10-31 13:47 Kloot Status new => assigned
2017-10-31 18:41 Kloot Changeset attached => spring develop fc8f962e
2017-10-31 18:41 Kloot Note Added: 0018592
2017-10-31 18:41 Kloot Status assigned => resolved
2017-10-31 18:41 Kloot Resolution open => fixed
2017-11-02 07:19 Google_Frog Status resolved => feedback
2017-11-02 07:19 Google_Frog Resolution fixed => reopened
2017-11-02 07:19 Google_Frog Note Added: 0018600
2017-11-02 07:19 Google_Frog File Added: infolog.txt
2017-11-02 12:50 Kloot Note Added: 0018601
2017-11-02 13:15 Google_Frog Note Added: 0018602
2017-11-02 13:15 Google_Frog Status feedback => assigned
2017-11-04 11:22 hokomoko Changeset attached => spring develop 32e99836
2017-11-04 11:22 hokomoko Note Added: 0018608
2017-11-04 11:22 hokomoko Assigned To Kloot => hokomoko
2017-11-04 11:22 hokomoko Status assigned => resolved
2017-11-04 11:22 hokomoko Resolution reopened => fixed
2017-11-04 11:24 hokomoko Changeset attached => spring maintenance 341c7717
2017-11-04 11:24 hokomoko Note Added: 0018609
2017-11-04 11:28 hokomoko Note Added: 0018610
+Issue History