Complete.Org: Mailing Lists: Archives: freeciv-dev: April 2005:
[Freeciv-Dev] Re: (PR#12856) proliferation of BONUS effects
Home

[Freeciv-Dev] Re: (PR#12856) proliferation of BONUS effects

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
Subject: [Freeciv-Dev] Re: (PR#12856) proliferation of BONUS effects
From: "Jason Short" <jdorje@xxxxxxxxxxxxxxxxxxxxx>
Date: Wed, 20 Apr 2005 13:19:16 -0700
Reply-to: bugs@xxxxxxxxxxx

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

Benoit Hudson wrote:
> <URL: http://bugs.freeciv.org/Ticket/Display.html?id=12856 >
> 
> On Wed, Apr 20, 2005 at 12:07:49AM -0700, Jason Short wrote:
> 
>><URL: http://bugs.freeciv.org/Ticket/Display.html?id=12856 >
>>
>>This patch proliferates the BONUS effects beyond all reason.
>>
>>There are two levels (called priorities, got a better name?) of bonus
>>effects.  Each of these has one bonus effect for each output type.  This
>>gives 12 total effects (compared to the 4 we have now).
> 
> How hard would it be to add a priority field to the effects?  So the
> modpacker could have as many priority levels as wanted, rather than
> being stuck with two; and you'd have half as many enum members.

Somewhat tricky.  We'll probably get around to it eventually but for the
moment it's easier to add new effect types.

Also, any design that does this should take into account other
effect-type variables that we need.  In particular the output type
should be an effect-type variable not a part of the effect type name.
Then instead of 12 effect types we'd have just 1 (and dozens of others
would be removed as well).

Perhaps the simplest way to implement this is just by adding a string
parameter.  The effects code does its caching including the effect type
# and a hash of the string.  So any lookup on an effect must do the
lookup by type and string.  In the above case the string would be
something like "food0" or "shield1".  The calling code (in this case, in
city.c) must know what possible strings are available.  This is ugly but
would be the easiest thing to write.

The problem with making something more elegant is that different effect
types need different parameters.  These particular effect types need two
parameters, priority and output type.  Other effect types would need
only output type.  Most effect types would need no parameters.  Some
effect types might need different parameters...

Finally, it might be possible to solve this using reqs, although I don't
see how.  An example of a similar situation is the make-veteran or
extra-moves effect types.  You'd think we'd want to add a parameter to
control the class or unit type that is to be made veteran or given extra
moves.  But in that case we can do it using reqs, if we have a unit type
or unit class req at local range.  I can't think how that could be done
for the output effects however (we can't really have an output-type req
can we?).

-jason





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