Re: Bugs in Bellum Aeternum

[Lincoln Peters <sampln at sbcglobal dot net>]

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.