Complete.Org: Mailing Lists: Archives: freeciv-dev: December 2001:
[Freeciv-Dev] Re: A bunch of patches
Home

[Freeciv-Dev] Re: A bunch of patches

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: <freeciv-dev@xxxxxxxxxxx>
Subject: [Freeciv-Dev] Re: A bunch of patches
From: "Per I. Mathisen" <Per.Inge.Mathisen@xxxxxxxxxxx>
Date: Fri, 21 Dec 2001 11:03:47 +0100 (MET)

On Fri, 21 Dec 2001, 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.

Sure :)

Please partition it up, weed out the worst bugs and send it to the
bugtracking system.

> 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.

This sounds very nice.

> Vet Levels: Replaced the two vet levels with any number, specified in
> units.ruleset.

How does this compare to the veteran patch in TeamCiv (at
http://www-c.informatik.uni-hannover.de/~kif/civ/teamciv.html)?

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

Sounds good. I am not sure what "all kinds of configurability" means, but
I suppose it means it must be turned on with a unit flag?

> 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.

Infinite paradrop sounds good. I don't think infinite move is viable for a
multiplayer game.

> 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).

Well then the unit is not really obsoleted, is it? I'd rather see that
obsoleted_by and upgradable_to are separated, and the latter (or both)
could be an array. But I don't really see great usefulness for this.

> 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).

Sounds fun.

Yours,
Per

"Economics is extremely useful as a form of employment for economists."
 -- John Kenneth Galbraith



[Prev in Thread] Current Thread [Next in Thread]