civil-devel Mailing List for Civil

On Fri, 29 Jun 2001, Gareth Noyce wrote:

>Dances with wolves proved to be the main one. I think gettysburg was in the 
>pile as well, although to be honest I didn't watch any of them, just 
>flicked through them trying to find interesting battle shots...

Aha! DwW contains a lot of really beautiful scenery. And it sure is long
too. Don't let Kevin Costner do stuff on his own, he makes *long* films...

>Suffice to say Dances with wolves gave me most of the best images that I've 
>used. You'll probably recognise the main bits of the 'You won' backdrop...

Ok, I'll try to see if I do when it gets ci:d. I haven't seen it for a few
years though.

We do seem to have some really active moments right now. That's good.

--------------------+--------------------------------------------------------
Jan 'Chakie' Ekholm |     Balrog New Media    http://www.balrog.fi/
   Linux Inside     | I'm the blue screen of death, nobody hears your screams

On 30 Jun 2001, Mike Earl wrote:

>This was actually pretty easy; it pretty much snapped right into the
>engine, most of the time was spent figuring out silly type mistakes
>because I didn't have all the relevent code in short-term-memory yet.
>move_fast still doesn't implement this; it should probably be tweaked to
>inherit the relevent code from move rather than cut-and-pasting it, but
>that was all I was hoping for tonight.

Nice work, Mike. I didn't think the engine code was that clear, or then
you are very good at reading my code.

Actually MoveFast already does inherit Move, so some parts are already
shared. The movement speed calculations are not, but they could be made
shared too.

Cut'n'paste of similar (or same) code is Evil. It leads to problems sooner
or later, so it should be fully inherited somehow. 

--------------------+--------------------------------------------------------
Jan 'Chakie' Ekholm |     Balrog New Media    http://www.balrog.fi/
   Linux Inside     | I'm the blue screen of death, nobody hears your screams

On 29 Jun 2001, Mike Earl wrote:

>
>The new headquarters stuff works on my box...

Good. It was really no rocket science, but there always creeps in bugs. 

>I'm planning on beginning work on terrain effects on movement and sight
>shortly.  This seems pretty straightforward; I think I can work up, eg.,
>different movement rates on different terrain quickly.

I saw the new code in terrain.py. That seems to work just fine. Maybe it
would be easier to create members in the class Terrain, and just let the
subclasses set new values? Would avoid having to override methods just to
provide a new value. Like in mode/mode.py and its subclasses. Just a
suggestion, and it may not work ok if we send in the unit type and other
data too.

>I'm also pretty close to being able to use altitude information; is this
>something the map editor can produce yet?  Dunno what a non-tedious
>interface for that would look like.

No, it can't. It could/should be derived from the terrain somehow. We do
know how each hex changes the height, and how the triangles are related to
each other. The editor could start from the upper left corner and define
that to be height 0. It could then iterate over all hexes and calculate
the relative heights for each hex/triangle. If some triangle ends up with
a negative height the entire map is offset a little bit to make the
smallest value 0.

>Also; given that I have to hack all the hexes to triangles anyhow to do
>the math, it will likely be the case that we can support 6 distinct
>types of terrain in each hex.  Since a lot of our hexes are
>intersections of physical feature types anyway, this may work out well.

Yep, I think that would work quite well, and would make the code I
suggested above easy to do.

>Presumably each hex icon will always have the same types?  Thoughts on
>best ways to store this data solicited; I'll probably slap up something
>quick and dirty first for basic testing that sets the whole six-triangle
>hex based on what its predominant terrain type (forest, hills, woods,
>water) is.

There are quite a few hexes where the contents are 50/50 between, say,
grass and sand. There neither type is predominant, and it would be better
to store the info per triangle.

Ideally we could have a static lookup table with data for all hex types.
Data such as:

	* terrain type for each triangle
	* relative height for each triangle

could be stored in it. Assuming 500 hexes there could be maybe 3 values
per triangle, making a total of 500 * 6 * 3 = 9000 values totally. Not too
bad.

>OTOH, I have a new hard drive, and may be attempting to install it and
>Mandrake 8.0 this weekend if I think I have a big enough block of time,
>so don't be surprised if I drop off the net a few days, either...

:-) You're not considering Debian? They're trying right now to get pygame
into Debain unstable, so you could soon simply do a:

	% apt-get install pygame

