civil-devel Mailing List for Civil

> Oh, I wish that SF could restore the proper Reply-To header so the
> replying to a civil-devel mail would put the list name in To and no Cc at
> all.

Me too, although I have finally figured out how to make a mail rule to
override the default behaviour. For once Microsoft saved the day. Entourage,
despite being a glorified outlook, is very nice sometimes... :)

G

-- 
  "Computer games don't affect kids; I mean if Pac-Man affected us as kids,
  we'd all be running around in darkened rooms, munching magic pills and
  listening to repetitive electronic music."
      -- Kristian Wilson, Nintendo Inc., 1989
--

On Fri, 31 May 2002, John Eikenberry wrote:

>I think Jan accidentally replied to me instead of the list... 

Yeah, because you had mailed me directly too, so I thought you didn't mean
to reply to the list.

Oh, I wish that SF could restore the proper Reply-To header so the
replying to a civil-devel mail would put the list name in To and no Cc at
all.

-- 
        Five exclamation marks, the sure sign of an insane mind.
                                              -- Terry Pratchett, Reaper Man

I think Jan accidentally replied to me instead of the list... 

Jan Ekholm wrote:

> On Thu, 30 May 2002, John Eikenberry wrote:
> 
> >Jan Ekholm wrote:
> >
> >> This is something that could be done by the scenario designer. The user
> >> could plot out some interesting points, such as crossroads, bridges etc,
> >> so that the path calculations always passes through these. Objectives
> >> could also automatically be added.
> >> 
> >> Of course if a scenario is never meant to be played against an AI player
> >> this is not really necessary?
> > 
> >Well, one of the benifits of Mike's idea was that it didn't require info
> >imbedded in the map. And I figure the less you have to do to create a
> >map the better. Anyways, by fixed points I meant as preset points to
> >calculate paths for... instead of entirely random points.
> >
> >Of course this could supported but optional, for map designers who likes
> >to control these things. It could come in handy when there is a bridge
> >that only one side knows of about or something. It'd also save on game
> >initialization time.
> 
> I think that doing a good scenario will anyway take considerable time.
> Creating and setting properties for, say, 200 units takes some serious
> time, as well as making the main map. Plotting out 50 important features
> of the map is nothing compared to the overall time. I assume designers
> want to be able to control the AI to a certain degree, maybe to make it
> follow the historical events.
> 
> Reducing the work for scenario designers is of course good, but there are
> other parts of that process that can be streamlined to gain more time than
> what the plotting would lose.

Good to know. Even if using the pathfinding to find bottlenecks isn't
entirely useful for civil, I think I'll work it up anyways. Its just a
cool idea. :) And maybe it will end up being useful in other ways.

-- 

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

[I though I sent this ages ago, but apparently it got interrupted along
 the way, and Pine sugegsted I do something about it, so here it is. :) ]

On Wed, 29 May 2002, John Eikenberry wrote:

>
>Now that I have simple influence mapping working I'm thinking about how
>to better reflect aspects of the game in the spreading of the values. I
>have a few ideas for this:
>
>1. A new attribute/api for units to get its base strategic value. It
>could start with a base value for the unit type and take fatigue and
>experience into account as modifiers. I'm thinking a method on Unit.

Base strategic value for a unit is a good idea, I think. It allows the AI
to "see" force concentrations and thus unit/map parts that can be attacked
or where threats are. The AI could then have rules that say when it would
attack and when retreat.

Hmm, the possibilities for such a thing are endless... Not that I have a
clue, I'm just guessing.

>2. A terrain modifier to the unit's base value based on terrain's attack
>and defence modifiers, as well as altitude.

The terrain modifiers already exist. You have an attack and defensive
value for each type of terrain. The map of terrain types may be a little
bit incomplete though.


-- 

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

On Thu, 30 May 2002, John Eikenberry wrote:

>> But the AI could identify bottlenecks, and here's how:
>> 
>> Start with the terrain map, and a weight map initialized 
>> to 0s.  Then iterate over the following procedure:
>> 
>> Pick two random points, A & B.  +=1 to every hex the 
>> fastest path between them passes through.
>
>In addition to the random point, a small set of fixed points might be
>necessary to ensure good coverage.

