civil-devel Mailing List for Civil

Hi...

Firstly, a big pat on the back to everyone for getting Civil to 0.50. =
It's been a long road, and it's taken more time than expected to =
traverse it, but I for one have a big smile on my face today, as I know =
we're on the downhill run from here... I'd just like to thank you all =
for the hardwork and commitment you've all put in to date.

It'll be more than worth it in the long-run...

Here's to 1.0 and the infamy that awaits us all... :)


Secondly, given the core of 0.6 is a sound-related push, I'm gonna work =
pretty much exclusively on SFX related issues for the next couple of =
months. Basically this is a tune for the front-screens (not sure *what* =
this is gonna be like yet) and the in-game ambient background SFX, plus =
related command SFX...

As and when you need a sample, post the list and I'll try and source =
something. We need some pretty clear visual/sonic feedback to the player =
that things are going on, so I'm not afraid of having a big stash of =
samples to call on. Dialog stuff is fairly easy, but in-game I'm open to =
suggestions...

It'd also be nice if one of our American brethren would commit to =
providing some speech for the game. Anyone got a convincing =
northern/southern accent and a microphone? I think this would be a nice =
touch, and to paraphrase some actor bloke "It'll make you famous"...

So, if there are no arguments, I'll kill my dev server, install 98 and =
the suite of editing tools I've "acquired" and attempt to annoy the =
neighbours with the click/gallop/gun fire sounds emanating from the =
computer room...

G

Hi again,

I was thinking a bit about the issue with ending games. Currently games
are ended just fine when some condition is satisfied. However, there's no
way to know *how* the game ended on the client side, more than that it
ended. So I was wondering wether anyone has any good ideas for the
following htings that need to be done:

    * notify clients of ended games (works)
    * tell the clients why it ended
    * calculate a victory score
    * present the different endings to the player

The second bullet could be achieved by just adding a flag to the
EndGameCmd that says what caused the game to end. Possibilities are
currently: time runs out, all units destroyed or demoralized.

The third bullet is just a claculation that takes some specific things
into account. These are among others objectives, destroyed units, guns and
men. It should be fairly simple to do that and then figure out some nice
ratio of the player's scores and use that to determine the winner.

The fourth needs some new end-game screens and thus some extra gfx, which
I think Gareth is already working on. The screens need to give the player
the needed information about how the game went. Later versions can also
include more detailed statistics, such as exact numbers of killed med in
all units etc. A simple version needs just give some basic statistics and
a winner.

Does this sound good? The actual code isn't really that hard to implement.
Any comments?


-- 

 He says gods like to see an atheist around. Gives them something to aim at.
                                            -- Terry Pratchett, Small Gods

Hi all,

The subject says it all. We can fix small bugs and add features forever,
so I played Linus and decided we tag 0.50 now. The nice codename for this
release is "0.50" and the symbolic tag is CIVIL-0_50.

The road to 0.60 is easier, and some parts are already done. Just because
we have a TODO-list with stuff for the various versions does not of course
mean that we *must* do stuff in that order. Feel free to do what feels fun
or interests you. I will try to work on the things that are needed for
0.60. :)

-- 

 He says gods like to see an atheist around. Gives them something to aim at.
                                            -- Terry Pratchett, Small Gods

I looked into the unit modes and combat a little bit, and found a few
missing bits and pieces. I noticed that no combat plan (skirmish, assault
and attack) did set the unit into proper modes. At least not fully.

So I added some mode handling, and especielly made the plans set the
proper idle mode *after* the combat had finished. This means that units
should now be eligible for more automatic combat.

Gee, we shouldn't really dig too deep, we'll just open up an unlimited
number of Pandora's boxes with lots of worms in 'em. :)

-- 
  "You can't trample infidels when you're a tortoise. I mean, all you could
                  do is give them a meaningful look."
                                              -- Terry Pratchett, Small Gods

On Tue, 30 Oct 2001, Gareth Noyce wrote:

>Apparently it's sourceforge's new policy. In a 
>reply they sent to Crash it was stated that we 
>should "learn to use our user agents reply to 
>all"...
>
>Sounds like a bunch of arse to me...

Yeah, why should it be a problem? Well, seems we'll have to remember to
make sure the To: line is ok before sending.

>BTW, I'm back after my Birthday Hiatus! Slowly 
>recovering from the worlds biggest hangover. :-/

Now that was some serious birthday partying... :)