to get it installed along with SDL, Python2 and all other needed cruft.
I'll convert my own main machine at home some day when I have time (an old
RedHat 6.1/6.2).

Good luck with the install! Let us know what you think of Mandrake 8.0!

--------------------+--------------------------------------------------------
Jan 'Chakie' Ekholm |     Balrog New Media    http://www.balrog.fi/
   Linux Inside     | I'm the blue screen of death, nobody hears your screams

>As for the movies, can you recommend any of them? I've seen the movie
>Gettysburg (from 1993, I think), and it was really cool. I've thought
>about getting it sooner or later, as I don't remember too many details.

Dances with wolves proved to be the main one. I think gettysburg was in the 
pile as well, although to be honest I didn't watch any of them, just 
flicked through them trying to find interesting battle shots...

Suffice to say Dances with wolves gave me most of the best images that I've 
used. You'll probably recognise the main bits of the 'You won' backdrop...

>I must say that I like the b/w stff we have very much. It looks very
>professional and polished.

Thanks! There will be more of the same...

>Yeah, the more types of terrain there are the more combinations there will
>be. Maybe you could reduce the number of variations of the same hex to
>save some effort?

I'm not really worried about the effort -- I've started so I'll finish! 
It's more a question of time...

Anyway, I'll keep you posted...

G

Well, I just committed a first draft of movement speed modifiers for
terrain.  It seems to work; there's a bit of an oddity in that it will
let units move one step into impassible water (because movement speed is
based on your current terrain), at which point they get stuck.  I'm not
sure the correct thing to do there.  Also, it does a lousy job deciding
what hexes/triangles are what sort of terrain - that was just a quick
hack, enough to test the engine work.

This was actually pretty easy; it pretty much snapped right into the
engine, most of the time was spent figuring out silly type mistakes
because I didn't have all the relevent code in short-term-memory yet.
move_fast still doesn't implement this; it should probably be tweaked to
inherit the relevent code from move rather than cut-and-pasting it, but
that was all I was hoping for tonight.

- mikee

The new headquarters stuff works on my box...

I'm planning on beginning work on terrain effects on movement and sight
shortly.  This seems pretty straightforward; I think I can work up, eg.,
different movement rates on different terrain quickly.

I'm also pretty close to being able to use altitude information; is this
something the map editor can produce yet?  Dunno what a non-tedious
interface for that would look like.

Also; given that I have to hack all the hexes to triangles anyhow to do
the math, it will likely be the case that we can support 6 distinct
types of terrain in each hex.  Since a lot of our hexes are
intersections of physical feature types anyway, this may work out well.
Presumably each hex icon will always have the same types?  Thoughts on
best ways to store this data solicited; I'll probably slap up something
quick and dirty first for basic testing that sets the whole six-triangle
hex based on what its predominant terrain type (forest, hills, woods,
water) is.

OTOH, I have a new hard drive, and may be attempting to install it and
Mandrake 8.0 this weekend if I think I have a big enough block of time,
so don't be surprised if I drop off the net a few days, either...

- mikee

Hi all,

Got some weird and divine coding energy from the Great Processor, so I
whacked the changes needed to support separate headquarter units. There
may be a few bugs left, but they should be trivial. 

It was fairly easy and didn't mean too much work at all. Of course a lot
of small changes here and there, but nothing major. The parser needed
some rehacking, but it was fairly easy.

Changelog:

* many changes du to creation of new unit type: headquarter. All files
  that were affected by the change are updated.
* scenario file format has changed to use headquarters too.
* scenario10.xml updated to new format.
* headquarters now show the companies belonging to the organization, but
  only for companies.


So, only scenario10.xml works right now. The other will maybe be
deprecated and deleted at some point. scenario11.xml has no units, or I
can copy the ones from 10 to it, as it has a nice map...

Clicking on a headquarter for some organization that has companies as
direct subordinate units (battallion and maybe regiments) lines will be
drawn from the hq to the companies to indicate what units are under its
command. A quite nice feature, although the current color is horrible. :-)

Nice to be back hacking on Civil again after a slow period!

--------------------+--------------------------------------------------------
Jan 'Chakie' Ekholm |     Balrog New Media    http://www.balrog.fi/
   Linux Inside     | I'm the blue screen of death, nobody hears your screams

I'll need to change the format of scenarios a little bit to make it
possible to store the headquarters in a more meaningful manner.
Scenario10.xml will be fixed first, and others later if I find the time.

