civil-devel Mailing List for Civil

On 31/7/02 9:36 am, "Jan Ekholm" <ch...@in...> wrote:

> 
> I played around some with the setup dialogs today. Just clicked around a
> bit, no code changes. I did notice that a few of the big buttons down in
> the screen, such as Lounge, Back, Credits etc do jump up and down a few
> pixels when flipping between screens. This seems to be because the buttons
> are all actually of different sizes. They have at leats varying heights,
> from 69px to 71-72px. The extra size does seem to be a little extra
> "frame" around the actual button content, thus it makes them visibly move
> a few pixels.
> 
> I could remove the little extra space, but I think I'd just fsck up the
> images somehow.

Yup, I noticed this a long while back. Had much to do with my not creating a
template when I first did them, so any additional ones have been "re-cut".

I'll fix this up - it's been added to my TODO :)

G

-- 
  "You know, I have one simple request...and that is to have messages with
  freakin' laser beams attached to their headers. Now evidently my MIME
  specification informs me that can't be done. Uh, can you remind me what
  I pay you people for? Honestly, throw me a freakin' bone here."
    
    -- http://www.advogato.com/person/fejj/diary.html?start=77
--

I played around some with the setup dialogs today. Just clicked around a
bit, no code changes. I did notice that a few of the big buttons down in
the screen, such as Lounge, Back, Credits etc do jump up and down a few
pixels when flipping between screens. This seems to be because the buttons
are all actually of different sizes. They have at leats varying heights,
from 69px to 71-72px. The extra size does seem to be a little extra
"frame" around the actual button content, thus it makes them visibly move
a few pixels.

I could remove the little extra space, but I think I'd just fsck up the
images somehow.

-- 
You've got a lot of time for abstract thought when you've got your hand
    stuck up a dead badger.
                                 -- Terry Pratchett, Johnny and the Bomb

Yup, I did some small changes to the way that units are handled when
several units are selected.

* when several units are selected the available orders are determined from
what the primary selected unit (the yellow one) can do. If it can't
assault, then assaulting isn't available at all.

* if the primary selected unit can do something doesn't mean that all
selected units can do the same thing. When the plans are assigned to the
selected units, they are all checked wether they can actually do the
thing. If they can't do it, then a warning is shown and the order for that
unit is ignored.

I think this is fairly logical?

Apart from that, I think that fatigue is used in most of the places
where we want it. It'll need no end of tweaks to get the "feeling" right,
but that's just changing coefficients.

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

Jan Ekholm wrote:

> On Tue, 30 Jul 2002, John Eikenberry wrote:
> 
> >John Eikenberry wrote:
> >
> >> I didn't mess with the editor yet. Wanted to make sure it didn't screw
> >> up the game to much first. I'll hit it next. I'll eliminate the
> >> redundant getNeighbors and fix getHexAdjacent while I'm at it.
> >
> >Ok. I did this, but I'm not sure how to run the editor so wasn't able to
> >test how well it went. 
> 
> % cd src
> % ./civil-editor
> 
> That should do it. Requires python-qt.
 
To steal a quote... Duh...

Guess I need to install pyqt.

Oh. And if any of you use Debian and ride sid, don't upgrade libvorbis0
and friends. It breaks pygame mixer. A bug report has already been
filed.

-- 

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

John Eikenberry wrote:

> I didn't mess with the editor yet. Wanted to make sure it didn't screw
> up the game to much first. I'll hit it next. I'll eliminate the
> redundant getNeighbors and fix getHexAdjacent while I'm at it.

Ok. I did this, but I'm not sure how to run the editor so wasn't able to
test how well it went. 

I also updated my AI related code and test scripts.

That's all of them that I could find easily. Time for bed.

-- 

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

Ok. I just committed the code to change all [x][y]'s to [y][x]'s and it
actually had very few side effects. It worked the first time. I was
quite surprized. :)

I didn't mess with the editor yet. Wanted to make sure it didn't screw
up the game to much first. I'll hit it next. I'll eliminate the
redundant getNeighbors and fix getHexAdjacent while I'm at it.

Oh, and I also fixed a bug with the terrain class. It was using 'type'
as both an attribute and a method. Changed the method to getType and
updated the only reference I could find to it in check_los.py.

-- 

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

Hola,

I added a file doc/xml/scenario-format.xml that describes in some detail
the format of the scenario files. Not too good yet, and a little bit
messy, but it's a start.

--
             In the Beginning it was a nice day.
                           -- Terry Pratchett & Neil Gaiman, Good Omens
			   

On Mon, 29 Jul 2002, John Eikenberry wrote:

