Re: New Action: change-type

[Hans Ronne <hronne at comhem dot se>]

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

>>while the utype
>> property u_size_needed_to_change_type would handle upgrades triggered by
>> unit size.
>
>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. Particularly if multiple
options are available at the same size. In reality, I see few uses for
this. A village that reaches a certain size might upgrade into a town, but
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?

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

Hans