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: Tue, 10 Dec 2002 00:44:55 -0800
Reply-to: rt@xxxxxxxxxxxxxx

On Mon, Dec 09, 2002 at 02:10:44PM -0800, Mike Kaufman via RT wrote:
> On Mon, Dec 09, 2002 at 01:28:45PM -0800, Raimar Falke via RT wrote:
> > I would suggest to s/pending/bld_missing_to_active/ or similar and/or
> > shorter.
> 
> pointless.
> 
> > 
> > If pending is only a cached value it would be nice if you can show the
> > speed difference.
> 
> see is_effect_emitting() for the reason why pending exists.
> This is called for every effect in every list when you're looking for an
> active effect. The reason it exists is because I thought it was ugly and
> slower to look at (eff->has_nat && eff->has_gov && eff->has_adv 
>                    && eff->has_no_equiv && eff->has_eff)
> everytime. was I wrong?

The ideal solution is IMHO is there is an
  bool is_pending(...);
this function can either have the body
  return eff->pending
or
  return (eff->has_nat && eff->has_gov && eff->has_adv
          && eff->has_no_equiv && eff->has_eff)

If you abstract the access to it you can implement both alternatives
and time them. As seen on the PF thread doubling the memory footprint
can make the computation slow down by an factor of 2.

It should be obvious that is_pending should be an inline function or
an macro.

> > 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?
> 
> no, this also applies to equiv_repl which doesn't allow you to build a
> building if its equivalent exists.
> 
> no, there are no unique effect types. This applies to buildings. an
> "equivalent" building suppresses all the effects of another. To actually
> replace the effects, the equivalent building has to have the same exact
> effects. Effects don't have priority either. the effect->defn->amount are
> simply additive. maybe equiv_dupl should be renamed to suppress_bldg

> > Either the unique flag or the priority would be nicer than the
> > equiv_range, equiv_dupl and equiv_repl.
> 
> I'm unsure whether you're searching for an explanation of the situation
> presented or offering an alternative. If you're offering an alternative,
> I don't think you've thought it out very far. giving uniqueness to an
> effect wouldn't be that difficult if you define uniqueness narrowly enough.
> Giving "priority" whatever that means would open a huge can of worms. I'm
> not interested in making general effects even more general or complex. I've
> even thought about killing off the idea of a conditional effect now that we
> no longer need it in the default ruleset (though it was already there
> so...)

I'm searching for an alternative. And yes I haven't understood
everything yet.

It looks like this is indead a building-only thing. IMHO we should
separate this from the effects. Only while both use a variable range
which have non-disjoint value sets we shouldn't mix them. Also "Local"
is rather pointless for equiv_range?!

> > 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.
> 
> If these we're assigned all over the place, perhaps I would be more
> sympathetic. As it is, they are assigned in only one: ruleset.c (two if
> you would count a memcpy in packhand.c) I don't see the problem.

Why do typesafety only benefit assignments?

> > > 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?!
> 
> I don't follow. see Per's comment.

I wrote non-sense. I mean: if the AI has been teched to understand the
effects all correctly the AI should be able to play at the same level
under all rulesets if only buildings.ruleset file is changed. If this
is true it contradicts your "as smart as long as the default ruleset
is used" from above. Or did you want to express the same?

        Raimar

-- 
 email: rf13@xxxxxxxxxxxxxxxxx
 A life? Cool! Where can I download one?




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