civil-devel Mailing List for Civil

Hi,

Ok, I've now finished for the day. For your information, the following 
have been committed:

Basic roads, junctions, roads on hills, basic roads in trees. In total 
about 100 hexes have hit the tree today, so update and comment if you 
wish! :)

I've yet to do the roads meeting the edges of woods, and I'm 
contemplating whether to put the more advance road parts in the woods 
i.e.: junctions and stuff... Any preferences?

I'm also not planning on having roads over sand or cracked mud. This 
seems fairly logical to me, but I'll listen to arguments for them...

In addition, I'll be adding roads fading out to grass. These will be 
most useful when roads lead to buildings, but don't expect them for a 
while yet... Oh, and bridges will be appearing in a couple of weeks; now 
that I've finally settled on what the roads will look like... ;-)

Anyway, happy coding!

The-joys-of-a-faster-Photoshop-G

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

Hi,

On Fri, Sep 28, 2001 at 07:04:06PM +0300, Jan Ekholm wrote:
> >Maybe a compromise: People still should announce their major changes on
> >civil-devel (no need to announce fixed typos etc...) and we could have
> >the civil-commits list additionally. It doesn't cause the developer who
> >commits something *any* additional work. He simply commits his stuff
> >exactly the same way as before...
> 
> Ok, I'm all for this. If someone isn't interested in commit info they
> don't have to subscribe to the list.
> 
> What do you need to set it up? SourceForge-wise, I mean.

First, you have to create the civil-commits mailinglist. As soon as
that's available, simply put the following line into the loginfo file in
CVSROOT (do a 'cvs co CVSROOT' in the civil source directory):

DEFAULT /usr/lib/cvs/contrib/log -f /dev/null -m civ...@li... %s


I already added that line to the file, but commented it out as the
mailinglist does not yet exist. As soon as it's available just uncomment
the line and 'cvs commit' the loginfo file.


That's it.

Uwe.
-- 
:------------------ Uwe Hermann <uh...@he...> ------------------:
| http://htsserver.sourceforge.net          -- Holsham Traders            |
| http://www.unmaintained-free-software.org -- Unmaintained Free Software |
:---------------------- http://www.hermann-uwe.de ------------------ :wq -:

Hi,

Well, it looks like Civil has a nearly complete set of roads. In fact, 
by the time you read this, it may have already... I've just got roads 
over hills, and some variants with trees and stuff to do...

Cheers

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

Hi all,

I was working a little on the code for handling destroyed units, and
stumbled on something I think should be changed, but I thought I'd check
here first.

What is the rationale for having Unit.applyDamage() instead of just
letting DamageCmd take care of applying the damage? I think it would be
simpler that way, as DamageCmd anyway has very little to actually do, so
it might as well take care of all that. Applying damage is anyway a very
straightforward process.


--

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

On Sat, 2001-09-29 at 20:19, John Eikenberry wrote:
> I'm currently figuring out the best way to implement the path finding. Its more
> complicated that I remembered due to the hex based map system (classic A* uses
> squares or points).

I fully appreciate this point (have a look at the line-of-sight code in
map.py)...

> Does it look like this: (A)
> 
>   __    __    __
>  /1 \__/  \__/  \
>  \__/  \__/  \__/
>  /  \__/  \__/  \
>  \__/  \__/2 \__/
>  /  \__/  \__/  \
>  \__/3 \__/  \__/
>  /  \__/  \__/  \
>  \__/  \__/  \__/
> 
> 
> Or this: (B)
> 
>   / \ / \ / \ / \ / \ / \ /
>  | 1 |   |   |   |   |   |  
>   \ / \ / \ / \ / \ / \ / \ 
>    |   |   |   |   |   |   |
>   / \ / \ / \ / \ / \ / \ / 
>  |   |   |   |   | 2 |   |  
>   \ / \ / \ / \ / \ / \ / \ 
>    |   |   |   |   |   |   |
>   / \ / \ / \ / \ / \ / \ / 
>  |   | 3 |   |   |   |   |  
>   \ / \ / \ / \ / \ / \ / \ 
>    |   |   |   |   |   |   |
>   / \ / \ / \ / \ / \ / \ / 
> 
> 
> There are different ways the coordinate can be laid out in either case. So
> could someone give the coord values for hexes 1,2,3 for whichever layout is
> most appropriate (A or B). 

B.  Hex 1 is (0,0), hex 2 is (4,2), hex 3 is (1,4).  The hex immediately
below and to the right of hex 1 is (1,1).  Unless I counted wrong.
 
> BTW, what's done with the blank areas on the edges? Is the hex map slightly
> bigger than the player's map? Are they given a terrain graphic but ignored
> otherwise? 

