Bugs in Bellum Aeternum

Bugs in Bellum Aeternum

[Lincoln Peters]

A few bugs I found in Bellum Aeternum:

1. If a unit that is restricted to clear terrain (e.g. armor, engineers)
tries to move from a road on such a restricted area area into another
unit (e.g. sea transport in neighboring coastal waters), it vanishes! 
Perhaps you should should use vanishes-on more carefully (i.e. don't .

2. It is currently allowed for units that cannot cross forests,
mountains, or swamps without a road to get off the roads while in such
terrain.  This can have the result that a unit gets stuck in a cell from
which it cannot escape (e.g. a plain cell surrounded on all sides by
mountain and forest).  Perhaps you should use mp-to-leave-terrain to
prevent this (it might also fix bug #1).

And a few problems that might not be bugs:

3. I think you should set the capacity of towns to something greater
than 2.  Currently, if a town has one unit as a garrison and one under
construction, it is impossible for any other units (except aircraft) to
pass through!

Re: Bugs in Bellum Aeternum

[Eric McDonald]

Hi Lincoln,

On 21 Sep 2003, Lincoln Peters wrote:

> 1. If a unit that is restricted to clear terrain (e.g. armor, engineers)
> tries to move from a road on such a restricted area area into another
> unit (e.g. sea transport in neighboring coastal waters), it vanishes! 
> Perhaps you should should use vanishes-on more carefully (i.e. 

I believe that in the latest version of Bellum, I have essentially 
disabled that table. Were you able to retrieve a recent CVS 
snapshot, or are you still having CVS problems?

> mountain and forest).  Perhaps you should use mp-to-leave-terrain to
> prevent this (it might also fix bug #1).

Good thought. I will look into it.

> 3. I think you should set the capacity of towns to something greater
> than 2.  Currently, if a town has one unit as a garrison and one under
> construction, it is impossible for any other units (except aircraft) to
> pass through!

OK, I will consider your suggestion.

In general, how does the game feel? Is the production model 
"too different"? Do units seem to have the correct number of moves 
per turn? Are there too many unit types? Is the game fun when 
played against a human opponent(s)? Etc, etc...?

  Thanks for the feedback,
    Eric

Re: Bugs in Bellum Aeternum

[Lincoln Peters]

On Sun, 2003-09-21 at 22:50, Eric McDonald wrote: 
> Hi Lincoln,
> 
> On 21 Sep 2003, Lincoln Peters wrote:
> 
> > 1. If a unit that is restricted to clear terrain (e.g. armor, engineers)
> > tries to move from a road on such a restricted area area into another
> > unit (e.g. sea transport in neighboring coastal waters), it vanishes! 
> > Perhaps you should should use vanishes-on more carefully (i.e. 
> 
> I believe that in the latest version of Bellum, I have essentially 
> disabled that table. Were you able to retrieve a recent CVS 
> snapshot, or are you still having CVS problems?

I finally got CVS to work by deleting my entire "xconq" tree and then
re-checking it out.  I can see some practical uses for the vanishes-on
table (e.g. infantry in the deep ocean), but this is not one of them.


Two more problems I found with the module:

4. Ruins exert ZOC, and in doing so prevent aircraft from flying over
them.  That doesn't seem right.

5. Attacking bombers, dive bombers, etc. have a chance to retreat when
*attacking* a capital.  I think that this would only make sense when the
bombers are themselves under attack, or if they (foolishly) try to
attack fighters.

> > mountain and forest).  Perhaps you should use mp-to-leave-terrain to
> > prevent this (it might also fix bug #1).
> 
> Good thought. I will look into it.
> 
> > 3. I think you should set the capacity of towns to something greater
> > than 2.  Currently, if a town has one unit as a garrison and one under
> > construction, it is impossible for any other units (except aircraft) to
> > pass through!
> 
> OK, I will consider your suggestion.
> 
> In general, how does the game feel? Is the production model 
> "too different"? Do units seem to have the correct number of moves 
> per turn? Are there too many unit types? Is the game fun when 
> played against a human opponent(s)? Etc, etc...?

So far, I've only played it against the AI mplayer.  However, as I
continue to play against the AI, I've noticed some more problems (many
of which, however, are problems with Xconq itself).  These are, in no
particular order:

1. It's somewhat difficult to keep track of all of the different
materials.  Although that may be a problem in Xconq itself rather than
your game (I had the same problem with space-civ.g).

2. Oftentimes, a unit with a low supply of something it can easily
produce in the background will stop whatever it's doing and ask for new
orders.  I almost always end up giving it the same orders as before.  I
think that you could, at the minimum, use doctrines to prevent immobile
producers (bases, towns, cities, et al.) from complaining if they run
low on 'c'.

3. It might be helpful if there was a way to simplify all of the various
grades of battleships into one unit-type, and simplify all of the
various grades of aircraft carriers into one unit-type.  However, last
time I looked, that was beyond the capabilities of Xconq.

4. As it is set up now (unless things have changed since my last CVS
update), armor has a 5% chance of success to capture a capital with each
attack.  No other units can do this.  Is the idea of the game that a
side persists until its capital is destroyed (or surrenders), or until
its capital is overrun?

5. There should be a way to clear ruins.  They get in the way when I try
to germinate.  It would also be interesting if one side could gut an
enemy town and build a grand citadel where the town used to be.
   The way I handled it in one of my projects (bolodd.g, which might
appear in the unfinished games library fairly soon) was that ruins were
always independent, but engineers could attack them and inflict 6d6
damage per hit, clearing them much faster than non-engineers could (they
rarely inflict more than 1d6 damage with each hit).

6. There should be an easy way to give orders such as "move to within 3
of x,y; then wait for a friendly transport ship with less than 6
occupants to move to x,y; then move to x,y."  I could probably do it
using standing orders (although I'm not sure that standing orders could
easily work here with *any* transport ship), but there should be a
simpler way.

7. There should be a relatively simple way to visualize the supply
system.  Perhaps a color could be assigned to each material, then an
option under the "View" menu could be used to display the supply using
alphablending?  If I haven't made this idea clear, I could try to send a
picture.

8. If a unit is unable to perform a create or build action due to
insufficient material, it should warn the player and give the
opportunity to resolve the situation, then tell the unit to proceed.

9. When the game gets really big, it becomes less desirable to
micromanage units that are not on the front lines.  One thing that can
become annoying is that, if I want a bunch of ground units to meet one
or more transport ships, it is often necessary to use several separate
"move" actions, since the pathfinding algorithm is so brain-dead.

10. There should be some way to instruct a unit to transfer x units of
material y to unit z.  The simple 'T' and 'G' commands don't cut it in
this game.

11. Once a unit's "SupplyLow" flag is up due to being less than half
full of one supply (e.g. 'c'), and you give it an order, it will not
stop for further instructions even if another, even more important
supply (e.g. 'f1') runs low.  (I say "more important" because, although
no unit can function without 'c', running out won't kill it, whereas
running out of 'f1' would kill any aircraft)
   Perhaps there should be some sort of distinction between a SupplyLow
condition that could incapacitate a unit and a SupplyLow condition that
could kill it.

Re: Bugs in Bellum Aeternum

[Eric McDonald]

On 23 Sep 2003, Lincoln Peters wrote:

> I finally got CVS to work by deleting my entire "xconq" tree and then
> re-checking it out.  I can see some practical uses for the vanishes-on
> table (e.g. infantry in the deep ocean), but this is not one of them.

It was useful in finding the "unit leaves road, crosses illegal 
terrain to get to legal transport" bug. But, like I said, I have 
had most of that table disabled for some time, so you should not 
have been seeing the vanishing behavior with any checkout over 
the past few weeks.

> 4. Ruins exert ZOC, and in doing so prevent aircraft from flying over
> them.  That doesn't seem right.

Well, independent ruins should allow aircraft into them.
As far as hostile ruins go, who is to say that occupation forces 
are not using them for a (rather shabby) depot or base of 
operations? In that case, aerial defenses might be present.  I 
don't know, I'll think about it some more. I actually did consider 
what you are suggesting during the design of the module.

> 5. Attacking bombers, dive bombers, etc. have a chance to retreat when
> *attacking* a capital.  I think that this would only make sense when the
> bombers are themselves under attack, or if they (foolishly) try to
> attack fighters.

Yes. I thought I had that behavior ironed out at some point. I'll 
see what I can do.

> 1. It's somewhat difficult to keep track of all of the different
> materials.  Although that may be a problem in Xconq itself rather than
> your game (I had the same problem with space-civ.g).

My module does have quite a few materials. It was my experience 
that, aside from command and control ('c'), they form a backdrop 
econcomy that you can usually ignore. One thing I could do to aid 
tracking would be to define the most important ones first so that 
they get displayed in the top row (of the Tcl/Tk info window), 
which generally does not get clobbered with other text.

> think that you could, at the minimum, use doctrines to prevent immobile
> producers (bases, towns, cities, et al.) from complaining if they run
> low on 'c'.

I thought that I had already cranked the resupply and rearm 
percentages down to 0 for facility types, but I will double check 
when I get home from work.

> 3. It might be helpful if there was a way to simplify all of the various
> grades of battleships into one unit-type, and simplify all of the
> various grades of aircraft carriers into one unit-type.  However, last
> time I looked, that was beyond the capabilities of Xconq.

Are you thinking in terms of some sort of class-subclass 
relationship, or do you have something else in mind?

I will agree 
that {frigate,cruiser,battleship} and {escort carrier,light 
carrier,fleet carrier} basically form a price-performance 
continuum (aside from special command-and-control production 
among the heavier members of each set).

> 4. As it is set up now (unless things have changed since my last CVS
> update), armor has a 5% chance of success to capture a capital with each
> attack.  No other units can do this.  Is the idea of the game that a
> side persists until its capital is destroyed (or surrenders), or until
> its capital is overrun?

Yes, unless you turn on the "Stubborn Sides" variant, in which 
case some other units can continue the fight after the Capitol 
falls.

Capitols are not meant to be easy to take or destroy. You 
correctly note that only Armor has enough oomph (and just barely) 
to make a successful capture attempt against a Capitol. I have not 
added a Stormtroopers unit type, but if I do, then it will also 
have that ability. The question is, does the module need yet 
another land unit type?

> 5. There should be a way to clear ruins.  

I have been contemplating adding a disband table entry to 
accomplish this.

>They get in the way when I try
> to germinate.  It would also be interesting if one side could gut an
> enemy town and build a grand citadel where the town used to be.

Yes.
And once the type change mechanism is fully functional, there will 
be the ability to evolve town->city->metropolis, which should help 
make things even more interesting.

So you like Grand Citadels? Do you think they are too powerful or 
too cheap (compared with Towns)?

>    The way I handled it in one of my projects (bolodd.g, which might
> appear in the unfinished games library fairly soon) was that ruins were
> always independent, but engineers could attack them and inflict 6d6
> damage per hit, clearing them much faster than non-engineers could (they
> rarely inflict more than 1d6 damage with each hit).

I thought I had given Engineers an advantage against them, but 
maybe that was just against mines....

Another way to handle this is to make Ruins' hp-max small (like I 
had it during most of the alpha phase), and just arrange things so 
that they have a hp-min = hp-max when versus all units except 
Engineers. That way only Engineers could destroy them. This is 
actually the direction I am thinking about heading, provided that 
part of Xconq actually works....

> 6. There should be an easy way to give orders such as "move to within 3
> of x,y; then wait for a friendly transport ship with less than 6
> occupants to move to x,y; then move to x,y."  I could probably do it
> using standing orders (although I'm not sure that standing orders could
> easily work here with *any* transport ship), but there should be a
> simpler way.

Agreed. I think Bruno Boettcher expressed a similar desire on this 
list several months ago.

> 7. There should be a relatively simple way to visualize the supply
> system.  Perhaps a color could be assigned to each material, then an
> option under the "View" menu could be used to display the supply using
> alphablending?  If I haven't made this idea clear, I could try to send a
> picture.

Good idea.

> 9. When the game gets really big, it becomes less desirable to
> micromanage units that are not on the front lines.  One thing that can
> become annoying is that, if I want a bunch of ground units to meet one
> or more transport ships, it is often necessary to use several separate
> "move" actions, since the pathfinding algorithm is so brain-dead.

One of the things I am going to propose to the community after 7.5 
is released is the idea of being able to set waypoints with the 
click of the mouse (or by the traditional move-to) and have them 
visually indicated whenever a relevant unit (one that is 
following the set of waypoints) is selected.

> 11. Once a unit's "SupplyLow" flag is up due to being less than half
> full of one supply (e.g. 'c'), and you give it an order, it will not
> stop for further instructions even if another, even more important
> supply (e.g. 'f1') runs low.  (I say "more important" because, although
> no unit can function without 'c', running out won't kill it, whereas
> running out of 'f1' would kill any aircraft)

Good observation.

  Thanks,
    Eric

Re: Bugs in Bellum Aeternum

[Hans Ronne]

>> 9. When the game gets really big, it becomes less desirable to
>> micromanage units that are not on the front lines.  One thing that can
>> become annoying is that, if I want a bunch of ground units to meet one
>> or more transport ships, it is often necessary to use several separate
>> "move" actions, since the pathfinding algorithm is so brain-dead.
>
>One of the things I am going to propose to the community after 7.5
>is released is the idea of being able to set waypoints with the
>click of the mouse (or by the traditional move-to) and have them
>visually indicated whenever a relevant unit (one that is
>following the set of waypoints) is selected.

Fixing the underlying problem, i.e. the brain-dead pathfinding algorithm,
is also high on the post-7.5 list.

Hans

Re: Bugs in Bellum Aeternum

[Lincoln Peters]

On Tue, 2003-09-23 at 13:17, Eric McDonald wrote: 
> On 23 Sep 2003, Lincoln Peters wrote:
> 
> > I finally got CVS to work by deleting my entire "xconq" tree and then
> > re-checking it out.  I can see some practical uses for the vanishes-on
> > table (e.g. infantry in the deep ocean), but this is not one of them.
> 
> It was useful in finding the "unit leaves road, crosses illegal 
> terrain to get to legal transport" bug. But, like I said, I have 
> had most of that table disabled for some time, so you should not 
> have been seeing the vanishing behavior with any checkout over 
> the past few weeks.

And I can now see that vanishes-on is no longer used.

> > 4. Ruins exert ZOC, and in doing so prevent aircraft from flying over
> > them.  That doesn't seem right.
> 
> Well, independent ruins should allow aircraft into them.
> As far as hostile ruins go, who is to say that occupation forces 
> are not using them for a (rather shabby) depot or base of 
> operations? In that case, aerial defenses might be present.  I 
> don't know, I'll think about it some more. I actually did consider 
> what you are suggesting during the design of the module.

A better solution might be if the occupants of the ruins exerted ZOC,
rather than the ruins itself.  I've never tried it, so I don't know if
it would work.

> > 5. Attacking bombers, dive bombers, etc. have a chance to retreat when
> > *attacking* a capital.  I think that this would only make sense when the
> > bombers are themselves under attack, or if they (foolishly) try to
> > attack fighters.
> 
> Yes. I thought I had that behavior ironed out at some point. I'll 
> see what I can do.
> 
> > 1. It's somewhat difficult to keep track of all of the different
> > materials.  Although that may be a problem in Xconq itself rather than
> > your game (I had the same problem with space-civ.g).
> 
> My module does have quite a few materials. It was my experience 
> that, aside from command and control ('c'), they form a backdrop 
> econcomy that you can usually ignore. One thing I could do to aid 
> tracking would be to define the most important ones first so that 
> they get displayed in the top row (of the Tcl/Tk info window), 
> which generally does not get clobbered with other text.

I was thinking that it might be useful to have finer control over the
supply system.  For example, I might want a base to give higher priority
to aircraft when supplying fuel, since they would die without it.

> > think that you could, at the minimum, use doctrines to prevent immobile
> > producers (bases, towns, cities, et al.) from complaining if they run
> > low on 'c'.
> 
> I thought that I had already cranked the resupply and rearm 
> percentages down to 0 for facility types, but I will double check 
> when I get home from work.
> 
> > 3. It might be helpful if there was a way to simplify all of the various
> > grades of battleships into one unit-type, and simplify all of the
> > various grades of aircraft carriers into one unit-type.  However, last
> > time I looked, that was beyond the capabilities of Xconq.
> 
> Are you thinking in terms of some sort of class-subclass 
> relationship, or do you have something else in mind?
> 
> I will agree 
> that {frigate,cruiser,battleship} and {escort carrier,light 
> carrier,fleet carrier} basically form a price-performance 
> continuum (aside from special command-and-control production 
> among the heavier members of each set).

I recall that the Game Designer's Manual indicated that this kind of
variation between different units could, in theory, be done with a
single unit type (the example I remember was young dragons and old
dragons).  On the other hand, it doesn't seem to work as well in
practice as it does in theory.

> > 4. As it is set up now (unless things have changed since my last CVS
> > update), armor has a 5% chance of success to capture a capital with each
> > attack.  No other units can do this.  Is the idea of the game that a
> > side persists until its capital is destroyed (or surrenders), or until
> > its capital is overrun?
> 
> Yes, unless you turn on the "Stubborn Sides" variant, in which 
> case some other units can continue the fight after the Capitol 
> falls.
> 
> Capitols are not meant to be easy to take or destroy. You 
> correctly note that only Armor has enough oomph (and just barely) 
> to make a successful capture attempt against a Capitol. I have not 
> added a Stormtroopers unit type, but if I do, then it will also 
> have that ability. The question is, does the module need yet 
> another land unit type?

What I was thinking was that, in most games, the capital is fairly easy
to capture if it is not well-garrisoned.  However, in a few games
(insect.g comes to mind), the only way to defeat another side is to
destroy its capital.  I wasn't sure if you wanted it to be set up so
that there would be that small chance of successful capture.

> > 5. There should be a way to clear ruins.  
> 
> I have been contemplating adding a disband table entry to 
> accomplish this.
> 
> >They get in the way when I try
> > to germinate.  It would also be interesting if one side could gut an
> > enemy town and build a grand citadel where the town used to be.
> 
> Yes.
> And once the type change mechanism is fully functional, there will 
> be the ability to evolve town->city->metropolis, which should help 
> make things even more interesting.

I've been waiting for that, too.  The bolodd.g module I sent to Hans
recently had all sorts of problems that stemmed from that it had to use
a time.g-like upgrade mechanism where change-type would be more
appropriate.

> So you like Grand Citadels? Do you think they are too powerful or 
> too cheap (compared with Towns)?

Well, they're certainly not cheap, but in the long run, they give far
better results than a simple town.

> >    The way I handled it in one of my projects (bolodd.g, which might
> > appear in the unfinished games library fairly soon) was that ruins were
> > always independent, but engineers could attack them and inflict 6d6
> > damage per hit, clearing them much faster than non-engineers could (they
> > rarely inflict more than 1d6 damage with each hit).
> 
> I thought I had given Engineers an advantage against them, but 
> maybe that was just against mines....

It looks like engineers can try to clear mines and shipwrecks, but they
can't do anything to ruins.

> Another way to handle this is to make Ruins' hp-max small (like I 
> had it during most of the alpha phase), and just arrange things so 
> that they have a hp-min = hp-max when versus all units except 
> Engineers. That way only Engineers could destroy them. This is 
> actually the direction I am thinking about heading, provided that 
> part of Xconq actually works....

I think I tried using hp-min once, and it worked.  Although that was a
while ago.

> > 6. There should be an easy way to give orders such as "move to within 3
> > of x,y; then wait for a friendly transport ship with less than 6
> > occupants to move to x,y; then move to x,y."  I could probably do it
> > using standing orders (although I'm not sure that standing orders could
> > easily work here with *any* transport ship), but there should be a
> > simpler way.
> 
> Agreed. I think Bruno Boettcher expressed a similar desire on this 
> list several months ago.

Looking back at his e-mail, I can certainly see the advantages to a more
powerful standing orders mechanism.  Particularly if it could:

* Distinguish between a specific (perhaps named) unit and any unit of a
particular type (e.g. should the dive bomber occupy *any* aircraft
carrier, or only a particular carrier?).

* Allow users to selectively apply standing orders to specific units.

* Allow defensive units (e.g. fighters) to respond immediately when a
hostile unit (e.g. bombers) is sighted within r units of the place it's
defending.

* Perform a task involving a unit or location that is unknown at the
time that the order was given (e.g. a patrolling fighter cannot know
ahead of time where enemy bombers will be sighted).

* Disregard previously-declared standing orders.

Perhaps some of these are already possible, but the existing
documentation is quite vague.

> > 9. When the game gets really big, it becomes less desirable to
> > micromanage units that are not on the front lines.  One thing that can
> > become annoying is that, if I want a bunch of ground units to meet one
> > or more transport ships, it is often necessary to use several separate
> > "move" actions, since the pathfinding algorithm is so brain-dead.
> 
> One of the things I am going to propose to the community after 7.5 
> is released is the idea of being able to set waypoints with the 
> click of the mouse (or by the traditional move-to) and have them 
> visually indicated whenever a relevant unit (one that is 
> following the set of waypoints) is selected.

I think that, as Hans said, an improved pathfinding algorithm that could
actually find the fastest route would be the best solution.  Although
using waypoints in conjunction with standing orders might eventually
yield more effective possibilities for automated patrolling units.


One last thing I noticed is that, as of when I last updated from CVS
(about 10 minutes ago), ruins now get 1 ACP per turn.  However, there is
nothing I can tell that they can do with that ACP!

Re: Bugs in Bellum Aeternum

[Eric McDonald]

On Wed, 24 Sep 2003, Lincoln Peters wrote:

> I was thinking that it might be useful to have finer control over the
> supply system.  For example, I might want a base to give higher priority
> to aircraft when supplying fuel, since they would die without it.

I see. Well, I did rearrange the order of the materials last 
night, so at least you'll have improved visual feedback, but not 
finer control, unfortunately.

> > Capitols are not meant to be easy to take or destroy. You 
> > correctly note that only Armor has enough oomph (and just barely) 
> > to make a successful capture attempt against a Capitol. I have not 
> > added a Stormtroopers unit type, but if I do, then it will also 
> > have that ability. The question is, does the module need yet 
> > another land unit type?
> 
> What I was thinking was that, in most games, the capital is fairly easy
> to capture if it is not well-garrisoned.  However, in a few games
> (insect.g comes to mind), the only way to defeat another side is to
> destroy its capital.  I wasn't sure if you wanted it to be set up so
> that there would be that small chance of successful capture.

Yes. Do you think it is too small? It is a 1 in 20 chance, iirc, 
and if you bring enough armor for the task, probability is that 
the Capitol will fall sooner rather than later....

> > So you like Grand Citadels? Do you think they are too powerful or 
> > too cheap (compared with Towns)?
> 
> Well, they're certainly not cheap, but in the long run, they give far
> better results than a simple town.

Agreed. :-)

