Complete.Org: Mailing Lists: Archives: freeciv-dev: August 2000:
[Freeciv-Dev] Re: client goto & patrol v2
Home

[Freeciv-Dev] Re: client goto & patrol v2

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: freeciv-dev@xxxxxxxxxxx
Subject: [Freeciv-Dev] Re: client goto & patrol v2
From: Jeff Mallatt <jjm@xxxxxxxxxxxx>
Date: Wed, 30 Aug 2000 17:33:02 -0400

The "goto line" is really neat!  But, there's a problem: the line is
visible as long as the destination is legal (over land on same continent),
and is not visible when the destination is illegal (over water or another
continent).  The line *is* visible even if the destination is unknown, as
long as it is legal.  This allows me to map an entire unknown continent
just by waving the mouse over the black area of the map, watching for when
the goto line is drawn.  I believe the easy solution to this is to not
allow goto's into the unknown.

Unfortunately, the "goto line" is almost invisible.  Perhaps if it were wider?

Also, why is the "goto line" not drawn when setting up a patrol route?  I
think it would be useful.

A bug in the patrol route handling:  If I put a caravan on patrol, and it
passes through a city, it does not stop at the city, but the "caravan
arrived" dialog pops-up.  Diplomats are also broken, in that the diplomat
stops, patrol state seems to get turned off and the "diplomat strategy"
dialog pops-up.

I like the graphics you did for patrol route, but they are very hard to see
in practice.  Perhaps, make them more yellow/brown (like the letters or the
fortify icon).  Also, they should be in the upper-right corner, where all
the other "activity" icons are.

The 'q' command needs to be added to the "Controls" section of the
data/helpdata.txt file.  (Gee, I'd like a better mnemonic, but we're
running out of keys :)

In control.[hc], the declaration and definition of request_unit_patrol
should specify an argument list of (void), not ().

In control.h, the request_unit_patrol declaration should be moved to after
request_unit_paradrop -- it's in lexical order.

In client/goto.c, change #include <stdio.h> to #include <string.h> --
needed by memset.

The biggest problem is that, somewhere between the shared visibility patch
and this patch, there's a bug which causes the client to core.  Could this
patch be made to not depend upon shared visibility?

In any case, when the next versions of the shared visibility and
goto/patrol patches are ready, I'll try to hunt down exactly why the client
is crashing.

jjm




[Prev in Thread] Current Thread [Next in Thread]