-- 
  "You can't trample infidels when you're a tortoise. I mean, all you could
                  do is give them a meaningful look."
                                              -- Terry Pratchett, Small Gods

> As for the "Reply-To", I did fix it a few weeks 
> ago, and it worked fine
> for a while. Now they must've done something 
> again, so I'll go check
> the
> setting.

Apparently it's sourceforge's new policy. In a 
reply they sent to Crash it was stated that we 
should "learn to use our user agents reply to 
all"...

Sounds like a bunch of arse to me...

Anyway, don't expect the list to get a reply-to 
back for a while if that really is the case.

BTW, I'm back after my Birthday Hiatus! Slowly 
recovering from the worlds biggest hangover. :-/

--
"Microsoft is like Islam; it is unwise to 
criticise either in print"

    -- Anonymous XBox Developer. Edge - Issue #102
--

-------------------------------------------------
This mail sent through UK Online webmail

On 29 Oct 2001, Michael Earl wrote:

>Chakie writes:
>>Well, this can't actually happen. The code is absolutely ok, and works
>>fine for me. 
>
>um, yeah.  I submitted a fix to the CVS between those messages, but
>accidentally only sent a note about it to myself.  (Whatever happened to
>reply-to: being the list?)

Ah, ok. As the message I got and what was in CVS didn't really match. :)

>> One oddity; units seem to only auto-target once.  Do they not clear
>> their targets when the target is destroyed?

There *is* code in there for that. I'll add some debugging and find out
what goes on.

As for the "Reply-To", I did fix it a few weeks ago, and it worked fine
for a while. Now they must've done something again, so I'll go check the
setting.

-- 
                        "Bingeley bingeley beep!"
               -- The Personal Disorganizer, Terry Pratchett in Feet of Clay

Chakie writes:
>Well, this can't actually happen. The code is absolutely ok, and works
>fine for me. 

um, yeah.  I submitted a fix to the CVS between those messages, but
accidentally only sent a note about it to myself.  (Whatever happened to
reply-to: being the list?)

Missing message follows.




On Sat, 2001-10-27 at 00:52, Michael Earl wrote:
> On Sat, 2001-10-27 at 00:17, Michael Earl wrote:
> > Frankly, I don't understand even a little why this doesn't work.
> > 
> > 
> >   File "engine/ai/morale.py", line 42, in execute
> >     for unit in scenario.units:
> > TypeError: loop over non-sequence
> 
> Oops, yeah, I do.  That should be
> 
> for unit in scenario.units.values():
> 
> because units is a dictinary, not a sequence.  Fixed (also in
> destroyed).
> 
> 
> Looks stable now to me...
> 
> One oddity; units seem to only auto-target once.  Do they not clear
> their targets when the target is destroyed?
> 
> 
> - mikee
> 

On Thu, 25 Oct 2001, John Eikenberry wrote:

>Sounds like a good idea. My only thought would be to add an audio cue as
>well. Maybe the sound of a horse riding off... like a messenger or
>something.

Sure, the framework is already there. What's needed is an actual sample
and two lines of code, one that defines a logical name for the sample,
such as "messenger_rides_off" and one line to play the sample with the
given logical name.

Unfortunately I don't have a horse, not even a car... :)

-- 
         Real stupidity beats artificial intelligence every time.
                                              -- Terry Pratchett, Hogfather

On 27 Oct 2001, Michael Earl wrote:

>Frankly, I don't understand even a little why this doesn't work.

<snip>

>  File "engine/engine.py", line 99, in update
>    self.executeAI ()
>  File "engine/engine.py", line 327, in executeAI
>    module.execute ( self )
>  File "engine/ai/morale.py", line 42, in execute
>    for unit in scenario.units:
>TypeError: loop over non-sequence

Well, this can't actually happen. The code is absolutely ok, and works
fine for me. I added a few checks to make sure that it does not get a
ZeroDivisionError if either player has no units left, but other than that
it works just fine.

I suggest you try to remove all .pyc files. It seems Python *can* leave
stale compiled files left at some weird circumstances. I have had some
weird problems (just like that) just vanish after such an operation.

Anyway, it Works For Me(tm)... :)

-- 

      Real children don't go hoppity-skip unless they are on drugs.
                          -- Susan Sto Helit, in Hogfather (Terry Pratchett)

Frankly, I don't understand even a little why this doesn't work.



