Follow-up Comment #8, bug #16148 (project wesnoth):
Both jamit's and natewr's test cases are good and reproduce for me using
1.11.2-263-g931e1f9
I think that they cover the same bug. The attack code taking place before the
last breath/die event adds "random results" in random.cpp; probably for
storing in the replay. These are queried for from actions::place_recruit, the
code there thinks they should be present only if itself is triggered (I think)
by player-recruit or recall. (IIRC the wml_triggered parameter in
place_recruit is false when triggered by a replay, an apparent unrelated bug
prevented me from checking it.)
There is an easy workaround using [unit] instead of [recall], since [unit] has
recall-or-create semantics. Probably only sensible for a single unit and when
referencing it by id. This workaround works, since the [unit]-recalling
doesn't use the same code as [recall], for probably no good reason, and
doesn't check those random results.
The [recall] tag doesn't need to be in that die/last breath event, it also
reproduces when another wml event in the same turn where the fight happened
tries to recall. The results probably get removed at turn change then,
recalling in the next turn is fine. wml mostly uses [recall] in prestart,
start or turn 1 events only when no fight happened yet, so this crash doesn't
happen more frequently.
The unit doesn't need to die.
I suppose this random check is made in case of player-recruit where trait
randomization is done. However, recalling doesn't need any randomization.
Also, [unit]-creation already doesn't do it anyway. A quick fix which seems to
work is disabling the call to recruit_checksums in actions::place_recruit in
case of a recall. From what the code looks like I assume recruit_checksums was
written with new units in mind only.
_______________________________________________________
Reply to this item at:
<http://gna.org/bugs/?16148>
_______________________________________________
Nachricht gesendet von/durch Gna!
http://gna.org/
_______________________________________________
Wesnoth-bugs mailing list
[email protected]
https://mail.gna.org/listinfo/wesnoth-bugs