> I'm not sure if this is much better as I can't seem to help but
> visualize the array with the first list as the top of the map and trying
> to think how a sideways map would effect things messes with my head.
> Though I'm sure I could deal with it if needed. 
> 
> What does everyone else think? I mean going through the code and
> adjusting things to a new coord layout would probably break some stuff.
> And while I'd be happy to do the initial changes, others would end up
> doing much of the related debugging. It might also have some odd side
> effects like rotating all displayed maps by 45 degrees.

I would like a hexes[y][x] approach. To repeat, this means that we 
have a list along the vertical axis, and for each element in the 
list, we have a list along the horizontal axis.

Pretty picture:

 hexes[y]
 |
 |
 |
 |------> hexes[0][x]
 |
 |
 |
 |------> hexes[1][x]
 |
 |
 |
 |------> hexes[2][x]
 |
 |
\|/
 
The only reason I can think of is legacy. "Everybody" else does it 
like this. At least, everybody I've seen (until now ;-)
Another reason is that it is also legacy to do

for y = 1...max_y
   for x = 1...max_x
      myhex = hexes[y][x]
      ...

The inner loop is "x" because it's easier to traverse along a list, 
rather than jump from one list to the next. So technically python
_could_ optimize this as

for y = 1..max_y
  hexrow = hexes[y]
  for x = 1...max_x
    myhex = hexrow[x]
    ...

Resulting in fewer lookups, better cache management etc.. But I guess 
this really doesn't matter that much in Python, especially for such 
small maps. But I just feel that this is the way things were done, and 
I won't be the one changing that... :)

Note that coordinates still are given as (x,y) to functions, as 
opposed to (y,x), no matter how the map itself is organised. IMHO.

Marcus

Jan Ekholm wrote:

> On Sun, 28 Jul 2002, John Eikenberry wrote:
> >Shouldn't these all be hexes[y][x]? 
> 
> Probably. Please don't respect any code that I've done that deals with
> maths. I can't do it and I hate it. I usually get working coordinate
> systems etc in my apps through trial and error. In Civil let's do it
> properly if there is a proper way. So, please just reverse indices that
> look just plain wrong. Maybe I should create a small non-square map so
> that we have something to test with?

I'm right there with you chakie. That's why I create all those little
ascii art maps to test with. I find it hard to believe how much time
I've spent just trying to figure out something seemingly so simple as a
coordinate system. Keeps one humble I suppose [0.5 wink].

After thinking about it, the old way does make sense if you think about
map.hexes as being the map on its side. I mean if you think of the top
row of hexes _not_ as the first list in the array, but instead as the
first item on each list it makes sense. The old hex allocator in
map.__init__() then works as do the hexes[x][y] references.

I'm not sure if this is much better as I can't seem to help but
visualize the array with the first list as the top of the map and trying
to think how a sideways map would effect things messes with my head.
Though I'm sure I could deal with it if needed. 

What does everyone else think? I mean going through the code and
adjusting things to a new coord layout would probably break some stuff.
And while I'd be happy to do the initial changes, others would end up
doing much of the related debugging. It might also have some odd side
effects like rotating all displayed maps by 45 degrees.

Hope this made sense... Still for the idea chakie?

-- 

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 Sun, 28 Jul 2002, John Eikenberry wrote:

>
>I found another prevalent bit of code that again uses the hex map as if
>x were rows and y columns. For example from map.py:
>
>    def getHex (self, x, y):
>        """Convenience method that returns a hex with given coordinates."""
>        return self.hexes[x][y]
>
>Or this snippet from gui/info_map.py:
>
>        # get the hexes of the map
>        hexes = scenario.map.getHexes ()
>
>        # loop over the hexes in the map
>        for y in range ( map.getYsize () ):
>            for x in range ( map.getXsize () ):
>                # get the hex for that position
>                hex = hexes [x][y]
>
>Shouldn't these all be hexes[y][x]? 

Probably. Please don't respect any code that I've done that deals with
maths. I can't do it and I hate it. I usually get working coordinate
systems etc in my apps through trial and error. In Civil let's do it
properly if there is a proper way. So, please just reverse indices that
look just plain wrong. Maybe I should create a small non-square map so
that we have something to test with?


-- 
                 "Students?" barked the Archchancellor.
    "Yes, Master. You know? They're the thinner ones with the pale faces?
  Because we're a university? They come with the whole thing, like rats --"
                                         -- Terry Pratchett, Moving Pictures

I found another prevalent bit of code that again uses the hex map as if
x were rows and y columns. For example from map.py:

    def getHex (self, x, y):
        """Convenience method that returns a hex with given coordinates."""
        return self.hexes[x][y]

