HostedRedmine.com has moved to the Planio platform. All logins and passwords remained the same. All users will be able to login and use Redmine just as before. Read more...
Bug #856360
open
Middle-click display of Go-To-orders stops short of city (3.0.0-alpha3+, various clients)
0%
Description
No savegame for this bug. You can use any savegame for any client. Select a land unit that has used up it's moves. Give him a Go To order to a normal empty land tile. Then middle-click on the unit and you get to see his order. All clients get this right and you see the path the unit will take and the destination tile boxed.
If you change the destination of the Go To order to a city or to a tile containing units, then the clients will display bugs when you 'show' the order by middle-clicking on the unit. When they get it wrong, they show the penultimate tile (in the path) boxed (as though it is the destination).
This is all 3.0.0-alpha3+. When I say 'right' I mean that the displayed order puts a box around the (correct) last tile. When I say 'wrong' I mean that the displayed order puts a box around the (incorrect) penultimate tile.
gtk3.22, gtk3, gtk2 and qt clients all get go-to-other-players-city and bribe-other-players-unit right and go-to-own-city and join-own-unit wrong.
This is so consistent that it makes me feel that it is intentional, but I can't see the point of displaying an order as ending one tile too early.
Files
| 30_goto_city.png (269 KB) 30_goto_city.png | S3_0 gtk3.22 civ2civ3; Caravan has orders to go into top city | ||
| diplomat-orders.png (207 KB) diplomat-orders.png | |||
| diplomat-join-stack.png (270 KB) diplomat-join-stack.png |
Updated by Jacob Nevins almost 5 years ago
- File 30_goto_city.png 30_goto_city.png added
- Sprint/Milestone set to 3.0.0
Reproduced, I think. Screenshot attached, with a caravan to own city. (By "boxed" I see the yellow 'user.attention' sprite, which is next to the target city, not any of the cyan 'path.*' sprites.)
I'm guessing this is somehow to do with the last step in the path being (at least potentially) an action rather than a movement.
I don't see the same with S2_6 (at least with a Caravan).
Updated by Chippo Elder almost 5 years ago
Jacob Nevins wrote:
Reproduced, I think.
Correct. I described the problem terribly (I didn't think of a screenshot), but your screenshot is exactly what I was trying to explain.
Updated by Chippo Elder almost 5 years ago
Jacob Nevins wrote:
I'm guessing this is somehow to do with the last step in the path being (at least potentially) an action rather than a movement.
Oh, absolutely! I incorrectly saw the pattern as your-own vs other-player and unit vs city. Until I tried an ally as other-player. In all cases where it gets it right, there is an action at the end (bribe, attack, do-trade-stuff). Except for the case where the destination is an empty tile, where it also gets it right.
I've tried almost every unit/destination-tile option possible.
Updated by Jacob Nevins almost 5 years ago
- Subject changed from Display of Go-To-orders bug (3.0.0-alpha3+, various clients) to Middle-click display of Go-To-orders stops short of city (3.0.0-alpha3+, various clients)
Updated by Jacob Nevins almost 5 years ago
I am slightly suspicious of *dest_tile = tile_index(old_tile) (which ends up in punit->goto_tile) at the end of make_path_orders() -- if final_order is an order with a direction, then the destination of that direction won't end up in *dest_tile.
But I haven't thought about it very hard.
Updated by Chippo Elder almost 5 years ago
- File diplomat-orders.png diplomat-orders.png added
- File diplomat-join-stack.png diplomat-join-stack.png added
Jacob Nevins wrote:
I don't see the same with S2_6 (at least with a Caravan).
Nor me. I've tested most possibilities (haven't researched the tech to test all) in S2_6 and they look pretty good.
Like in the attached diplomat-orders pic, that is perfect. Since S2_6 doesn't have Go-to-and, here it's completely unambiguous - the diplomat can't enter the city, but is going to perform an action on it.
However, in the attached diplomat-join-stack pic (also S2_6), it's almost perfect. You might not notice the error, if you aren't looking for faults. Strictly speaking, there should be the last bit of cyan going into the destination tile because the diplomat will actually move onto that tile.
Updated by Sveinung Kvilhaugsvik almost 5 years ago
Chippo Elder wrote:
Strictly speaking, there should be the last bit of cyan going into the destination tile because the diplomat will actually move onto that tile.
Note for anyone trying to implement this: Be aware that some actions won't move the actor unit to the target tile. It is non deterministic in some cases.
Updated by Chippo Elder almost 5 years ago
Also seen in S3_0 (3.0.0-alpha3+ (23e4b52eca)).
Updated by Marko Lindqvist almost 3 years ago
- Sprint/Milestone changed from 3.0.0 to 3.0.1
Updated by Marko Lindqvist over 2 years ago
- Sprint/Milestone changed from 3.0.1 to 3.0.2
Updated by Marko Lindqvist over 2 years ago
- Sprint/Milestone changed from 3.0.2 to 3.0.3
Updated by Marko Lindqvist over 2 years ago
- Sprint/Milestone changed from 3.0.3 to 3.0.4
Updated by Marko Lindqvist about 2 years ago
- Sprint/Milestone changed from 3.0.4 to 3.0.5
Updated by Marko Lindqvist almost 2 years ago
- Sprint/Milestone changed from 3.0.5 to 3.0.6
Updated by Marko Lindqvist almost 2 years ago
- Sprint/Milestone changed from 3.0.6 to 3.0.7
Sveinung Kvilhaugsvik wrote in #note-7:
Chippo Elder wrote:
Strictly speaking, there should be the last bit of cyan going into the destination tile because the diplomat will actually move onto that tile.
Note for anyone trying to implement this: Be aware that some actions won't move the actor unit to the target tile. It is non deterministic in some cases.
So we likely would need some utility functions (-> dependency tickets) to determine whether to expect unit to enter target tile or not.
Updated by Marko Lindqvist over 1 year ago
- Sprint/Milestone changed from 3.0.7 to 3.0.8
Updated by Marko Lindqvist 8 months ago
- Sprint/Milestone changed from 3.0.8 to 3.1.1
.