> It looks like engineers can try to clear mines and shipwrecks, but they
> can't do anything to ruins.

Yeah, I noticed that when I looked at the module yesterday. I 
guess the computer forgot to record that thought when I had it....

> I think I tried using hp-min once, and it worked.  Although that was a
> while ago.

Well, if you are still kicking Bellum's tires, I am now using it 
for Ruins, so you can see if it still works.

> Looking back at his e-mail, I can certainly see the advantages to a more
> powerful standing orders mechanism.  Particularly if it could:
> 
> * Distinguish between a specific (perhaps named) unit and any unit of a
> particular type (e.g. should the dive bomber occupy *any* aircraft
> carrier, or only a particular carrier?).
> 
> * Allow users to selectively apply standing orders to specific units.
> 
> * Allow defensive units (e.g. fighters) to respond immediately when a
> hostile unit (e.g. bombers) is sighted within r units of the place it's
> defending.
> 
> * Perform a task involving a unit or location that is unknown at the
> time that the order was given (e.g. a patrolling fighter cannot know
> ahead of time where enemy bombers will be sighted).
> 
> * Disregard previously-declared standing orders.

I think these are good ideas. 

> I think that, as Hans said, an improved pathfinding algorithm that could
> actually find the fastest route would be the best solution.  Although
> using waypoints in conjunction with standing orders might eventually
> yield more effective possibilities for automated patrolling units.

