civil-devel Mailing List for Civil

On 27 Mar 2002, Michael Earl wrote:

>On Wed, 2002-03-27 at 12:37, Jan Ekholm wrote:
>> 1. easily get previous/next unit. A unit is always part of a regiment or
>> battallion, so there should be some easy way to get the next/previous unit
>> in the same formation. If a unit is the last in its formation 'next'
>> should get the HQ of the next formation. Just some traversing of the data
>> in scenario.brigades, and setting the current unit.
>> 
>> 2. find the hq (and activate it) of a selected unit. This is even easier
>> to do.
>
>Another useful similar thing would be to go the next level up/down the
>organizational chart.  Select a unit, then hit a key to select its
>entire battallion (unit is still primary selection), hit again to select
>its regiment, then again to select its corps... (well, I may have
>structure wrong, but you hopefully get idea).  Could go back down, too. 
>Dunno, maybe this isn't as necessary in turn-based as there is time to
>give individual orders?

It could be very useful, at least for the "lower" organizations, such as
battallion and regiment. It gives you a fast overview of where the troops
that belong to a HQ are, wether they still are in command range etc.

I'll add the feature to my mental TODO list.

-- 
    Pets are always a great help in times of stress. And in times of 
    starvation too, o'course.
                                        -- Terry Pratchett, Small Gods

On Wed, 2002-03-27 at 12:37, Jan Ekholm wrote:
> 1. easily get previous/next unit. A unit is always part of a regiment or
> battallion, so there should be some easy way to get the next/previous unit
> in the same formation. If a unit is the last in its formation 'next'
> should get the HQ of the next formation. Just some traversing of the data
> in scenario.brigades, and setting the current unit.
> 
> 2. find the hq (and activate it) of a selected unit. This is even easier
> to do.

Another useful similar thing would be to go the next level up/down the
organizational chart.  Select a unit, then hit a key to select its
entire battallion (unit is still primary selection), hit again to select
its regiment, then again to select its corps... (well, I may have
structure wrong, but you hopefully get idea).  Could go back down, too. 
Dunno, maybe this isn't as necessary in turn-based as there is time to
give individual orders?

- mikee

Hi all,

I came to think of a few extra features I want to add to Civil. They are
all pretty minor and should be quite easy to implement. I've been thinking
a bit what it would be like to actually play Civil, and what it lacks
compared to other games. The features are:

1. easily get previous/next unit. A unit is always part of a regiment or
battallion, so there should be some easy way to get the next/previous unit
in the same formation. If a unit is the last in its formation 'next'
should get the HQ of the next formation. Just some traversing of the data
in scenario.brigades, and setting the current unit.

2. find the hq (and activate it) of a selected unit. This is even easier
to do.

3. denter the map around the currently selected unit. This is useful if
you have a unit selected, but scroll the map and "lose" the unit. Just hit
a key and the unit is again as centered as it can be. Very useful.

Comments? Other missing small usability things?

-- 
    There were no public health laws in Ankh-Morpork. It would be like
                installing smoke detectors in Hell.
                                            -- Terry Pratchett, Feet of Clay

On Tue, 26 Mar 2002, Korruptor wrote:

Oh, you got a mail straight to the list this time. :)

>These changes will require some mods to the various XSLT bits I'm working.
>Nothing too major for scenario2html pov, but enough to require me to sit
>down and do some reworks and tidying that I had planned...

>I'm planning to spend some time on all the XML bits over the weekend as it's
>a holiday. I'll start committing stuff as it gets completed...

Well, the changes are all done now. At least everything I came to think
about when doing the "Edit unit" dialog for the editor. 

Of course, as soon as Gareth has updated the XSLT I'll break the scenario
format again... ;)

-- 
     "I name you... Esmeralda Margaret Note Spelling of Lancre!"
                                      -- Terry Pratchett, Carpe Jugulum

On 26/3/02 1:22 pm, "Jan Ekholm" <ch...@in...> wrote:

> I've done some additions to Civil today that also change the scenario
> format. I added a <rank> tag to each commander of each organization. This
> means that the parser expects the tag to be there, and all the old
> scenarios that are in CVS don't yet have it. I'll fix it some day, but for
> now all scenarios are broken, and you'll get a nice stack trace (I think)
> if you try to load them.

Hi,

I've already mentioned this to Jan on IRC, but for the benefit of the rest
of you:

These changes will require some mods to the various XSLT bits I'm working.
Nothing too major for scenario2html pov, but enough to require me to sit
down and do some reworks and tidying that I had planned...

I'm planning to spend some time on all the XML bits over the weekend as it's
a holiday. I'll start committing stuff as it gets completed...

Cheers

G

Hola,

I've done some additions to Civil today that also change the scenario
format. I added a <rank> tag to each commander of each organization. This
means that the parser expects the tag to be there, and all the old
scenarios that are in CVS don't yet have it. I'll fix it some day, but for
now all scenarios are broken, and you'll get a nice stack trace (I think)
if you try to load them.

I also need to add some other data to the scenarios, so I'll do all the
updates at once. The extra stuff that's needed is at least a tag that
tells the "number of weapons" the unit has. An infantry unit probably has
one rifle for each man, but artillery units will not have one gun for each
guy. :) 

I've also thought about adding some kind of system where each unit may
have primary and secondary weapons. An artillery unit may have 3 guns, but
will also have a number of rifles too. That addition will require "a few"
changes all over the code, and it'll have to be for now. There are other
things that need some attention...


-- 

                  - "What're quantum mechanics?"
        - "I don't know. People who repair quantums, I suppose."
                                               -- Terry Pratchett, in Eric

>> What's left now for a nice 0.70 tag is:
>> 
>>   * get the scenario editor up and running
>>   * do some fixes for combat
>
>Oooo! I'm so excited... It'll be good to make public the amount of progress
>that you've made in the last few months...

Maybe we should keep quiet until 1.0 is out? Would avoid giving people
false impressions and unnecessarily boost expectations. Sure, people would
think we're a dead project, but that's their problem.


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

Reply-to...

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

---------- Forwarded message ----------
Date: Thu, 21 Mar 2002 21:33:19 +0000
From: Korruptor <the...@bt...>
To: Jan Ekholm <ch...@in...>
Subject: Re: [Civil-devel]The road ahead

> What's left now for a nice 0.70 tag is:
> 
>   * get the scenario editor up and running
>   * do some fixes for combat

Oooo! I'm so excited... It'll be good to make public the amount of progress
that you've made in the last few months...

> What's needed now is some ideas on *how* it should work: what is good,
> bad, missing, buggy or just plain stupid. All negative feedback is
> welcome. I'd rather hear it from people on this list *now* than from the
> /. crowd after we release.

Hmmm, that could be tricky from my end. I have no spare machine that I can
easily put debian or linux in general on. I hear qt for OS X is out, so I
may try and get that and see how far my progress is, but I'm hesitant to
spend a lot of time trying to get this to work...

Any other Civil-ians who'd be willing to beta test?

Cheers

G

Yup,

Apart from a few fixes that'll come along the way, I think loading/saving
games is good enough for now. I'll leave it, but more and better code is
always welcome. :)

What's left now for a nice 0.70 tag is:

    * get the scenario editor up and running
    * do some fixes for combat

The latter is quite easy, just add some old existing code to
engine/ai/resolve_combat.py and it should be done. After that w can start
adding modules for handling morale, fatigue etc. I think it's going to be
quite simple to do most of that stuff with modules, and I like the concept
too.

The scenario editor is some more work. Currently it *works*, but it's a
pain to use. It lacks needed features and isn't user friendly. For those
wanting to test it, there is a python-qt (or similar) package in Debian
unstable. I got the .deb and installed it on testing, works like a charm.

Making maps works well, I've used the editor for that for over a year now
(not that I've made that many maps...). 

What's needed now is some ideas on *how* it should work: what is good,
bad, missing, buggy or just plain stupid. All negative feedback is
welcome. I'd rather hear it from people on this list *now* than from the
/. crowd after we release.

I have only so much time, but I'll try to fix the most b0rken things and
the most needed missing features.

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

I'm not sure Gareth's mailer can do Reply-To, so I just bounce here a mail
I think he intended for the list. :)

