civil-devel Mailing List for Civil

On Mon, 29 Apr 2002, Jan Ekholm wrote:

>On Mon, 29 Apr 2002, Marcus Alanen wrote:
>
>>On Mon, 29 Apr 2002, Jan Ekholm wrote:
>>
>>> I'll start fixing the handling of selected units any day now. It does not
>>> work too well to have scenario.selected contain full Unit instances.
>>> Instead I'll do a small wrapper class that handles the selected units, and
>>> let it store the selected unit based on id:s instead.
>>
>>ok, i'm really going out on a limb here but I'm also ina  hurry. 
>>Python objects are references, and I don't see a need to copy the 
>>Unit, only copy the reference. So why the extra wrapper class?
>>Sorry, I don't have time to check the source code either, so this 
>>might be pure bs.
>
>This should be the case, yes. But in the state/action.py file we do a deep
>copy of the scenario.units data, so that we have something to "go back to"
>when scrolling backwards in time. The selected data has to be kept up to
>date when doing the deep copies. It's a bit slower to have a separate
>class handle it, but also somewhat safer and easier.

I started the implementation last night, but apparently my hammering
headache made me take the easier wasy and just fix the selection handling
in state/action.py. It now at certain points will refresh the selected
units, ie. copy them back from scenario.units, so that it again contains
references to valid units, and not units left dangling after a deep copy.

So, it seems to work ok now.

-- 

             Gravity is a habit that is hard to shake off.
                                              -- Terry Pratchett, Small Gods

On Mon, 29 Apr 2002, Marcus Alanen wrote:

>On Mon, 29 Apr 2002, Marcus Alanen wrote:
>
>> I'll do a quick upload of what I wrote yesterday regarding the "no 
>> busy looping" when I get home.
>
>Cancel that, I noticed it doesn't handle ending the turn correctly
>(just hangs). Will try later this week.
>
>(Now for something completely different :*)

Have fun.

Not to non-finns: we may be a bit "off-line" for a few days, and if we're
online don't expect anything coherent. :)

-- 
          "Yes, bugger all that." said Nanny. "Let's curse somebody."
                                            -- Terry Pratchett, Wyrd Sisters

On Mon, 29 Apr 2002, Marcus Alanen wrote:

>On Mon, 29 Apr 2002, Jan Ekholm wrote:
>
>> I'll start fixing the handling of selected units any day now. It does not
>> work too well to have scenario.selected contain full Unit instances.
>> Instead I'll do a small wrapper class that handles the selected units, and
>> let it store the selected unit based on id:s instead.
>
>ok, i'm really going out on a limb here but I'm also ina  hurry. 
>Python objects are references, and I don't see a need to copy the 
>Unit, only copy the reference. So why the extra wrapper class?
>Sorry, I don't have time to check the source code either, so this 
>might be pure bs.

This should be the case, yes. But in the state/action.py file we do a deep
copy of the scenario.units data, so that we have something to "go back to"
when scrolling backwards in time. The selected data has to be kept up to
date when doing the deep copies. It's a bit slower to have a separate
class handle it, but also somewhat safer and easier.

-- 
          "Yes, bugger all that." said Nanny. "Let's curse somebody."
                                            -- Terry Pratchett, Wyrd Sisters

On Mon, 29 Apr 2002, Marcus Alanen wrote:

> I'll do a quick upload of what I wrote yesterday regarding the "no 
> busy looping" when I get home.

Cancel that, I noticed it doesn't handle ending the turn correctly
(just hangs). Will try later this week.

(Now for something completely different :*)

Marcus

On Mon, 29 Apr 2002, Jan Ekholm wrote:

> I'll start fixing the handling of selected units any day now. It does not
> work too well to have scenario.selected contain full Unit instances.
> Instead I'll do a small wrapper class that handles the selected units, and
> let it store the selected unit based on id:s instead.

ok, i'm really going out on a limb here but I'm also ina  hurry. 
Python objects are references, and I don't see a need to copy the 
Unit, only copy the reference. So why the extra wrapper class?
Sorry, I don't have time to check the source code either, so this 
might be pure bs.

I'll do a quick upload of what I wrote yesterday regarding the "no 
busy looping" when I get home.

-- 
Marcus Alanen * Department of Computer Science * http://www.cs.abo.fi/
maa...@ab...

Hi,

