[Freeciv-Dev] Re: Ruleset Development - improvements

[Petr Baudis <pasky@xxxxxxxxxxx>]

Dear diary, on Tue, Dec 04, 2001 at 06:00:52PM CET, I got a letter,
where Ben Webb <ben@xxxxxxxxxxxxxxxxxxxxxx> told me, that...
> On Tue, 4 Dec 2001, 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...
> > > 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;
> 
>       No... that's just reading it from the ruleset. All of the 
> necessary information is currently read from the ruleset and then sent to 
> the client - it's just that many fields (such as the "effect" field) 
> aren't acted upon.
Obviously, however that what pasted means that it doesn't occur anywhere else
at all ;p. That command named grep just searched all files in given directory
(if with parameter -r) for given string.

> > > the unusual terrain requirements of the Hydro Plant are now read from 
> > > the rulesets).
> > Shouldn't gates for Hoover Dam be the same, BTW?
> 
>       I don't know, not having played the original Civ. As far as I 
> recall, wonders can be built anywhere, no matter how silly that may sound 
> (e.g. you can build Lighthouse in an inland city). This may have been 
> fixed with the inclusion of the part of impr-gen that Sebastian committed, 
> however.
Well, in civ1/2 ruleset the original behaviour may remain.

> > >   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?
> 
>       I forget exactly why (I announced the patch back in April). Lack 
> of interest mainly, I believe. I think some parts of the code need a bit 
> more work anyway, but it'd be nice to have some feedback. ;)
There is interest, I believe. At least I have a great piece of it ;). IMHO we
need those changes and they should go in (if code is reasonable and works).

> > If it's just lack of review, can you please re-send the patches? (it 
> > would be nice to have them splitted into pieces).
> 
>       I will attempt to do this at some point over the next week - I'll 
> take another look at the code and try to split it up (it's not easy, 'cos 
> a lot of parts are interdependent). My aim will be to split the patches 
> into a) those which shouldn't "break" anything and could be committed 
> immediately and b) those which alter important behaviour (e.g. the 
> implementation of happy/content bonuses, etc. alters the way unhappiness 
> and disorder is calculated, and could cause problems).
Ok. Looking forward... :)

> > > - 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.
> 
>       No, it's not that hard really (he says confidently). Just rather 
> than, when the AI decides it wants extra food, weighing up the cost of 
> building a granary, it should instead weigh up the cost of building any 
> improvement that confers the "Growth_Food" effect. Since this effect also 
> includes an "amount" subfield, it should be trivial to include this amount 
> into the weighting without any hard-coding. (I guess a pessimistic way of 
> looking at it is that you're replacing hard-coded buildings in the AI with 
> hard-coded building effects, but at some point the AI needs to be told 
> this stuff in code anyway.)
Well, the granary was the easiest example, I would be interested in way how you
would do this with, say, City Walls or Coinage much more :).

> Oh, and consider the following snippet from advdomestic.c:-
> 
>   if (could_build_improvement(pcity, B_LIBRARY))
>     values[B_LIBRARY] = sci/2;
> 
>   if (could_build_improvement(pcity, B_MARKETPLACE))
>     values[B_MARKETPLACE] = (tax + 3*pcity->ppl_taxman +
>      pcity->ppl_elvis*wwtv)/2;
> 
>       What this is essentially saying is "we want to build a Library if 
> we already have plenty of science" and "we want a Marketplace if we have 
> plenty of tax income". This assumes that Libraries boost science and 
> Marketplaces boost tax. Isn't it more flexible (and more readable!) to 
> weight science against the "Science_Bonus" effect and tax against the 
> "Tax_Bonus" effect? I think it is. ;)
I didn't object against that at any rate! This is main benefit I see in your
changes in fact. Just the special cases remain :-).

> > You need either a heap of capabilities similiar to the ones units have
> 
> This is what the "effect" field in buildings.ruleset does.
Ok then. We can by one hand hardcode specialities as effects and by other
hand write essays about flexibility then ;).
> 
> > > - 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.
> 
>       Well, the first problem is the only major one. There's nothing to 
> stop you from setting up a building which (for example) acts as a Bank in 
> every city in the world (for all civs) but, since the client and server 
> calculate effects independently, if you can't see the enemy civ that has 
> the "magic" building, your cities will display the wrong luxury score, and 
> you'll wonder why the server keeps giving you buckets of gold every turn. 
> (Although, maybe you could consider this a "feature".)
If it has such effect, it should be certainly a WoW ;). However it looks
neccessary that server just needs to tell the client about additional
effects from 'unknown sources'.

> Solutions:
> 1. Have the server inform the clients of all active effects (fiddly)
> 2. Have the server tell the clients what the luxury production (etc.) of 
>    each city is (probably not so bad, since it sends cityinfo packets 
>    anyway)
This looks best.
> 3. Reveal cities that have "global" effects (in the same way that global 
>    wonders are currently revealed)
Those buildings should be _forced_ to be WoW probably. Or just all improvs
with global effects will be WoW. however I don't see the difference between
WoW and that improvement. However some effects aren't global to whole world,
but still may apply to more civs. Or just to one continent, but you may not
know about some cities they are on same continent, may you?

-- 

                                Petr "Pasky" Baudis

UN*X programmer, UN*X administrator, hobbies = IPv6, IRC, FreeCiv hacking
.
  "A common mistake that people make, when trying to design
   something completely foolproof is to underestimate the
   ingenuity of complete fools."
     -- Douglas Adams in Mostly Harmless
.
Public PGP key, geekcode and stuff: http://pasky.ji.cz/~pasky/