[Civil-devel]Road to 0.6

[Gareth Noyce <gareth.noyce@uk...>]

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

[Civil-devel]Ending games

[Jan Ekholm <chakie@in...>]

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

[Civil-devel]0.50 tagged

[Jan Ekholm <chakie@in...>]

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

[Civil-devel]Unit modes

[Jan Ekholm <chakie@in...>]

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

Re: [Civil-devel]more crash fun - morale victory module problems?

[Jan Ekholm <chakie@in...>]

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

Re: [Civil-devel]more crash fun - morale victory module problems?

[Gareth Noyce <gareth.noyce@uk...>]

> 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

Re: [Civil-devel]more crash fun - morale victory module problems?

[Jan Ekholm <chakie@in...>]

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

Re: [Civil-devel]more crash fun - morale victory module problems?

[Michael Earl <mearl@me...>]

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
> 

Re: [Civil-devel]New unit modes

[Jan Ekholm <chakie@in...>]

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

Re: [Civil-devel]more crash fun - morale victory module problems?

[Jan Ekholm <chakie@in...>]

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)

[Civil-devel]more crash fun - morale victory module problems?

[Michael Earl <mearl@me...>]

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 civil-devel@...
so that the error can be fixed. Thank you! -- the Civil team

Re: [Civil-devel]New unit modes

[John Eikenberry <jae@zh...>]

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.

Jan Ekholm wrote:

> 
> Hi all,
> 
> I was playing a little bit last night, and noticed that changing the mode
> of a unit could be better. When the mode is changed the unit (infantry in
> this case) changes from, say, "column" to "formation", the unit will not
> do the change immediately, as it naturally takes some time. However, there
> is no feedback to the user that the unit actually received the order to
> change mode at all. The panel just shows the same old mode and nothing
> seems (to the player) to happen, which means the player may issue the same
> order again, thus changing back to the original mode once the first change
> has been done.
> 
> There should IMHO be intermediate modes that all units are in while
> changing between the "major" modes. Something like this:
> 
>        formation  -> changing to column    -> column
>        column     -> changing to formation -> formation
>        limbered   -> unlimbering           -> unlimbered
>        unlimbered -> limbering             -> limbered
>        mounted    -> dismounting           -> dismounted
>        dismounted -> mounting              -> mounted
> 
> The middle state would be activated immediately when the unit is starting
> to change state, thus giving the player the needed visual feedback. The
> needed changes would be very minor, just making sure executing the SetMode
> plan sends out one extra SetModeCmd to set the intermediate mode.
> 
> Or is this the wrong way to attack the problem?
> 
> -- 
> 
>     Greebo could, in fact, commit sexual harrassment simply by sitting 
>                     very quietly in the next room.
>                                              -- Terry Pratchett, Maskerade
> 
> 
> _______________________________________________
> Civil-devel mailing list
> Civil-devel@...
> https://lists.sourceforge.net/lists/listinfo/civil-devel

-- 

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

Re: [Civil-devel]Remaining issues for 0.50?

[Michael Earl <mearl@me...>]

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

Re: [Civil-devel]Remaining issues for 0.50?

[Jan Ekholm <chakie@in...>]

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

Re: [Civil-devel]Remaining issues for 0.50?

[Michael Earl <mearl@me...>]

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

[Civil-devel]Remaining issues for 0.50?

[Jan Ekholm <chakie@in...>]

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

[Civil-devel]New unit modes

[Jan Ekholm <chakie@in...>]

Hi all,

I was playing a little bit last night, and noticed that changing the mode
of a unit could be better. When the mode is changed the unit (infantry in
this case) changes from, say, "column" to "formation", the unit will not
do the change immediately, as it naturally takes some time. However, there
is no feedback to the user that the unit actually received the order to
change mode at all. The panel just shows the same old mode and nothing
seems (to the player) to happen, which means the player may issue the same
order again, thus changing back to the original mode once the first change
has been done.

There should IMHO be intermediate modes that all units are in while
changing between the "major" modes. Something like this:

       formation  -> changing to column    -> column
       column     -> changing to formation -> formation
       limbered   -> unlimbering           -> unlimbered
       unlimbered -> limbering             -> limbered
       mounted    -> dismounting           -> dismounted
       dismounted -> mounting              -> mounted

The middle state would be activated immediately when the unit is starting
to change state, thus giving the player the needed visual feedback. The
needed changes would be very minor, just making sure executing the SetMode
plan sends out one extra SetModeCmd to set the intermediate mode.

Or is this the wrong way to attack the problem?

-- 

    Greebo could, in fact, commit sexual harrassment simply by sitting 
                    very quietly in the next room.
                                             -- Terry Pratchett, Maskerade

Re: [Civil-devel]Re-arranged A* code.

[Jan Ekholm <chakie@in...>]

On 24 Oct 2001, Michael Earl wrote:

>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.

Yes, this would be nice, but I think it's fine to ignore for now. We
should however also take into account that when attacking a stacked unit
then other units will suffer damage too. Especially when being shelled by
artillery damage should spread along all stacked units.

-- 

    Greebo could, in fact, commit sexual harrassment simply by sitting 
                    very quietly in the next room.
                                             -- Terry Pratchett, Maskerade

Re: [Civil-devel]Ending games

[Jan Ekholm <chakie@in...>]

On Tue, 23 Oct 2001, John Eikenberry wrote:

>
>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? 

I meant the check for either morale drop or destroyed units, as one
normally implies the other. But they are both already implemented, so I
think they can be left in there. 

-- 

    Greebo could, in fact, commit sexual harrassment simply by sitting 
                    very quietly in the next room.
                                             -- Terry Pratchett, Maskerade

Re: [Civil-devel]damage, endgame

[Michael Earl <mearl@me...>]

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

Re: [Civil-devel]Re-arranged A* code.

[Michael Earl <mearl@me...>]

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

Re: [Civil-devel]Ending games

[John Eikenberry <jae@zh...>]

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
[jae@... - http://zhar.net]
______________________________________________________________
"They who can give up essential liberty to purchase a little temporary
 safety, deserve neither liberty nor safety."
                                          --B. Franklin

Re: [Civil-devel]Ending games

[Jan Ekholm <chakie@in...>]

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

Re: [Civil-devel]Re-arranged A* code.

[Jan Ekholm <chakie@in...>]

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

[Civil-devel]Re-arranged A* code.

[John Eikenberry <jae@zh...>]

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
[jae@... - http://zhar.net]
______________________________________________________________
"They who can give up essential liberty to purchase a little temporary
 safety, deserve neither liberty nor safety."
                                          --B. Franklin