From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14924 invoked by alias); 23 Sep 2003 20:17:26 -0000 Mailing-List: contact xconq7-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: xconq7-owner@sources.redhat.com Received: (qmail 14903 invoked from network); 23 Sep 2003 20:17:22 -0000 Received: from unknown (HELO garm.central.cmich.local) (141.209.15.48) by sources.redhat.com with SMTP; 23 Sep 2003 20:17:22 -0000 Received: from leon.phy.cmich.edu ([141.209.165.20]) by egate1.central.cmich.local with Microsoft SMTPSVC(5.0.2195.6713); Tue, 23 Sep 2003 16:17:20 -0400 Received: from localhost (unknown [127.0.0.1]) by leon.phy.cmich.edu (Postfix) with ESMTP id 98AEC7004F; Tue, 23 Sep 2003 16:17:10 -0400 (EDT) Date: Tue, 23 Sep 2003 21:11:00 -0000 From: Eric McDonald To: Lincoln Peters Cc: Xconq list Subject: Re: Bugs in Bellum Aeternum In-Reply-To: <1064342492.8973.107.camel@odysseus.peterslan> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-OriginalArrivalTime: 23 Sep 2003 20:17:20.0624 (UTC) FILETIME=[B13DBF00:01C3820F] X-SW-Source: 2003/txt/msg00447.txt.bz2 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