Or this snippet from gui/info_map.py:

        # get the hexes of the map
        hexes = scenario.map.getHexes ()

        # loop over the hexes in the map
        for y in range ( map.getYsize () ):
            for x in range ( map.getXsize () ):
                # get the hex for that position
                hex = hexes [x][y]

Shouldn't these all be hexes[y][x]? 

-- 

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 Sun, 28 Jul 2002, John Eikenberry wrote:

> I should have thought to double check that map's __init__ was right. I
> thought it strange to use that layout. Oh well.
> 
> Sorry for breaking your code Marcus.

No problem, I was goning ask you later but you already noticed..
 
Neither was I aware of the mixup in Map.__init__, so it's 
great that it gets fixed. 

Marcus

On Sun, 28 Jul 2002, John Eikenberry wrote:

>
>Noticed Marcus' note in cvs for map.py 1.35. Thought I'd explain why I
>changed getNeighbors and get us all on the same page as far as map
>coords.
>
>I based all my code on how map.__init__() initializes self.hexes as a
>xsize long list of ysize long lists. Or xsize as the rows and ysize as
>the columns. This is counter to how x and y are used everywhere else I
>can find where x references columns and y rows. This will cause things
>to break if a non-square map is used. 

If the coords are reversed let us fix map.__init__() to follow common
standards instead. That code is *ancient*, and we've always used square
maps, so it has never been a problem (for me) so far.

Do not unnecessarily create weird hacks that are hard to understand in a
few years just because something I've written is fubar. :)

-- 
By reading this message, you may be causing Armageddon. Needless to say,
Armageddon will wipe out your hard drive and damage your computer.
                                -- Email hoax as seen on Hoaxbusters.com
				

Noticed Marcus' note in cvs for map.py 1.35. Thought I'd explain why I
changed getNeighbors and get us all on the same page as far as map
coords.

I based all my code on how map.__init__() initializes self.hexes as a
xsize long list of ysize long lists. Or xsize as the rows and ysize as
the columns. This is counter to how x and y are used everywhere else I
can find where x references columns and y rows. This will cause things
to break if a non-square map is used. 

I'm going to change my code in line with this and I'll also fix
map.__init__ as well as getNeighbors and getHexAdjacent (which I 'fixed'
previously). 

I should have thought to double check that map's __init__ was right. I
thought it strange to use that layout. Oh well.

Sorry for breaking your code Marcus.

-- 

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, 26 Jul 2002, Marcus Alanen wrote:

>On Fri, 26 Jul 2002, Jan Ekholm wrote:
>
>> Hmm, where? The editor uses QPixmaps, not Pygame surfaces, so it should
>> *never* do .convert().
>
>Indeed, since pygame/SDL is not initialized (my first "patch" 
>acutually did initialize them, but that just felt silly)
>
>Anyway ./src/map.py:loadFeatureIcon

Hmm, yes, this would trigger an error... :) The editor shouldn't need to
use any pygame stuff, at least not initialize pygame nor create surfaces.

Haven't seen this error, as I haven't done anything to scenario10 (which
has trenches that get added as "features" to the map) in a while. Will
need to work around that in some properish way some day.

-- 
    - "Remember -- that which does not kill us can only make us stronger."
    - "And that which does kill us leaves us dead!"
                                           -- Terry Pratchett, Carpe Jugulum

On Fri, 26 Jul 2002, Jan Ekholm wrote:

> Hmm, where? The editor uses QPixmaps, not Pygame surfaces, so it should
> *never* do .convert().

Indeed, since pygame/SDL is not initialized (my first "patch" 
acutually did initialize them, but that just felt silly)

Anyway ./src/map.py:loadFeatureIcon

        # load the icon
        icon = pygame.image.load ( filename )
 
        # set the transparent color
        icon.set_colorkey ( (255,255,255), RLEACCEL )
 
        # The try block is because editor doesn't use sdl
        try:
            # convert the icon to a more efficient format
            icon = icon.convert ()
        except:
            pass

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

On Fri, 26 Jul 2002, Marcus Alanen wrote:

>On Thu, 25 Jul 2002, Jan Ekholm wrote:
>
>> >Note: I hade problems loading/saving the scenario in the editor, so 
>> >I had to manually edit the xml file. I'll look into this some day, I
>> >guess it is a common problem.
>> Hmm, no? What did go wrong? Stacktrace?
>
>It was only some silly typo or so, and it complained also when trying 
>to do icon.convert(). Nowadays in a try..catch block, a bit crude 
>perhaps, but does the job. It's only the editor...

Hmm, where? The editor uses QPixmaps, not Pygame surfaces, so it should
*never* do .convert().