I believe the hex map is slightly bigger.

Also, two further complications for exact calculation as things
presently stand: 

1) each hex decomposes into six triangles (the center and each side),
and each triangle may have different terrain.  See hex.py and map.py

2) Movement granularity is by pixel, not by hex, and a hex is something
like 48-pixels across (don't remember the numbers right now).

I don't know if trangles make things better or worse.  You might just
stick to hex-based calculation as to point 2 unless you have some
powerful magics handy :).

- mikee

I'm still here... just been a bit overwhelmed with work as of late. That
should ending thankfully (not the work... the overwhelmed part ;).

I'm currently figuring out the best way to implement the path finding. Its more
complicated that I remembered due to the hex based map system (classic A* uses
squares or points).

Related to this I have a quick question on the hex layout.  There are different
algorithms for A* distance calcuations based on the way the hex grid system
works. I know hexes are kept in a 2-dem list on the map object. But I'm not
sure how these are layed out on the map. 

Does it look like this: (A)

  __    __    __
 /1 \__/  \__/  \
 \__/  \__/  \__/
 /  \__/  \__/  \
 \__/  \__/2 \__/
 /  \__/  \__/  \
 \__/3 \__/  \__/
 /  \__/  \__/  \
 \__/  \__/  \__/


Or this: (B)

  / \ / \ / \ / \ / \ / \ /
 | 1 |   |   |   |   |   |  
  \ / \ / \ / \ / \ / \ / \ 
   |   |   |   |   |   |   |
  / \ / \ / \ / \ / \ / \ / 
 |   |   |   |   | 2 |   |  
  \ / \ / \ / \ / \ / \ / \ 
   |   |   |   |   |   |   |
  / \ / \ / \ / \ / \ / \ / 
 |   | 3 |   |   |   |   |  
  \ / \ / \ / \ / \ / \ / \ 
   |   |   |   |   |   |   |
  / \ / \ / \ / \ / \ / \ / 


There are different ways the coordinate can be laid out in either case. So
could someone give the coord values for hexes 1,2,3 for whichever layout is
most appropriate (A or B). 

BTW, what's done with the blank areas on the edges? Is the hex map slightly
bigger than the player's map? Are they given a terrain graphic but ignored
otherwise? 

Thanks. 

-- 

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 Fri, 2001-09-28 at 02:07, Jan Ekholm wrote: 
> I think the plan should be aborted if the target is not visible anymore.
> There's no target, so nothing to shoot at. 


My thinking (and more code would be necessary, it should be pretty easy)
was that in skirmish mode, if there is no target the unit should pick a
new one; or, if none was in range at all, remain idle in skirmish mode
(possibly continue to reload?). Partly this is complicated more than it
should because the plans (attack at least) are partly engine code and
partly server-side AI.  I'm not sure if it makes sense to seperate that,
or if the server-side AI is so limited that it's not a problem, or if
I'm ranting meaninglessly....?

I like the unit destruction plan, and yeah, that's most likely my pygame
problem.  If there's no update to libc shortly I'll figure a plan B.

 - mikee

Hi,

On Wed, Sep 26, 2001 at 12:47:17PM +0300, Jan Ekholm wrote:
> What could be added is a link or reference to the main manual, either
> where it's installed locally or on SourceForge. If it refers to the
> locally installed version the man-pages should probably pass through
> autoconf variable substitution.

