Re: New Action: change-type

[Eric McDonald <mcdonald at phy dot cmich dot edu>]

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