civil-devel Mailing List for Civil

On Fri, 23 Nov 2001, Jan Ekholm wrote:

>I'll try to find some time before Christmas to create it all from scratch.

Now is a good time to come up with ideas as to how it *should* have been
done, and what *sucks* especially hard.

After that I'll just "rm -rf " the dirs src/state and src/protocol and
start over.

-- 

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

I was fixing a few bugs related to handling assaults, and while I was at
it looked at some of the other plans too. The code is horrible, the
readability sucks biggus dikkus and I feel like rewriting it all sooner or
later. As it is now it's is a pain to work with.

No, I'm not blaming anybody except myself, but it sure is one pile of
crappy code there. :)

I'll try to find some time before Christmas to create it all from scratch.

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

Hi,

I was wondering about some of the commands in protocol/command, and came
to the conclusion that some of them are unnecessary.

We have;

	* MoveCmd
	* MoveFastCmd
	* RetreatCmd

These all do the same and have the same data. So I propose we waste
MoveFastCmd and RetreatCmd and instead use MoveCmd for all moving. It only
contains a unit id and a new position, so it works just fine. I could then
use the same command for moving a rushing unit.

Or would this break something that I'm now aware of right now?

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

Hi all,

I had the SF crew remove a few extra dirs that have been in the CVS
forever. They are never seen if you update with the P flag, such as:

	% cvs update -z3 -dP

One dir, "civil", causes problems if you forget that P flag, and then try
to ./configure, as the "civil.in" script should be generated into a
"civil" script, which fails as there already is a directory with that
name. 

You *may* need to do a recheckout or edir the CVS/Entries file in the
toplevel directory if there are problems.

-- 

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

For those who have looked at protocol/plan/assault.py there is a last
method runAssault() there which does nothing at the moment, apart from
setting a "done" mode. The idea I had when creating the method was that
assaults will be performed basically like this:

1. unit advances fast towards the enemy
2. unit fires at regular intervals when it is in range
3. when unit has reached a close range (70m right now) it fires one last 
   volley
4. if the unit still is capable (not disorganized) it will start the final
   rush towards the enemy
5. when the unit is "on" the enemy for hand-to-hand combat is initiated
6. one unit is destroyed or pulls out

So far the code works all the way up to 3). This is where the empty method
runAssault() should kick in and do the last stuff. I think that what we
need is:

* a new plan Rush (or similar) that runs a unit full speed towards a
  target. This plan would not be normally accessible to units, i.e. a
  player can not order a unit to rush on demand.

* a new command RushCmd for doing updates to the above. Alternative use
  one of the other commands MoveCmd or MoveFastCmd for the purpose?

* implement some melee code in the engine for resolving melees. T

-- 

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

Hi all,

I just committed a batch of code that cleans up the end game dialog. It
now has a "faded part" behind the labels the make them better visible.
The fading is done after a few seconds, so that the player can admire the
nice background image first. :)

Please have a look. Scenario11 is currently 120 something turns long, and
suitable for "end game testing".

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

> Anyways, remember to fetch the cvsroot-tarball from SF from time to time,
> just in case...

Funny you should mention that, the recent SF paranoia on the web prompted me
to grab the tarball on friday... I still have my doubts about SF in the
medium term, although for now I'm content to believe their hype and trust
that we'll continue to have free service for the lifetime of Civil's
development process...

G

Hmm, it seems to work for everyone else. Something must be fubar on this
machine, as well as on my home machine. I'm silently getting fed up with
CVS at SF. How hard can it be to have it working. I've used a CVS server
at home for a few years, and it's had no problems at all. No weird freezes
there.

