[Freeciv-Dev] Re: Ruleset Development - improvements

[Raimar Falke <hawk@xxxxxxxxxxxxxxxxxxxxxxx>]

On Tue, Dec 04, 2001 at 04:20:49PM +0100, Petr Baudis wrote:
> Dear diary, on Tue, Dec 04, 2001 at 02:01:57PM CET, I got a letter,
> where Ben Webb <ben@xxxxxxxxxxxxxxxxxxxxxx> told me, that...
> >     Oh come on - we're only human. We haven't got rid of 
> > OLD_IMPR_TYPE_ENUM because (as you point out earlier) its use is implicit 
> > all through the Freeciv code. In particular, we haven't touched the AI, 
> > which uses this extensively. If you're not too bothered about the AI not 
> > understanding your new customised buildings, however, the rest of the code 
> > should (largely) work; we don't actually rely on OLD_IMPR_TYPE_ENUM for 
> > much of the behaviour now.
> > 
> >     Here's a quick summary of the situation with regard to handling 
> > of buildings.ruleset (as I read the situation):-
> > 
> >     Freeciv-1.12 lets you change the building names (although not 
> > everywhere - e.g. "needs an Aqueduct to grow further" is still hardcoded, 
> > I believe), the tech requirements, build cost, and upkeep. I'm not sure if 
> > the sabotage field is used, but I _think_ it isn't.
> pasky@machine:~/src/freeciv/aiciv/freeciv/ai$ grep -r -- "->sabotage" 
> ../server/
> ../server/ruleset.c:    b->sabotage = secfile_lookup_int(file, "%s.sabotage", 
> sec[i]);
> ../server/ruleset.c:    packet.sabotage = b->sabotage;
> > 
> >     Current Freeciv CVS does this, plus it incorporates a small part 
> > of the AC impr-gen patch, which understands the bldg_req, terr_gate and 
> > spec_gate fields (e.g. you can specify "coastal" improvements using 
> > "terr_gate=Ocean", and the unusual terrain requirements of the Hydro Plant 
> > are now read from the rulesets).
> Shouldn't gates for Hoover Dam be the same, BTW?
> > 
> >     In addition to all of the above, the AC impr-gen patch also does 
> > the following:-
> > 
> > - Understands the equiv_range, equiv_dupl and equiv_repl fields (for 
> >   setting behaviour like "Sun Tzu's replaces a Barracks in every city 
> >   owned by this civ")
> > - Removes the "fixed number of buildings" limitation
> > - Understands most of the "effect" parameters - e.g. the following should 
> >   be taken directly from the rulesets, and not hardcoded:
> >   - Shield/Food/Trade bonuses for city tiles (e.g. effect of Supermarket)
> >   - City tax/luxury/science/production bonuses (e.g. effect of Bank)
> >   - Pollution modifiers (e.g. effect of Mass Transit)
> >   - Content/happy modifiers (e.g. Bach)
> >   - Proper selling of "coastal" improvements when city becomes landlocked
> >   - Generalisation of capital city and airlift effects
> >   - Generalisation of all "veteran making" effects (e.g. Barracks)
> > 
> >     With this, most of the Alpha Centauri buildings work in 
> > FreecivAC. (Some Wonders are still non-functional though.)

> That sounds great. Reasons why it wasn't accepted? Raimar? If it's just lack
> of review, can you please re-send the patches? (it would be nice to have them
> splitted into pieces).

AFAIK there wasn't a submission till I got maintainer. Also note this:

\begin{quote}

This is an automated notification of a change to freeciv cvs,
on Wed Aug 22 14:40:06 PDT 2001 = Wed Aug 22 21:40:06 2001 (GMT)
by Sebastian Bauer <sebauer@xxxxxxxxxxx>

---- Files affected:

freeciv/client packhand.c
freeciv/common city.c city.h game.c game.h improvement.c improvement.h player.c 
player.h
freeciv/data/civ1 buildings.ruleset
freeciv/data/civ2 buildings.ruleset
freeciv/data/default buildings.ruleset
freeciv/server citytools.c cityturn.c diplhand.c diplomats.c gamehand.c 
maphand.c savegame.c

---- Log message:

Generalized the construction of the improvements by using the things defined in 
the buildings.ruleset.
Changed the differnt buildings.ruleset so that they are compatible to the old 
hardcoded code.

Patch by Ben Webb <ben@xxxxxxxxxxxxxxxxxxxxxx> and me

\end{quote}

So Sebastian does know more about this.

> > We still don't do (among other things):-
> > 

> > - AI support; it should really consider building effects, rather than 
> >   considering building types directly
> That's very nice to say, but much harder to implement. Basically, it's pretty
> hard to tell it universally what granary does, what leonardo workshop does
> and what magellan's does. Not mentioning city walls or even palace.
> You need either a heap of capabilities similiar to the ones units have, or 
> some
> scripting language embedded into the ruleset, and you should be able to modify
> desire of particular building that way.

From my todo list:
 - effect of building (client only)

Consider something like this:
 - save city state
 - for each improvement which can be build:
   - virtually build the improvement
   - recalculate the city
   - calculate and save the difference (effect) to the starting point
   - restore saved state
 - for client: display the effect
 - for AI: weighten effects and select one

Some buildings won't have an immediate effect. There you need some
estimations. Something like this (from
ai/aitools.c:ai_evaluate_government):

  if (government_has_flag(g, G_BUILD_VETERAN_DIPLOMAT)) {
    rating += 100; /* ignore this advantage for now -- SKi */
  }
  if (government_has_flag(g, G_REVOLUTION_WHEN_UNHAPPY)) {
    rating -= 50000; /* very bad! */
  }
  if (government_has_flag(g, G_HAS_SENATE)) {
    rating -= 300; /* undesirable */
  }
  if (government_has_flag(g, G_UNBRIBABLE)) {
    rating += 100; /* nice */
  }
  if (government_has_flag(g, G_INSPIRES_PARTISANS)) {
    rating += 100; /* nice */
  }

You may now think about how to obtain these special numbers (a lot of
test games, genetic algorithms, guessing, roll a dice, ...) but this
doesn't change the basic idea. And I don't know any other way to this.

> > - Client and server have different ideas of the world (e.g. islands can be 
> >   different in the client, due to unexplored territory) and this can give 
> >   the client incorrect effects
> > - Handling of population size limits (e.g. Aqueduct, Sewer System)
> > - Code optimisation; many algorithms are still O(N**2) in number of 
> >   cities, and we iterate over effects too frequently for my liking
> Anyway, this isn't something so fatal IMHO and can be adjusted on the fly.

http://arch.freeciv.org/freeciv-dev-200109/msg00019.html

And from http://arch.freeciv.org/freeciv-dev-200109/msg00051.html:

> I think much of update_all_effects() and the other calls are really
> unneccessary, but I wanted to wait for the next step of the
> generalizaton where time needed will further increases (this is the
> price). Ben wanted to create the patch but actually he is on
> holliday. Before the code is optimzied I really would like to have
> that this is really nearly free of bugs.

Well the next step didn't managed to get included. And the tree is
left with code which uses 40% of the runtime.

So I'm a bit critical.

        Raimar

-- 
 email: rf13@xxxxxxxxxxxxxxxxx
 "The Internet is really just a series of bottlenecks 
  joined by high speed networks."
    -- Sam Wilson