[Freeciv-Dev] Re: A bunch of patches

["andi payn" <paynfc@xxxxxxxxxxx>]

Wow, this is a much higher-traffic list than I expected.... I'll try
to reply to everyone's comments on the messages I sent right before
Christmas all at once.

[general stuff]
Per:
> Please partition it up, weed out the worst bugs, and sent it to the
> bugtracking system.
The stuff I already partitioned out and sent to the ftp server, I'll
send to the bugtracking system as well, some time tonight or tomorrow.

As for the rest, as I mentioned in my last message, it's going to be
hard to disentangle, but I'll get to it soon (once I finish the
changes I personally care about most, which should be soon, I'll start
separting everything out, making patches, and testing them).

[calendar]
Tony:
> Sub-year advancement should also be possible here.
On my local tree, I have this, but it displays like "Year: 1944.25,"
which clearly sucks. The question is, how should it work? Should we
just assume Gregorian calendaring? Or should we come up with something
flexible? If so, how flexible? Real-world flexibility would be a
nightmare (imagine each player changing from a nation-specific
"native" calendar to Gregorian at different times; imagine handling
lunar calendars with cycles that don't match the year; imagine
handling early calendars like the pre-Julian Roman system or the
pre-reform Hebrew calendar; etc.). I mentioned this briefly in the
.txt file that I uploaded with the patch.

Jules:
> ... if not only did techs trigger changes of 'age', but also
> changes of age could allow new techs...
I had some thoughts along those lines, but they all ran into dead
ends. I think what we really need is to finish gen-impr, then extend
it so that techs, governments, and calendar ages can trigger effects
just like buildings (obviously they'd be player-range or world-range
only, of course), and so techs (and maybe other things) can depend on
effects, rather than only on techs. But then you don't need calendar
age effects; they could just be effects of the techs that trigger the
age.

[vet levels]
Per:
> How does this compare to the veteran patch in TeamCiv...?
TeamCiv has a fixed set of hardcoded veteran levels. Each is
identified only be number, and affects the unit's attack and defense
strength, settler activity, trireme survival, and chance of rising to
the next level.

