This is the mail archive of the
xconq7@sources.redhat.com
mailing list for the Xconq project.
Re: New Action: change-type
- From: Eric McDonald <mcdonald at phy dot cmich dot edu>
- To: Hans Ronne <hronne at comhem dot se>
- Cc: xconq7 at sources dot redhat dot com
- Date: Wed, 7 Jan 2004 23:28:02 -0500 (EST)
- Subject: Re: New Action: change-type
On Thu, 8 Jan 2004, Hans Ronne wrote:
> >I guess a uu_change_type_into (a table of booleans presumably) is
> >needed for acp-independent play. For acp-dependent play,
> >uu_acp_to_change_type (or whatever it is called) should already
> >handle things fine.
>
> Yes. But any acp-dependent code would have to live in actions.c and run
> from move_one_unit_multiple instead.
Sure. But the auto-change-type stuff is going to be run from
run_turn_start in run2.c (probably in the vicinity of the
run_advanced_units and run_auto_repair calls).
uu_auto_change_type, like uu_auto_repair, does not have an
ACP deduction associated with it.
I assumed you were suggesting uu_change_type_into for the
acp-dependent action model, but perhaps you were suggesting it to
do what I was proposing uu_auto_change_type for? The only reason I
picked uu_auto_change_type was to more closely match the
uu_auto_repair analogue I was partially following.
> >I would argue for uu_size_needed_to_change_type because one may
> >have several different evolutionary paths available.
>
> If we allow multiple upgrade options, we also need some mechanism (i.e.
> easily understood principle) to pick which one to apply, at least for the
> acp-independent automatically executed code.
Well I was thinking in terms of the upgrade being triggered
whenever a certain size or other criteria are met. I did make the
erroneous assumption that a designer would, say, not pick the same
size to allow two different upgrade options.
To deal with the case of a set of criteria being met and enabling
two or more different upgrade options as a result, I guess we
could make uu_auto_change_type (or whatever) a table of weights or
probabilities instead of booleans. That way we avoid having the
referee code making a helper AI-like decision about the supposed
superiority of one upgrade over another.
> options are available at the same size. In reality, I see few uses for
> this.
I assume that the auto-change-type mechanism would refer to the
same criteria tables that the change-type mechanism would use. I
would agree that multiple upgrade paths do not make much sense in
the auto-change-type case, but can be perfectly legit in the
manual change-type case.
But I would consider a possible auto-downgrade as well, in which
case you need to have 2 utype entries. Perhaps a whole table is
not warranted, but it still might be fun to make it weighted and
leave it as an option.
> why should it be able to upgrade directly into a metropolis? I know you
> have a test example in Bellum that works that way, but do you really intend
> to keep it?
Absolutely not. I deliberately rigged the Town->City and
Town->Metropolis stuff to test the manual change-type menu
selection. That was strictly for testing and does not in any way
reflect my thinking. I do have a few brain cells, Hans. :-)
> >Consumption upon and supply after type change might also be
> >interesting to consider.
>
> I presume that is what um_material_to_change_type is supposed to be used
> for.
Oh, I thought it was just to be used as a prerequisite, not a
consumption table. I believe that is how [as a prereq] it is
currently used in the existing code.
> We could of course make it work like the firing code where two
types
> of materials are defined: those that are consumed (ammo) and those that are
> just needed (guns).
That is exactly what I had in mind.
> I don't think the non-consumed material table is used
> in any game, though (well, in fact it is used incorrectly for ammo in a few
> games, but I will fix that).
I use the material-to tables in Bellum for several reasons:
(1) They sometimes result in better user feedback to check the
material-to prereqs than to check the consumption.
(2) I seem to remember either reading docs or code to the effect
that an action can still occur even if there is not enough
material to consume. This seems wrong, and I can't remember the
exact source of information. But nonetheless, that impression
drove me to implement the material-to guards at some point.
Eric