Follow-up Comment #19, bug #8522 (project wesnoth):
>OK, sorry to belabor such a minor issue, but I just don't agree. >:p
Belaboring minor issues is fine. It is a good exercise to explain the
thoughts behind certain decisions that would otherwise go undocumented.
Besides, you, I, or both of us might learn something in the process.
>1) generating a user-visible decription that should be >translateable from
one that should NOT be marked translateable >seems to encourage incorrect
translatability for one or the >other. So I don't see this as an elegant
feature, but rather an >odd backwards compatibility that should probably be
removed.
I don't disagree that it would be good to have it removed in principle. In
fact, if you read a litte further down in the comments, in response to
Zookeeper's I say the following: "I am not strongly opposed to making it so
that user_description is required for all units in a scenario, but I do think
that such a change would be a significant enough impact that I would want to
poll more devs before making it ... If I was doing things from scratch, I
would do it this way, but I hesitate to soft-break things like this after the
fact." And, if you follow the thread in the forum, that is currently the
plan, barring major objections from scenario designers before I get around to
implementing it. Yes, I know that people should expect development versions
to break things, but I don't think that it should be done without
consultation of the parties that will be most effected by it.
>2) I see what you're trying to do with the AI, but I don't buy >the
"undesirable split" argument. If you want AiWML to support >SUF then that is
good. But, unit::matches_filter match is slow >and should not be performed
unless it is specified. At that >point it could look up the unique id, and
thus the internal >mechanic would be invisible to the WML coder.
Making an optimization before it is known to be needed and that will
obfuscate things is not generally a good idea. Once everything is working
properly it makes sense to go back and profile the code and see where
optimizations will have a real impact on performance. This is not the time
to do that. Certainly, if it turns out that the AI searching for a
particular element in a unit is the primary source of inefficiencies, there
are things that can be done such as indexing with numbers.
Jumping straight into indexing with numbers has a few undesirable features.
For one thing, when assessing what the AI is doing/thinking, it is useful to
look at what the AI is filtering on in its decision process. Having to dig
through save files to correlate by hand the number of a unit with its
description to figure out if things are working correctly, or why they are
working incorrectly, is a little excessive. If there is a need for
efficiencies sake to go add in numerical indexing later, it will not be made
more difficult by the current solution.
>3) While the gains from an integer as unique-id might be >negligible in this
case, I think it could be a significant >improvement in the long term. In
particular, if it could replace >the location based unit map which is
currently a source of >invalidated iterator errors, expensive unit copy
operations, and >location-based assumptions.
That is a much larger change. First off, inevitably location based searches
will need to be done. In fact, this being a map based game, I would guess
that most searches for units are location based (for example, what is
adjacent to the current unit?). So, I don't think that simply a implementing
a numerical unique-id would be able to generaly replace location based unit
map. As such, the benefits might be significantly smaller than you expect.
Even if it somehow would make a significant impact, it would do so only by
changing a whole lot of code. Such a major change is well beyond the scope
of what I am willing to undertake at this time, and certainly far more than
is necessary to accomplish the specified goals.
_______________________________________________________
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