My patch includes all of these veteran level features, plus a name
(displayed in the GUI, though I've only tested Gtk), hitpoint factor,
firepower factor, diplomacy factor, movement factor, and movement
bonus (off the top of my head, but I don't think I missed anything).

More importantly, my patch lets you configure veteran levels in a
ruleset, so you can play with Civ2 rules, TeamCiv rules, Civ3 rules,
or something of your own devising.

Also, I think my code is a little cleaner. I've added functions to do
things like calculate a unit's defense strength given the unit or
given just the type and vet level (for AI guesses) so all those
d*(v?15:10) messes scattered throughout the code become more readable
as well as handling multiple, configurable vet levels.

Tony:
> ... this needs to be flexible enough to accomodate at least Civ1+2,
> SMAC, Civ3, and CTP.
As-is, the code handles Civ1+2, Civ3, and TeamCiv (although you will
need Civ3 and TeamCiv rulesets). I don't know about CTP. To handle
SMAC requires added psi combat bonuses. Adding them to the vet level
code is easy, and adding them to the psi combat code should be easy
given that the psi combat code has yet to be written.

Nobody asked about this, but: Given both vet-levels and gen-impr, it's
possible that a city can create units with a vet level above 1. The AI
always assumes that if the city might be able to create veteran units,
all units are at vet level 1. If you've gone wild with the rulesets
and your city is pumping out units at vet level 15, the AI will
underestimate you. This is the only real problem I've found so far.

[withdraw]
Per:
> ... I am not sure what "all kinds of configurability" means...
Unit flag for withdrawal, plus server variables for:
 withdraw hp threshold (e.g., "withdraw when at 50% hp")
 withdraw success (e.g., "50% chance to withdraw")
 attackers and defenders, or just defenders (or neither) can withdraw
 whether hp percentage affects success (so if threshold is 50, and
   your unit is at 25%, does it only have half as good a chance to
   withdraw?)
 whether a unit can advance to vet status by withdrawing, or only
   by winning (actually part of the vet-level patch)
 whether an attacker will move into the space vacated by a withdrawal
   (if there's a chance to move forward on victory)

Raimar:
> ... I suspect the AI need updating for this.
The AI ignores whether or not a unit can withdraw. It would probably
be better if the AI considered attacking with a weaker unit if it knew
that unit could withdraw and survive (assuming you've set that server
option), but otherwise, it seems to work OK as-is.

Tony:
> Is this a SMAC addition?
Yes, but I'm not 100% sure how SMAC works, and I wanted to make it
more configurable anyway. Hopefully you can get the exact SMAC rules
with these options (and put them in a smac.serv file), but I'm not
sure.

[infinite move]
Per:
> Infinite paradrop sounds good. I don't think infinite move is viable
> for a multiplayer game.
I agree that infinite paradrop (aka "orbital insertion" in SMAC) is a
much easier question. As for infinite move, it's necessary for my
satellite code. For more normal units, I'm not sure whether it's
viable or not. See below.

Raimar:
> I suspect you would have a hard time to implement this in the
> correct way. What unit/thing has an infinite move rate?
The "correct" way isn't too hard, but I used a much simpler hack (at
startup, any unit type with infinite move is adjusted to the map's
width plus height).

Other than satellites, units with effectively infinite move might
include anything that flies ballistically--scramjets (fighters,
bombers, and spyplanes), ICBMs (nuclear and otherwise), etc. These can
effectively strike anywhere in the world as easily as they can strike
next door. The real-life justification is obvious, but there are two
issues:

First, scramjet bombers and nuclear ICBMs drastically change the game
balance when they become available. Suddenly, borders and lines of
defense aren't nearly as important. Of course this is exactly what
happened when nuclear ICBMs became available in the real world, but
the question is whether it works within Civ-style gameplay. The AI
clearly needs work to handle it, as it tends to get paralyzed once you
can nuke any of its cities from anywhere in the world....

Second, you might not need infinite move to handle this. Maybe the
ballistic flight could be implemented as an infinite paradrop followed
by a normal move. So a nuclear ICBM is a nuclear missile that can
paradrop at the start of its turn, then move 6 more spaces. Voila, no
more need for infinite move.

[city report subfields]
Raimar:
> I implemented this some time ago and there were no consent how to
> do it.
I think the way I implemented it is simple and should satisfy anyone
who likes it, while not affecting at all anyone who doesn't like it
(unless they like right-clicking randomly around the screen to make
sure it has no effect, or they're adding their own additional columns
and don't want to have to type in a few extra characters).

Do we need everyone to agree that this is a perfect solution, or do we
just need to make sure it answers all substantial objections?

[obsolesence]
Per:
> I'd rather see that obsoleted_by and upgradable_to are separate, and
> the latter (or both) could be an array. But I don't really see great
> usefulness for this.
First, your solution is much better than mine. Thank you! As for the
usefulness, in addition to the Engineers->Formers example I gave and
Greg's SMAC examples, you could have multiple upgrade path for horse
units (do you want 5/1/2 or 4/2/2?).

Raimar:
> Wouldn't a switch "show obsolete" in the city change dialog be
> easier?
This gives much the same effect as my original idea, but it's not
exactly the same (your idea means nothing is _ever_ really
obsolete). However, Per's idea gives much more power.

I think I'm going to put off any further work on this until I see
where the progress is on SMAC-style "partial unit types" in
freeciv-ac, because that will obviously change everything
radically. I'll continue to use my existing patch locally (I like the
ruleset I've created with Engineers upgrading to Formers), but it may
be that nobody else wants it.

[satellites]
Raimar:
> Yes. Satellites would be a complete new unit type. I'm not sure if
> this should be implemented.
I added two new unit types, actually. But some types of satellites
might be better handled by not being units at all. For example, the
SMAC satellites may be more appropriately handled as improvements.

As for whether they should be implemented, personally, I'd like to be
able to use at least some SMAC functionality within FreeCiv, if it can
be added without hurting Civ1/Civ2/Civ3/classic FreeCiv functionality.
(OK, my changes add a few K to the binary, but they don't affect
gameplay or even CPU usage if you never use them). So, while I realize
there's a separate freeciv-ac project, I think this might belong in
the main tree. (And ultimately, I'd like full SMAC functionality to be
part of the main FreeCiv tree, so I could play Civ3, SMAC, or my own
game just by using different tiles and rulesets.)

[borders]
Raimar:
> Merge them with others or wait until one border patch makes it into
> CVS and provide an improvement patch.
Great idea. I'll take the latest border patch and modify it to be
configurable, and throw out my hack.

As for Jules' ideas: I used fixed radii (where the radius is a server
option). I suppose in an ideal patch you'd want to be able to
configure how cities' contributions to a nation's borders are
combined. Maybe you'd even want to have different effects for
different-strength claims (so a strong claim means nobody can move
into the tile without provoking an incident, a lesser claim means
nobody can build a city on the tile, etc.). But that sounds like a
separate discussion; all I wanted to do is replace some of the
hardcoded numbers with options.




_________________________________________________________________
Send and receive Hotmail on your mobile device: http://mobile.msn.com