This is a bad day, I'm in a *very* bad mood. I feel this whole week is
already doomed. :(

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

On Mon, 2001-11-19 at 04:32, Jan Ekholm wrote:
> 
> Has anybody had weird problems with SF CVS these last few days? Whatever I
> do seems to just hang. 

Nope, success for me this morning as well.

- mikee

> Whatever I do with CVS on SF it all just freezes. An 'add' frezes. An
> 'update' freezes. A 'commit' freezes. Sourceforge is b0rken. Badly b0rken.
> In my end nothing has changed, so the problem is on the SF end. Argh...!

I updated twice yesterday morning and all was fine then. Not tried today, so
can't comment on what's going on...

Sorry, can't help...

G

Hi Jan,

On Mon, Nov 19, 2001 at 01:07:54PM +0200, Jan Ekholm wrote:
> Whatever I do with CVS on SF it all just freezes. An 'add' frezes. An
> 'update' freezes. A 'commit' freezes. Sourceforge is b0rken. Badly b0rken.
> In my end nothing has changed, so the problem is on the SF end. Argh...!

Just did an 'cvs update', worked fine for me
(cvs 1.11.1p1, Debian unstable, too).

Anyways, remember to fetch the cvsroot-tarball from SF from time to time,
just in case...


Uwe.
-- 
Uwe Hermann
uh...@he...     | Unmaintained Free Software:
http://www.hermann-uwe.de | http://www.unmaintained-free-software.org

Anonymous CVS still seems to be working fine. I can update or check out
fresh with no problem. Not really helpful when it comes to add or
commit, but its all I can test.

debian unstable (cvs 1.11.1p1)

Jan Ekholm wrote:

> 
> Fsck.
> 
> Whatever I do with CVS on SF it all just freezes. An 'add' frezes. An
> 'update' freezes. A 'commit' freezes. Sourceforge is b0rken. Badly b0rken.
> In my end nothing has changed, so the problem is on the SF end. Argh...!
> 
> -- 
>     There were no public health laws in Ankh-Morpork. It would be like
>                 installing smoke detectors in Hell.
>                                             -- Terry Pratchett, Feet of Clay
> 
> 
> _______________________________________________
> Civil-devel mailing list
> Civ...@li...
> https://lists.sourceforge.net/lists/listinfo/civil-devel

-- 

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

Fsck.

Whatever I do with CVS on SF it all just freezes. An 'add' frezes. An
'update' freezes. A 'commit' freezes. Sourceforge is b0rken. Badly b0rken.
In my end nothing has changed, so the problem is on the SF end. Argh...!

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

Has anybody had weird problems with SF CVS these last few days? Whatever I
do seems to just hang. An update/commit seems to perform what it should,
but then just hangs there and needs a Ctrl-C. The commit/update seems to
have been completed ok, but I'm not sure.

I also managed to get the old nice error:

cvs [update aborted]: could not chdir to civil: Not a directory

Urk. SF support is really slow too. Last I had this problem it took them
three months to respond. Maybe it would work if I re-checkout my entire
repository? May need to try that. Damn...

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

Hi,

On Fri, Nov 16, 2001 at 02:03:38PM -0600, Sandi Tecuantzi Flores wrote:
> I got the repository of the civil war game, but in this directory dosen't
> exist the configure file, could you can help me and  tellme where can i
> find the file.

After you checked out the code from CVS, you need to run 'autoconf'.
That will create the configure file.

HTH, Uwe.
-- 
Uwe Hermann
uh...@he...     | Unmaintained Free Software:
http://www.hermann-uwe.de | http://www.unmaintained-free-software.org

I got the repository of the civil war game, but in this directory =
dosen't exist the=20
configure file, could you can help me and  tellme where can i find the =
file.

I apreciate your help.

Regard.
Sandi.=20

On Tue, 13 Nov 2001, Gareth Noyce wrote:

>> 0- 25 rebel major victory
>> 26- 40 rebel minor victory
>> 41- 59 draw
>> 60- 74 union minor victory
>> 75-100 union major victory
>>
>> Thus the game would've been a "union minor victory".
>>
>> Does this sound logical?
>
>I quite like this, but it's gonna be a hard job for smaller armies to whip
>the big boys...

IMHO, the point when playing a small army against a larger is that the
smaller is usually defending, and the mission for that smaller army is to
try to hold on to objectives, and not let the attacking large army get
hold of them. Thus it can win by just holding the objectives. 

If we gave points for surviviors the larger army might win without doing
*anything at all*, and that would be slightly boring.

So, when a smaller fights a larger there has to be something that makes
the odds more even, such as a more skilled force, objectives, fatigue etc.

-- 

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

Hi all,

After while of silence I'm back with some more code. I fiddled a little
bit with calculating a score for the players, and this is what I came up
with:

* after the game has ended a score is calculated.
* each player gets 1 point for each killed enemy.
* each player gets 100 points for each destroyed enemy gun.
* players who hold objectives get the value of the objective added.

After that calculation we have a score, say 1500 vs 1000. We add those and
get a total score of 2500. The player with 1500 points had 60% of the
score in the game and gets a final score of 60, while the player with 40%
gets 40. Thus we have two nice values that can easily be compared and a
final result defined. If we assume the union player got 60:

	 0- 25 rebel major victory
	26- 40 rebel minor victory
	41- 59 draw
	60- 74 union minor victory
	75-100 union major victory

Thus the game would've been a "union minor victory". 

Does this sound logical?

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

On Wed, 2001-11-07 at 08:53, Jan Ekholm wrote:
> So we could just add an optional tag <plans> to within the <unit> tag. If
> it's present then it contains a number of <plan> tags, which have as data
> the stuff that toString() spits out.

This should be good.  Major fooling about with protocol may break save
games, but I suppose that's not too bad a problem.

> There is one problem though. The server runs ahead of the clients, so that
> means that when the server saves state then it has already applied a lot
> of commands that the clients will not apply for a few seconds. 

Ick.  I'm not sure a couple turns is enough to worry about, but icky. 
The 'Game saved' message will arrive when the save actually happens, so
that at least will feel right.  You could do saves at the client
instead, would work, but I'm not sure we won't want to do something
later that would break that.

- mikee

After some thinking I came up with the following bright idea. I'd like to
have only one XML format for both saved games and new scenarios, and that
means the unit plans must be in the somewhere. MikeE already came up with
the fact that the current toString() methods of plans can be used for
serializing them. 

So we could just add an optional tag <plans> to within the <unit> tag. If
it's present then it contains a number of <plan> tags, which have as data
the stuff that toString() spits out.

There is one problem though. The server runs ahead of the clients, so that
means that when the server saves state then it has already applied a lot
of commands that the clients will not apply for a few seconds. This means
that a unit may get destroyed during that time. When the player loads a
saved game he/she wants all units the be at the same places where they
were left, and not have some units gone (even though it may have been
almost destroyed when saving). It creates an impression that Civil loses
data when saving. :)