--
'Educational' refers to the process, not the object. Although, come to think
of it, some of my teachers could easily have been replaced by a cheeseburger.
                                   -- Terry Pratchett, alt.fan.pratchett
			   


---------- Forwarded message ----------
Date: Wed, 20 Mar 2002 17:20:55 +0000
From: Korruptor <the...@bt...>
To: Jan Ekholm <ch...@in...>
Subject: Re: [Civil-devel]Loading games

On 20/3/02 3:54 pm, "Jan Ekholm" <ch...@in...> wrote:

> 
> ...seems to work ok now. Also a lot of small things fixed. When saving a
> game the id of the local player is also saved, so the local player can't
> later load a game and play as the other player. But if he/she wants to
> cheat it's not too difficult to do, so this is more a convenience thing.
> 
> *phew*


Many thanks for all your hard work recently Jan. You've done a superb job...

For those who think I've fallen off the map, well, I have kinda. Got tied up
with some other game projects, and also bought some new hardware...

I'm currently working on the XSLT for manuals, updating the sceanrio2HTML
XSLT, and pumping out a schema for the scenarios. I may even get a new panel
done in time for 0.70 being tagged, but don't hold your breath...

Hope everyone is happy and well...

Laters

G

...seems to work ok now. Also a lot of small things fixed. When saving a
game the id of the local player is also saved, so the local player can't
later load a game and play as the other player. But if he/she wants to
cheat it's not too difficult to do, so this is more a convenience thing.

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

Hullo,

Saving games works now. Loading not yet, I'll fix that tomorrow, I think.

-- 
         In the Beginning there was nothing, which exploded.
                                        -- Terry Pratchett, Lords and Ladies

On Tue, 19 Mar 2002, Jan Ekholm wrote:

>On Tue, 19 Mar 2002, Korruptor wrote:
>
>>Usual no list at work syndrome...
>>
>>> Any ideas for naming of saved games? There is two major ways to do it:
>>> 
>>> 1. use a smart automatical naming scheme, based on scenario, time, players
>>>  etc.
>>> 
>>> 2. ask the player for a name.
>>> 
>>> I actually like neither too well, but from a player point of view 2) is
>>> better, as it allows the player to more easily recognize his/her games.
>>> The problem with that approach is that I (or someone else. <hint>) have to
>>> code up a playfield layer and state for getting textual input from the
>>> user. Not too fond of doing that...
>>
>>
>>Unfortunately 2 does seem to be the best solution. Didn't SLM extend the
>>civil-dialog stuff far enough?! ;-P
>
>Yes, But it still requires a lot of copy/paste programming. But the
>FrameWork(tm) we have should provide flexible enough to handle it. I'll
>attack it right away... :)

... and such a beast is mostly done. There is now a way to ask the user
for textual input. The code is mostly ripped from gui/editfield.py, and
can be used like this in the state classes:

    # ask the question with some default text
    text = input.Input ( ['Some question'], 'default text' ).run ()
    if text != None:
       # dialog was accepted
       ...
    else:
       # dialog was rejected
        ...

Simple enough. I'll add the actual saving a little later. It's actually
just a matter of a few lines of code. :)

Ah, a Good Day(tm). Not too many of them so far this year. 0.70 is IMO
approaching quite fast. 

-- 
     "I name you... Esmeralda Margaret Note Spelling of Lancre!"
                                      -- Terry Pratchett, Carpe Jugulum

On Tue, 19 Mar 2002, Korruptor wrote:

>Usual no list at work syndrome...
>
>> Any ideas for naming of saved games? There is two major ways to do it:
>> 
>> 1. use a smart automatical naming scheme, based on scenario, time, players
>>  etc.
>> 
>> 2. ask the player for a name.
>> 
>> I actually like neither too well, but from a player point of view 2) is
>> better, as it allows the player to more easily recognize his/her games.
>> The problem with that approach is that I (or someone else. <hint>) have to
>> code up a playfield layer and state for getting textual input from the
>> user. Not too fond of doing that...
>
>
>Unfortunately 2 does seem to be the best solution. Didn't SLM extend the
>civil-dialog stuff far enough?! ;-P

