View Issue Details

IDProjectCategoryView StatusLast Update
0002083Spring engineGeneralpublic2019-02-21 12:30
Reporterslogic Assigned ToKloot  
PrioritynormalSeverityminorReproducibilityalways
Status resolvedResolutionfixed 
Product Version0.82.5 
Fixed in Version0.82.3+git 
Summary0002083: Unit don't stop moving to unreachabe place
DescriptionSee screenshot. Unit don't stop in this situation. Kloot told me the algo: if unit can't achieve positive speed for 8 sec it will stop. It is not working or positive speed threshold is too small.

Map is Victoria Crater.
TagsNo tags attached.
Attached Files
screen00084.png (Attachment missing)
Mantis2083.png (Attachment missing)
Mantis2083B.png (Attachment missing)
screen00085.png (Attachment missing)
Checked infolog.txt for Errors

Activities

Kloot

2010-09-04 17:58

developer   ~0005438

BA's armcom *can* actually cross that ridge in both directions (see the blue line in Mantis2083.png), but it and the move order need to be positioned just right. I'm not sure if a unit should stop in this case or keep trying to find the narrow corridor where its slope tolerance allows passage.

slogic

2010-09-04 18:14

reporter   ~0005439

Last edited: 2010-09-04 18:14

So complicated. If there is a path why not to directly pass it? I understand that pathgraph (or mesh) has lower resolution than map. But I don't understand how commander is sure it can pass there while not passing it actually? Visually I see no passage there.

Kloot

2010-09-04 19:03

developer   ~0005440

Last edited: 2010-09-04 19:07

There are in fact multiple passages (Mantis2083B.png, slightly changed the visualisation function).

And yes, this happens exactly because not all engine code operates at the same resolution, therefore units can get stuck on non-passable tiles even when their paths only touch passable squares.

slogic

2010-09-05 14:12

reporter   ~0005448

What will you say about screen00085.png situation? Problem is the same but there is no passage at all.

Kloot

2010-09-05 15:35

developer   ~0005452

That is indeed a bug (caused by some hardcoded distance check). Fixed with 351aef.

Kloot

2019-02-21 12:30

developer   ~0019756

Fix 351aef666f49f8e3f848321b0adcffb9513d30c6 committed to develop branch: * fix 0002083 (units ignored ETA failures when <= 200 elmos from goal, even if goal unreachable), repo: spring changeset id: 11476

Issue History

Date Modified Username Field Change
2010-09-04 17:32 slogic New Issue
2010-09-04 17:32 slogic File Added: screen00084.png
2010-09-04 17:55 Kloot File Added: Mantis2083.png
2010-09-04 17:58 Kloot Note Added: 0005438
2010-09-04 17:59 Kloot Status new => feedback
2010-09-04 18:14 slogic Note Added: 0005439
2010-09-04 18:14 slogic Note Edited: 0005439
2010-09-04 18:58 Kloot File Added: Mantis2083B.png
2010-09-04 19:03 Kloot Note Added: 0005440
2010-09-04 19:07 Kloot Note Edited: 0005440
2010-09-04 19:18 Kloot Severity major => minor
2010-09-05 14:11 slogic File Added: screen00085.png
2010-09-05 14:12 slogic Note Added: 0005448
2010-09-05 15:35 Kloot Note Added: 0005452
2010-09-05 15:36 Kloot Status feedback => resolved
2010-09-05 15:36 Kloot Fixed in Version => 0.82.3+git
2010-09-05 15:36 Kloot Resolution open => fixed
2010-09-05 15:36 Kloot Assigned To => Kloot
2019-02-21 12:30 Kloot Changeset attached => spring develop 351aef66
2019-02-21 12:30 Kloot Note Added: 0019756