Sorry for the inconvenience.

--------------------+--------------------------------------------------------
Jan 'Chakie' Ekholm |     Balrog New Media    http://www.balrog.fi/
   Linux Inside     | I'm the blue screen of death, nobody hears your screams

On Fri, 29 Jun 2001, Gareth Noyce wrote:

>Quoting Jan Ekholm <ch...@in...>:
>
>Wedding panic? Nothing major I hope?
>
>> I've read your Advogato entries, so I think we=20
>> can expect something
>> extraordinary (as usual) when the G makes=20
>> a 'cvs ci'. What other
>> 'goodies'
>> could there be? Interesting... :-)
>
>Well, I hope they are 'extraordinary', but we'll=20
>have to wait and see what Saturday brings. ;-)
>
>I think I've got the basic roads mapped out, it's=20
>just the ditches and bush verges that are causing=20
>the problems now... They took a while to measure=20
>out, as I was originally making them a little=20
>narrower than the rivers. Then I realised the=20
>scale would mean that they were ~ the same size.=20
>Had to scrap some stuff and widen them. Stupid=20
>mistake really, but all seems well again now.

I assume the scale can be quite tricky. I think I'd=A0manage to do hedges
etc that are 20m wide or 3m wide rivers...

>I'm working on the game over win/lose full screen stats backdrops. I've
>bought a load of Civil war movies on DVD and I've made a load of
>captures of various bits. I'm trying to work my magic on some more
>'Photo realistic' stuff, but it's a full-on composite of various bits
>from different films, with a lot of work on the 'camera' focus of the
>overall image. Bit hard to explain, but these are looking like being the
>most impressive bits yet to be 'cvs ci'ed. :)

Holy sh*t! You do have some really cool stuff brewing. It's going to be
really interesting to see what comes out of your pixel studio.=20

As for the movies, can you recommend any of them? I've seen the movie
Gettysburg (from 1993, I think), and it was really cool. I've thought
about getting it sooner or later, as I don't remember too many details.

>I'm gonna do some full colour versions, and the usual 'Black and white'
>photo efforts as seen on the front dialog stuff. I just want these to be
>more impressive than usual, and I think the full colour versions may
>prove useful for adverts, posters or other 'Civil Promo' related
>material... You never know!

I must say that I like the b/w stff we have very much. It looks very
professional and polished.

>The downside to this is I'll have to do the roads through sand, trees,
>hills, etc. And I've still not really finished all the variations of the
>rivers through these things! Please be sure to post any hexes that you
>note are missing as maps are made. I've not been sensible and made a
>list and I'm currently flitting between bits as the mood takes me... In
>fact, I may sit down this afternoon and do this in case I miss something
>important out...

Yeah, the more types of terrain there are the more combinations there will
be. Maybe you could reduce the number of variations of the same hex to
save some effort?

--------------------+------------------------------------------------------=
--
Jan 'Chakie' Ekholm |     Balrog New Media    http://www.balrog.fi/
   Linux Inside     | I'm the blue screen of death, nobody hears your screa=
ms

Quoting Jan Ekholm <ch...@in...>:

Wedding panic? Nothing major I hope?

> I've read your Advogato entries, so I think we 
> can expect something
> extraordinary (as usual) when the G makes 
> a 'cvs ci'. What other
> 'goodies'
> could there be? Interesting... :-)

Well, I hope they are 'extraordinary', but we'll 
have to wait and see what Saturday brings. ;-)

I think I've got the basic roads mapped out, it's 
just the ditches and bush verges that are causing 
the problems now... They took a while to measure 
out, as I was originally making them a little 
narrower than the rivers. Then I realised the 
scale would mean that they were ~ the same size. 
Had to scrap some stuff and widen them. Stupid 
mistake really, but all seems well again now.

As for other things (Spoiler alert):

I'm working on the game over win/lose full screen 
stats backdrops. I've bought a load of Civil war 
movies on DVD and I've made a load of captures of 
various bits. I'm trying to work my magic on some 
more 'Photo realistic' stuff, but it's a full-on 
composite of various bits from different films, 
with a lot of work on the 'camera' focus of the 
overall image. Bit hard to explain, but these are 
looking like being the most impressive bits yet 
to be 'cvs ci'ed. :)

Probably about another couple of months work. 