**********************************************************************
advanceTurn: turn: 76
Engine.update: executing unattached: newturn
Engine.update: executing: attack
Engine.update: executing: attack
Engine.update: executing: attack
updateEngine: adding & sending 0 -1 73
updateEngine: adding & sending 0 -1 73
updateEngine: adding & sending 20 4 76 10 402 368
updateEngine: adding & sending 20 4 76 10 402 368
updateEngine: adding & sending 20 5 76 9 394 311
updateEngine: adding & sending 20 5 76 9 394 311
updateEngine: adding & sending 20 6 76 8 420 330
updateEngine: adding & sending 20 6 76 8 420 330
applyEvents: at 76 applying command: move
applyEvents: at 76 applying command: move
applyEvents: at 76 applying command: move
943
**********************************************************************
advanceTurn: turn: 77
Engine.update: executing unattached: newturn

Oops, something went wrong. Dumping brain contents: 
---------------------------------------------------------------------------
Traceback (most recent call last):
  File "civil-server.py", line 144, in ?
    main ()
  File "civil-server.py", line 136, in main
    mainLoop ( clients )
  File "server/server_main_loop.py", line 211, in mainLoop
    updateEngine ( clients )
  File "server/server_main_loop.py", line 128, in updateEngine
    scenario.engine.update ()
  File "engine/engine.py", line 99, in update
    self.executeAI ()
  File "engine/engine.py", line 327, in executeAI
    module.execute ( self )
  File "engine/ai/morale.py", line 42, in execute
    for unit in scenario.units:
TypeError: loop over non-sequence
---------------------------------------------------------------------------

Please mail this stack trace to civ...@li...
so that the error can be fixed. Thank you! -- the Civil team

On Thu, 2001-10-25 at 09:40, Jan Ekholm wrote:
>  def updateRealtimeSecond (self):
>     """Updates the current realtime second to the second of the system
>        time. Also stores the current millisecond."""
>     # TODO: should maybe just be a +=1 to avoid skipping a turn?
>         
>     # current realtime second
>     self.realtime_second = int(math.ceil(pygame.time.get_ticks() /1000.0))
> 
> 
> Can that code possible skip a turn?

Well, I think getRealtimeUntilAdvance will throw an exception if we're
about to do that, at least on the server side.  We may need to put a
call to that or something similar back in the client loop and make sure
the result is sane when we're about to advance the turn.

- mikee

On 25 Oct 2001, Michael Earl wrote:

>On Thu, 2001-10-25 at 07:27, Jan Ekholm wrote:
>> Do you still get any weirdness when trying the current version? Much has
>> been changed, but I haven't tested the combat code that much lately, been
>> a little busy with other parts.
>
>Haven't had a change to run it; will try to get to that by this weekend
>sometime...  it certainly looks like that will eliminate the main glitch
>I saw, but who knows.

Yeah, at least it's simpler now from the client/AI point of view. Less
code to worry about, and no timings at all that need to be taken care of.

There is of course a risk with clients that lag horribly that they remain
stuck on some specific turn for a long time, thus plans that get created
are timestamped "way back in time" compared to where the server currently
runs. The solution for this is to have the client/AI ack every NewTurnCmd
it gets, and have the server wait for the ack before progressing. 

Another possible bug *could* be in gametime.py, in the method
updateRealtimeSecond(). It is:

 def updateRealtimeSecond (self):
    """Updates the current realtime second to the second of the system
       time. Also stores the current millisecond."""
    # TODO: should maybe just be a +=1 to avoid skipping a turn?
        
    # current realtime second
    self.realtime_second = int(math.ceil(pygame.time.get_ticks() /1000.0))


Can that code possible skip a turn?

-- 
                        "Bingeley bingeley beep!"
               -- The Personal Disorganizer, Terry Pratchett in Feet of Clay

On Thu, 2001-10-25 at 07:27, Jan Ekholm wrote:
> Do you still get any weirdness when trying the current version? Much has
> been changed, but I haven't tested the combat code that much lately, been
> a little busy with other parts.

Haven't had a change to run it; will try to get to that by this weekend
sometime...  it certainly looks like that will eliminate the main glitch
I saw, but who knows.

- mikee

Mike,

Do you still get any weirdness when trying the current version? Much has
been changed, but I haven't tested the combat code that much lately, been
a little busy with other parts.

Otherwise I'll need to test it a little bit more heavily after the
weekend. I'll be away the whole weekend. 

