civil-devel Mailing List for Civil

Hi,

The first batch of XSLT bits are in the tree. There's a lot of random bits 
there, I'll document and explain all later. For now you can poke around and 
amuse yourselves! :)

For the inclined, you'll require Xalan from xml.apache.org in order to run 
any of it... Like I say, when I get near a releasable version I'll take you 
guys through what's going on...

G

P.S. Ignore the test.html file -- it's just my random output file...

-- 
"Computer games don't affect kids. I mean if Pacman had affected us as
kids, we'd all be running around in a darkened room munching pills and
listening to repetitive music." -- Unknown
--

Quoting Jan Ekholm <ch...@in...>:
> >Somewhat off-topic: any of you guys run across 
XML-RPC?  I hear
> >generally good things about it.  At this point 
I think our custom
> >protocol is the right thing, mind you, mostly 
curious for general
> >opinions...
> 
> Looked at it, but not used yet. I think it's a 
Good Thing, but maybe a
> little bit more heavyweight than what we have 
now. All stuff goes
> through
> XML, so there's more parsing and more data to 
send. Of course, this is
> AFAIK.

Hmmm, I don't know if I'd call it heavy, the 
packets are a damn sight lighter than Soap, 
implementation frameworks are _very_ skinny 
(compared to other RPC like structures I've 
played with) and the choice of languages with 
working XML-RPC modules is _large_.

To be honest I very much like it, although we 
ended up using SOAP at work due to .NET. There 
are a lot of reasons to use XML-RPC, it's just 
unfortunate that it's being steam-rolled over 
with SOAP (which in my opinion /is/ heavy)...

There's also no need for a full XML parser in 
order to work with it. But depending on services 
used this can be a good or bad thing... For the 
low barrier to entry though, I'd say XML-RPC is a 
very good service for distributed server-side 
stuff...


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

> Somewhat off-topic: any of you guys run across 
> XML-RPC?  I hear
> generally good things about it.  At this point 
> I think our custom
> protocol is the right thing, mind you, mostly 
> curious for general
> opinions...

Er, yeah. I'm an XML consultant by day. If you've 
got any questions, email me directly! :)

G


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

On 30 Jul 2001, Mike Earl wrote:

>On 30 Jul 2001 11:25:26 +0300, Jan Ekholm wrote:
>> Here be dragons.
>
>Yup.  I think you have diagnosed symptoms correctly, and that workaround
>might be a good thing on its own merits.  Maybe have plans throw an
>exception when they're finished, and let the server loop send the done
>command was my thought, but it amounts to the same thing.  However, the
>sequencing issue makes me a bit nervous.  I'll try to chase that down -
>ought to learn that code anyway - otherwise it will come back and bite
>us later.  What I really don't get is why we have the bug for fire but
>not for move; I don't see the difference...?

I don't know either, but I do know how it happens. But why it won't
happend for move is anyone's guess. I'll do the simple workaround today.
Or it's not really a workaround, just another way of doing it. Why not
utilize the return value from execute to something useful?

>Question on attack types: is the shooting actually handled differently,
>or is it a matter of differences in the plans about formation, movement
>rates, when to fire vs. move, etc.?  It would be nice if that all
>derived from unit state and plan rather than being explicitly coded in.

I think we derive from the base plan you created. Reuse and share as much
as possible, and derive Skirmish, Assault, Attack and Bombard (or whatever
we call them) from Fire.

>As to GGZ, I think a chat room and meta-server would be nifty; really,
>all the metaserver would need to do is let remote clients find each
>other and agree on who will run server - communications don't have to be
>relayed through it.

Yep, this should be done _some day_. Probably not now. I don't really
think it would be too impossible to add an extra dialog to Civil which
connects to an external always-running "meta-server" and let people play a
game.

>Somewhat off-topic: any of you guys run across XML-RPC?  I hear
>generally good things about it.  At this point I think our custom
>protocol is the right thing, mind you, mostly curious for general
>opinions...