-- 
                 "Students?" barked the Archchancellor.
    "Yes, Master. You know? They're the thinner ones with the pale faces?
  Because we're a university? They come with the whole thing, like rats --"
                                         -- Terry Pratchett, Moving Pictures

On Thu, 2002-07-25 at 15:05, Jan Ekholm wrote:
> I suggest having the actual game just rely on the map being correct.
> There's enough stuff to do anyway that makes loading scenarios slow, so
> assuming they're ok could avoid adding even more stuff.

Yeah.  A verifier in the editor is a really good idea, game could depend
on that.

OTOH, a corrupted map might cause bugs that would be really really hard
to track down, so having the main game double-check just in case could
be worthwhile.   On the third hand (!?), you could just load the map
into the editor to check in that case, I guess, so again it's no big
deal.

- mikee

On Thu, 25 Jul 2002, Jan Ekholm wrote:

> >Note: I hade problems loading/saving the scenario in the editor, so 
> >I had to manually edit the xml file. I'll look into this some day, I
> >guess it is a common problem.
> Hmm, no? What did go wrong? Stacktrace?

It was only some silly typo or so, and it complained also when trying 
to do icon.convert(). Nowadays in a try..catch block, a bit crude 
perhaps, but does the job. It's only the editor...

Marcus

On Thu, 25 Jul 2002, Marcus Alanen wrote:

>Note: I hade problems loading/saving the scenario in the editor, so 
>I had to manually edit the xml file. I'll look into this some day, I
>guess it is a common problem.

Hmm, no? What did go wrong? Stacktrace?

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

On Mon, 22 Jul 2002, Marcus Alanen wrote:

>On Sun, 21 Jul 2002, Korruptor wrote:
>
>> Random question: does the editor "parse" the map in any way to check for
>> such oddities? ie: broken hills? Or is it left to the map designer to ensure
>> content in the playfield is "sensible"?
>
>Upto now I thought the loading routine of the game would enforce map
>correctness. But I don't have strong arguments either way.

I suggest having the actual game just rely on the map being correct.
There's enough stuff to do anyway that makes loading scenarios slow, so
assuming they're ok could avoid adding even more stuff.

We could add a little flag in the <scenarioinfo> tag that is set when the
map is successfully validated in the editor, and then saved without any
further alternations. Civil would then just ignore unvalidated scenarios.
Of course someone can alter that flag manually with an text editor, but
we're not trying to be idiot proof here.

Comments?

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

duh, forgot to mention. Alt-G to enable/disable debug grid while 
playing.

You'll soon notice that not all hills are completely correct. 
Currently, hills are all on the "same height". This means that a hill 
hex which is mostly "high" still is considered the same height as a 
hill hex which is mostly "low". You'll notice this easiest if you pan 
along a hill-line, and press LMB. stdout gives the height of the hex.

If nobody understood the above, ignore.

Marcus

I made simple copies of the ambiguous icons. While this wastes a bit 
memory I didn't care optimize this (yet) because it's only a couple of 
icons among 600+ :)

The absolute map height is calculated and I'd say it should be 
enforced also. It can only lead to trouble, and I don't understand 
why anybody would like to play with a map where the heights go 
bananas.

It now reports errors on stdout, but technically I 
think it should raise an error. The map editor could have a "verify 
heights" button, and then mark the hexes which are bad.

I fixed scenario10 but not the others, and they naturally report huge 
amounts of errors because of the ambiguous icon thing..

Note: I hade problems loading/saving the scenario in the editor, so 
I had to manually edit the xml file. I'll look into this some day, I
guess it is a common problem.

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

On 21 Jul 2002, Michael Earl wrote:

> Err, I'm confused.  Are these absolute or relative values? I had thought
> they were relative, thus -1,-1,0,1,1,0.  

Ignore this - I got confused. They are relative values, but they are 
all positive at the moment, which is wrong...

We discussed this earlier Chakie, I'll use only 6 values, including 
negative relative heights. I'll fix this.

> Mm.  Then we have to set absolute values for some hexes.  Set (0,0) to
> 0.  Spill out from there in the map editor, figure out which hexes are
> defined/undefined/inconsistant.  Allow map creator to set hard values on
> more hexes to clarify/fix.  Does this work?

It could, but I think copying the icons is easier. What do you think, 
should we enforce map correctness?

Marcus

On Sun, 21 Jul 2002, Korruptor wrote:

> Random question: does the editor "parse" the map in any way to check for
> such oddities? ie: broken hills? Or is it left to the map designer to ensure
> content in the playfield is "sensible"?

Upto now I thought the loading routine of the game would enforce map
correctness. But I don't have strong arguments either way.

Marcus