This is something that could be done by the scenario designer. The user
could plot out some interesting points, such as crossroads, bridges etc,
so that the path calculations always passes through these. Objectives
could also automatically be added.

Of course if a scenario is never meant to be played against an AI player
this is not really necessary?

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

On Thu, 30 May 2002 ml...@at... wrote:

>I was telling a friend about the nice AI foundation 
>being laid in Civil, and the problems with AI in 
>wargames in general yesterday, and had an interesting 
>idea I thought I'd throw out for discussion:
>
>One of the big issues AIs usually have is that they 
>don't understand the topology of the map.  I find that 
>they can often be beaten by placing fortified 
>troops/artillery in positions that dominate bottlenecks 
>(where the maps have them that is); bridges, canyons, 
>and the like.

Yes, I've seen this tactic work out in some games, most notably RTS games
with weaker AI. Getting the AI to understand the terrain can be quite
hard, I think. I've seen a lot of the AI in Combat Mission that I play
quite a lot, and it has a really hard time to understand the terrain.
There you rarely have some bottleneck, but you do need to use hills in
order to see the battlefield, and you should use what cover there is for
advances. The AI often fails this and does ridicilous advances over open
fields.

>But the AI could identify bottlenecks, and here's how:
>
>Start with the terrain map, and a weight map initialized 
>to 0s.  Then iterate over the following procedure:
>
>Pick two random points, A & B.  +=1 to every hex the 
>fastest path between them passes through.
>
>Do this some number of times related to the size of the 
>map (until the total weights assigned are some constant 
>times the total number of map hexes?).  Maybe blur it 
>afterwards?

Or try to find the paths and build up a graph with the fast lanes from
place to place? This graph could naturally have the road network as a
base, and then add extra fast paths after this calculation. Not that I
know wether such a thing would be of any use at all...

>You should end up with a map where bottlenecks and quick 
>paths - roads, bridges - have extremely high values, and 
>impassible/dead-end terrain has low values.

This whole thing is actually an excellent idea. That "path map" could also
be combined with the influence map that gives the enemy strength, thus
letting the AI see which paths are associated with great resistance. Using
this info the AI could maybe avoid sending troops into bottlenecks that
are known to be heavily guarded, maybe instead prompting it to use some
other slower and less guarded path.

>Maybe make another pass over it then, and 
>assign 'strategic importance' values to hexes based on 
>the total 'path weights' of all hexes within Line-of-
>Sight?  (Thus, a hill overlooking a key bridge & road 
>would have a very high value).

I'm not exactly sure I got that last part. Still too early in the morning.
But somehow terrain elevation and terrain type could be assembled into a
map giving the AI a sense of what parts of the map are worth "getting".

Doing AI is no simple feat.

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

On Thu, 2002-05-30 at 19:04, John Eikenberry wrote:
> 3. Using bottlenecks for pathfinding optimization. With large maps
> pathfinding long paths get burdensome. One common trick to deal with
> this is to break the map up into regions, and identify connection points
> (bottlenecks). Plot a inter-region path using just the connection
> points, then plot the intra-region paths (possibly lazily). This gives
> us a way to calculate this without having to add the infomation directly
> to the map.

Mmmm.  That's interesting.  Oddly, this gives you the waypoints but not
the region boundries.  Although you might be able to deduce them from a
second pass over the, um, 'path density' map: take a point not assigned
to any region, do a spill fill that stops at very high or low path
density.  That's now a region.  Repeat until all passable areas are
assigned.


> In addition to the random point, a small set of fixed points might be
> necessary to ensure good coverage.

My intuition is that random points would be ok on a big map, but I don't
really know; you might be better off just taking every point (a,b) such
that a & b mod N (for some value of n, 10?? maybe) is 0 and doing them
all to each other.

On an X*Y map, though, this would be O(X^2*Y^2).  That could turn into a
couple hundred thousand pathfinds pretty quickly.  Dunno how many paths
you need.

Ooh, and another thought; if there are objectives on the map, there
should be a large number of paths with the objectives as one endpoint
(count related to objective value somehow?).