Looked at it, but not used yet. I think it's a Good Thing, but maybe a
little bit more heavyweight than what we have now. All stuff goes through
XML, so there's more parsing and more data to send. Of course, this is
AFAIK.

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

On 30 Jul 2001 11:25:26 +0300, Jan Ekholm wrote:
> Here be dragons.

Yup.  I think you have diagnosed symptoms correctly, and that workaround
might be a good thing on its own merits.  Maybe have plans throw an
exception when they're finished, and let the server loop send the done
command was my thought, but it amounts to the same thing.  However, the
sequencing issue makes me a bit nervous.  I'll try to chase that down -
ought to learn that code anyway - otherwise it will come back and bite
us later.  What I really don't get is why we have the bug for fire but
not for move; I don't see the difference...?


Question on attack types: is the shooting actually handled differently,
or is it a matter of differences in the plans about formation, movement
rates, when to fire vs. move, etc.?  It would be nice if that all
derived from unit state and plan rather than being explicitly coded in.



As to GGZ, I think a chat room and meta-server would be nifty; really,
all the metaserver would need to do is let remote clients find each
other and agree on who will run server - communications don't have to be
relayed through it.

Somewhat off-topic: any of you guys run across XML-RPC?  I hear
generally good things about it.  At this point I think our custom
protocol is the right thing, mind you, mostly curious for general
opinions...

- mikee

Som random docs about the propsed combat system in Civil. These are just
my own interpreatations and ideas, and need to be fixed and adjusted for
realism, playability and fun. So comments, everybody!


TYPES OF COMBAT

There are four basic types of combat. They differ in how the enemy is
attacked and wether the attacker moves or not. All types of combat can not
be used by all types of units. Headquarters are treated as infantry units
in this discussion.


1. SKIRMISH

This is the basic form of attack for infantry and cavalry units. The unit
just fires at an enemy whithout moving. It's also the attack to use when
defending against an advancing enemy. Volley after volley is fired against
the target until the attack is either cancelled, attacker or target
destroyed, attacker disorganized or the target retreats. 

Applies to:       infantry, cavalry
Attacker moves:   no
Attacked visible: yes
Attacker risk:    none
Attacked risk:    low


2. ATTACK

This form of attack is a cautious advancing attack. The attacker advances
slowly against the enemy in combat formation and fires volleys at the
target at regular intervals. The aim is not to overrun the target, but
instead to get closer to the target and inflict higher casualities by
reducing the range to the target. While advancing the attacker is also
subject to defensive skirmishing fire. The target may fail a morale check
and retreat if casualities are too high. If the attacker suffers too heavy
casualities while advancing the advance mau halt and transform into a
SKIRMISH, or the advancer may break up and retreat.

Applies to:       infantry, cavalry
Attacker moves:   yes
Attacked visible: yes
Attacker risk:    moderate
Attacked risk:    moderate


3. ASSAULT

This is the most aggressive form of attacking. The attacker advances just
as in ATTACK, but the advance is faster and attacker tries to overrun the
target. The advance is as fast as the unit can do without breaking the
formations, usually a bit faster than fast movement. Moving too fast would
break the formation and cause the assault to be ineffective. The attacker
will stop at a close distance from the target and fire a few volleys
against the target. If neither breaks up and retreats after these deadly
volleys at close range the attacker assaults the target and engages in
close combat. The result is usually that either unit retreats/routs and
the other is left disorganized. Often the last stage of the assault is
never executed, as either unit will break up and retreat.

Applies to:       infantry, cavalry
Attacker moves:   yes 
Attacked visible: yes
Attacker risk:    high
Attacked risk:    high


4. BOMBARD

This form of attack is only used by artillery. It is a form of SKIRMISH
for artillery. Artillery units can bombard a unit and track its movements,
or it can bombard a location. The location must not even be visible, as
long as something can direct the fire [can this be done?]. Artillery units
are very sensitive to facing, and can't bombard targets that deviate a lot
from its facing. An unit that bombards will have a low chance of blowing
up a gun.