One idea I have, regarding waypoints, would be to allow them to be 
assigned to units/transports and not just fixed coordinates.

> One last thing I noticed is that, as of when I last updated from CVS
> (about 10 minutes ago), ruins now get 1 ACP per turn.  However, there is
> nothing I can tell that they can do with that ACP!

But, if you send an Engineers into a Ruins, then the Ruins should 
be able to perform a disband action, because the Engineers doubles 
(in theory, haven't tested this yet) the Ruins' ACP, thereby 
giving it 2 ACP, which should be sufficient to do a disband.

I was going to test this RSN (I checked it in yesterday, 
because I thought there was a good chance that it would work, and 
it wasn't harming anything if it didn't). 

Also, once the Ruins gets down to 2 HP, you should be able to 
withdraw the Engineers and let the Ruins finish itself off. 
Obviously this is also untested, and there is a higher chance that 
this might not work correctly, since I haven't looked at the 
interpolation-list code in a while.

  Regards,
   Eric

Re: Bugs in Bellum Aeternum

[Lincoln Peters]

On Wed, 2003-09-24 at 19:30, Eric McDonald wrote:
> > What I was thinking was that, in most games, the capital is fairly easy
> > to capture if it is not well-garrisoned.  However, in a few games
> > (insect.g comes to mind), the only way to defeat another side is to
> > destroy its capital.  I wasn't sure if you wanted it to be set up so
> > that there would be that small chance of successful capture.
> 
> Yes. Do you think it is too small? It is a 1 in 20 chance, iirc, 
> and if you bring enough armor for the task, probability is that 
> the Capitol will fall sooner rather than later....

It seems fine if that's what you want.  And there isn't anything wrong
with doing it that way.

I think that the reason that I was somewhat confused by it was the first
time I played it, I swarmed a bunch of armors around the capital and
started pounding.  When that 1 in 20 chance finally came around, the
game ended quite abruptly (at least it was abrupt in comparison to most
other games).

> 
> > > So you like Grand Citadels? Do you think they are too powerful or 
> > > too cheap (compared with Towns)?
> > 
> > Well, they're certainly not cheap, but in the long run, they give far
> > better results than a simple town.
> 
> Agreed. :-)
> 
> > It looks like engineers can try to clear mines and shipwrecks, but they
> > can't do anything to ruins.
> 
> Yeah, I noticed that when I looked at the module yesterday. I 
> guess the computer forgot to record that thought when I had it....
> 
> > I think I tried using hp-min once, and it worked.  Although that was a
> > while ago.
> 
> Well, if you are still kicking Bellum's tires, I am now using it 
> for Ruins, so you can see if it still works.

