Follow-up Comment #12, bug #8522 (project wesnoth):
Ok, I have to disagree with you here. First off, a lot of thought did go
into the current implementation, although what discussion there was about it
was quite a long time ago. I have not been a regular on IRC recently, so I
can't comment on the more recent discussion that you are referring to. I
really don't see the current implementation as a hack.
I realize that there might be some confusion because of the kludgey way user
defined names was implemented and modified in the C++ over the years before I
even touched it, so before I begin my argument, let me clarify what definition
I will use for this post. Here I will use "description" to describe the
unique identifier for a unit which can be used in WML filters, and
"user_description" for the name of the unit that can be modified by the
player and is seen in th gui. The C++ code unfortunately has a mess of names
associated with these which I won't use for this post.
"description" has from the beginning been meant to be a unique identifier.
As far as the game was originally concerned, it only needed to be used for
scenario special units which the designer explicitly named and the designer
could then use that identifier to define filters using that unique unit and
tell the AI to target it. A designer who made two units with the same
description has always been asking for unspecified and unpredictable
behaviour. Eventually the ability to give players the ability to create
custom names which did not effect the underlying unique identifier led to the
addition of the "user_description" which is not used by the underlying engine
for anything important.
The change I made was to make it so that the unique identifier "description"
was specified even for units that did not have it specified in the scenario.
This is entirely consistent with its original use. It led to this minor bug
based upon the secondary use of description to define user_description when
the latter is undefined.
It is absolutely necessary to have a unique id if the AI is ever to be able
to handle fog of war and other invisible units intelligently. It is silly to
have more than one unique identifier. It will ultimately make the WML for AI
and events diverge and just make both the WML and C++ more complicated. I am
opposed to adding a second identifier for this purpose. I will repeat, the
description tag has always been meant to act as a unique id.
The only way my implementation ends up with multiple units having the same
underlying "description" is if the scenario designer explicitly gives
multiple units the same description on purpose. The designer presumably is
doing this specifically because he is seeking ill defined behaviour out of
the events and AI. Thensecond way that two units will share a unique id is
on the very odd chance that two units of the same type are recruited with the
same number of SDL ticks, which is extremely unlikely. Even if such an
autogenerated conflict occured, it would be an isolated incideant and mean
only a minor confusion to any AI that used it. I don't see either of these
as a particular problem with the current implementation and does not
contribute at all to any justification to change the way things work.
If we really want to have units that can have "user_description" completely
empty then the solution in my mind is to completely remove the autogeneration
of user_description from the description. This will force scenario designers
to add a "user_description" for every unit in which they have left it empty
because "description" was previously sufficient. I don't think that is a
great solution as it breaks backward compatability in a way that is more than
just aesthetic. Scenarios that didn't make the change would find themselves
giving directions to move a unit, say "Konrad" to a particular hex and having
no unit that the player can see named "Konrad." I think the current
implementation is better than this alternative.
_______________________________________________________
Reply to this item at:
<http://gna.org/bugs/?8522>
_______________________________________________
Message sent via/by Gna!
http://gna.org/
_______________________________________________
Wesnoth-bugs mailing list
[email protected]
https://mail.gna.org/listinfo/wesnoth-bugs