Applies to:       artillery
Attacker moves:   no 
Attacked visible: not needed, can bomb any area
Attacker risk:    none
Attacked risk:    depends


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

On Friday 27 July 2001 21:21, Jan Ekholm wrote:
> Somehow the image could not be loaded? Does it not exist, or is the
> installation procedure bad? I've never seen any problem with this, so
> there is something interesting going on. I've added a catch for the error,
> which should print out the file it tries to load.

It was a really weird SDL error - it seems SDL_image references libraries 
outside it's sourcetree during buildtime, therefore it didn't load any GIF 
images - I noticed that when I renamed IMG_Load to IMG_Loadxyz and started 
the "showimage" tool locally, it complained about an undefined reference to 
IMG_Load which should normally not occur. But anyway, this error is gone :)
I only had to disable
	scenario.audio.loadMusic ( properties.music_main )
	scenario.audio.playMusic ()
in civil.py/def main(), but the rest works ok. (The music continues from the 
menu though)
And it looks pretty good!

> Seeing Josef's signature below, and having read a few docs about GGZ and
> looked at the API, I wonder wether it would be hard to adapt Civil to some
> day use GGZ. Could be interesting to be able to provide some kind of
> "lounge" where games can be set up. Any Python interface? Just a thought
> though... :)

On the client side that wouldn't require more than 3 lines of Python or so 
(i.e. when given an option it connects to a local socket instead of to a 
port).
The server side seems more complicated - if I've understood the concept of 
the civil server right, it is intended to run permanently, which we don't 
support yet :(
However, we had some really weird ideas in the past weeks, including playing 
scripted games (Python, Perl, Ruby) directly from CVS or adding OOP methods 
during runtime - but most of those ideas are far from being realistic and 
will need some time. There is just no common concept available - at LinuxTag 
I've spoken with a WorldForge guy, they're also just beginning with this kind 
of libraries (including meta-servers etc.). Hopefully in some months there's 
some decent code present.

Josef

-- 
The MindX Open Source Project: Fighting proprietary games
GGZ now! - The GGZ Gaming Zone: http://ggz.sourceforge.net
ggz.morat.net | ggz.snafu.de | jzaun.com | mindx.sourceforge.net/europeone

Hi,

I added the "field of fire" attribute to units. The method is
getFieldOfFire() and is used in the method Fire.pointedAt(). I made
infantry and cavalry have a FOF of 3, artillery 2 and headquarters 4. The
latter as hq:s are small units that are more mobile and flexible than
larger units.

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

I looked more thoroughly at the problem you got, Mike, fixed a few bugs in
fire.py but managed to get the same error as you got. I'm not exactly sure
where it comes from, and what can be done to remedy it.

The problem basically is that somehow two DoneCmd:s end up being sent to
the clients. The first one clears away the plan as it's supposed to do,
but the second DoneCmd tries to clear away the same plan, but fails. It
fails as there are no plans for the unit anymore. The problem here is to
determine why two DoneCmd:s end up being sent.

After reading the debug output thoroughly I found that somehow
Fire.execute() got called twice for the same unit/target. It should never
be called more than once with the current code: get in, calculate, send a
MoveCmd if needed and terminate with a DoneCmd. However, it got called one
more time, the next time updateEngine() was called in mainLoop() in
server_main_loop.py. This should not happen, and I think it's a timing
problem in checkTime() in the same file. Apparently the server changes the
current turn *before* it has a chance to execute the first DoneCmd, thus
never removing it from the unit's plans, and ends up executing it once
more. For the server this is no problem, as the plans still exists and can
be executed, but this of course leads to another DoneCmd being sent out.

Here be dragons.

Solution:

Better timing handling. I propose that the execute() method be made to
return a valud indicating wether the plan is done, instead of relying on
DoneCmd removing it on the server side too. The change would be in
the method executeUnitPlans() in server/engine.py:

   # loop over all units we have
   for unit in scenario.units.values ():
      # does the unit have any plans?
      plan = unit.getActivePlan ()

      # do we have a plan that is valid and that was not executed
      # previously this turn?
      if plan and plan.getLastExecuted () != turn:
          # yep, all ok, execute the plan
          if plan.execute ( self.outgoing ):
              # plan is done now, remove it
              unit.getPlans ().remove ( plan )

          else: 
              # not yet done, set new last execution time to make sure it
              # will not be called again this turn
              plan.setLastExecuted ( turn )


The DoneCmd is of course created and sent as before, as the clients need
it. It should however not be executed on the server side, as the plan is
already removed. So the method applyServer() on DoneCmd could just be made
empty, and more the code the removes the plan to applyClient() and
applyAI().

What do you think? It's really unbeliveably hard to make a good server
engine that works well. I'd like to still believe the system we have is
not fundamentally broken by design. It may be a little crippled and
flawed, but I still would like to believe in it...

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

On 29 Jul 2001, Mike Earl wrote:

>On 29 Jul 2001 17:40:01 +0300, Jan Ekholm wrote:
>> What we do need to think abou tis what types of combat we'll use. I wrote
>> something about it a while ago, must dig it up. I personally think this
>> new plan you added should not shoot only one volley, but set the enemy
>> unit as target and *constantly* fire at it. I don't think the player would
>> want to set a target for every single volley of fire that is fired? 
>
>No.  Really, fire.execute ought not be there at all, it's just for
>testing.  My idea was that the 'real' attack plans will be subclasses of
>that, so that all the logic for handling attacks is in one place.

Ok, that's what you meant in one of the comments in the file. That is
probably a very good idea.

>IIRC your earlier proposal was (paraphrased):
>
>a) Skirmish: sit stationary, fire on enemy units which approach.
>b) Attack: move toward and fire on an enemy unit
>c) Assault: move toward and overrun a position (then fire??).
>d) Bombard: Continuously attack an area not in LoS.