I'll start fixing the handling of selected units any day now. It does not
work too well to have scenario.selected contain full Unit instances.
Instead I'll do a small wrapper class that handles the selected units, and
let it store the selected unit based on id:s instead.

So if there are any weird bugs with selected units, the bugs may be fixed
by the end of the week. :)

-- 
          "Yes, bugger all that." said Nanny. "Let's curse somebody."
                                            -- Terry Pratchett, Wyrd Sisters

On Fri, 26 Apr 2002, Sean Carroll wrote:

>I would like to help out on the ai module for civil. What 
>do you wantthe ai to be like? hard? easy? Also, is the only 
>ai file of Civil the civil-ai.py?

Hi Sean,

Sorry for the late reply. I'll CC this to the list (please let's keep all
discussions there, makes it easier for everyone to come with ideas) for
comments.

John is currently working with AI, he might have a few pointers to what
the AI will/should be able to do.

As for the code, the main action takes part in ai/event_loop.py. It has
the main loop which will eventually call the AI calculations.

-- 
           "Right, you bastards, you're... you're geography"
                                         -- Terry Pratchett, Guards! Guards!

On Sun, 28 Apr 2002, Marcus Alanen wrote:

>On Sun, 28 Apr 2002, Jan Ekholm wrote:
>
>> Did you want to do it, or should I do it? Maybe a new class in the net/
>> module to deal with it?
>
>I can give it a shot. You can tidy it up ;)

Ok. Or you give it a shot, I whine and then you clean it up... :)

--
  Shadwell hated all southerners and, by inference, was standing at the
  North Pole.
                           -- Terry Pratchett & Neil Gaiman, Good Omens

On Sun, 28 Apr 2002, Jan Ekholm wrote:

> Did you want to do it, or should I do it? Maybe a new class in the net/
> module to deal with it?

I can give it a shot. You can tidy it up ;)

-- 
Marcus Alanen * Department of Computer Science * http://www.cs.abo.fi/
maa...@ab...

On Sun, 28 Apr 2002, Marcus Alanen wrote:

>On Sun, 28 Apr 2002, Jan Ekholm wrote:
>
>> The pygame event handling *should* be thread safe, I think I've read that
>> somewhere. So basically it should be safe to create a "timer" thread to
>> just pump out timing events. 
>
>I saw a mail regarding that also. It did stress the thread safe 
>part, so we should be safe.
>
><snip good description of the implementation> 
>
>This sounds like the way to go. 
>
>> thread for monitoring the socket for incoming data. It needs just check
>> for availability, not even read anything, that could be left to the main
>> thread?
>
>Ah, good idea!

Thinking about it, it would be a fairly simple thing to do. Threads are
easy to do in Python, and it only needs to do a select(). I think that
threads work crossplatform too, so we should have no problems with threads
being weird on other platforms.

Did you want to do it, or should I do it? Maybe a new class in the net/
module to deal with it?

-- 
  And it came to pass that in time the Great God Om spake unto Brutha,
    the Chosen One: "Psst!"
                                        -- Terry Pratchett, Small Gods

On Sun, 28 Apr 2002, Jan Ekholm wrote:

> The pygame event handling *should* be thread safe, I think I've read that
> somewhere. So basically it should be safe to create a "timer" thread to
> just pump out timing events. 

I saw a mail regarding that also. It did stress the thread safe 
part, so we should be safe.

<snip good description of the implementation> 

This sounds like the way to go. 

> thread for monitoring the socket for incoming data. It needs just check
> for availability, not even read anything, that could be left to the main
> thread?

Ah, good idea!

-- 
Marcus Alanen * Department of Computer Science * http://www.cs.abo.fi/
maa...@ab...

On Sun, 28 Apr 2002, Marcus Alanen wrote:

>Hi, civil busy loops in the main event handler. It checks
>* SDL events via pygame
>* Network activity
>* Animates various parts of the display

These are the only things that I think will need "realtime" access.

>How do we combine the SDL main event loop and network activity?
>A separate thread that posts USEREVENTs?

The pygame event handling *should* be thread safe, I think I've read that
somewhere. So basically it should be safe to create a "timer" thread to
just pump out timing events. 

Reading stuff from the net has to be done (if without threads) using
polling or blocking. The same goes for reading pygame events. That's why
the current solution uses polling for both the net and the events. That
also makes it easy to call the animation regularly.