> It might also be possible to use the in game pathfinding to find
> bottlenecks not found in the original analysis.

That might make sense, as those are presumably paths you especially care
about for some reason... come to think of it, this gets especially
interesting if the pathfinder is using run-time data.  Yeah, you might
have an AI defending an objective add the paths created from enemy units
to that objective - with the influence map added to movement cost to
create the cost function for that run pathfinder.  The movement paths
would thus run through the least defended areas, flagging them as
significant, and the AI would know to reinforce them.  

- mikee

Great idea! 

This should be fairly straightforward to implement and provides quite a
bit of useful information.

1. Mark strategic points on the map. Useful for determining sub-goals
and general strategy. The essence of your idea.

2. Influence map modifier using the LOS strategic importance values. A
unit on that hill overlooking the bridge and road would have a greater
influence. Not sure about this one, I'll need to think about it some
more.

3. Using bottlenecks for pathfinding optimization. With large maps
pathfinding long paths get burdensome. One common trick to deal with
this is to break the map up into regions, and identify connection points
(bottlenecks). Plot a inter-region path using just the connection
points, then plot the intra-region paths (possibly lazily). This gives
us a way to calculate this without having to add the infomation directly
to the map.

More stray thoughts scattered below...

ml...@at... wrote:

> I was telling a friend about the nice AI foundation 
> being laid in Civil, and the problems with AI in 

Thanks. :)

> wargames in general yesterday, and had an interesting 
> idea I thought I'd throw out for discussion:
> 
> One of the big issues AIs usually have is that they 
> don't understand the topology of the map.  I find that 
> they can often be beaten by placing fortified 
> troops/artillery in positions that dominate bottlenecks 
> (where the maps have them that is); bridges, canyons, 
> and the like.

/me nods. I can't really remember one game that really took good
advantage of bottlenecks.
 
> But the AI could identify bottlenecks, and here's how:
> 
> Start with the terrain map, and a weight map initialized 
> to 0s.  Then iterate over the following procedure:
> 
> Pick two random points, A & B.  +=1 to every hex the 
> fastest path between them passes through.

In addition to the random point, a small set of fixed points might be
necessary to ensure good coverage.

> Do this some number of times related to the size of the 
> map (until the total weights assigned are some constant 
> times the total number of map hexes?). 

A possibly useful addition would be to mark bottlenecks the opponents
uses frequently and raise their strategic values accordingly. 

It might also be possible to use the in game pathfinding to find
bottlenecks not found in the original analysis.

> Maybe blur it afterwards?

I think so, by a small amount (1-2 hex(es)). This will increase the
values on area with a clustering of high valued hexes and lower tha
values of areas with a solitary high valued hex.
 
> You should end up with a map where bottlenecks and quick 
> paths - roads, bridges - have extremely high values, and 
> impassible/dead-end terrain has low values.
> 
> Maybe make another pass over it then, and 
> assign 'strategic importance' values to hexes based on 
> the total 'path weights' of all hexes within Line-of-
> Sight?  (Thus, a hill overlooking a key bridge & road 
> would have a very high value).

-- 

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

I was telling a friend about the nice AI foundation 
being laid in Civil, and the problems with AI in 
wargames in general yesterday, and had an interesting 
idea I thought I'd throw out for discussion:

One of the big issues AIs usually have is that they 
don't understand the topology of the map.  I find that 
they can often be beaten by placing fortified 
troops/artillery in positions that dominate bottlenecks 
(where the maps have them that is); bridges, canyons, 
and the like.

But the AI could identify bottlenecks, and here's how:

Start with the terrain map, and a weight map initialized 
to 0s.  Then iterate over the following procedure:

Pick two random points, A & B.  +=1 to every hex the 
fastest path between them passes through.

Do this some number of times related to the size of the 
map (until the total weights assigned are some constant 
times the total number of map hexes?).  Maybe blur it 
afterwards?

You should end up with a map where bottlenecks and quick 
paths - roads, bridges - have extremely high values, and 
impassible/dead-end terrain has low values.