Yep. We should probably write some descriptions about what each of these
are supposed to do to avoid confusion later. What unit states they
require, keyboard shortcuts, what units can perform them etc etc.

>> I added an "return state.own_unit.OwnUnit ()" to the end of
>> handleLeftMousePressed() in attac_unit.py. Solves the problem. Otherwise
>> the same state ends up still being active, i.e. if you return None no
>> state changes are done.
>
>Ok, I get it.  Actually pretty simple.

The basic idea is that all callbacks in the State subclasses return either
None or a new State of some kind. Returning None means that the same state
will continue to be active, and returning a new state means that the new
state replaces the old one as the active state.

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

On 29 Jul 2001 17:40:01 +0300, Jan Ekholm wrote:
> What we do need to think abou tis what types of combat we'll use. I wrote
> something about it a while ago, must dig it up. I personally think this
> new plan you added should not shoot only one volley, but set the enemy
> unit as target and *constantly* fire at it. I don't think the player would
> want to set a target for every single volley of fire that is fired? 

No.  Really, fire.execute ought not be there at all, it's just for
testing.  My idea was that the 'real' attack plans will be subclasses of
that, so that all the logic for handling attacks is in one place.

Probably one will fire at the nearest enemy unit (if any) forever,
another one or two will inherit from both Move and Fire and decide which
to do in their 'execute' function?

IIRC your earlier proposal was (paraphrased):

a) Skirmish: sit stationary, fire on enemy units which approach.
b) Attack: move toward and fire on an enemy unit
c) Assault: move toward and overrun a position (then fire??).
d) Bombard: Continuously attack an area not in LoS.

Unit formations may figure into this, too...



> I added an "return state.own_unit.OwnUnit ()" to the end of
> handleLeftMousePressed() in attac_unit.py. Solves the problem. Otherwise
> the same state ends up still being active, i.e. if you return None no
> state changes are done.