With a separate thread to do all this we could just post events to the
queue when something arrives, and have the main thread that does all the
hard work, just sit in a pygame.event.wait(). Animation could be handled
by turning on the pygame timer function. We already use it for the state
classes, but we can instead use, say, USEREVENT+3 for the animation
events.

>The animating should be quite easy, perhaps using 
>pygame.time.set_timer. On second thought, for sake of consistency
>yet another thread could be ok?

I read this part before I wrote the thing up there about timers, but I
somehow forgot it was mentioned here... Anyway, I think this is the way to
go. Why not use something that's already there? Threads can be *really*
painful to debug if something goes wrong. The current idea would need one
thread for monitoring the socket for incoming data. It needs just check
for availability, not even read anything, that could be left to the main
thread?

so, we could do this all with very minor changes, just an extra thread
that select():s the socket and posts USEREVENT:s to the queue.

msa, does this sound logical?

-- 
          "Yes, bugger all that." said Nanny. "Let's curse somebody."
                                            -- Terry Pratchett, Wyrd Sisters

Hi, civil busy loops in the main event handler. It checks
* SDL events via pygame
* Network activity
* Animates various parts of the display

These should naturally be combined, so we don't waste CPU cycles

How do we combine the SDL main event loop and network activity?
A separate thread that posts USEREVENTs?

The animating should be quite easy, perhaps using 
pygame.time.set_timer. On second thought, for sake of consistency
yet another thread could be ok?

Comments? If no objections arise I'll start doing this...

Marcus

Forwarded mail from Gareth below.

-- 

              Many an ancient lord's last words had been:
         "You can't kill me because I've got magic aaargh...."
                                      -- Terry Pratchett, Interesting Times


Jan wrote:

I'm pretty sure that the reason is that the environment variable HOME
isn't defined on Windows. Which sounds logical, when I think about it.
--

Hi, 

This is one of those "undocumented" features that will be solved by the
windows installer when we reach 1.0. -- There was some long discussion about
windows users and homing a while back which never got fully resolved as we
got caught up in Linux standards and some other hairy points...


You do need to manually define $HOME under windows until that time, and it's
not something we've discussed in a while as I was the only windows user and
knew what I was doing...

>From what I recall, and what I intend to do for the distribution; windows'
civil will create a home dir on install, or check for an existing one that
may have been setup by cygwin, emacs or some other *nix centric windows port
and use that -- it'd be semi transparent to the windows abuser.

For now, either add the home variable to the autoexec.bat (in win9x) or
through "my computer -> properties -> environment" under NT, 2K or XP.

I'd not forgotten about it, just not had to adjust it for a while, and after
the last discussion was fairly intent on doing "the right thing" nearer the
time, or when I rolled an install shield distro...

Please note: the home var should be set to something like:

c:/development/cvs/games/civil

There should be no trailing slash on the var or an error will be caused as
civil appends one when creating the .folders...

--
with an alternative to HOME for Windows users, or we need to define the
variable to have some meaningful value if it does not exist.
--

See above. As many apps do require a HOME var of some description we should
check for this first, if not create the sensible one ("My Documents" springs
to mind) for the muppets...

In the meantime I should probably hit the docs with some more details on
running under windows. There's a couple of "funnies" with it atm...

--
src/gui/select_scenario.py to avoid having Civil read own scenarios. That
should work as a temporary workaround.
--

Indeedy...

Sorry for the crap formatting -- the life of mobile internet is fraught...

Cheers

G

On Sat, 27 Apr 2002, Sean Carroll wrote:

>Ok, i tried running civil with a main client, and an
>ai client. 
>
>Everything connected ok, but when i got to the server
>options on the main client, and clicked the scenario
>button, everything shut down and the python shell gave
>me this:

[snip]

>    scenario.scenario_manager.loadAllScenarioInfos (
>os.environ['HOME'] + '/.civil/scenarios' )
>  File "C:\PYTHON22\lib\os.py", line 387, in
>__getitem__
>    return self.data[key.upper()]
>KeyError: HOME

>I dont see why that happened...i think mainly because
>in the civil-ai code, it receives the scenario id to
>gather the scenario info...BUT in the client, you cant
>select a scenario, so it would send a negative id
>which would mess up the ai's processing abilities for
>the scenario? does that sound right?

I'm pretty sure that the reason is that the environment variable HOME
isn't defined on Windows. Which sounds logical, when I think about it.

Please try in a python interpreter:
	
	>>> import os
	>>> print os.environ['HOME']

