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]
To: kaufman@xxxxxxxxxxxxxxxxxxxxxx
Cc: freeciv-dev@xxxxxxxxxxx
Subject: [Freeciv-Dev] Re: (PR#2521) general effects framework
From: "Raimar Falke via RT" <rt@xxxxxxxxxxxxxx>
Date: Mon, 9 Dec 2002 13:28:45 -0800
Reply-to: rt@xxxxxxxxxxxxxx

On Mon, Dec 09, 2002 at 01:05:26PM -0800, Mike Kaufman via RT wrote:
> > 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.

IMHO you should mark all cached variables as such and also cite the
function which updates them.

I would suggest to s/pending/bld_missing_to_active/ or similar and/or
shorter.

If pending is only a cached value it would be nice if you can show the
speed difference.

> (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 like it. So the only reason is that we don't apply the same
effect twice? This means that there are unique effects types (only one
effect can be active for a given range) and non-unique effects types
(multiple can be active)? Or is more that uniqueness more related to
the source? So there are effect priorities and if the priorities
differ (default is all 0) the source with the highest priority rules?

Either the unique flag or the priority would be nicer than the
equiv_range, equiv_dupl and equiv_repl.

> > 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.

Only as 
  struct effect_defn;

> 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.

While I agree that the reasons (reduce compile time, create base work
for inlining) for 2350 were not enough I think that type-safety is a
good reason.

> > 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.

I think this is the main reason. 

> Also note that the ai will be just as smart as long as the default
> ruleset is used.

It should be good in every ruleset if only buildings.ruleset changes?!

> Have faith in the AI guys. They'll get us through it...

How many years will they need?

        Raimar

-- 
 email: rf13@xxxxxxxxxxxxxxxxx
  (On the statement print "42 monkeys"+"1 snake"): BTW, both perl and Python
  get this wrong. Perl gives 43 and Python gives "42 monkeys1 snake", when 
  the answer is clearly "41 monkeys and 1 fat snake".  
    -- Jim Fulton, 10 Aug 1999




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