The same goes for all of you. It's better to report anything to the list
that bugs you or that otherwise feels weird. If you think something is
wrong or just needs improving the chances that many from the intended
audience will think so too.

As soon as we have 0.50 done then there's not too much to be done for 0.60
either. Which is nice. :)

-- 
"It would seem that you have no useful skill or talent whatsoever," he said.
              "Have you thought of going into teaching?"  
                                                    -- Terry Pratchett, Mort

On Mon, 2001-10-22 at 07:47, Jan Ekholm wrote:
> I added a plan NewTurn that now takes care of notifying the client/ai that
> a new turn has started. It also runs the functions doTurnUpdates(), so
> the functions checkTime() for the client and ai are deprecated. So they no
> longer need to manage time in any way. Just read stuff from the net and
> repaint/run the AI code.

Code that isn't there won't have bugs, so I suppose this is a good
thing. :)  I'm kinda inclined to think the client ought to have a clock
anyway, but it's mostly irrelevent unless the variation in latency is
huge (occasional dropped packets would do this, I suppose...).  Easy
enough to add if it turns out to be necessary.

Anyhow, this looks very good, haven't had chance to test yet.

- mikee

On Tue, 2001-10-23 at 06:06, John Eikenberry wrote:
> Its the same code and will very likely need some optimization. One
> simple optimization is caching the terrain costs. This is particularly
> easy... if they are static?

Yup.  Well, there was speculation about changing them due to weather
conditions (dirt roads becoming impassable as rain continues) or the
like, but I doubt it's worth worrying about now and they'd be mostly
static in any event.

