[Freeciv-Dev] Re: Ruleset Development - improvements

[Raimar Falke <hawk@xxxxxxxxxxxxxxxxxxxxxxx>]

On Tue, Dec 04, 2001 at 05:00:52PM +0000, Ben Webb wrote:
> 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.
> 
> > > 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.
> 
> > >   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. ;)
> 
> > 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).
> 
> > > - 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.)
> 
> 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. ;)
> 
> > You need either a heap of capabilities similiar to the ones units have
> 
> This is what the "effect" field in buildings.ruleset does.
> 
> > > - 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".)
> 
> 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)
> 3. Reveal cities that have "global" effects (in the same way that global 
>    wonders are currently revealed)
> 
>       Thoughts? I'm inclined to go for (2) and make the client more 
> dumb than it is presently. It'll increase the bandwidth required, but not 
> by an enormous amount, surely. (1) would require extra network traffic 
> too, anyway.

2. will prevent any good client side AI. Either the clients
calculations are wrong and so useless or the client has to ask the
server every time (slow). From the client side AI point of view 3. is
the best. Reveal any information the client needs. Come on if the
effect affects your city you know the source.

        Raimar

-- 
 email: rf13@xxxxxxxxxxxxxxxxx
  What's nice about GUI is that you see what you manipulate.
  What's bad about GUI is that you can only manipulate what you see.