I'm gonna do some full colour versions, and the 
usual 'Black and white' photo efforts as seen on 
the front dialog stuff. I just want these to be 
more impressive than usual, and I think the full 
colour versions may prove useful for adverts, 
posters or other 'Civil Promo' related 
material... You never know!

ATM they are just a more 'artistic' interlude 
from the hex based stuff -- not a full time 
effort... 

Anyway, I'll try to at least get a mock of the 
roads up this weekend. If the wind is behind me 
I'll get the normal first batch cut and in the 
tree. 

The downside to this is I'll have to do the roads 
through sand, trees, hills, etc. And I've still 
not really finished all the variations of the 
rivers through these things! Please be sure to 
post any hexes that you note are missing as maps 
are made. I've not been sensible and made a list 
and I'm currently flitting between bits as the 
mood takes me... In fact, I may sit down this 
afternoon and do this in case I miss something 
important out...

Funny how the small bits take the most time...

G

-------------------------------------------------
This mail sent through UK Online webmail

On Fri, 29 Jun 2001, Gareth Noyce wrote:

>I apologise for being off list for so long. 
>Hectic holiday and all...

So have I, but no holiday here (in August). Some minor panic with the
wedding thingie, and just summer apathy...

>Yeah, sounds like a plan to me, and I agree with it primarily from a
>gameplay POV. It makes a lot of sense as the commanders would be more
>autonomous than their current representation possbily allows...

Yeah, I couldn't find too many drawbacks either. It will clean up some
parts of the code too and make the relationships easier to grasp.

>BTW I've been quite busy on the roads. I'm hoping that these will be
>committed over the weekend. I may also have some other goodies for
>you...

I've read your Advogato entries, so I think we can expect something
extraordinary (as usual) when the G makes a 'cvs ci'. What other 'goodies'
could there be? Interesting... :-)

--------------------+--------------------------------------------------------
Jan 'Chakie' Ekholm |     Balrog New Media    http://www.balrog.fi/
   Linux Inside     | I'm the blue screen of death, nobody hears your screams

Jan Ekholm said a load of stuff I cut out: 

Hi all, 

I apologise for being off list for so long. 
Hectic holiday and all...

> [SCHNIP]
> Ok, lots of blurbs here. What do you guys think?

Yeah, sounds like a plan to me, and I agree with 
it primarily from a gameplay POV. It makes a lot 
of sense as the commanders would be more 
autonomous than their current representation 
possbily allows... 

The visualisation isn't a problem. I'm thinking 
of jumping headlong into the problem of units 
next month so it's just another to add to the 
list...

BTW I've been quite busy on the roads. I'm hoping 
that these will be committed over the weekend. I 
may also have some other goodies for you...

Cheers!

G


-------------------------------------------------
This mail sent through UK Online webmail

Hi all,

After a while of silence I'm back again with some more code and new ideas.
Well, not so new, but after I started working with visualizing
organizations on the map I ran into some problems.

Currently all commanders for various organizations (company, battallion
etc) are "integrated" into some company. So a company contains the normal
company commander but may also contain a much higher commander for some
higher level organization such as a brigade. This creates some interesting
problems when visualizing and organizing the units ane their
relationships.

So I've decided to split up commanders into smaller "headquarter" units
that contain only the hq and necessary staff. All companies (the units
that currently are seen on a map) contain only their own comapny
commander, bothing else. So we'll have a new type of unit: headquarter.

This makes for some more work to integrate the new unit type into Civil,
but it also gives more flexibility and more interesting gameplay. An enemy
would in a real battle very likely try to shoot at commanders if they
could see/identify them, as they knew that the loss of a commander could
be very fatal. Thus the player has to protect the hq units. A hq unit
could also be used for some specialized actions, such as boost morale for
nearby units, persuade them to do really hard defending and so on. Think
of it as general riding among the men shouting orders and encouraging the
men to do their best and fight harder.

Any opinions for or against such a split at this late stage? I'll do the
code, so nobody needs to suffer for my whimsicals. :-) At some later point
we might want to have a special icon for hq:s, maybe even for different
types of hqs (brigade, division, regiment etc). As the hq:s are smaller
(maybe up to 10 men?), the icons could be somewhat smaller to reflect
that and make it easier to distinguish them?

Ok, lots of blurbs here. What do you guys think?

--------------------+--------------------------------------------------------
Jan 'Chakie' Ekholm |     Balrog New Media    http://www.balrog.fi/
   Linux Inside     | I'm the blue screen of death, nobody hears your screams

