[Freeciv-Dev] Re: A bunch of patches

[Raimar Falke <hawk@xxxxxxxxxxxxxxxxxxxxxxx>]

On Fri, Dec 21, 2001 at 05:46:18AM +0000, andi payn wrote:
> Hi there. I'm new to this list, but I've got a whole slew of changes to my 
> local copy of FreeCiv and I'd like to get comments on some of them.
> 
> They're pretty horribly intertwined at present; I'd be happy to make usable 
> patches out of any of them if anyone's interested. Here are the changes:
> 
> Calendar: Replaced the hard-coded calendar system in FreeCiv (50 yrs/turn to 
> -1000, 25 to 1 AD, etc.) with a flexible system that's configurable in 
> game.ruleset. You can set the start year and years/turn for each age, and 
> give it a name (which appears in the Gtk client). You can also require a 
> certain tech before entering an age, and you can specify a tech that jumps 
> to an age early (you can even have the ages completely controlled by techs 
> if you want). The spaceship tech special-casing is still there as well, but 
> has been made more flexible to handle gen-impr. The names are nice, except 
> that I can't come up with good ones for standard FreeCiv ages. The flexible 
> years are handy for the Ancients ruleset (so I can play 425 turns by 1500AD, 
> as intended by the designer), but so far not for much else. The tech-based 
> calendaring is a nifty idea, but I haven't found it to be too useful in 
> actual play. It does seem to work perfectly, though.

This is an independent topic (which is good). It also goes in the
right direction. I would have no problems with such a patch.

> Vet Levels: Replaced the two vet levels with any number, specified in 
> units.ruleset. Each vet level has a name and a combat bonus, as in 
> Civ2/standard FreeCiv, as well as all kinds of other stuff: multipliers to 
> hitpoints (as in Civ3), movement, and firepower; settler activity bonuses 
> (requires rescaling activity counts, and there are already patches that do 
> this better than I did); additive move bonuses (like SMAC elite), diplomat 
> battle bonuses (only useful with my Diplomat patch), trireme loss chances, 
> and I think a few other things. Other settings allow units to advance 
> through completed settler actions (which can depend on the complexity of the 
> action), diplomat actions (defending a city, completing an attack on a city, 
> bribing/sabotaging, etc.), surviving at high sea, and different combat 
> results (with the withdraw patch; otherwise this last one is meaningless). I 
> play with this one all the time; it seems to work perfectly, and it adds a 
> lot to the game.

Teamciv has such a feature. This feature hasn't been integrated in
freeciv. Please talk with Karl about this.

> Withdraw: Units with >1 moves can withdraw if losing in battle. All kinds of 
> configurability. Some bugs, too, but close to usable.

Sounds small, so no problem. However I suspect that the AI need
updating for this.

> Diplomat: Options to change diplomatic battles. In addition to Civ2/standard 
> FreeCiv diplomacy contests, you can also take the attacker into 
> consideration, or handle diplomacy contests similarly to combat (as in 
> SMAC). Also, diplomats can fight in the field (as in SMAC) if you select 
> another option. Yet another option adds biological warfare (kill half the 
> city, higher chance of failure/getting caught, requires discovering a tech 
> with a new flag, so of course you also have to add such a tech to the tech 
> ruleset).

I want to see the patch and get the opionions from other people about this.