Yes, But it still requires a lot of copy/paste programming. But the
FrameWork(tm) we have should provide flexible enough to handle it. I'll
attack it right away... :)

-- 

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

Hup,

Any ideas for naming of saved games? There is two major ways to do it:

1. use a smart automatical naming scheme, based on scenario, time, players
   etc.

2. ask the player for a name.

I actually like neither too well, but from a player point of view 2) is
better, as it allows the player to more easily recognize his/her games.
The problem with that approach is that I (or someone else. <hint>) have to
code up a playfield layer and state for getting textual input from the
user. Not too fond of doing that...

Hmm, maybe I just have to bite the bullet and do 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

On Tue, 19 Mar 2002, Korruptor wrote:

>On 19/3/02 7:52 am, "Jan Ekholm" <ch...@in...> wrote:
>
>> 
>> What does OSX print for the following:
>> 
>> import sys
>> print sys.platform
>
>Darwin...

Ok, it's now added as a "linuxy" system that has home directories.

-- 
  +++ Divide By Cucumber Error. Please Reinstall Universe And Reboot +++
                                        -- Terry Pratchett, Hogfather

Ehlo,

Well, adding compressed scenarios wasn't that much work. Python has a
ready "gzip" module that contains a GzipFile class that works as a normal
file. So it was mainly a matter of replacing:

	file = open (filename, mode)
with
	file = gzip.GzipFile (filename, mode)
	
Seems to work ok, and I already gzipped our fabulous scenarios and checked
them in. Please remember to use the command "cvs add -kb scenario.xml.gz"
to add compressed scenarios, as they are now binary files.

The scenario editor also seems to work just fine with the new scenario
formats. It also writes the info files just fine. This means that as the
in-game saving will use the same writing funtions as the scenario editor
(the class ScenarioWriter), saving in-game should also work out of the box
as soon as we figure out a naming convention for the saved games. Any
suggestions?

The main in-game scenario loading, ie, the activated when starting a new
game and pressing "Scenario" will already load scenarios from
$HOME/.civil/scenarios/ too. This implies that if you have some testing
scenario you don't want to add to CVS you can put it there.

-- 
  +++ Divide By Cucumber Error. Please Reinstall Universe And Reboot +++
                                        -- Terry Pratchett, Hogfather

What does OSX print for the following:

	import sys
	print sys.platform

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

Ok, I feel productive today, so another idea (and unless any counterideas
are stated, it's a fact too). :)

I will make Civil save games in: 

	$HOME/.civil/saved_games/

This will make saved games personal for each user, which I think is good.
It's easy to read the info-files from this directory when loading games. I
think that'll be the next thing on my Civil-agenda.

Next, I think I'll make scenarios that the user downloads (from the lounge
[if we still want that POS to exist] or some other means) go into:

	$HOME/.civil/scenarios/

Scenarios can also go into /usr/share/games/civil/scenarios/, but that
requires superuser privilegies. Installing them into the personal
scenarios directory should be straightformard and it's easy to make the
server find them from that directory. Hmm, ok, it was actually one line of
code to add that functionality, so it's already done.

What needs to be thought out is how to do stuff for Windows. I think OSX
has proper users (most importantly, a valid $HOME directory) and that this
code should work as-is there. I'd appreciate if any Windows-guru could
look into what goes wrong, and come up with a suggestion for a solution.
We could of course just shuffle all scenarios in the registry, all other
apps put all data there too. :)

Another thing, while I'm bitching and whining. Maybe scenarios should be
compressed? Then the main scenario file would be saved as a *.zml.gz. Hmm,
does Windows handle multiple extensions? I don't remember. On a real
system the {de}compression can be handled transparently while
{save,open}ing the file.

Comments?

-- 

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

Well, it was quite easy to convert Civil to use only so called "info"
files. Currently they are supposed to be the normal filename, but with an
added "-info" extension, i.e. we could have these files:

	waterloo.xml
	waterloo-info.xml