On 25 Jun 2001 16:17:02 +0300, Jan Ekholm wrote:
> I assume you have an indentation of 8 chars and 'untabify' when you save? 
> I use 4 as tab size and also do an 'untabify', so that explains it.
> Normally emacs uses the indantation of above lines, but the function
> hexFactory() was the first thing in the file, so there were no indented
> lines above it, so it used your default setting of 8 chars. 

Right on all counts.  Just changed that setting to 4.

Ok, so here's my super-high level plan/explaination of map.py.  (Much
harder without pictures - I really ought to spend an hour producing
those sometime.  Anyhow...)

The map is responsible for keeping track of what terrain is where, and
what you can see from where.  It has a big 2-D array of hexes; a 2-D
array of sets of triangles that make up those hexes; and a bunch of ugly
math.

The hexes are initalized straight into the array by the scenario_parser.
Since the hexFactory function is used, we 'reuse' hexes that have the
same icon and altitude, and just have a second/third/whatever pointer to
the same hex.

Doing math with the hexes with cartesian coordinates is a pain, so we
don't.  Fortunately, we can imagine that each hex is composed of 6
triangles.  Doing math with the triangles isn't nearly so bad.  Now, if
you take a hex map and draw six triangles (center and each side) in each
hex, you'll see that what you end up with is three sets of parallel
lines.  For the hex size currently used in civil, the formulas for those
sets of lines are:

x = 24n        (runs along the vertical hex sides)
x + 2y = 48 n  (runs along one set of diagonal hex sides)
x - 2y = 48 n  (runs along other set of diagonal hex sides)

For a whole bunch of values of n.  This is a whole lot clearer with a
picture; perhaps I'll try to put one together later.  There's another
nice little result; the y-coordinate of a hex center is always a
multiple of 36, and that isn't true of any hex corner.  (Draw a
horizontal line across the centers of a row of hexes, it passes through
the vertical sides in the middle.)

A walk-through of pointToHex follows:

So if we look at the map coordinate (1,1), what hex is it in?

Well, it's easy enough to see that it's between the lines:
x = 0 and x = 24  (call this set A)  [because 0>x>24]
x + 2y = 0 and x + 2y = 48 (call this set B) [because 0 > x+2y > 48] 
x - 2y = 0 and x - 2y = -48 (call this set C) [because -48 > x- 2y > 0 ]

So, the lines from A&B intersect in four points:
(0,0),(0,24),(24,-12),(24,12).  

[The code, in fact, will 'cheat' and stop here; since only one of those,
(0,0), can be a hex center, that must be the center of our hex, which is
therefore hex (0,0).  But let's finish up...]

A&C intersect in four points, too:
(0,0),(0,24),(24,-12),(24,12)

As do B&C:
(0,0),(-24,-12),(24,12),(0,24)

We see that (0,0), (0,24), and (24,12) are in all three lists; these are
the triangle that holds (1,1); for any triangle, 1 point is the center
of a hex, and that's (0,0) here.


Woo, that was longer than I expected.  That's some of the worst of
what's going on now; there's another messy bit with the altitudes of
triangles, but perhaps that's for another email a bit later. :)

- mikee

On 25 Jun 2001, Mike Earl wrote:

>On 25 Jun 2001 08:58:34 +0300, Jan Ekholm wrote:
>
>> Should not confuce it too much. The part where the initial map is created
>> will not work, but it should be a matter of changing a Hex() call to a
>> hexFactory() call inside a 'for' loop.
>
>Pretty much, yeah.  Note that there's no harm in mixing the two sorts of
>creation - just that if you call Hex() it's guarenteed to be a unique
>object.  Also note that the hex.coordinates may return completely bogus
>values for hexes from hexFactory - map never uses this method, but I'm
>not sure the map editor doesn't; depending on the data structures there,
>it might be simpler to just keep the hex call.

No parts of my code should really use the coordinates. The editor uses the
nice method pointToHex() in Map to translate clicks to hex coords.

>Odd about indentation.  Been using emacs; will look at that later.

I assume you have an indentation of 8 chars and 'untabify' when you save? 
I use 4 as tab size and also do an 'untabify', so that explains it.
Normally emacs uses the indantation of above lines, but the function
hexFactory() was the first thing in the file, so there were no indented
lines above it, so it used your default setting of 8 chars. If you add a
method in the middle of a class I think you'll get the same indentation as
the other code above.

Thus speaketh Chakie, great selfappointed Emacs guru... :-)