If that fails then that's the problem. So, it seems we need to come up
with an alternative to HOME for Windows users, or we need to define the
variable to have some meaningful value if it does not exist.

Sean, you should be able to comment out line 72 in
src/gui/select_scenario.py to avoid having Civil read own scenarios. That
should work as a temporary workaround.


--
  Shadwell hated all southerners and, by inference, was standing at the
  North Pole.
                           -- Terry Pratchett & Neil Gaiman, Good Omens

On Sat, 27 Apr 2002, Sean Carroll wrote:

>whenever i click on scenario, i quits out. bug maybe?

Do you get a stack trace in the dos prompt? There should be one in case of
errors.

--
  Shadwell hated all southerners and, by inference, was standing at the
  North Pole.
                           -- Terry Pratchett & Neil Gaiman, Good Omens

Ok, i tried running civil with a main client, and an
ai client. 

Everything connected ok, but when i got to the server
options on the main client, and clicked the scenario
button, everything shut down and the python shell gave
me this:

******************************************************************************
TODO: local directories in windows? see
initDirectories() in civil.py.
******************************************************************************
local directories created ok
Initializing hardware accelerated mode.
audio: 8 sound channels available
audio: no audio CD found
EditField.paint: cursor at 7
EditField.paint: cursor at 5
Parsing: ../scenarios//scenario10-info.xml...
Parsing: ../scenarios//scenario13-info.xml...
Parsing: ../scenarios//scenario14-info.xml...

Oops, something went wrong. Dumping brain contents: 
---------------------------------------------------------------------------
Traceback (most recent call last):
  File "C:\civil\src\civil.py", line 364, in ?
    main ()
  File "C:\civil\src\civil.py", line 341, in main
    initAll ()
  File "C:\civil\src\civil.py", line 322, in initAll
    setup ()
  File "C:\civil\src\civil.py", line 269, in setup
    if MainDialog ().run () != ACCEPTED:
  File "C:\civil\src\gui\dialog.py", line 200, in run
    returncode = self.wm.handle ( event )
  File "C:\civil\src\gui\widget_manager.py", line 104,
in handle
    return self.handleMouseReleased (event)
  File "C:\civil\src\gui\widget_manager.py", line 221,
in handleMouseReleased
    status = w.handle ( widget.MOUSEBUTTONUP, event )
  File "C:\civil\src\gui\widget.py", line 145, in
handle
    code = self.callbacks[type] ( self, event )
  File "C:\civil\src\gui\main_dialog.py", line 87, in
newGame
    state = dialog.run ()
  File "C:\civil\src\gui\dialog.py", line 200, in run
    returncode = self.wm.handle ( event )
  File "C:\civil\src\gui\widget_manager.py", line 104,
in handle
    return self.handleMouseReleased (event)
  File "C:\civil\src\gui\widget_manager.py", line 221,
in handleMouseReleased
    status = w.handle ( widget.MOUSEBUTTONUP, event )
  File "C:\civil\src\gui\widget.py", line 145, in
handle
    code = self.callbacks[type] ( self, event )
  File "C:\civil\src\gui\new_game.py", line 88, in
selectScenario
    dialog = SelectScenario ()
  File "C:\civil\src\gui\select_scenario.py", line 45,
in __init__
    Dialog.__init__ (self, scenario.sdl)
  File "C:\civil\src\gui\dialog.py", line 59, in
__init__
    self.createWidgets ()
  File "C:\civil\src\gui\select_scenario.py", line 72,
in createWidgets
    scenario.scenario_manager.loadAllScenarioInfos (
os.environ['HOME'] + '/.civil/scenarios' )
  File "C:\PYTHON22\lib\os.py", line 387, in
__getitem__
    return self.data[key.upper()]
KeyError: HOME
---------------------------------------------------------------------------

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

Traceback (most recent call last):
  File "C:\civil\src\civil.py", line 385, in ?
    sys.exit ( 1 )
SystemExit: 1


I dont see why that happened...i think mainly because
in the civil-ai code, it receives the scenario id to
gather the scenario info...BUT in the client, you cant
select a scenario, so it would send a negative id
which would mess up the ai's processing abilities for
the scenario? does that sound right?

---
Sean Carroll

__________________________________________________
Do You Yahoo!?
Yahoo! Health - your guide to health and wellness
http://health.yahoo.com

I think that is actually i great idea. I think it
should be when to units run close enough into each
other, they go into hand-to-hand combat, or bayonette
one another.