It's not noticeably slower, and sure makes it easier to manage. When we
now add scenarios we need to send two files, but the files need not be
installed in any way except copied to the proper dir. It would thus be
easy to make packages for scenarios, as they need not fiddle with any
scenarioindex.xml files anymore, just blotch in two files.

Saving games can be made easy, as the code for saving just has to create
two files and not bother with any other files that may be present in the
same directory.

Well, I think I'll test some more and then just commit then fixes.


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

On Sun, 2002-03-17 at 15:58, Jan Ekholm wrote:
> Any others want to vote/comment?

Seems reasonable.  The only other option I can think of offhand is to
embed all the index information in the filename, which probably isn't a
good idea. ;)

Any issues here with index and scenario files getting mismatched
somehow?  (I suppose you can just have it rebuild indexes for scenarions
with missing ones...)

- mikee

On Sun, 17 Mar 2002, Korruptor wrote:

>> 3. extract the <sceanrioinfo> data from each saved game and store it in a
>> separate file. So we could have for a saved game called "chakie1" the
>> files chakie1.xml and chakie1-index.xml, where the latter is just the info
>> about the saved game.
>
>> So, what do you think?
>
>
>Yeah, I think I'm with you here. Option 3 seems to be the most likely way
>forward, and the increase in file numbers is no problem.
>
>Gets my vote! :-)

Good! 

Any others want to vote/comment?

-- 
  The trouble with being a god is that you've got no one to pray to.
                                        -- Terry Pratchett, Small Gods

> 3. extract the <sceanrioinfo> data from each saved game and store it in a
> separate file. So we could have for a saved game called "chakie1" the
> files chakie1.xml and chakie1-index.xml, where the latter is just the info
> about the saved game.

> So, what do you think?


Yeah, I think I'm with you here. Option 3 seems to be the most likely way
forward, and the increase in file numbers is no problem.

Gets my vote! :-)

Cheers

G

Hi ho,

I was was thinking a bit about the issues involved in saving games, and
there is one thing that needs to be solved somehow, namely the issue of
the index files. There is a few ways to do it:

1. use no index files at all. Have Civil parse parts of all saved files to
get the needed data.
	
    + easy
    - slow, as the data is picked out from a DOM-tree, so the whole file 
      must be parsed

2. use a similar index file to the normal scenario index file. This would
work in exactly the same way as all the normal scenarios, with all
advantages and drawbacks.

    + easy to read in the data when the index is updated
    - regenerating the index file can be very slow for a lot of saved
      games
    - need to regenerate the index file when saved games are deleted

3. extract the <sceanrioinfo> data from each saved game and store it in a
separate file. So we could have for a saved game called "chakie1" the
files chakie1.xml and chakie1-index.xml, where the latter is just the info
about the saved game.

    + very easy to parse
    + fast to generate, just save the info in a separate file when saving
    - can be slow to parse in the info about a lot of saved games, as a
      new parser must be created for each file

Any comments? I personally somehow prefer 3, and with some adaption it
could maybe be used for all the scenarios we have. It would get rid of the
more or less controversial and not-too-liked index file, at the expense of
some extra parsing (speed loss) and a duplicated number of files (no big
deal, imho).

So, what do you think?

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

On Thu, 14 Mar 2002, Jon Eriksson wrote:

>Hi, my name is Jon Eriksson.
>  I'm quite new with the linux environment (but i've coded C and C++ for 
>a while)
>However.. I was woundering, where can i get information about coding 
>graphical games (such
>as civil.. using sprites and so on).. All help would be appreachiated.

Hi Jon,

I think you can get information basically anywhere. :) There are a number
of big sites on the 'net full of nice info. And then there's Google, which
satisfies all your information needs. I'm not really the correct one to
ask for links, but I'd go to:

	http://www.gamedev.net/
	http://www.flipcode.com/

and just look around. They all have a lot of tutorials and articles about
gfx/sprite programming.

Good luck!

	Chakie
-- 

                  - "What're quantum mechanics?"
        - "I don't know. People who repair quantums, I suppose."
                                               -- Terry Pratchett, in Eric