I see.  I haven't tried to blow up any ruins yet, but it looks like I
could.

> 
> > Looking back at his e-mail, I can certainly see the advantages to a more
> > powerful standing orders mechanism.  Particularly if it could:
> > 
> > * Distinguish between a specific (perhaps named) unit and any unit of a
> > particular type (e.g. should the dive bomber occupy *any* aircraft
> > carrier, or only a particular carrier?).
> > 
> > * Allow users to selectively apply standing orders to specific units.
> > 
> > * Allow defensive units (e.g. fighters) to respond immediately when a
> > hostile unit (e.g. bombers) is sighted within r units of the place it's
> > defending.
> > 
> > * Perform a task involving a unit or location that is unknown at the
> > time that the order was given (e.g. a patrolling fighter cannot know
> > ahead of time where enemy bombers will be sighted).
> > 
> > * Disregard previously-declared standing orders.
> 
> I think these are good ideas. 

One more thing regarding standing orders and such automation mechanisms:
I ran into a situation where there was a severe shortage of 'c' at the
front lines, despite the presence of a Field HQ unit.  It would be nice
if I could set a condition (perhaps that its supply of 'c' drops below
25) under which it would move to a predetermined place (most likely a
metropolis), resupply 'c', then return to its previous location.

On the other hand, maybe I'm just not swarming enough Field HQ units to
keep up with my other swarms.

