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 14:10:44 -0800
Reply-to: rt@xxxxxxxxxxxxxx

On Mon, Dec 09, 2002 at 01:28:45PM -0800, Raimar Falke via RT wrote:
> 
> IMHO you should mark all cached variables as such and also cite the
> function which updates them.

I probably can do that.
> 
> 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?

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

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

> > 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.
 
> > Have faith in the AI guys. They'll get us through it...
> 
> How many years will they need?

see your own comment. This doesn't have to be done all at once. And I
guarantee it won't be.

-mike



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