Follow-up Comment #1, bug #12558 (project wesnoth):
It seems that since 1.5.5, the system for making unit ids unique was removed
in favour of making a separate underlying_id which is an integer. I assume
this by the following changelog entries:
++
* WML engine:
* Changed underlying_id in unit to be unique number
* Miscellaneous and bug fixes:
* Fixed wesnoth not to try to add duplicate ids to unit_map
--
This breaks badly with the following code. The code's preconditions are that
$NPC_birds[] is an array of WML containers created by a Standard Unit Filter
matching a list of possible unit types, and that $i is an iterator in a
FOREACH macro-based loop. $random is the result thrown by the RANDOM macro
after choosing from a list like "n,ne,nw,s,se,sw".
++
# Now move the bird
[kill]
id=$NPC_birds[$i].underlying_id
side=$NPC_birds[$i].side
[/kill]
[move_unit_fake]
gender=$NPC_birds[$i].gender
variation=$NPC_birds[$i].variation
type=$NPC_birds[$i].type
side=$NPC_birds[$i].side
x=$NPC_temp_movepath_x
y=$NPC_temp_movepath_y
[/move_unit_fake]
{VARIABLE NPC_birds[$i].facing $random}
[unstore_unit]
# In case the coordinates were screwed up in the process by a design flaw
in this code,
# make sure we don't kill any existing units by unstoring in an used hex
find_vacant=yes
variable=NPC_birds[$i]
[/unstore_unit]
--
Albeit the safety measures taken here to avoid duplicating the unit, this
*still* causes an assertion failure and aborts the game*:
++
"wesnoth: src/unit_map.cpp:502: void unit_map::add(std::pair<map_location,
unit>*): Assertion `false && "Duplicated underlying_id not allowed"'
failed."
--
... Which did not happen before the introduction of this change, of course.
This is most likely a flaw of the n_unit::id_manager (src/unit_id.hpp)
implementation or something else that popped out after 1.5.4. Too bad as it
limits the power of WML-based unit modifications greatly. Notice the unit is
[kill]ed before unstoring it. [kill]s remove units from the game map, but it
seems it is *currently not unregistering* the underlying_id or whatever
should be done so that the same unit can be used again ("resurrected")
without manual modification of the underlying_id by the WML author.
This code snippet was originally designed to use the text .id of the units,
and was compatible with 1.5.4 and earlier. wmllint doesn't suggest changing
anything on that revision, which means there is no wmllint conversion for
this change.
The text .id of units is no longer unique, either - for units of type Falcon
spawned with default parameters, irrespective of their underlying_id, all of
them have id=Falcon (the unit_type id). I personally wrote much WML that was
based upon the formerly safe assumption that no units with duplicate .id
would appear in the game unless the WML author forced such a thing to happen
(if the game would allow that). It was specially useful for things like
describing subsets of recall lists, where there were no unique parameters for
each unit except the .id, as .x and .y are invalid there.
I'd personally like to see the unique text .id back to its original format
(Unit_Type-SomeUniqueNumber) for units which didn't have their .id specified
when spawned. The SomeUniqueNumber could be the new underlying_id. Of course,
the above flaw that causes the game to abort may have to be fixed first.
I am not aware of the WML techniques employed in mainline content - it is
possible that this bug is actually a blocker, not sure.
_______________________________________________________
Reply to this item at:
<http://gna.org/bugs/?12558>
_______________________________________________
Message sent via/by Gna!
http://gna.org/
_______________________________________________
Wesnoth-bugs mailing list
[email protected]
https://mail.gna.org/listinfo/wesnoth-bugs
