[Freeciv-Dev] Re: (PR#12930) RFC: generalizing output types in effects

["Per I. Mathisen" <per@xxxxxxxxxxx>]

<URL: http://bugs.freeciv.org/Ticket/Display.html?id=12930 >

On Thu, 28 Apr 2005, Jason Short wrote:
> It would be nice to generalize the output types in the effects code.
> This would cut down on the number of output-modifying effects by a
> factor of 6, as well as allowing potential future gen-output work.

Yes.

> There are basically 3 ways we can do effects with output:
>
> 1.Hard-code each type of output as a different type of effect.  This
> is what's done now.Advantages: fast, easy.  Disadvantages: many
> different effect types bloat the (user) API; impossible to change or add
> effect types without breaking things.
>
> 2.Add a new parameter to the effect structure.  I'm not entirely sure
> how this would work, but it would amount to a new entry in the
> [effect_xxx] section in the effects.ruleset.This would be its very own
> variable in the effect structure in effects.h.Advantages: fast.
> Disadvantages: more effect parameters bloat the (user) API; parameter is
> specific to just a few effect types; lots of work to code.

Another option is to reserve N effects for outputs, and dynamically
allocate effects to outputs when we read the rulesets. So we have a list
of outputs 0,1...N where the first must be as the hardcoded ones, and we
have effects OUTPUT_BONUS_SHIELDS, OUTPUT_BONUS_FOOD ...
OUTPUT_BONUS_USER9 to match.

> 3.Add an output type as a requirement.  I hinted at this before but
> here is how it would work: a new requirement source type REQ_OUTPUT_TYPE
> is added.At first glance this may not make any sense whatsoever.
> However when we pass in a target_output_type to the req functions then
> the requirement is only met if the output type we're considering at the
> moment is the one in the requirement.Advantages: easy, extensible.
> Disadvantages: the req can only have range REQ_LOCAL and only applies to
> a few effects (and never to buildings or other reqs users); it's slower
> than #1 or #2 because you have to go through the inapplicable effects to
> get to the ones you want (for instance to find the prod bonus you have
> to iterate over science, luxury, and gold bonus effects as well).
>
> The attached patch implements #3.This is basically a demo at this
> point.To be workable it'll need some cleaning up, plus documentation
> (README.effects) and updates for the other rulesets.However I think
> this is the best way to do it, at least for now.

Sorry, I think this is an unworkable design. It is completely
non-intuitive for a modpack writer to add a requirement to specify the
contents of an effect. If we are to implement it this way in the core
code, we have to hide this implementation ugliness somehow from the user.

  - Per