Also at some future point, I think multiple units moving in the same
area ought to interfere/slow/block each other (they don't currently),
but that's annoying to implement in the engine and can likely also be
neglected for the near future.

> I'm still thinking abou the AI player. I first need to figure out how to
> process the incoming data stream into something that would be useful for
> strategic planning (or some semblance thereof). I need a 'spec' of the
> server->client/ai messages. Seems like this 'spec' would be the files in
> the protocol/ dir?

Yes.  Do note that most of this work, at least in draft, was already
done by Chakie; the existing 'AI' client (civil-ai.py) does lots of
tedious connecting to the server, then sits and spins in a loop,
applying status updates from the server to maintain the scenario.*
structure up-to-date with game status.  It's mostly the interactive
client with the GUI lobotomized away; it does most everything the AI
needs to do except for, well, AI.

The interactive client code to issue orders is the whole state/*
classes, the actual order-sending is of the form:

cmd = protocol.plan.Attack(unitid=unit.getId(),turn=turn,
	targetid=targetid)

scenario.connection.send(cmd.toString () )

- mikee

Jan Ekholm wrote:

> >These two seem related to me... that is as the strength of an army is
> >reduced, this would reduce the moral. By the time there are 75%
> >casualties, the moral would be pretty low. Leading to a withdrawl or
> >route unless there were some pretty big events to raise moral. That is,
> >the effects of casualties on moral seem like they'd get worse as thier
> >number rose.
> 
> Hmm, basically you are absolutely correct. I think we don't need to change
> anything anyway, as to the player it all looks the same. On the server
> side it just makes it easier to handle. Or do you think we should skip one
> of the possibilities?

Hmm... I'm not sure what 'possibilities' is referring to here? 

-- 

John Eikenberry
[ja...@zh... - http://zhar.net]
______________________________________________________________
"They who can give up essential liberty to purchase a little temporary
 safety, deserve neither liberty nor safety."
                                          --B. Franklin

On Tue, 23 Oct 2001, John Eikenberry wrote:

>
>Jan Ekholm wrote:
>
>> The latter two need a little clarification. An army is considered
>> destroyed when a certain percentage of it has been destroyed. It should
>> not be nevessary to destroy every single unit, as an army that is at, say,
>> 25% strength has probably collapsed. A collapsed army surrenders or
>> withdraws.
>> 
>> The same goes for army morale. If the average morale drops too low the
>> army has lost its will to fight and will surrender or flee.
>
>These two seem related to me... that is as the strength of an army is
>reduced, this would reduce the moral. By the time there are 75%
>casualties, the moral would be pretty low. Leading to a withdrawl or
>route unless there were some pretty big events to raise moral. That is,
>the effects of casualties on moral seem like they'd get worse as thier
>number rose.

Hmm, basically you are absolutely correct. I think we don't need to change
anything anyway, as to the player it all looks the same. On the server
side it just makes it easier to handle. Or do you think we should skip one
of the possibilities?

-- 
         Real stupidity beats artificial intelligence every time.
                                              -- Terry Pratchett, Hogfather

On Tue, 23 Oct 2001, John Eikenberry wrote:

>
>Attached is the pathfinding code re-arranged to separate the test code
>out. Its now a set of functions. Though calculatePath() is the only one
>needed externally.
>
>Its the same code and will very likely need some optimization. One
>simple optimization is caching the terrain costs. This is particularly
>easy... if they are static?

They should be static.

>I'm still thinking abou the AI player. I first need to figure out how to
>process the incoming data stream into something that would be useful for
>strategic planning (or some semblance thereof). I need a 'spec' of the
>server->client/ai messages. Seems like this 'spec' would be the files in
>the protocol/ dir?

Yes. There are two dirs there, "command" and "plan". A plan is something
that the player (or AI for that matter) does. If the player orders a unit
to move it will create a Move plan that contains the proper informations
(which unit, when started, destination). Same goes for a rotation, all
combat, changing mode, ending the game. Everything the clients (human and
AI) do create a plan.

The server will when it receives a plan add it to the plans for the unit
in question. So a unit has a queue of plans, and performs them FIFO. Some
plans (such as ending the game) are reacted upon immediately, and are not
added to any unit. The plans that get attached to units are also sent back
to both clients, so that they know that the plan was accepted, and can
thus use the information for, say, painting a movement path. Clients
should *never* assume a plan is active just because it was sent away, it's
valid when the server has sent it back.

Plans have a method attachAI() that is executed when a plan is sent back
from the server to the AI client. It by default just attaches the plan to
the concerned unit, and can be overridden if needed.


So far so good, now everyone knows that is going to happen.

The classes in the "command" directory are different from plans, although
they have similar names (+ an added "Cmd"). A command is sent out by the
server when it executes plans. The active plan for each unit is executed
each turn and may lead to one or more commands being sent out. A command
is a small incremental step of something larger. For instance a MoveCmd
contains one single movement step for one unit and one turn. The commands
are received by both clients, and when applied do something to the
internal state of the data.

Every command has a methid applyAI() that is called when the command
should be applied to the internal data. By default it usually just
performs some modifications to a unit or some other internal data. These
methods can be overridden if some custom behaviour is needed when a
command is applied, maybe to perform some reaction to the command.
Otherwise the AI client would just run ai.event_loop.updateAI() all the
time and do whatever needs to be done. At least according to old ideas.

So basically I *think* the AI has hooks into everything that it needs to
be notified about, and also an own event loop which can be customized as
much as needed.

Hmm, I hope my weird description makes sense. And I sure do hope our
protocol makes sense, as it's a little bit late now to change it... :)

-- 
         Real stupidity beats artificial intelligence every time.
                                              -- Terry Pratchett, Hogfather

Attached is the pathfinding code re-arranged to separate the test code
out. Its now a set of functions. Though calculatePath() is the only one
needed externally.

Its the same code and will very likely need some optimization. One
simple optimization is caching the terrain costs. This is particularly
easy... if they are static?

I'm still thinking abou the AI player. I first need to figure out how to
process the incoming data stream into something that would be useful for
strategic planning (or some semblance thereof). I need a 'spec' of the
server->client/ai messages. Seems like this 'spec' would be the files in
the protocol/ dir?

-- 

John Eikenberry
[ja...@zh... - http://zhar.net]
______________________________________________________________
"They who can give up essential liberty to purchase a little temporary
 safety, deserve neither liberty nor safety."
                                          --B. Franklin

Jan Ekholm wrote:

> The latter two need a little clarification. An army is considered
> destroyed when a certain percentage of it has been destroyed. It should
> not be nevessary to destroy every single unit, as an army that is at, say,
> 25% strength has probably collapsed. A collapsed army surrenders or
> withdraws.
> 
> The same goes for army morale. If the average morale drops too low the
> army has lost its will to fight and will surrender or flee.

These two seem related to me... that is as the strength of an army is
reduced, this would reduce the moral. By the time there are 75%
casualties, the moral would be pretty low. Leading to a withdrawl or
route unless there were some pretty big events to raise moral. That is,
the effects of casualties on moral seem like they'd get worse as thier
number rose.

-- 

John Eikenberry
[ja...@zh... - http://zhar.net]
______________________________________________________________
"They who can give up essential liberty to purchase a little temporary
 safety, deserve neither liberty nor safety."
                                          --B. Franklin

I got a bit bored so I implemented a few of the modules that Mikee
suggested a while ago. The modules plug into the server engine and provide
code for checking when a game ends. Currently there are a few possible
ways the game can end:

    * quitting the game
    * surrendering (not fully implemented)
    * a cease fire (not fully implemented)

    * timeout, i.e. all turns in the game have passed
    * army destroyed
    * army demoralized

The latter two need a little clarification. An army is considered
destroyed when a certain percentage of it has been destroyed. It should
not be nevessary to destroy every single unit, as an army that is at, say,
25% strength has probably collapsed. A collapsed army surrenders or
withdraws.

The same goes for army morale. If the average morale drops too low the
army has lost its will to fight and will surrender or flee.


Endings that need to be implemented:

    * when all objectives are captured/held for some time


-- 

  That's right," he said. "We're philosophers. We think, therefore we am.
                                             -- Terry Pratchett, Small Gods

On 21 Oct 2001, Michael Earl wrote:

>It's not as bad as it sounds, which is why it was missed so long; all
>the updates are given in absolute terms, so errors don't accumulate.  I
>think it was showing up before, but only as occasional 'skipping' with
>moving units.  I'm still not sure why/when it happens exactly.
>
>However, if you miss an update that flags a unit as destroyed, things
>get weird.

Yep, and there might be other nice things too, such as some unit that
should be hidden, have a changed modifier of some sorts, end game missed
etc.

>
>> More traffic (marginally), but added security. Could be implemented as a
>> simple command pair, for instance: TurnCmd and TurnAckCmd. Or something
>> like that. As people *will* play over connections that are not localhost
>> or 10/100Mbit we need to address this issue sooner or later anyway, as it
>> seems to be a problem.
>
>Yeah, that would do.  Actually, I think you get about 90% of the benefit
>from just server-issued TurnCmd.  Upon finishing a turn, the server
>sends out TurnCmd for that turn; if clients find themselves about to
>start a turn for which turncmd has not been issued, they wait for it. Or
>maybe they wait for the turn after the coming turn to finish, I had some
>reason once why I thought that was correct but can't recall it now.

I added a plan NewTurn that now takes care of notifying the client/ai that
a new turn has started. It also runs the functions doTurnUpdates(), so
the functions checkTime() for the client and ai are deprecated. So they no
longer need to manage time in any way. Just read stuff from the net and
repaint/run the AI code.

>There's some debug code in event_loop now, which causes frequent
>exceptions (it seems the clients are getting ahead of the server,
>maybe?); you'll want to comment that out if working on something
>unrelated to this problem.

That should not happen anymore. I left the debugging in there, it may be
needed later. Eventually we may want to move debugging into a separate
module so that it can all be turned off by just setting a single flag.

-- 
               "Stercus, stercus, stercus, moriturus sum."
                                       -- Terry Pratchett, Interesting Times

On Sun, 2001-10-21 at 11:35, Jan Ekholm wrote:
> Hmm, that's a major problem. A lost command can mean some serious
> problems, as the clients and server could end up with wildly different
> ideas about the state of the game.

It's not as bad as it sounds, which is why it was missed so long; all
the updates are given in absolute terms, so errors don't accumulate.  I
think it was showing up before, but only as occasional 'skipping' with
moving units.  I'm still not sure why/when it happens exactly.

However, if you miss an update that flags a unit as destroyed, things
get weird.


> More traffic (marginally), but added security. Could be implemented as a
> simple command pair, for instance: TurnCmd and TurnAckCmd. Or something
> like that. As people *will* play over connections that are not localhost
> or 10/100Mbit we need to address this issue sooner or later anyway, as it
> seems to be a problem.

Yeah, that would do.  Actually, I think you get about 90% of the benefit
from just server-issued TurnCmd.  Upon finishing a turn, the server
sends out TurnCmd for that turn; if clients find themselves about to
start a turn for which turncmd has not been issued, they wait for it. Or
maybe they wait for the turn after the coming turn to finish, I had some
reason once why I thought that was correct but can't recall it now.


There's some debug code in event_loop now, which causes frequent
exceptions (it seems the clients are getting ahead of the server,
maybe?); you'll want to comment that out if working on something
unrelated to this problem.

- mikee