Great idea.

---
Sean Carroll


__________________________________________________
Do You Yahoo!?
Yahoo! Health - your guide to health and wellness
http://health.yahoo.com

I had to add a little thing to the scenario format. The "name" attribute
for objectives was missing, and is now added.

The scenario editor is now improved a bit, so i actually loads units into
the "displays" too, as well as objectives. Also simplified it a little bit
and removed an unnecessary abstraction class (Palette).

Hope you all have a nice weekend!

-- 
   Kids! Bringing about Armageddon can be dangerous. Do not attempt it in
   your home.
                             -- Terry Pratchett & Neil Gaiman, Good Omens

Yup,

I did the initial code yesterday for handling melees. A unit that assaults
another unit gets put in a "melee" mode when at point blank range, as is
the defender.

What I was thinking about was that all units that are close enough should
be put in a melee mode. If two units should run into each other in thick,
dark woods they would start meleeing, and not just run on. :) I could
create a class FindMelee or somthing similar and have the engine run it
periodically.

As for the melee combat itself, I think it must be resolved in some
special way. It's not normal combat, it's hand-to-hand combat and very
bloody. Always results in one party breaking up and routing, I think.

Ideas?

--
Voodoo is a very interesting religion for the whole family, even those
    members of it who are dead.
                          -- Terry Pratchett & Neil Gaiman, Good Omens
		       

Congrats everyone!

Civil has made it to 0.70, and the news is now being spread far and wide...

I'd personally like to thank everyone for their work over the last few months, particularly Chakie, who's been a master at doing the nasty work that this change has left us with. You're a hero!

So, enjoy the weekend, and lets keep groovin towards that 1.0 release!

Thanks all!

G

Announced Civil on FM today, and it's already been on the front page. The
project info is still not updated, but I assume it will be changed as soon
as someone of the staff applies it.

-- 

              Many an ancient lord's last words had been:
         "You can't kill me because I've got magic aaargh...."
                                      -- Terry Pratchett, Interesting Times

Hi all,

Today I tagged 0.70 in CVS. It's taken a while, but me and Gareth didn't
think it's worth waiting forever. There are bugs and stuff that just
doesn't work properly, but for now we don't mind them.

It's now time to look forward to what should be in 0.80, get those bugs
fixed and add even more features. :)

I thank you all for your code/gfx, ideas, comments, bugreports, patience
and everything else. 

Let us hope that 0.80 isn't as far off in the future. It should really be
much easier, as there should be only incremental fixes to be done now,
nothing that needs to be revolutionized.

Have a nice weekend!

-- 

        Most gods find it hard to walk and think at the same time.
                                             -- Terry Pratchett, Small Gods

Here's the message as it went out:


Sir,

After much work, sweat and tears, I'm pleased to announce that Civil (a cross-platform, turn-based, networked strategy game, developed using Python, PyGame and SDL -- http://civil.sf.net) has reached version 0.70. 

It's been a long time coming, but as you can see below the changes have been significant, and very much worth the wait. The full changelog for this version:

*    Civil is no longer Realtime
*    Civil no longer requires a separate server
*    Full support for Linux, OS , BSD and Windows as of this version
*    Simple and extendable game engine
*    Scenario Handling greatly improved
*    Improved Scenario Editor
*    A player can store their own local scenarios
*    Civil properly creates directories for user local files
*    Initial support for a lounge system
*    Games can be saved and loaded
*    In-game infrastructure for user input
*    Much more efficient graphics updating
*    Screen resolution can be changed in-game
*    The panel has been removed and replaced with floating windows
*    Civil now supports sound effects and background music
*    In-game CD playing now supported
*    All commands for units work
*    Initial support for combat
*    Weapons handled intelligently
*    Weapon ranges displayed in-game
*    New terrain types and objective icons
*    Game Over handled
*    Credits screen added
*    Full support for animation
*    Proper transformations of the docbook manual to XHTML via XSLT
*    XSLT scenario processing updated for new GFX and changes to scenario markup

I'd be grateful if you could update your readership of this change in status. 

Best Regards

Gareth Noyce

Congrats everyone!

Civil has made it to 0.70, and the news is now being spread far and wide...

I'd personally like to thank everyone for their work over the last few months, particularly Chakie, who's been a master at doing the nasty work that this change has left us with. You're a hero!

So, enjoy the weekend, and lets keep groovin towards that 1.0 release!

Thanks all!

G