Maybe make another pass over it then, and 
assign 'strategic importance' values to hexes based on 
the total 'path weights' of all hexes within Line-of-
Sight?  (Thus, a hill overlooking a key bridge & road 
would have a very high value).

- mikee

Now that I have simple influence mapping working I'm thinking about how
to better reflect aspects of the game in the spreading of the values. I
have a few ideas for this:

1. A new attribute/api for units to get its base strategic value. It
could start with a base value for the unit type and take fatigue and
experience into account as modifiers. I'm thinking a method on Unit.

2. A terrain modifier to the unit's base value based on terrain's attack
and defence modifiers, as well as altitude.

3. Somehow take LOS into account. Not sure how to do this efficiently at
the moment.


I've also been messing around with the Mike's idea of keeping around the
values from the previous turn with a decay rate. Both as a way to reduce
the number of iterations and to give a sense of time to the data. I like
it and have added it to my code. 

Currently if the same map is reused, it starts with the weightmap from
the previous round. The decay is used if set. If you don't want
persistent values you can either create a new instance or reset the
map.

-- 

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

Jan Ekholm wrote:

> That influence map works great! Tried playing a little with different
> maps, and they all look ok to me. It's actually a joy looking at the maps,
> I've never seen ascii art used that good. :)

Thanks. I've found them to be immensely helpful in figuring this stuff
out. When working a lot by trial and error, its great to get quick
feedback.
 
> Now a little question. Is there a good reason for doing the influence maps
> hexbased? Or, for that matter, have the AI think in hexes at all? The
> normal graphical map and the icons that make it up are hexbased, but
> nothing else really is. The AI calculation could AFAIK use normal
> "rectangular" coordinates, either discrete or continuous. Or am I way off
> thinking silly stuff here?

Well, I think I need hex based calculations for the pathfinding. As the
path will get used directly for movement on the map. Using the
"rectangular" or grid based coordinates for path plotting could end up
uith some odd looking paths when displayed.

I wanted to use the same representation for the influence map as the
pathfinding used to make it easier to use the influence map to guide
pathfinding.

I also thought it'd be easier to develope the AI if all its maps
corresponded directly to the graphical map. To avoid having to mentally
convert it when trying to figure out why things aren't behaving
correctly.


On the other hand, it might not be so bad for the influence map. As its
more of an abstract representation of the map. And the resulting shape
of the influence values on the hex map is not much different. 

Try commenting out the 2 _shift_hex_* calls and changing the factor
array to 4.0 (at the top) to see what I mean. This might be good to
know if we need a performance improvement... but it took me a while to
figure out the hex based version, and I don't want to throw it away just
after getting it right. :)

-- 

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 Thu, 23 May 2002, John Eikenberry wrote:

>
>I finally got the hex based influence map working. It was a pain, though
>not as big a one as the time elapsed would suggest (workus interruptus).
>
>Its API isn't there, but you can play with the test script to see it in
>action. On linux you can just cd into the src/ai/tests dir and run
>./influ_test.py. Not sure if/how this will work in windows.

That influence map works great! Tried playing a little with different
maps, and they all look ok to me. It's actually a joy looking at the maps,
I've never seen ascii art used that good. :)

Now a little question. Is there a good reason for doing the influence maps
hexbased? Or, for that matter, have the AI think in hexes at all? The
normal graphical map and the icons that make it up are hexbased, but
nothing else really is. The AI calculation could AFAIK use normal
"rectangular" coordinates, either discrete or continuous. Or am I way off
thinking silly stuff here?

-- 
"It would seem that you have no useful skill or talent whatsoever," he said.
              "Have you thought of going into teaching?"  
                                                    -- Terry Pratchett, Mort

John Eikenberry wrote:

> Trying your suggestion of shifting the edges back on themselves leads to
> the opposite problem (the values are too high). I think a halfway
> solution would be to change the value of 'zero' to something between 0.2
> and 0.5. This would nudge those edge values up a bit, while not
> unbalancing the map. I've got it at .33 at the moment and it raises the
> edge value by about 55% and those one and two in by a bit as well.
 
After a bit more testing I realized .33 wasn't right. It does better
with a higher setting. I have it at .66 currently and it comes very
close to what it would be away from the edge.