--------------------+--------------------------------------------------------
Jan 'Chakie' Ekholm |     Balrog New Media    http://www.balrog.fi/
   Linux Inside     | I'm the blue screen of death, nobody hears your screams

On 25 Jun 2001 08:58:34 +0300, Jan Ekholm wrote:

> Should not confuce it too much. The part where the initial map is created
> will not work, but it should be a matter of changing a Hex() call to a
> hexFactory() call inside a 'for' loop.

Pretty much, yeah.  Note that there's no harm in mixing the two sorts of
creation - just that if you call Hex() it's guarenteed to be a unique
object.  Also note that the hex.coordinates may return completely bogus
values for hexes from hexFactory - map never uses this method, but I'm
not sure the map editor doesn't; depending on the data structures there,
it might be simpler to just keep the hex call.

Odd about indentation.  Been using emacs; will look at that later.

- mikee

Hi all,

It's nice to see some action again in the code. :-) I'll start doing a few
additions today or tomorrow too, so we seem to wake up again after a small
slumber. 

>I just committed a couple of changes to scenario_parser/hex/terrain/map.
>This is a first pass at implementing the idea of only keeping unique
>copies of hexes that are actually unique; it trims memory usage a bit on
>the current map, and should slash it quite heavily on large maps with
>broad expanses of similar terrain.

Of course. This is really smart. There is really very little (currently
nothing) data that a hex must keep private, so why not share them.
Depending on the laziness of the scenario designer and wether he/she uses
a lot of different icons, quite large savings can be made. Good work,
Mike!

I looked through the changes, and they look ok to me. Haven't tested yet,
but will once I get some coffee. I did some reindentations to some parts
of the code, as the lines were far too much indented. Maybe you just have
a larger tab setting? I also added a few comments, but they are more a
sign that I understood what happened, nothing more. :D

>It Works For Me (TM), but I haven't tested much, and I'm especially
>unsure it won't confuse the editor (although I think not).  This version
>is also something of a quick hack, but I had a spare evening and wanted
>to try to get back into the swing of things, so...

Should not confuce it too much. The part where the initial map is created
will not work, but it should be a matter of changing a Hex() call to a
hexFactory() call inside a 'for' loop.

I need to try to understand the code in map.py. Quite a lot of math in
there, and I can't say I know all what's going on in there. Some day when
you feel like you have some spare time you could brief me on the gorier
parts?

>I'll go into more detail later if there's interest and the code isn't
>clear - right now it's past my bedtime, or will be by the time I get
>there.

Nice to have you back again. 

--------------------+--------------------------------------------------------
Jan 'Chakie' Ekholm |     Balrog New Media    http://www.balrog.fi/
   Linux Inside     | I'm the blue screen of death, nobody hears your screams

I just committed a couple of changes to scenario_parser/hex/terrain/map.
This is a first pass at implementing the idea of only keeping unique
copies of hexes that are actually unique; it trims memory usage a bit on
the current map, and should slash it quite heavily on large maps with
broad expanses of similar terrain.

It Works For Me (TM), but I haven't tested much, and I'm especially
unsure it won't confuse the editor (although I think not).  This version
is also something of a quick hack, but I had a spare evening and wanted
to try to get back into the swing of things, so...

I'll go into more detail later if there's interest and the code isn't
clear - right now it's past my bedtime, or will be by the time I get
there.

- mikee

> Hah, all your base are belong to us. Have a 
> nice holiday and put up
> pics
> on the web somewhere for us to look at!

Funny you should mention that. I have my "All 
your base are belong to us" T-shirt. I intend to 
wear it as I visit all the ancient ruins! ;-)

The Cd /pub; more beer; one will be reserved for 
the evenings! :)

G


-------------------------------------------------
This mail sent through UK Online webmail

On Thu, 7 Jun 2001, Gareth Noyce wrote:

>> Yep, now it works fully too. It uses the built-
>> in support for Unicode
>> that
>> SDL has, so every keypress comes with the 
>> decoded key as uniocode, with
>
>SDL has unicode? Cool... I never knew that...

Or it's a feature of Pygame. It works anyway...