Yes, that would be nice, IMHO. We could then also let several other
things be generated by autoconf, e.g. the list of authors and
contributors in the same in all three manpages, so we could just put
that info into configure.in, so we don't have to change three manpages
anymore (if there's a new contributor for example) but only the
configure.in file...

If noone objects, I'll implement that as soon as I find enough time for
it...

I'll remove doc/*.6 and add doc/*.6.in to the repository. At
installation time the *.6.in will geenrate the *.6 files which will then
be copied to /usr/share/man or whatever...


Uwe.
-- 
:------------------ Uwe Hermann <uh...@he...> ------------------:
| http://htsserver.sourceforge.net          -- Holsham Traders            |
| http://www.unmaintained-free-software.org -- Unmaintained Free Software |
:---------------------- http://www.hermann-uwe.de ------------------ :wq -:

Hi,

On Fri, Sep 28, 2001 at 08:47:33AM +0300, Jan Ekholm wrote:
> It could be a good idea, as all commits then get "announced". But it also
> removes the need for developers to communicate their changes, as "it's
> anyway going on the list". I think I rather have people mail to the main
> list when they have done something major that's worth mentioning. But
> that's just my current opinion, if there's good reasons for such a list
> please tell me.

Well, the only reason why I'd like such a list is to be automatically
notified if any changes were made to CVS...
But, you're right, without such a list there's probably more
communication on civil-devel...

Maybe a compromise: People still should announce their major changes on
civil-devel (no need to announce fixed typos etc...) and we could have
the civil-commits list additionally. It doesn't cause the developer who
commits something *any* additional work. He simply commits his stuff
exactly the same way as before...

Just a suggestion...

Uwe.
-- 
:------------------ Uwe Hermann <uh...@he...> ------------------:
| http://htsserver.sourceforge.net          -- Holsham Traders            |
| http://www.unmaintained-free-software.org -- Unmaintained Free Software |
:---------------------- http://www.hermann-uwe.de ------------------ :wq -:

On Fri, 28 Sep 2001, John Eikenberry wrote:

>Jan Ekholm wrote:
>
>> Good to hear. Are you on a Windows or Linux machine?
>
>Dual boot. Though I see Windows as strictly a gaming platform. For
>everything productive I use Linux.

Could you please try it out some day? Or don't you have a 3-button mouse?

--

   Sometimes it's better to light a flamethrower than curse the darkness.
                                            -- Terry Pratchett, Men at Arms

Jan Ekholm wrote:

> Good to hear. Are you on a Windows or Linux machine?

Dual boot. Though I see Windows as strictly a gaming platform. For
everything productive I use Linux.

-- 

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 Fri, 28 Sep 2001, John Eikenberry wrote:

>TheG wrote:
>
>> Well, that's problem. In window the middle button is the mouse wheel, 
>> but that's a separate thing entirely... doubt it'll work, but I don't 
>> have either to test unfortunately.
>
>On most mice I've seen the mouse wheel can also be depressed for the middle
>mouse button. And it should be possible, I've played several windows games
>that used the middle mouse button.

Good to hear. Are you on a Windows or Linux machine?

--

              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,

Mike asked a few days ago how destroyed units should be dealt with. There
are a few ways to do it that I'm aware of:

1. delete the unit entirely from all structures. 

It's the easiest way, but we lose all ways of referring to the unit later.
It could be nice to be able to calculate losses and show them on the "end
game" screen. We'd also not know if any organization had lost any
companies.


2. move the destroyed units to a separate structure.

Also easy to handle, but needs some more code when serializing. I think we
must save destroyed units too when games are saved.


3. mark the unit as destroyed in the Unit class.

The flag must be manually honored everywhere, which means that very much
code must be altered and checked up. This is design-wise the cleanest
approach, but means most work.


Personally I advocate version 2. I can easily adapt the saving/loading
code to save the destroyed units and when loading automatically place them
in the "destroyed structure".

Speak up now or forever shut up... :)

--

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

TheG wrote:

> Well, that's problem. In window the middle button is the mouse wheel, 
> but that's a separate thing entirely... doubt it'll work, but I don't 
> have either to test unfortunately.

On most mice I've seen the mouse wheel can also be depressed for the middle
mouse button. And it should be possible, I've played several windows games
that used the middle mouse button.

-- 

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 27 Sep 2001, Michael Earl wrote:

>Trying to get going again, added some case-handling stuff to
>skirmish-mode.  I *think* it's a no-brainer, but check - I'm getting
>segfaults now on startup, something wrong with my pygame...

You mean the code:

  # are we facing the enemy?
  if not self.pointedAt (unit, target):
        # nope, so turn ourselves to face the target. We use the inherited
        # code from 'rotate' to take care of that. is this the first time
        # we call this method?
            
        # ** Does it matter? If they moved, we should rotate again, yes? - MLE
            
        if not self.executionstarted:
            # this is the first time called, setup for execution
            self.executionstarted = 1

I think you are right. If they move we should turn to follow them. So I
changed the code so that all code except the calculateTurnSpeed() call is
outside the "if not self.executionstarted" check.

Later in runLoop() there's this code:

  # what should we do?
  #  ready to shoot?
  if action == 'p' or action == 'r':
      # pause or reload, do nothing
      pass
  else:
      # able to shoot?
      if self.inRange(unit,target) and target.isVisible():
         # fire! add a new entry to the combat schedule in the server
         # engine. this gets resolved later 
         scenario.engine.getCombatSchedule ().add ( self.targetid, unit )

      else:
         # ready to shoot, but can't.  Don't shoot, don't advance counter.
         return

  # advance loop position
  self.looppos += 1


I think the plan should be aborted if the target is not visible anymore.
There's no target, so nothing to shoot at. It would be a matter of moving
the target.isVisible() outside and sending a DoneCmd if not visible?
Agree? Otherwise we'll have out unit track the hidden enemy by always
facing it. The enemy could then be pinpointed bu having two units track
the same unit. If it moves out of sight the enemy can still be
triangluated by looking at the facings of the two units. Not good. :)

