[Freeciv-Dev] Re: (PR#10290) rfc: city production circuit

["Jason Short" <jdorje@xxxxxxxxxxxxxxxxxxxxx>]

<URL: http://rt.freeciv.org/Ticket/Display.html?id=10290 >

Benoit Hudson wrote:
> <URL: http://rt.freeciv.org/Ticket/Display.html?id=10290 >
> 
> The city update code that computes the production surpluses given the
> buildings, workers, specialists, etc is slow at the moment.  The CM code is
> very good at avoiding calling that code, but could still be sped up
> enormously were that code faster.  Also, it would be simplified a lot if
> generic_city_refresh were sufficiently fast.  The same goes for other
> what-if scenarios, other than just CM.

Indeed.

> First of all, I can't find the gen-effects patch anywhere on RT.  Maybe
> that's because I don't know what to search for, but if someone could point
> me the right direction, that'd be appreciated.  I don't know how much I'm
> repeating.

As Mike pointed out, the so-called "effects patch" is now in CVS.

> The idea is that the CM code and other what-if scenarios change only a
> small part of the computation of the city refresh.  Therefore, recomputing
> should only touch that small part.  The mechanism will be to have a file
> that produces a graph.  For instance, I'll write out the part of the file
> relating to shields production:
>         factory_factor  = .5 * exists(factory);
>         power_factor    = .5 * exists(factory) * exists(power);
>         mfg_factor      = .5 * exists(factory) * exists(mfg_factor);
>         industry_factor = factory_factor + power_factor + mfg_factor;
>         industry        = input(shields) * industry_factor;
>         indsurplus      = industry - input(unitupkeep);
>         /* assume disorder has already been computed */
>         output(shields-produced) = industry;
>         output(shields-surplus)  = conditional_clip_max(indsurplus, 0, 
> disorder);       
> A what-if scenario that just wanted to check the new production if it built
> a mfg plant could just call a function to add the mfg plant, then ask to
> recompute the shields.  Given the graph, we can know when adding the mfg
> plant that only mfg_factor, industry_factor and so on change, and we can
> clear them.  Then, when asked to recompute the shields surplus, we know
> that only depends on indsurplus and disorder, and work our way back until
> all the values are initialized. 

If you are building a building N, you iterate over all effects provided 
by that building, and for each effect update the output affected by that 
effect.

This is complicated because there is more than one effect for each 
output type.  For instance production is changed by EFT_PROD_ADD_TILE, 
EFT_PROD_INC_TILE, EFT_PROD_PER_TILE, and EFT_PROD_BONUS.  Check out 
get_city_bonus() and its uses with these effects.

If you want the AI to calculate the benefit given by a mfg plant, you 
don't need to resort to the CM at all (you could but in most cases it 
won't make any difference).  You can calculate the extra shields you get 
from an EFT_PROD_BONUS building by:

   old_bonus = get_city_bonus(pcity, EFT_CITY_BONUS);
   extra_shields = pcity->shield_total * amount * (100 / old_bonus)

but this may be too simple - it won't work for EFT_PROD_ADD_TILE 
(Richard's Crusade), for instance.

> Another effect of building the graph is that we could then easily invert
> it and solve for the minimum inputs to achieve a certain output.  For
> instance, how much food do we need to produce from tiles to be able to feed
> the whole population and the settlers and still grow?  The CM can use this
> to decide whether to ignore a whole class of possible solutions, and thus
> reduce the number of city updates it needs.

To large degree this graph already exists in the "ruleset cache" in 
effects.c.  There are some accessor functions for finding the effects 
provided by a single building, the buildings that can provide an effect, 
etc.  These are all fast lookups but there is function overhead.

> Probably the coolest effect of the graph is that we can easily change the
> rules quite drastically, perhaps even have this be in the ruleset.  With
> all our what-if codes operating on the graph, we should be able to get them
> all to use all sorts of assumptions (for speed) and yet still be correct
> when we change the way city update computation works.

Building effects are now in the ruleset.  However there are lots more 
hard-coded rules (like waste/corruption) that it would be nice to move 
into the ruleset.

> So the question now is: do people think this is worth implementing at the
> moment? Or is the city code too variable still for another big patch to be
> floating around?

The city code isn't particularly variable at the moment.  So now would 
be a good time for changes.  Just remember we want to be getting rid of 
hard-coded rules rather than adding new ones (or fortifying the ones 
that are already there).

jason