First, see feature request 4336:
https://gna.org/bugs/?func=detailitem&item_id=4336
I don't know why the f.r. is set to duplicate, but it pertains to the heart
of what Jetryl is getting at. Bear with me now... we're going to be a
little abstract here.
Individuality is an illusion that the game intentionally creates to make
play interesting.
Names and traits are two methods used to *automatically* create the illusion
of individuality in units. A copy is made from a mold then it is customized
to appear different from the other copies.
Creation of campaign heroes is essentially the same process. We take a
single unit and personalize it for story purposes. This individual become
very important to most (all) campaigns. This is a case of a method used to
*manually* create the illusion of individuality in units. The manual
techniques include giving a unit a special name, special stats, special
portrait, and not using any other copies of that unit.
When making a campaign hero, a copy is made from a mold then it is
customized to appear different. We could create an identical copy and
destroy the illusion.
The two methods of individualizing a unit, automatic and manual, use the
same process: a copy is made from a mold then changes are applied. The
problem is that the automatic "tools" differ somewhat from the manual
"tools", although the manual tools include all of the automatic tools. The
problem is that SOME OF THE MANUAL TOOLS ARE HACKS! Using a separate unit
type to simulate an individual unit should be unnecessary, especially when
the mold-copy model still must be followed to create and manually
individualize the campaign hero.
Back to the feature request - in essence I am asking that the effects
achieved with manual-personalization hacks be made available in the
automatic-personalization toolbox.
I realize there are technical problems, namely only a subset of unit config
data are copied when the mold is read. Storing the entire unit config for
each recruited unit just in case I want to poke a value sometime to
personalize the unit is probably bad programming (I wouldn't know).
Could there be a way to store any diffs from the unit config file in
[modifications]?
Either way - increasing the number of keys stored or letting [modifications]
act like a diff - solves the immediate problem of portraits, but it also
fixes a glaring discrepancy in how units are made and opens a nice realm of
flexibility.
Scott
_______________________________________________
Wesnoth-dev mailing list
[email protected]
https://mail.gna.org/listinfo/wesnoth-dev