Actually, I think I'll move it now.

--

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

On Thu, 27 Sep 2001, Uwe Hermann wrote:

>Hi guys,
>
>how about setting up a new mailinglist which will automatically receive
>a mail about who changed which file (and the commit changelog)...
>
>This is quite useful IMHO, every developer is always up-to-date with the
>current status of the code-base...
>
>The technical side is quite simple, I've done this for several other
>projects (mine and those where I'm just a contributor).

It could be a good idea, as all commits then get "announced". But it also
removes the need for developers to communicate their changes, as "it's
anyway going on the list". I think I rather have people mail to the main
list when they have done something major that's worth mentioning. But
that's just my current opinion, if there's good reasons for such a list
please tell me.

--

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

On 27 Sep 2001, Michael Earl wrote:

>Trying to get going again, added some case-handling stuff to
>skirmish-mode.  I *think* it's a no-brainer, but check - I'm getting
>segfaults now on startup, something wrong with my pygame...

Running Debian unstable and pygame 1.2? Then libc6 is b0rken. Was a mail
about it yesterday on the pygame list.

--

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

Trying to get going again, added some case-handling stuff to
skirmish-mode.  I *think* it's a no-brainer, but check - I'm getting
segfaults now on startup, something wrong with my pygame...

Hi guys,

how about setting up a new mailinglist which will automatically receive
a mail about who changed which file (and the commit changelog)...

This is quite useful IMHO, every developer is always up-to-date with the
current status of the code-base...

The technical side is quite simple, I've done this for several other
projects (mine and those where I'm just a contributor).

Comments?


Uwe.
-- 
:------------------ Uwe Hermann <uh...@he...> ------------------:
| http://htsserver.sourceforge.net          -- Holsham Traders            |
| http://www.unmaintained-free-software.org -- Unmaintained Free Software |
:---------------------- http://www.hermann-uwe.de ------------------ :wq -:

On Thu, 27 Sep 2001, TheG wrote:

>
>On Thursday, September 27, 2001, at 11:03 AM, Jan Ekholm wrote:
>
>>
>> Came to think about the fact that Windows does not really use the middle
>> button for anything. Is it enabled at all, i.e. do events from the 
>> middle
>> button get to SDL/pygame at all?
>>
>
>Well, that's problem. In window the middle button is the mouse wheel, 
>but that's a separate thing entirely... doubt it'll work, but I don't 
>have either to test unfortunately.

Hmm, this could be the case, yes. Well, Windows folks will just have to
get an OS that handles the events properly then.

>Something for later perhaps?

Yeah. If it works we'll be happy. If it doesn't we'll still be happy.

--

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

On Thursday, September 27, 2001, at 11:03 AM, Jan Ekholm wrote:

>
> Came to think about the fact that Windows does not really use the middle
> button for anything. Is it enabled at all, i.e. do events from the 
> middle
> button get to SDL/pygame at all?
>

Well, that's problem. In window the middle button is the mouse wheel, 
but that's a separate thing entirely... doubt it'll work, but I don't 
have either to test unfortunately.

Something for later perhaps?

G

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

       - Author unknown, originally seen on Cix...
--

Came to think about the fact that Windows does not really use the middle
button for anything. Is it enabled at all, i.e. do events from the middle
button get to SDL/pygame at all?

What if they aren't propagated at all? Hmm, my stand on that issue is that
I really don't care too much. :) It's a nice that works as it is now, and
I don't want to fiddle with it more than necessary...

--

              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,

I added an IMHO nice feature a few minutes ago. The map can be
scrolled by pressing (and holding) the middle mouse button. Moving the
mouse scrolls the map until the button is released.

Oh, I just tested it a little bit more, and it just seem to "work ok".
Even when a unit is selected or when waiting for the player to click a
movement destinationm there are no problems. Great stuff, and 20 lines of
code... :)

--

              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,

Well, the minimap seems to work ok now. Units no longer jump all over the
map when scrolling. I have no idea what happens when a map is larger than
64x64 (what fits in the panel), i.e. when the minimap must be scrolled.
I'll fix problems later when we have a map that big.

--

              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 Wed, 26 Sep 2001, TheG wrote:

>
>On Tuesday, September 25, 2001, at 10:54 PM, Uwe Hermann wrote:
>
>> Hi everyone.
>>
>> I wrote and commited manpages for civil, civil-server and civil-ai
>> today.
>
>Superb :)
>
>I've added you to the contributors list on the website. We might have to 
>dedicate a page to this in order to properly thank people... Don't let 
>me forget!

Yeah, we really should have a separate "thank you" page, I think. Some
day.

--

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