Ok, I get it.  Actually pretty simple.

 - mikee

On 28 Jul 2001, Mike Earl wrote:

>I slapped together a very preliminary fighting implmentation.  Or most
>of one.  Well, and it crashes the server.  Other than that it looks
>pretty good... um.

Yeah, good addition. There seems to be most of the needed framework for
doing combat. Great work, Mike! Unfortunately I can't test it properly
here at home, as I'm still stuck with pygame 0.9, which crashes when an
USEREVENT is used to update the unit mode. Used when rotating an unit.

I'll test it at work tomorrow and try to come up with what crashes it.


>The relevent changes are:
>
>Added 'fire' plan which shoots once.  Damage is not-well-handled. ;)

No, but that's merely a cosmetic issue. :) 

What we do need to think abou tis what types of combat we'll use. I wrote
something about it a while ago, must dig it up. I personally think this
new plan you added should not shoot only one volley, but set the enemy
unit as target and *constantly* fire at it. I don't think the player would
want to set a target for every single volley of fire that is fired? 

>Added attack_unit state to GUI (uses movement cursor).

Added an own cursor for it, but still refers to the same file you used.

>Made 'target unit' in own_unit state go to attack_unit.

Yep.


>Bugs:
>
>Attack_unit state somehow terminates with the targeted unit selected.

I added an "return state.own_unit.OwnUnit ()" to the end of
handleLeftMousePressed() in attac_unit.py. Solves the problem. Otherwise
the same state ends up still being active, i.e. if you return None no
state changes are done.

>I think the bugs in plan.fire and state.attack_unit are because I don't
>quite understand the 'done order' command and the way the state-stacking
>works.  Chakie, can you have a look?  I suspect the fixes will be
>obvious to you.  If not, I'll go digging around further.

I'll have a look tomorrow. My testing and poking around the code today
showed nothing directly bad, thge code looks fine. But I'll do some
testing tomorrow. I think you understand the big "mess" I've come up with
perfectly ok.

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

On 28 Jul 2001 23:07:03 -0400, Mike Earl wrote:
> Bugs:
> 
> Attack_unit state somehow terminates with the targeted unit selected.

Ok, re-read the code when it was before midnight local time, and
discovered that it made sense.  This is fixed now.

It still crashes if you rotate and then fire.  Something to do with
set-mode??  Looks like the fire plan isn't actually removed from the
server side, then sends another done to the client?

Server output:
------------------
checkTime: at 76 applying command: rotate
Engine.update: executing: rotate
updateEngine: adding & sending rotate
checkTime: at 77 applying command: rotate
Engine.update: executing: rotate
updateEngine: adding & sending rotate
checkTime: at 78 applying command: rotate
Engine.update: executing: rotate
updateEngine: adding & sending rotate
updateEngine: adding & sending done
checkTime: at 79 applying command: rotate
checkTime: at 79 applying command: done
Engine.update: executing: fire
firing!
updateEngine: adding & sending done
Engine.update: executing: fire
firing!
updateEngine: adding & sending done
checkTime: at 80 applying command: done
connection closed by remote party
----------------------

client output:
---------------

doTurnUpdates: applying command: 14 1 79 22 11

doTurnUpdates: applying command: 13 1 79 22

doTurnUpdates: applying command: 13 2 79 22

doTurnUpdates: applying command: 13 2 80 22


Oops, something went wrong. Dumping brain contents: 
---------------------------------------------------------------------------
Traceback (most recent call last):
  File "civil.py", line 217, in ?
    main ()
  File "civil.py", line 209, in main
    event_loop ()
  File "event_loop.py", line 205, in event_loop
    checkTime ()
  File "event_loop.py", line 134, in checkTime
    doTurnUpdates ()
  File "event_loop.py", line 71, in doTurnUpdates
    command.applyClient ()
  File "protocol/command/done_cmd.py", line 64, in applyClient
    self.applyServer ()
  File "protocol/command/done_cmd.py", line 88, in applyServer
    raise "DoneCmd.applyServer: we got a done, but have no plans?"
