This is the mail archive of the
xconq7@sources.redhat.com
mailing list for the Xconq project.
Re: Bugs in Bellum Aeternum
- From: Eric McDonald <mcdonald at phy dot cmich dot edu>
- To: Lincoln Peters <sampln at sbcglobal dot net>
- Cc: Xconq list <xconq7 at sources dot redhat dot com>
- Date: Tue, 23 Sep 2003 16:17:10 -0400 (EDT)
- Subject: Re: Bugs in Bellum Aeternum
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