Project

Profile

Help

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 #647612

Can't enter transport if transport has G state (Go to)

Added by bluss contributor about 4 years ago. Updated 3 months ago.

Status:
Closed
Priority:
Normal
Category:
Client
Sprint/Milestone:
Start date:
Due date:
% Done:

0%

Estimated time:

Description

Using Gtk 3 client. Setup: A transport has 0 moves left and is in the G state (goto with moves left to go). Can't use Go to to enter the transport.

(I don't know if this is client specific).

Freeciv version 2.5.6 gui-gtk-3.0 (debian)

History

#1 Updated by Marko Lindqvist about 4 years ago

Do you have a savegame from which to reproduce this?

#2 Updated by Sveinung Kvilhaugsvik about 4 years ago

Am I correct in assuming that moving the unit on board with the arrow keys or the numpad works?

#3 Updated by Sveinung Kvilhaugsvik about 4 years ago

Savegame where this can be reproduced.

#4 Updated by bluss contributor about 4 years ago

Thanks. Sorry about now providing a savegame. With no numpad, I hadn't considered any other way of moving units than goto in fact.

#5 Updated by Jacob Nevins about 4 years ago

This is a consequence of the check in pf_tools.c:pf_potential_unit_class_transport() for unit_has_orders(). Removing that check fixes the symptom.

That was added in svn r24889 (gna bug #21871) in order to stop pathfinding treating transports as pontoon bridges if they were on their way elsewhere and would not be there long enough to allow the unit to cross.

In order to preserve that behaviour while fixing this bug, we probably need to treat it as a special case if it's the last step of a route, or something.

#6 Updated by Jacob Nevins over 1 year ago

  • Category changed from gui-gtk-3.22 to Client

This is a consequence of the check in pf_tools.c:pf_potential_unit_class_transport() for unit_has_orders(). Removing that check fixes the symptom.

That code only exists on S2_5. In later branches, the code looks different.

Gna bug #21871, where the code I mentioned was added, says "During review of patch #3901, pepeto and I decided to only fix this in S2_5, and address this issue in a different manner in that patch."

The symptom remains on S2_6 and later branches. On those branches, pf_tools.c has calls to unit_has_orders() in pf_transport_check(). I haven't investigated further.

#8 Updated by Marko Lindqvist 3 months ago

  • Sprint/Milestone changed from 2.6.4 to 2.6.5

#9 Updated by Marko Lindqvist 3 months ago

  • Status changed from Resolved to Closed
  • Assignee set to Marko Lindqvist

#10 Updated by Christian Knoke 3 months ago

Hello,

not sure this is the right fix.

Bug #647612: Can't enter transport if transport has G state (Go to)

the original code blocked the GoTo, if the unit sent wouldn't reach its target in one (this) turn, so to avoid a GoTo command to a target which most probably did not exist any more, when the target eventually would reach it. (Or even worse, another ship is laying there).

GoTo can be used, still, when you reach the ship/target in the same turn, but this is rarely true with using pontons.

Regards,

Christian

Using Gtk 3 client. Setup: A transport has 0 moves left and is in the G
state (goto with moves left to go). Can't use Go to to enter the
transport.

#11 Updated by Marko Lindqvist 3 months ago

Sigh. Ticket has been open for four years, and a patch in review for a month, and still we get comments only (immediately) after it has been pushed in. Not to blame anyone, I myself often miss the review and see things only after they have already gone in, but this one was a bit frustrating.

Well, the old code did not allow entering transport that has GoTo status with GoTo even on the same turn. Reproducing that was the first thing I did when I started working on the patch.

You may have a valid point of multi-turn goto behaving worse with this patch than before. Needs testing of different scenarios. OTOH it should be obvious to the user that attempt to load unit to a transport that will move away before it will fail. Remember that we talk about the transport being the final destination of the goto, not some longer route being planned through it.

#12 Updated by bluss contributor 3 months ago

Hey Marko, thanks a lot for fixing the bug I reported :)

#13 Updated by Marko Lindqvist 3 months ago

Marko Lindqvist wrote:

You may have a valid point of multi-turn goto behaving worse with this patch than before.

Tested it, and yes, it's now possible to request multi-turn goto to enter transport despite it certainly failing as transport will move away. Open a new ticket about that if you see that as a problem.
In any case I see the problem that has been fixed more important one than the regressions caused (so should not revert this), as some people, especially in UIs geared towards it, like to consistently do all the unit movement with goto. It should be possible to do the loading to transport in adjacent tile with goto.

Also available in: Atom PDF