If you want to see what I've done, I'm about to commit.

-- 

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

Michael Earl wrote:

> Nice! The test script is lovely, too.

Thanks. :)
 
> It seems to interact weirdly with the edge of the board, though; I
> suspect the off-the-board hexes are effectively locked at 0 and this is
> producing odd results.  I think this can be offset by tweaking shift_up
> and shift_down to have those 0-rows shift the last rows onto themselves
> (as well as the row before), but am currently butchering the slicing to
> attempt this:

Trying your suggestion of shifting the edges back on themselves leads to
the opposite problem (the values are too high). I think a halfway
solution would be to change the value of 'zero' to something between 0.2
and 0.5. This would nudge those edge values up a bit, while not
unbalancing the map. I've got it at .33 at the moment and it raises the
edge value by about 55% and those one and two in by a bit as well.

I think this is what you were shooting for...

> def shift_up(cells):
>     return concatenate((cells[1:], cells[:0]))
    return concatenate((cells[1:], cells[-1:]))
 
> def shift_down(cells):
>     return concatenate((cells[1], cells[:-1]))
    return concatenate((cells[:1], cells[:-1]))

 
> YMMV.  This may also not be a real problem, especially on really big
> boards, but it strikes me a bit funny.

I don't think its a big problem either. But its a nice tweak.

-- 

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, 2002-05-24 at 00:14, John Eikenberry wrote:
> 
> I finally got the hex based influence map working. It was a pain, though
> not as big a one as the time elapsed would suggest (workus interruptus).

Nice! The test script is lovely, too.

It seems to interact weirdly with the edge of the board, though; I
suspect the off-the-board hexes are effectively locked at 0 and this is
producing odd results.  I think this can be offset by tweaking shift_up
and shift_down to have those 0-rows shift the last rows onto themselves
(as well as the row before), but am currently butchering the slicing to
attempt this:

def shift_up(cells):
    return concatenate((cells[1:], cells[:0]))

def shift_down(cells):
    return concatenate((cells[1], cells[:-1]))

Is what I wanted to try, but there's a type error because of some kind
of array dimension mismatch.

YMMV.  This may also not be a real problem, especially on really big
boards, but it strikes me a bit funny.

- mikee

I finally got the hex based influence map working. It was a pain, though
not as big a one as the time elapsed would suggest (workus interruptus).

Its API isn't there, but you can play with the test script to see it in
action. On linux you can just cd into the src/ai/tests dir and run
./influ_test.py. Not sure if/how this will work in windows.

I'm planning on implementing a persistent map with degrading influence
values to supplement the purely iterative version.

I committed it just a few minutes ago. 

-- 

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 Tue, 2002-05-21 at 06:13, John Eikenberry wrote:
> I'm committing the fix now and it shouldn't effect anything as nothing
> else seems to be using it.

I'm pretty sure the only code that uses that is map.calculateHexTris,
which is currently itself dead code.  It's intended to produce a
continuous altitude map (composed of triangular planar sections) from
the discrete altitudes of the individual hexes (and LoS uses this
already), but currently all the hexes are labeled as altitude 0, so this
field is just initialized to flat anyway in map.__init__.

- mikee

I think getHexAdjacent is currently broken. The map's x,y coord system
is set up to have x on the verticle axis and y on the horizonal:

        # initialize the array of hexes
        self.hexes = [ None ] * xsize
        for index in range (xsize):
            self.hexes[index] = [ None ] * ysize

getHexAdjacent() is set up for x as the horizonal and y verticle.

This is backwards from what I'm used to dealing with, but happens to be
the same as Numeric's array slicing behaviour. So it works out.

I'm committing the fix now and it shouldn't effect anything as nothing
else seems to be using it.

-- 

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 Sat, 2002-05-18 at 20:17, Marcus Alanen wrote:
> ok, it was probably unnecessary work in that case... I thought we 
> lacked this function.

No, it's used by (I think) the editor, and by the line-of-sight,
movement, and combat code to figure out what terrain type a location is
(indirectly, via map.getTerrain).  The LoS code calls it an awful lot;
might speed that up noticably if a faster implementation is swapped in.