> 
> > I think that, as Hans said, an improved pathfinding algorithm that could
> > actually find the fastest route would be the best solution.  Although
> > using waypoints in conjunction with standing orders might eventually
> > yield more effective possibilities for automated patrolling units.
> 
> One idea I have, regarding waypoints, would be to allow them to be 
> assigned to units/transports and not just fixed coordinates.
> 
> > One last thing I noticed is that, as of when I last updated from CVS
> > (about 10 minutes ago), ruins now get 1 ACP per turn.  However, there is
> > nothing I can tell that they can do with that ACP!
> 
> But, if you send an Engineers into a Ruins, then the Ruins should 
> be able to perform a disband action, because the Engineers doubles 
> (in theory, haven't tested this yet) the Ruins' ACP, thereby 
> giving it 2 ACP, which should be sufficient to do a disband.

The only problem I can see there is that the engineers might vanish
along with the ruins.  Although I haven't tried it.

What I did in bolodd.g was:

* Ruins are always independent (they aren't useful for *anything*).
* They start with 50HP.
* They lose 1HP per round (as per attrition).
* They can be attacked and suffer damage comparable to what an attacker
would inflict on a base (usually 1d6).
* Engineers, however, inflict 6d6 damage vs. ruins with every blow, and
so they can clear ruins very quickly.
* Finally, engineers don't require any ammo to attack ruins.

> 
> I was going to test this RSN (I checked it in yesterday, 
> because I thought there was a good chance that it would work, and 
> it wasn't harming anything if it didn't). 
> 
> Also, once the Ruins gets down to 2 HP, you should be able to 
> withdraw the Engineers and let the Ruins finish itself off. 
> Obviously this is also untested, and there is a higher chance that 
> this might not work correctly, since I haven't looked at the 
> interpolation-list code in a while.

I think it would work, but there is probably an easier way.  See above.


Two more small things:

1. This is probably beyond the current capabilities of Xconq, but it
would be nice if there was a way to prevent two sides from starting on
the same continent.  When they do, the game often ends too quickly for
anyone to build a grand citadel, a fully-loaded fleet carrier, etc.

2. It looks like a name is assigned to every capital, but the only time
Xconq refers to a capital by name is when it is captured (the rest of
time it's refered to by coordinates, e.g. "your capital at x,y").  It
might be useful for Xconq to refer to capitals by name, especially if a
game has lots of sides and consequently toward the end, a few sides have
a lot of captured capitals (if nothing else, I could easily find a
specific capital using the "Find" command).

Re: Bugs in Bellum Aeternum

[Eric McDonald]

Hi Lincoln,

On Fri, 26 Sep 2003, Lincoln Peters wrote:

> > Yes. Do you think it is too small? It is a 1 in 20 chance, iirc, 
> > and if you bring enough armor for the task, probability is that 
> > the Capitol will fall sooner rather than later....
> 
> It seems fine if that's what you want.  And there isn't anything wrong
> with doing it that way.
> 
> I think that the reason that I was somewhat confused by it was the first
> time I played it, I swarmed a bunch of armors around the capital and
> started pounding.  When that 1 in 20 chance finally came around, the
> game ended quite abruptly (at least it was abrupt in comparison to most
> other games).

But, if the "Stubborn Sides" option is on, then the self-unit 
should get resurrected as any other unit that can be a self-unit 
(capital ships, field HQ's, other capitols which you own, grand 
citadels).

As a side note, I am playing a game where 1 armor was able to 
capture a Capitol after 15 tries.

> > I think these are good ideas. 
> 
> One more thing regarding standing orders and such automation mechanisms:
> I ran into a situation where there was a severe shortage of 'c' at the
> front lines, despite the presence of a Field HQ unit.  It would be nice
> if I could set a condition (perhaps that its supply of 'c' drops below
> 25) under which it would move to a predetermined place (most likely a
> metropolis), resupply 'c', then return to its previous location.
> 
> On the other hand, maybe I'm just not swarming enough Field HQ units to
> keep up with my other swarms.

What is your other unit to Field HQ ratio? And what is the 
admixture of the other units?

When I have playtested, I have generally thought that there was 
still too much command-and-control ('c') floating around, and have 
been contemplating tuning it down even more. But your comment is 
giving me second thoughts about that.

> > But, if you send an Engineers into a Ruins, then the Ruins should 
> > be able to perform a disband action, because the Engineers doubles 
> > (in theory, haven't tested this yet) the Ruins' ACP, thereby 
> > giving it 2 ACP, which should be sufficient to do a disband.
> 
> The only problem I can see there is that the engineers might vanish
> along with the ruins.  Although I haven't tried it.

I also had that concern, which is why I opted to use the 
acp-damage-effect interpolation list, so that when Ruins HP 
reaches 2, then its ACP goes up to 2, thereby allowing it to 
finish itself off. In theory.

I haven't been able to test this, because ever time I issue a 
disband command to a healthy, Engineers-occupied Ruins, Xconq says 
it is going to perform the task and then doesn't. I need to figure 
out if this is a result of something screwy in my module or in 
Xconq.

> What I did in bolodd.g was:
> 
> * Ruins are always independent (they aren't useful for *anything*).
> * They start with 50HP.
> * They lose 1HP per round (as per attrition).
> * They can be attacked and suffer damage comparable to what an attacker
> would inflict on a base (usually 1d6).
> * Engineers, however, inflict 6d6 damage vs. ruins with every blow, and
> so they can clear ruins very quickly.
> * Finally, engineers don't require any ammo to attack ruins.

And I could certainly adopt something like that (it is a good 
idea), if it was not for the fact that Towns become Ruins if you 
destroy them, and so you end up with Ruins that are owned by a 
side.

> > Also, once the Ruins gets down to 2 HP, you should be able to 
> > withdraw the Engineers and let the Ruins finish itself off. 
> > Obviously this is also untested, and there is a higher chance that 
> > this might not work correctly, since I haven't looked at the 
> > interpolation-list code in a while.
> 
> I think it would work, but there is probably an easier way.  See above.

Yeah, what I did was a bit hackish, but I think we are approaching 
the concept of ruins slightly differently, so I am not sure that I 
can adapt what you did.

Just out of curiosity, I see the word "bolo" in "bolodd". Is your 
module a take on the old "Bolo" tank game? In any case, I would 
like to try it out sometime.

> 1. This is probably beyond the current capabilities of Xconq, but it
> would be nice if there was a way to prevent two sides from starting on
> the same continent.  When they do, the game often ends too quickly for
> anyone to build a grand citadel, a fully-loaded fleet carrier, etc.

I could change the terrain generation params to make continents 
that are smaller than the country radii. I think that would solve 
the issue.

Also, I already plan on adding a sea transport to each side's 
initial reportoire of units, so that sides which start out on  
islands will not be as disadvantaged.

> 2. It looks like a name is assigned to every capital, but the only time
> Xconq refers to a capital by name is when it is captured (the rest of
> time it's refered to by coordinates, e.g. "your capital at x,y").  It
> might be useful for Xconq to refer to capitals by name, especially if a
> game has lots of sides and consequently toward the end, a few sides have
> a lot of captured capitals (if nothing else, I could easily find a
> specific capital using the "Find" command).

I can fix that by altering the description-format property for 
Capitols.

  Thanks for the feedback,
    Eric

Re: Bugs in Bellum Aeternum

[Lincoln Peters]

On Fri, 2003-09-26 at 19:37, Eric McDonald wrote: 
> > I think that the reason that I was somewhat confused by it was the first
> > time I played it, I swarmed a bunch of armors around the capital and
> > started pounding.  When that 1 in 20 chance finally came around, the
> > game ended quite abruptly (at least it was abrupt in comparison to most
> > other games).
> 
> But, if the "Stubborn Sides" option is on, then the self-unit 
> should get resurrected as any other unit that can be a self-unit 
> (capital ships, field HQ's, other capitols which you own, grand 
> citadels).
> 
> As a side note, I am playing a game where 1 armor was able to 
> capture a Capitol after 15 tries.

I'd believe that, as long as the Capitol is not properly garrisoned.

> > On the other hand, maybe I'm just not swarming enough Field HQ units to
> > keep up with my other swarms.
> 
> What is your other unit to Field HQ ratio? And what is the 
> admixture of the other units?

I probably had a mixture of 20 cavalry and armor scouring the place with
1 Field HQ in place.  As soon as I found that it wasn't working, I
scrambled another Field HQ to the area as quickly as I could.

> When I have playtested, I have generally thought that there was 
> still too much command-and-control ('c') floating around, and have 
> been contemplating tuning it down even more. But your comment is 
> giving me second thoughts about that.

Well, I'm still learning the game!

> > > But, if you send an Engineers into a Ruins, then the Ruins should 
> > > be able to perform a disband action, because the Engineers doubles 
> > > (in theory, haven't tested this yet) the Ruins' ACP, thereby 
> > > giving it 2 ACP, which should be sufficient to do a disband.
> > 
> > The only problem I can see there is that the engineers might vanish
> > along with the ruins.  Although I haven't tried it.
> 
> I also had that concern, which is why I opted to use the 
> acp-damage-effect interpolation list, so that when Ruins HP 
> reaches 2, then its ACP goes up to 2, thereby allowing it to 
> finish itself off. In theory.

I don't think that anyone has ever used acp-damage-effect to give a unit
more ACP when it is damaged (although it might be appropriate in fantasy
games for beserker warriors and such).  I have often found that, when I
try something that has never been done before, there are a few bugs.

> > What I did in bolodd.g was:
> > 
> > * Ruins are always independent (they aren't useful for *anything*).
> > * They start with 50HP.
> > * They lose 1HP per round (as per attrition).
> > * They can be attacked and suffer damage comparable to what an attacker
> > would inflict on a base (usually 1d6).
> > * Engineers, however, inflict 6d6 damage vs. ruins with every blow, and
> > so they can clear ruins very quickly.
> > * Finally, engineers don't require any ammo to attack ruins.
> 
> And I could certainly adopt something like that (it is a good 
> idea), if it was not for the fact that Towns become Ruins if you 
> destroy them, and so you end up with Ruins that are owned by a 
> side.

You could use a line such as:

(add ruins possible-sides "independent")

I think that panzer.g also does this.

> Just out of curiosity, I see the word "bolo" in "bolodd". Is your 
> module a take on the old "Bolo" tank game? In any case, I would 
> like to try it out sometime.

It is, but just barely.  It combines the idea of a simple tank game with
Dungeons & Dragons-style fantasy elements, such as robotic units that
resemble werewolves, giant spiders, elementals, etc.  And the AI is
absolutely terrible at it (not surprisingly).

I had tried making a game that behaved more like the old "Bolo" tank
game, but it didn't work very well.

> > 1. This is probably beyond the current capabilities of Xconq, but it
> > would be nice if there was a way to prevent two sides from starting on
> > the same continent.  When they do, the game often ends too quickly for
> > anyone to build a grand citadel, a fully-loaded fleet carrier, etc.
> 
> I could change the terrain generation params to make continents 
> that are smaller than the country radii. I think that would solve 
> the issue.

Although there would be fewer towns in the vicinity that could be
captured early on, at least without the aid of transport ships.  Perhaps
it would be appropriate as a variant.

> Also, I already plan on adding a sea transport to each side's 
> initial reportoire of units, so that sides which start out on  
> islands will not be as disadvantaged.

That sounds like a good idea.

> > 2. It looks like a name is assigned to every capital, but the only time
> > Xconq refers to a capital by name is when it is captured (the rest of
> > time it's refered to by coordinates, e.g. "your capital at x,y").  It
> > might be useful for Xconq to refer to capitals by name, especially if a
> > game has lots of sides and consequently toward the end, a few sides have
> > a lot of captured capitals (if nothing else, I could easily find a
> > specific capital using the "Find" command).
> 
> I can fix that by altering the description-format property for 
> Capitols.

That would be great.

> 
>   Thanks for the feedback,
>     Eric

Re: Bugs in Bellum Aeternum

[Eric McDonald]

Hi Lincoln,

On Sun, 28 Sep 2003, Lincoln Peters wrote:

> I probably had a mixture of 20 cavalry and armor scouring the place with
> 1 Field HQ in place.  As soon as I found that it wasn't working, I
> scrambled another Field HQ to the area as quickly as I could.

Yeah, that is a lot of cnc being consumed in one area.

> > When I have playtested, I have generally thought that there was 
> > still too much command-and-control ('c') floating around, and have 
> > been contemplating tuning it down even more. But your comment is 
> > giving me second thoughts about that.
> 
> Well, I'm still learning the game!

I am too. Just because I made it doesn't mean that I can 
anticipate how everything is going to mesh. Hence the public 
beta....

To be honest, I have been doing more intensive play-testing 
(playing it like a game, rather than treating it like an 
experiment for certain features) lately, and I am beginning to 
agree that the amount of available cnc could be tweaked slightly 
upward rather than downward.

> > I also had that concern, which is why I opted to use the 
> > acp-damage-effect interpolation list, so that when Ruins HP 
> > reaches 2, then its ACP goes up to 2, thereby allowing it to 
> > finish itself off. In theory.
> 
> I don't think that anyone has ever used acp-damage-effect to give a unit
> more ACP when it is damaged (although it might be appropriate in fantasy

It is admittedly somewhat of a hack, or "novel use" as I will 
prefer to call it, if it works. (Still haven't tested it.)

> You could use a line such as:
> 
> (add ruins possible-sides "independent")
> 
> I think that panzer.g also does this.

I'll look into it, especially if it forces a wrecked-type to 
change owners (from a player to independent).

> It is, but just barely.  It combines the idea of a simple tank game with
> Dungeons & Dragons-style fantasy elements, such as robotic units that
> resemble werewolves, giant spiders, elementals, etc.  And the AI is

Nifty.

> > I could change the terrain generation params to make continents 
> > that are smaller than the country radii. I think that would solve 
> > the issue.
> 
> Although there would be fewer towns in the vicinity that could be
> captured early on, at least without the aid of transport ships.  Perhaps
> it would be appropriate as a variant.

You might want to try playing the game with the "Large Continents" 
variants turned off (it is on by default).

> > Also, I already plan on adding a sea transport to each side's 
> > initial reportoire of units, so that sides which start out on  
> > islands will not be as disadvantaged.
> 
> That sounds like a good idea.

I added a sea Transport, Patrol Ship, and Frigate to the starting 
pieces for each side. (If you try laying any Sea Mines with the 
Patrol Ship, you might notice that the Xconq build code gets a 
little bit over-zealous.)

I also experimented with your suggested change of increasing 
Town's capacity to prevent traffic jams. It worked okay, but what 
I ultimately ended up doing was decreasing the size-in-terrain for 
Ruins, Towns, and Bases from 16 to 13. This allows 3 other units 
to pass through the sector (without incurring any mp-to-enter/mp-to-leave 
penalties).

And I modified the zoc-range for Ruins and some other units. One 
thing that can occur now is that enemy land forces can force their 
way into the same hex as one of your Ruins or Towns.

I cut down the retreat-chance for air units when they are 
attacking city units. I still would like them to have some retreat 
chance, because if a Capitol or Metropolis is not producing 
anything, it has a lot of ACP to expend on AA activities.

Some other major changes:
* Reduced the build time for paratroopers, marines, and many of 
the sea units.
* Beefed up Fighters' ground assault capabilities. This makes them 
a stronger alternative to Escort Fighters, in spite of the 
difference in range.

I will commit all of this to CVS in another hour or so.

> > I can fix that by altering the description-format property for 
> > Capitols.
> 
> That would be great.

Also did that.

  Thanks,
   Eric

Re: Bugs in Bellum Aeternum

[Lincoln Peters]

On Sun, 2003-09-28 at 18:07, Eric McDonald wrote: 
> Hi Lincoln,
> 
> On Sun, 28 Sep 2003, Lincoln Peters wrote:
> 
> > I probably had a mixture of 20 cavalry and armor scouring the place with
> > 1 Field HQ in place.  As soon as I found that it wasn't working, I
> > scrambled another Field HQ to the area as quickly as I could.
> 
> Yeah, that is a lot of cnc being consumed in one area.

Perhaps the 'c' isn't being moved around as efficiently as it should
be.  

> 
> > > When I have playtested, I have generally thought that there was 
> > > still too much command-and-control ('c') floating around, and have 
> > > been contemplating tuning it down even more. But your comment is 
> > > giving me second thoughts about that.
> > 
> > Well, I'm still learning the game!
> 
> I am too. Just because I made it doesn't mean that I can 
> anticipate how everything is going to mesh. Hence the public 
> beta....

Actually, I've written (or tried to write) enough games that I know how
that is.

> 
> To be honest, I have been doing more intensive play-testing 
> (playing it like a game, rather than treating it like an 
> experiment for certain features) lately, and I am beginning to 
> agree that the amount of available cnc could be tweaked slightly 
> upward rather than downward.
> 
> > > I also had that concern, which is why I opted to use the 
> > > acp-damage-effect interpolation list, so that when Ruins HP 
> > > reaches 2, then its ACP goes up to 2, thereby allowing it to 
> > > finish itself off. In theory.
> > 
> > I don't think that anyone has ever used acp-damage-effect to give a unit
> > more ACP when it is damaged (although it might be appropriate in fantasy
> 
> It is admittedly somewhat of a hack, or "novel use" as I will 
> prefer to call it, if it works. (Still haven't tested it.)

I just tried it, and I couldn't get the engineers to enter the ruins!

> 
> > You could use a line such as:
> > 
> > (add ruins possible-sides "independent")
> > 
> > I think that panzer.g also does this.
> 
> I'll look into it, especially if it forces a wrecked-type to 
> change owners (from a player to independent).

It does.  I've already used it (and I've seen it work in Panzer).

> > It is, but just barely.  It combines the idea of a simple tank game with
> > Dungeons & Dragons-style fantasy elements, such as robotic units that
> > resemble werewolves, giant spiders, elementals, etc.  And the AI is
> 
> Nifty.
> 
> > > I could change the terrain generation params to make continents 
> > > that are smaller than the country radii. I think that would solve 
> > > the issue.
> > 
> > Although there would be fewer towns in the vicinity that could be
> > captured early on, at least without the aid of transport ships.  Perhaps
> > it would be appropriate as a variant.
> 
> You might want to try playing the game with the "Large Continents" 
> variants turned off (it is on by default).

I'll try it.

> 
> > > Also, I already plan on adding a sea transport to each side's 
> > > initial reportoire of units, so that sides which start out on  
> > > islands will not be as disadvantaged.
> > 
> > That sounds like a good idea.
> 
> I added a sea Transport, Patrol Ship, and Frigate to the starting 
> pieces for each side. (If you try laying any Sea Mines with the 
> Patrol Ship, you might notice that the Xconq build code gets a 
> little bit over-zealous.)

I noticed that, with the recent changes, the following problems can
occurr:

1. I think that the ships should not be at sea at the start of the game
(it would make more sense for them to start in the Sea Base).

2. Land units have a chance of starting in the Sea Transport, which is
probably not what you want.  Additionally, if the Sea Transport is not
in the Sea Base, it can slow down the side at the start of the game.

3. If a side starts with shallow waters in its country but it's not next
to land, there is still a chance that the Sea Base will be created in
those shallow waters!  That makes it rather inconvenient to get land
units to the Sea Base!

4. This may or may not be related, but I'm finding that I can no longer
land air units in towns.  Is there a reason for that?

I had noticed that, but I forgot to mention it.  Perhaps it would work
better if you set mines to require 3 CP and only allowed Patrol Ships to
add 1 CP per "build" action.  I think future.g also does this.

> I also experimented with your suggested change of increasing 
> Town's capacity to prevent traffic jams. It worked okay, but what 
> I ultimately ended up doing was decreasing the size-in-terrain for 
> Ruins, Towns, and Bases from 16 to 13. This allows 3 other units 
> to pass through the sector (without incurring any mp-to-enter/mp-to-leave 
> penalties).

That makes sense, too.

> And I modified the zoc-range for Ruins and some other units. One 
> thing that can occur now is that enemy land forces can force their 
> way into the same hex as one of your Ruins or Towns.

I'm not sure that it makes sense for towns, but definitely for ruins. 
Having towns exert ZOC against land units makes capturing them rather
awkward (I click the town to attack, and even if the capture action
failed, the attacker is suddenly sharing the cell with the town
anyway!).

> 
> I cut down the retreat-chance for air units when they are 
> attacking city units. I still would like them to have some retreat 
> chance, because if a Capitol or Metropolis is not producing 
> anything, it has a lot of ACP to expend on AA activities.

I would imagine that the best solution would be if the air units only
retreated when they are under a direct attack (e.g. intercepted by enemy
fighters) or they are counterattacked (e.g. after hitting a capitol or
metropolis).  I don't know if Xconq can do this (it's not documented
anywhere).

Re: Bugs in Bellum Aeternum

[Eric McDonald]

Hi Lincoln,

On Tue, 30 Sep 2003, Lincoln Peters wrote:

> > Yeah, that is a lot of cnc being consumed in one area.
> 
> Perhaps the 'c' isn't being moved around as efficiently as it should
> be.  

I would tend to agree. Part of the problem is that city types 
horde more 'c' than they need. Perhaps it would be worth 
investigating whether to provide suggestions about material levels 
to Xconq in the form of tables.

> > It is admittedly somewhat of a hack, or "novel use" as I will 
> > prefer to call it, if it works. (Still haven't tested it.)
> 
> I just tried it, and I couldn't get the engineers to enter the ruins!

Yes, I noticed that the other day. Probably has something to do 
with a change I made to the occupant-max table. I will fix it 
after work.

> I noticed that, with the recent changes, the following problems can
> occurr:
> 
> 1. I think that the ships should not be at sea at the start of the game
> (it would make more sense for them to start in the Sea Base).

OK. Sounds reasonable.

> 2. Land units have a chance of starting in the Sea Transport, which is
> probably not what you want.  Additionally, if the Sea Transport is not
> in the Sea Base, it can slow down the side at the start of the game.

I don't think I can prevent land units from starting inside any 
type of transport, unless I make their terrain chances 100%.

> 3. If a side starts with shallow waters in its country but it's not next
> to land, there is still a chance that the Sea Base will be created in
> those shallow waters!  That makes it rather inconvenient to get land
> units to the Sea Base!

I am not sure that there is much I can do about that within the 
current constraints of Xconq. I do think that what you are 
describing happens fairly infrequently (usually there are more 
coastal waters abutting a land mass, and hence the Sea Base has a 
greater chance of being placed there). I will look at the terrain 
generation parameters; I think I might be randomly sprinkling 
coastal waters in the sea (to simulate groups of tiny islands 
and unsersea ridges). If so, I can turn this off and make 
non-coastal "coastal waters" go away.

> 4. This may or may not be related, but I'm finding that I can no longer
> land air units in towns.  Is there a reason for that?

You can still land lighter aircraft, just not Cargo Planes or 
Bombers. The airstrips of Forts and Towns are not long enough to 
handle these heavier aircraft. I may have to increase the range of 
the these aircraft to compensate.

> I had noticed that, but I forgot to mention it.  Perhaps it would work
> better if you set mines to require 3 CP and only allowed Patrol Ships to
> add 1 CP per "build" action.  I think future.g also does this.

Sure I can do that as a workaround. And I will do that, if I can't 
actually fix the Xconq build code (which I looked into a little 
bit).

> I'm not sure that it makes sense for towns, but definitely for ruins. 
> Having towns exert ZOC against land units makes capturing them rather
> awkward (I click the town to attack, and even if the capture action
> failed, the attacker is suddenly sharing the cell with the town
> anyway!).

I'll reconsider. But I think of Towns as being fairly small 
compared to the size of the hex, and so an oppposing unit might be 
able to conceivably share the hex with the Town without crossing 
its defense perimeter or being in range of its relatively weak 
AAA.

> I would imagine that the best solution would be if the air units only
> retreated when they are under a direct attack (e.g. intercepted by enemy
> fighters) or they are counterattacked (e.g. after hitting a capitol or
> metropolis).

But that is what the effect of having the 100% retreat-chance was. 
Bombers attacked Capitol; Capitol counterattacked; Bombers 
retreated. But as you mentioned, it was making it hard to get at 
the Capitol.

And I still have a large retreat-chance against Fighters.

  Thanks,
    Eric