Hmm, comments?

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

Fscking Reply-To...


On Wed, 7 Nov 2001, Uwe Hermann wrote:

>On Wed, Nov 07, 2001 at 01:30:35PM +0200, Jan Ekholm wrote:
>> I think we should supply prebuilt manuals (ps, html and pdf) in all the
>> packages that we eventually build (including source tar.gz). This would
>> make it a lot easier to install from source without having the needed
>> tools (xsltproc and stylesheets).
>
>Depending on how big the docs will be, I'd rather put them in a separate
>package... The code/images is/are big enough right now, I wouldn't add
>even more huge files in the package...

The html manuals shouldn't be big. ~100k max, I think. The ps/pdf are most
likely a lot bigger. Not that the package will be any less huge anyway...
But if people are downloading some funny 100Mb+ demo of some funny game
then they can sure download our 20Mb finalized game too.

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

Hi,

I think we should supply prebuilt manuals (ps, html and pdf) in all the
packages that we eventually build (including source tar.gz). This would
make it a lot easier to install from source without having the needed
tools (xsltproc and stylesheets).

Those that do a CVS checkout and wish to have manuals too would still need
to build the manuals, so we don't check the prebuilt manuals into CVS.

Changes needed:

    Makefile.in: dist should also make the manuals and include them in the
                 final tar.gz. The same goes for all other ways of
                 building packages.

    doc/Makefile.in: use xsltproc instead of db2xxx as it does now

    configure.in: could optionally check for xsltproc and the stylesheets


Comments? Uwe?

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

Michael Earl wrote:

> On Mon, 2001-11-05 at 23:29, John Eikenberry wrote:
> > I think the AI client will probably need to save some state info. At
> > least as I am thinking of it. It would be possible to not save any state
> > info on the AI client, but that would handicap the already stupid AI. In
> > the sense that the player would have memory while the AI wouldn't. 
> 
> Why is this?  Would it be sufficient to give the AI a few seconds before
> restarting the event loop but after scenario load to work up its
> strategy?

I guess this mostly depends on if the AI cheats or not. If it cheats by
using its knowledge of the entire map, it could probably behave as you
describe. Though I thought it'd be interesting to at least start with
the goal of no cheating. The AI has access to the same info (and no
more) as a human player. 

Even with cheating it still might come in handy. Hard to say at this
point, as I only have some vague ideas about large portions of how the
AI could work. As of late I've been spending most of my civil allocated
cycles thinking about the AI's map. 

> In some sense the history isn't meaningful.  Although I suppose if
> you're keeping maps with records of who's moving where etc., such might
> be useful for the AI.

I wasn't thinking of just command history. I was thinking of things like
remembering where enemy units were spotted and the like.

> Alternately (as well?), instead of saving games as scenarios, we could
> save a log of the datastream out of the server and apply it as a 'diff'
> to the starting scenario.  It might take a while to restore, though.  On
> the other hand, this would be really neat as a seperate feature, as it
> would allow you to watch replays of games for alternate perspectives...

To restore the state from this sort of info would require the AI to
basically fast forward through the game to retrieve the state info. That
is, it probably would take a while to restore.

-- 

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

On Wednesday, November 7, 2001, at 05:03 AM, Michael Earl wrote:

> Heh.
>
> Well, I just threw up a couple real quick shots as well, nothing
> exciting.

Thank you Mike!

This is gonna be fun...

G
--
"A computer is essentially a trained Squirrel"
       - Theodor Holm Nelson, Literary Machines 93.1 1/3
--

On 7 Nov 2001, Michael Earl wrote:

>Heh.
>
>Well, I just threw up a couple real quick shots as well, nothing
>exciting.

Got to have a look. I'm absolutely certain you don't look like anything I
think you should look like. Tall, fairly thin, short dark hair, no
glasses, jeans and button-shirt... :)

-- 

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