Complete.Org: Mailing Lists: Archives: freeciv-dev: December 2002:
[Freeciv-Dev] Re: (PR#2521) general effects framework
Home

[Freeciv-Dev] Re: (PR#2521) general effects framework

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
Cc: freeciv-dev@xxxxxxxxxxx
Subject: [Freeciv-Dev] Re: (PR#2521) general effects framework
From: "Mike Kaufman via RT" <rt@xxxxxxxxxxxxxx>
Date: Mon, 9 Dec 2002 13:05:26 -0800
Reply-to: rt@xxxxxxxxxxxxxx

> Is this true
>   active == has_nat && has_adv && has_gov && has_bldg && has_eff && 
> has_no_equiv
> ? Is this true
>   pending == has_nat && has_adv && has_gov && has_eff && has_no_equiv
> ?

here's the code: effects.c:525

  eff->pending = eff->has_nat && eff->has_gov && eff->has_adv
                 && eff->has_no_equiv && eff->has_eff;
  eff->active = eff->pending && eff->has_bldg;

so... yes.

(maybe I should save memory by putting these in a bitfield...)

> The current ruleset says:
> 
> ; equiv_range   = range for which this may be equivalent to another
> ;                 building; one of:
> ;                   "None", "Building", "City", "Island", "Player", "World"
> 
> This doesn't make it any clearer. What is equiv_range?

yes, it's very confusing. I'm not ashamed since I didn't write it :)

equiv_range is a part of equiv_dupl and equiv_repl. It defines at what
range an improvement (not effect) is equivalent to another. The example of
Sun Tzu has an equiv range of Player, that means any building with it as
equiv_[repl|dupl] (like Barracks) owned by the player would be equivalent. 
This only tangentially impacts general effects since we need to suppress the
Barrack's effects (for example) if Sun Tzu exists. Hence eff->has_no_equiv.

For example: something nasty might be to set Sun Tzu's equiv_range to
World, but leave its effects as Player. Then if you built it, all your
enemies Barracks would stop working! (so would yours, but _you_ would get
Sun Tzu's effects, nobody else would). I think that's kinda spiffy.

> I don't see the problem. The only change would be that you create two
> new files effect_list.[ch]. Both will be very short. All logic will
> stay in effect.h

huh? as I am aware, the struct must be defined before the list definition.
This equals screwed. Prove me wrong, but even if I were, this is still
butt-ugly, just less so. Also see similar reasons for rejecting 2350.

> So you guarantee a maximal slowdown of 10% for non-AI?

no, of course I don't. See previous posts from Ben and Per.

> The problem of the AI is that it can't hardcode the buildings
> anymore. This means that it really has to do extra work _AND_ have to
> understand the effects either as effects or looking what the given
> building changes.
> 
> So my current case is that the AI will even much more stupid that it
> is now.

No, AI will be smarter because they will actually understand what all this
stuff does. Since will also require an audit of the code and all the stupid
stuff will get thrown out. Also note that the ai will be just as smart as
long as the default ruleset is used. Have faith in the AI guys. They'll get
us through it...

-mike



[Prev in Thread] Current Thread [Next in Thread]