>> above the panel. I someone is interested I 
>> could smack up a new
>> screenshot.
>
>Please do, although I doubt I'll get time to view 
>it as I'm off to Crete tomorrow! :)
>
>Hope you guys all have a good week. I'll touch 
>base upon my return... (If I'm not too burnt...)

Hah, all your base are belong to us. Have a nice holiday and put up pics
on the web somewhere for us to look at!

--------------------+--------------------------------------------------------
Jan 'Chakie' Ekholm |     Balrog New Media    http://www.balrog.fi/
   Linux Inside     | I'm the blue screen of death, nobody hears your screams

> Yep, now it works fully too. It uses the built-
> in support for Unicode
> that
> SDL has, so every keypress comes with the 
> decoded key as uniocode, with

SDL has unicode? Cool... I never knew that...

> above the panel. I someone is interested I 
> could smack up a new
> screenshot.

Please do, although I doubt I'll get time to view 
it as I'm off to Crete tomorrow! :)

Hope you guys all have a good week. I'll touch 
base upon my return... (If I'm not too burnt...)

G

P.S. Excellent work Jan!


-------------------------------------------------
This mail sent through UK Online webmail

On Wed, 6 Jun 2001, Gareth Noyce wrote:

>Quoting Jan Ekholm <ch...@in...>:
>
>Chat! Kewl! :)
>
>Time to brush up on some suitable ye-olde-world 
>insults. ;-)

Yep, now it works fully too. It uses the built-in support for Unicode that
SDL has, so every keypress comes with the decoded key as uniocode, with
all modifiers applied. Only thing is that it's a little bit slow, as it
repaints the entire playfield for every keypress. I'll try to figure out
some way to repaint only the dirty area, i.e. the small little window
above the panel. I someone is interested I could smack up a new
screenshot.

--------------------+--------------------------------------------------------
Jan 'Chakie' Ekholm |     Balrog New Media    http://www.balrog.fi/
   Linux Inside     | I'm the blue screen of death, nobody hears your screams

Quoting Jan Ekholm <ch...@in...>:

Chat! Kewl! :)

Time to brush up on some suitable ye-olde-world 
insults. ;-)

> This is still unsolved, and ideas are welcome. 
> When this works Civil
> can
> be used as a heavyweight substitute for the 
> good old "talk" program...
> :-)

I know it's pretty common to just fix a set of 
keys in the hendler code. This is certainly what 
I do. Admittedly this can be annoying if your on 
a different keymap, but it's what a lot of games 
end up doing.

Does pyhton support a locale? (module for it? 
Can't remember) -- if so, does this give clues? 

I did a windows solution once, but that was a 
registry hack. Obviously wouldn't work on *NIX...

G


-------------------------------------------------
This mail sent through UK Online webmail

Hi all,

I've done some stuff on the editor lately, but nothing major. Another
thing that may be of interest is that I whacked up initial support for
chatting between players. It works ok, but has some more or less big
flaws (some of which aren't my fault)...

Anyway, to send a message press '0' (zero), which will bring up a small
dialog (looks like the help dialog) one line high above the panel. All
keypresses are now directed to this field and will be echoed there.
Pressing <enter> sends the message to the server and from the server to
the other client. The message is then displayed in the message area of the
panel. Hitting <escape> or clicking the mouse should close the chat window
and abandon the changes.

The problems arise in handling special characters that are "behind" shift,
alt graph or similar modifier keys. There is currently no good way of
determining which character should be displayed, as it depends on the
installed keymap etc. I know the pressed "base" key, such as "1", but if
shift is also pressed it should become a "!". Some characters are in
predictable locations, but many are not, such as ()[]-+?\/*:; and so on.
This is still unsolved, and ideas are welcome. When this works Civil can
be used as a heavyweight substitute for the good old "talk" program... :-)

--------------------+--------------------------------------------------------
Jan 'Chakie' Ekholm |     Balrog New Media    http://www.balrog.fi/
   Linux Inside     | I'm the blue screen of death, nobody hears your screams

At 09:26 PM 6/1/01, you wrote:
>Good work, Gareth! You've had one hell of a
>productive week, where do you get all energy from?

I'd only be half joking if I said Beer, and vigorous masturbation... :P

Anyway -- thanks for the comments, I've not yet had my 'second look' at the 
lakes yet. That normally decides if I like something or not!

BTW, I may not be able to do the roads as planned; real life has just 
landed with a bang. I can't say too much atm, other than Emily and I have 
hit a rather large bump. Hexes over the next month will be an excellent 
barometer on how well things are going...


G


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