- mikee

On 18 May 2002, Michael Earl wrote:

> > (I was actually a bit surprised to find pointToHexCenter, was there
> > something wrong with that routine? 
> Nope, works fine so far as I know.

ok, it was probably unnecessary work in that case... I thought we 
lacked this function.

Marcus

On Sat, 2002-05-18 at 13:05, Marcus Alanen wrote:
> Hi, Map.pointToHex2() calculates hex coordinates based on the gfx
> pixel you give it[1]. 

Er, is this actually different than Map.pointToHex()?  It's admittedly
probably faster, although I think the logic is basically the same.

> 
> (I was actually a bit surprised to find pointToHexCenter, was there
> something wrong with that routine? 

Nope, works fine so far as I know.
 

- mikee

Hi, Map.pointToHex2() calculates hex coordinates based on the gfx
pixel you give it[1]. It isn't used anywhere yet, but will probably be
needed later. You can try it by uncommenting terrain_layer's
"Debuggin, draws hex lines" part and 
State.activateUnit's "scenario.map.pointToHex2((x,y))" line.
Then click around.

(I was actually a bit surprised to find pointToHexCenter, was there
something wrong with that routine? Anyway, this one ought to be 
faster)

Unfortunately it's very hard to explain without pen & paper, and quite 
a bit of time. So you won't find any _good_ explanation in the code of 
how it works... :(

[1] or actually, the "map gfx" coordinate, not real graphical 
pixel coordinate on-screen. E.g., unit coords in the scenario file.

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

>> mmh, I think the possibility to add/remove specific hexes for
>> non-rectangular blocks (and blocks with "holes" in them) would be
>> cool. This way you could save e.g. a river, a group of forests etc.
>> and _only_ that, no need to have any of the crap around them.
>> 
>> If it isn't too much work (for the user) to simply start with a "click
>> on every hex you want in the block" kinda thing, I'd weakly suggest
>> that.
> 
> Sounds like a good plan, but I'm not sure how you'd present the functionality
> nicely to the user...
> 
> Chakie, your serve I guess.
> 
> G

-- 
 "With sufficient thrust, pigs fly just fine."
    -- RFC 1925
--

On Wed, 15 May 2002, Korruptor wrote:

> I'd vote for the ol "Draw a rectangle around some hexes on the map view, and
> click 'Make User defined Block'" or similar.

mmh, I think the possibility to add/remove specific hexes for 
non-rectangular blocks (and blocks with "holes" in them) would be 
cool. This way you could save e.g. a river, a group of forests etc.
and _only_ that, no need to have any of the crap around them.

If it isn't too much work (for the user) to simply start with a "click 
on every hex you want in the block" kinda thing, I'd weakly suggest 
that.

Marcus

-- 
A man's four essential food groups are: white meat, red meat, warm beer and
cold lager. Please ensure all meals contain a good balance of the above in
acceptable quantities.  Everything else falls under the category 'garnish'.

  - Author: Unknown Sexist...
--

------ Forwarded Message
> From: Korruptor <kor...@ma...>
> Date: Wed, 15 May 2002 17:18:31 +0100
> To: Jan Ekholm <ch...@in...>
> Subject: Re: [Civil-devel]Editor help
> 
>> complete set of icons and the current map. Somehow we should let the user
>> define aither a part of the map as a block, or select from the icons and
>> build up a block.
> 
> Building a block kinda implies another dialog with the requisite block
> building bits on. As much as you like Qt designer, I've rather you weren't
> working on the editor for ages! ;-)
> 
> I'd vote for the ol "Draw a rectangle around some hexes on the map view, and
> click 'Make User defined Block'" or similar.
> 
> My 0.02p
> 
>> Also, I will make blocks that the user creates be saved under
>> $HOME/.civil/editor/blocks/, as we can't guarantee that the user actually
>> has write permissions to wherever the editor might be installed.
> 
> Ack...
> 
> G 
> -- 
>   "If Bill Gates had a dime for every time Windows crashed...
>    Oh, wait a minute. He already does..."
> 
>       -- Anon
> -- 
> 
>       

------ End of Forwarded Message