Complete.Org: Mailing Lists: Archives: freeciv-dev: December 1999:
[Freeciv-Dev] At long last: the Worklist patch
Home

[Freeciv-Dev] At long last: the Worklist patch

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: freeciv-dev@xxxxxxxxxxx
Subject: [Freeciv-Dev] At long last: the Worklist patch
From: Corin Anderson <corin@xxxxxxxxxx>
Date: Wed, 22 Dec 1999 19:04:26 -0800 (PST)

Hello folks!

  I've been hinting that it's been coming for some time.  Well, it's
finally here:  my Worklist patch.  This patch adds the city build queues
to both the Xaw and Gtk clients.  Uncompressed, the patch is big -- about
162K.  Compressed, it fits under 30K, so I've attached it to this message.
Let me know if it doesn't get sent properly.

--- Play features ---

There are actually two "play" features in this patch:  worklists are added
and the shield stock penalty rules have been revised (this revision was
motivated by http://arch.freeciv.org/freeciv-dev-199909/msg00213.html and
promised by http://arch.freeciv.org/freeciv-dev-199909/msg00235.html).  
I'll hit the less exciting one first.

SHIELD STOCK

Under the old rules, when a player changed the build target "flavor" of a
city (ie, unit -> improvement, or wonder -> unit), the city would lose
half its shield stock because of the switch.  Moreover, if a player
changed flavors many times in a single turn, he or she could watch as the
shield stock was cut in half each time, until nothing remained.  I've
changed this behavior somewhat.  Two new rules replace the old rule:

* A city is never assesed more than one "one-half shield stock loss" per
  turn.  If a player changes a city's build target many times in a single
  turn, then only the first switch is penalized.
* A city is -not- assessed -any- penalty if the build target is switched
  in the same turn that a city produces something.  For instance, if a
  city has just completed building a temple, and has 4 shields left over
  from the process, and the player switches the city to bulid settlers,
  then the city will -not- lose 2 shields in the process.


WORKLISTS

This feature is my little pride and joy.  With a worklist, you can
pre-program a city to build an entire list of targets, instead of just
repeating the last unit, or changing to some suggested improvement.  Gone
are the days of forgetting to change a city's target "next turn" or having
to hand-hold a city through some crucial four-target sequence of temple,
settlers, granary, and settlers.

Each city has its own worklist, which you can view by clicking on the
Worklist button in the city dialog (remember, this feature has been added
to both the Xaw and Gtk client; sorry, no mui support. 8(  ).  On the left
side of the worklist edit dialog is the city's current worklist, with the
current target at the head of the list.  On the right is a list of the
available targets to add to the worklist.  If nothing is selected on the
left when you insert a new target, the new target is appended to the
worklist.  To insert a target in the middle of the worklist, select the
point after which you want the new target to appear, then click insert.
To commit the worklist, click Close.  Whatever target is at the top of the
worklist when you commit will be seleceted as the city's new current
target.

A player also has a number of "global" worklists that are defined for the
entire empire.  You can access the list of global worklists by selecting
Worklists from the Kingdom menu.  You can create, delete, rename, and edit
global worklists from this dialog.  Note that, when editing a global
worklist, -all- targets are listed, not just the ones that you can
presently build.  I've chosen this option to allow a player to define
worklists for the whole game all at once, up front.  I'm mulling over
other filter options, though; stay tuned.

Global worklists are largely a convenience for managing city worklists.
When you edit a city worklist, the names of all the global worklists will
appear at the end of the Available Targets list in the city worklist
dialog.  If you insert a global worklist, you will _copy_ the global
worklist's contents into the city's worklist.  There is no support for
linking city worklists to global worklists.  If there is a call for such a
feature, I'll look into it; however, I find that I don't ever want to have
a linked worklist -- copying is actually the preferred option.


<toot horn="my own">I've been playing games with the worklists since I
coded the first version of them in September.  I won't play a game with
the "stock" Freeciv client anymore -- worklists are too useful!</toot>


--- Code features ---

Worklists are implemented with code on both client and server.  On the
client, obviously, I've added code for the worklist dialogs for the Xaw
and Gtk clients.  However, most of the "interesting" code actually exists
on the server -- I've coded worklists to be processed on the server,
without the need for client intervention.  This way, if the client is
disconnected for some number of turns, your empire will continue to chug
away under your fine pre-established leadership.

I've added a new event type, E_WORKLIST, so that the client can be
notified of worklist events (either as the city changes its build target
because of the worklist, or if the worklist empties out).  I've also added
two new packet (request) types, for the CITY_WORKLISTs and
PLAYER_WORKLISTs, and augmented the packet structs for players and cities
as necessary.  I've added "+worklist" to the capability string because
these changes are pretty widespread.  (If there's call for it, I could
change this to "worklist" -- without the + -- to allow non-worklist
clients to play with a worklist server or vice versa.  It won't be fun,
but if need be, I'll do it.)

Worklists are persistent across game saves/loads -- the worklists are
stored in the saved game file.  As such, old saved games are -not-
compatible with the worklist-enabled server.  It would be easy enough to
write a tool that converted .sav files to include worklist info, if
there's interest.


--- Patch features ---

I've made this patch against the latest CVS version (ie, the 12.22.99 CVS
repo data).  The patch expects that the Freeciv code lives in a freeciv/
subdirectory beneath the current directory.

I've included in my diff a patch for all the files I've modified that are
also in CVS.  In particular, my diff includes patches for auto-generated
code (Makefile.am's, Freeciv.h).  I've included these patches because
they're in CVS, but if I shouldn't have, please let me know.  (Why are the
auto-gen'd files in CVS, anyway?  Shouldn't they be built only as part of
the config or make process, and not actually in the repo?)  Of course,
I've made the appropriate changes to the "source" files for these
auto-created files, too.

I've been playing with worklists for some time, and I can confidently say
that I don't think there are any serious bugs in the code.  Of course, if
I'm proven wrong, I'll fix what's broken.  There are a few known "issues"
that I'll look at when I get a chance, but they're not serious.



Corey

Attachment: worklist-1.9.0+.patch.gz
Description: Binary data


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