DoneCmd.applyServer: we got a done, but have no plans?
---------------------------------------------------------------------------

I slapped together a very preliminary fighting implmentation.  Or most
of one.  Well, and it crashes the server.  Other than that it looks
pretty good... um.

The relevent changes are:

Added 'fire' plan which shoots once.  Damage is not-well-handled. ;)
Added attack_unit state to GUI (uses movement cursor).
Made 'target unit' in own_unit state go to attack_unit.

Stability issues:

'Fire' plan does not properly terminate itself, and crashes the server
(error message is along the lines of 'plan 2 ended, plan 1 active'?)

Bugs:

Attack_unit state somehow terminates with the targeted unit selected.

Missing features:

Anything relating to damage.  



I think the bugs in plan.fire and state.attack_unit are because I don't
quite understand the 'done order' command and the way the state-stacking
works.  Chakie, can you have a look?  I suspect the fixes will be
obvious to you.  If not, I'll go digging around further.


- mikee

On 27 Jul 2001, Mike Earl wrote:

>
>One other oddity; the function pygame.event.get_blocked is in the online
>docs 
>
>http://pygame.seul.org/docs/ref/pygame_event.html#get_blocked
>
>But does not appear to be implemented, at least in the version I have???

This is a new function. Pete said he'd implement it yesterday. The docs
always reflect the CVS version of pygame, not any older released version.

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

One other oddity; the function pygame.event.get_blocked is in the online
docs 

http://pygame.seul.org/docs/ref/pygame_event.html#get_blocked

But does not appear to be implemented, at least in the version I have???

On 27 Jul 2001 12:27:46 +0300, Jan Ekholm wrote:
> Start the game. Select on own unit. Right-click to bring up the menu of
> orders. Select 'move unit'. If the game then does nothing you have a bug,
> but if it changes the mousepointer to the normal 'move' pointer then it
> works for you... 

Same bug here under Linux.   Logic certainly looks straightforward...
will have a look, just for kicks.

On Fri, 27 Jul 2001, Josef Spillner wrote:

>Hello,
>
>there are some minor difficulties with Civil:
>
>- the civil-ai shell script should pass the options to civil-ai.py:
>	python2 civil-ai.py $@
>So you can add an --union or something.

Yes, this is a smart idea and will be done. Thanks for the tip. The
shellscripts are quite new and have most likely not been used too much.

>- I cannot play - Civil starts with nice music, provides some screens and 
>when selecting a map it fails with an error. At first I used SDL 1.2.0 (and 
>pygame 1.1), and it crashed because the gamma value couldn't be changed 
>(which seems to happen when pygame loads an image). After upgrading to 1.2.2, 
>it emits an empty error message.

<snip>

>  File "/usr/local/games/civil/src/image.py", line 24, in __init__
>    self.surface = pygame.image.load ( filename )
>error

Somehow the image could not be loaded? Does it not exist, or is the
installation procedure bad? I've never seen any problem with this, so
there is something interesting going on. I've added a catch for the error,
which should print out the file it tries to load. 

The server crash is just missing errorhandling when a client quits too
soon. Easy to fix, but should be fixed nevertheless.

Thanks for the feedback, Josef, I really appreciate it. There are
definitely a few rough edges still, but that's why we still haven't
released anything.

Seeing Josef's signature below, and having read a few docs about GGZ and
looked at the API, I wonder wether it would be hard to adapt Civil to some
day use GGZ. Could be interesting to be able to provide some kind of
"lounge" where games can be set up. Any Python interface? Just a thought
though... :)

>-- 
>The MindX Open Source Project: Fighting proprietary games
>GGZ now! - The GGZ Gaming Zone: http://ggz.sourceforge.net
>ggz.morat.net | ggz.snafu.de | jzaun.com | mindx.sourceforge.net/europeone


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

On Fri, 27 Jul 2001, Gareth Noyce wrote:

>At 10:27 27/07/01, you wrote:
>>If you want to test it out have a look at src/event_loop.py and the
>>function event_loop(). Enable the two commented out calls to
>>pygame.event.set_blocked() and the one call to pygame.event.set_allowed().
>>That will re-enable the error too. But if it works on your machines then
>>we have something weird here. Could someone on Windows please test it?
>
>Of course! I'll look into it on Sunday and report back...

Good. I'm not sure I want it to work on Windows or not. If it doesn't then
the bug is at least consitent among platforms, but if it does then we have
something that shown up only on Linux.

The plot thickens...

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

Hello,

there are some minor difficulties with Civil:

- the civil-ai shell script should pass the options to civil-ai.py:
	python2 civil-ai.py $@
So you can add an --union or something.

- I cannot play - Civil starts with nice music, provides some screens and 
when selecting a map it fails with an error. At first I used SDL 1.2.0 (and 
pygame 1.1), and it crashed because the gamma value couldn't be changed 
(which seems to happen when pygame loads an image). After upgrading to 1.2.2, 
it emits an empty error message.

- Not really related to civil, more a python 2.1.1 issue: Python may crash 
when the server terminates incorrectly.

Two relevant backtraces are attached.

Josef
(now subscribed to this list)

Client side:
[...]
  File "/usr/local/games/civil/src/new_game.py", line 85, in selectScenario
    state = SelectScenario ().run ()
  File "/usr/local/games/civil/src/dialog.py", line 168, in run
    returncode = self.wm.handle ( event )
  File "/usr/local/games/civil/src/widget_manager.py", line 104, in handle
    return self.handleMouseReleased (event)
  File "/usr/local/games/civil/src/widget_manager.py", line 213, in 
handleMouseReleased
    status = w.handle ( widget.MOUSEBUTTONUP, event )
  File "/usr/local/games/civil/src/widget.py", line 144, in handle
    code = self.callbacks[type] ( self, event )
  File "/usr/local/games/civil/src/select_scenario.py", line 130, in select
    self.selection = Image ( properties.scenario_selection_icon, (x,y) )
  File "/usr/local/games/civil/src/image.py", line 24, in __init__
    self.surface = pygame.image.load ( filename )
error

Server side:
connection closed by remote party
 
Oops, something went wrong. Dumping brain contents:
---------------------------------------------------------------------------
Traceback (most recent call last):
  File "civil-server.py", line 141, in ?
    main ()
  File "civil-server.py", line 127, in main
    clients = initLoop ( sock )
  File "/usr/local/games/civil/src/server/server_init_loop.py", line 141, in 
initLoop
    ready, clients = waitForData ( clients, socket )
  File "/usr/local/games/civil/src/server/server_init_loop.py", line 36, in 
waitForData
    incoming, out, execptional = select ( connections, [], [] )
ValueError: file descriptor cannot be a negative integer (-1)
---------------------------------------------------------------------------
 
Please mail this stack trace to civ...@li...
so that the error can be fixed. Thank you! -- the Civil team
 
/usr/local/bin/civil-server: line 7: 18815 Segmentation fault      python2 
civil-server.py

-- 
The MindX Open Source Project: Fighting proprietary games
GGZ now! - The GGZ Gaming Zone: http://ggz.sourceforge.net
ggz.morat.net | ggz.snafu.de | jzaun.com | mindx.sourceforge.net/europeone

At 10:27 27/07/01, you wrote:
>If you want to test it out have a look at src/event_loop.py and the
>function event_loop(). Enable the two commented out calls to
>pygame.event.set_blocked() and the one call to pygame.event.set_allowed().
>That will re-enable the error too. But if it works on your machines then
>we have something weird here. Could someone on Windows please test it?

Of course! I'll look into it on Sunday and report back...

G

-- 

"Computer games don't affect kids. I mean if Pacman had affected us as
kids, we'd all be running around in a darkened room munching pills and
listening to repetitive music." -- Unknown
--

