<URL: http://bugs.freeciv.org/Ticket/Display.html?id=39798 >

> [wsimpson - Sat Oct 27 09:22:54 2007]:
> I'm trying to understand the goto problem reports, and one common thread
> seems to be that folks are trying to use goto to explore.  Then, they
> complain that it won't goto an unknown location (PR#15629), or the trireme
> sinks, or the unit doesn't handle dangerous paths (PR#39697), or the unit
> chooses suboptimal paths as they change during the goto (PR#13348), or
> problems flying across unknown territory, or whatever.
> In effect, this is really a cheat!  They are trying to get the server to
> confirm information about places they don't know, or select good paths to
> places that are obscured by fog-of-war.

No it's not.  Client-side goto (which is what the user uses that shows
the path to be taken) knows only what the client knows and this does not
include anything more than what is shown.  Unless there's a specific bug
cheating is not possible; your words show you clearly don't understand
how client-side goto works.

What actually happens is that client-side goto assumes unknown tiles are
generic, non-dangerous, base-move-level tiles.  This means your triremes
and airplanes will happily goto over them and sink or whatever.

> I propose that whenever the goto is destined to an unknown location, the
> cursor change to "explore" (or X or something) and the turns disappear.
> The explore action should have a direction, and a destination.

Hiding the estimated number of turns in such situations is an option. 
But it's not a perfect fix as there are many instances where you want to
do goto with ships or goto just one tile into the unknown and you really
would want to see the number of turns.

> It could zig-zag for optimal exploration coverage (which it should be
> doing for AI units, anyway).

Doing a goto into/through the unknown is not actually an explore. 
Zig-zag is an option (previous versions of goto/pf have tricked the
search routine into taking diagonals) but again it's not a perfect
solution as many times you will want to take the shortest/safest route
possible.  And of course you can always zig-zag yourself using waypoints.

> The server would have to select a new path every turn (which it should be
> doing for AI units, anyway).

That is server goto.  Quite the opposite of client goto.  And yes that
is what's used for AI units.  Changing over from server to client goto
was quite a step forward (only with client goto can the path to be taken
be shown) and this isn't something that should be reverted.  Also server
goto is potentially buggy and tends to cheat.

> The orders list would be simplified, using the technique currently used
> for multi-part path selection.  (What, you didn't know that the current
> code allows a goto, followed by a road, followed by another goto, etc?
> Seems overly complicated, and undocumented, but it's in there....)

Undocumented, yes.  Incomplete, yes.  But if you want more complex
client goto (such as connect) that shows the path to be taken (highly
desirable for road-building and one of the most oft-requested features
before we implemented it) then this is the way it has to be done.  It's
also not overly complicated; the code was actually simplified to make
orders work that way.


Freeciv-dev mailing list

Reply via email to