> Infinite Move: Allows you to specify units with infinite move rate and/or 
> infinite paradrop range (like SMAC's orbital insertion). Infinite paradrop 
> works great; infinite move range causes some problems, such as danger 
> overflows. I've made some changes to fix the danger problem, but I'm not 
> sure they work quite right.

I suspect you would have a hard time to implement this in the correct
way. What unit/thing has an infinite move rate?

> City Report Subfields: Many columns in the city report dialog have multiple 
> fields. This patch lets you sort by any of them. Plus, numerical fields are 
> sorted numerically (no more "1, 10, 16, 2, 23, 3, 4"). Each client needs 
> some way to pick the sort field; the Gtk client has a context menu, the 
> others so far have nothing. There are a couple of minor issues with the 
> implementation that nobody will notice, but I want to fix them.

I implemented this some time ago and there were no consent how to do
it.

> Additional City Report Columns: In addition to porting the Grow Turns, 
> Attack, and Defense patches from new-columns to handle the Subfields changes 
> (most of the rest are unnecessary with subfields), I added some more: 
> Martial Law (units present that are capable of providing martial law and 
> total contentness effect of those units), Support (number of units, plus 
> H/F/P/G upkeep under current conditions), and Potential Support (H/F/P/G 
> upkeep before compensating for government, helpful in fixing up cities 
> before a revolt). This all works. I also merged the code that handles 
> counting this stuff up into one place, and stored some stuff that was being 
> thrown away (potential support per unit) to save CPU time (and passes it 
> across the network to waste bandwidth), which doesn't have much effect 
> without the rest of the changes.

I see no problems with this one.

> Obsolesence: Currently, once a unit can be upgraded, it becomes obsolete. 
> I've added a second field in units.ruleset that changes this. If you specify 
> an "obsoleted_by2" for a unit (which can be "Never"), the unit can be 
> upgraded to its "obsoleted_by" unit, but can be built anyway until its 
> "obsoleted_by2" unit is also available. This is useful for a few purposes in 
> variant rulesets I've used (e.g., Engineers can upgrade to Formers, which 
> can't build cities but don't take food cost, but they aren't obsoleted by 
> them, because you still need to be able to build Engineers).

Wouldn't a switch "show obsolete" in the city change dialog be easier?

> Satellites: Units that don't participate in combat or ZOC (this almost 
> works, but other units can still move into squares occupied by friendly 
> satellites to get around ZOC, which is silly), don't move, and don't defend 
> cities (they should either disappear or be captured, I suppose). Handles 
> SMAC-style satellites (basically do-nothing units with negative upkeep, 
> which required minor changes in itself). Also allows "spy satellites," which 
> can "paradrop" (enter geosynchronous orbit over) any square on the map (even 
> on top of enemy units or cities, although this causes some serious problems) 
> and see the area "below" them. Should also handle killer satellites, but 
> they don't work. Maybe some kinds of satellites should be improvements, not 
> units. 

> The whole thing needs more thought.

Yes. Satellites would be a complete new unit type. I'm not sure if
this should be implemented.

> Borders: My borders aren't nearly as good as the patch already available (or 
> in FreeCiv-ac), but they are more configurable. You can specify the city 
> influence radius, configure what happens when two cities are equally close, 
> decide what effects borders have on the game (most of the latter settings 
> don't work yet), and crash the game spectacularly.

Merge them with others or wait till one border patch makes it into CVS
and provide an improvement patch.

> Advanced Tech Build Bonuses: For each tech you discover that depends on a 
> unit's (or improvement's) required tech, the price for that unit (or 
> improvement) comes down. This is controlled by a server option (set 
> atechbuild=9950, and the price goes down to 99.50% of its former price for 
> each new tech). The game calculates the dependency tree when loading the 
> ruleset, so there's no CPU time wasted. You can also configure whether 
> future techs are dependent on all techs or dependent on none, or whether 
> they give a separate bonus. This seems to work, but I haven't tested it 
> much. Also, with the standard tech tree, it'll probably give weird results. 
> To make this work well, it'll probably need some additional settings in the 
> tech ruleset, so you can specify that tech B requires tech A but doesn't 
> count as a more advanced tech in the same field, while tech C requires tech 
> A and does count as a more advanced tech in the same field. This would allow 
> other features of the SMAC tech system as well.

I want the opionions from other people about this.

        Raimar

-- 
 email: rf13@xxxxxxxxxxxxxxxxx
 Q:  Do you know what the death rate around here is?
 A:  One per person.