Hi again,

Modified a whole lot of files again today. Basically it's just nothing
more than optimizations for the packet sizes. Previously packets have
included as the first data a string identifying the command or plan being
sent, such as "movefast-p" for a plan for moving fast. Now the id:s are
instead allocated by the packethandler (src/protocol/packethandler.py)
when it registers all packet types. The id:s are now integers starting
from 0 and up. We now use 1 or 2 characters for the type.

If needed the packet length can still be reduced a bit by encoding stuff
as hex instead of pure ascii (i.e. ff instead of 255). Ultimately a fully
binary format can be used to reduce the size even more. But that's for
later.

This shouldn't have broken anything, although the "cvs update" will reveal
quite a lot of files were changed. But bugs are never intentional... :)

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

Hi all,

I've been hunting bugs the last few days wrt to the USEREVENT:s that seem
to go missing. Pete Shinners (author of pygame) has also tried to track
down the problem, and his opinion is that it's the fault of either Civil
or SDL itself. I've been staring at our code for so long that I'm pretty
sure we don't do anything silly. Of course if somebody finds an error in
Civil I humbly declare myself as incompetent. :)

Bottom line is that we seem to both blame SDL for this issue. As it is now
it works, but I want to block MOUSEMOTION from being triggered every time
the mouse is moved. Too much overhead.

If you want to test it out have a look at src/event_loop.py and the
function event_loop(). Enable the two commented out calls to
pygame.event.set_blocked() and the one call to pygame.event.set_allowed().
That will re-enable the error too. But if it works on your machines then
we have something weird here. Could someone on Windows please test it?

How to test:

Start the game. Select on own unit. Right-click to bring up the menu of
orders. Select 'move unit'. If the game then does nothing you have a bug,
but if it changes the mousepointer to the normal 'move' pointer then it
works for you... All orders in the menu will work (except for 'attack')
when events are not blocked.

I'm not sure as to what can be done to cure or work around this. I'd like
to get it to work, but for now I'll leave it and do some other stuff. All
ideas and patches are of course welcome. Eternal glory to the one who
fixes this. :)

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

On 24 Jul 2001, Mike Earl wrote:

>On 24 Jul 2001 02:38:48 -0700, John Eikenberry wrote:
>> BTW, what's the current line of thought about the AI?
>
>That we need to implement basic combat first. :)  Chakie wrote an AI
>that runs as a seperate client process but doesn't actually do anything
>yet.  

Yeah, it should work as a fairly good framework for adding the AI stuff
into. Currently it has to be started separately and given the data on the
commandline, but that could be changed to be spawned if needed from within
the normal client.

>I have some ideas about this; a fairly simple heirarchical rules-based
>planning system might be a passable opponent, especially if the scenario
>file included hints for the AI about appropriate roles for various
>units.

That would require scenario editors to think about the way the AI works.
Could be too much to ask? But *if* there was something then the info could
be used.

>Wilder possibilities might be some kind of emergent behavior based on
>signalling (sort of the way ants work) or some kind of neural net; these
>would probably be a little more robust if they could be made to work at
>all (not straightforward).

Sounds like advanced plans. I have no idea about AI myself (apart from
brute force stuff), and neural nets have AFAIK not really shown themselves
to be worthy of all the attention they've got. :)

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

On 24 Jul 2001 02:38:48 -0700, John Eikenberry wrote:
> BTW, what's the current line of thought about the AI?

That we need to implement basic combat first. :)  Chakie wrote an AI
that runs as a seperate client process but doesn't actually do anything
yet.  I have some ideas about this; a fairly simple heirarchical
rules-based planning system might be a passable opponent, especially if
the scenario file included hints for the AI about appropriate roles for
various units.

Wilder possibilities might be some kind of emergent behavior based on
signalling (sort of the way ants work) or some kind of neural net; these
would probably be a little more robust if they could be made to work at
all (not straightforward).

- mikee