John McNabb <[EMAIL PROTECTED]>:
> Ok, here is what I think that is happening based on a quick look over the
> code.
I feel fairly sure, just from reading this, that you've nailed it.
> The unit is killed and the animation triggers. This then triggers any
> events that depend upon the unit death, in this case Mordak's. Note
> that events don't necessarily remove the unit that has been killed,
> since the event might be meant to stop the death from happening in
> some way (although I don't know off the top of my head an example
> where this is done).
I do. There are a couple of hero-death events in Northern Rebirth
attached to white mages that make them immortal -- on death they
teleport back to their side's home keep with their starting HP.
> Since this particular event has an endlevel
> result=victory, the game throws an end_level_exception which used to
> proceed to the next level, without finishing the removal of the dead
> unit. Without a linger mode, it was irrelavent. With linger, the
> dead unit isn't removed (although the death animation has taken
> place). Note that when you linger in a broken scenario, if you hover
> your mouse over the hex that the unit died in, you will see it's
> ghost.
This sounds right, though it fails to explain why the bug didn't manifest
in AIO.
> With a linger mode (which is very cool!) I see a couple of
> possibilties on how to deal with the problem.
> 1) Have all events that trigger off of killed units actually remove
> the unit from the game before being triggered, but put them into a
> "graveyard" for temporary safekeeping. An event could then actively
> resurrect a unit in the graveyard if that was desired. Units in the
> graveyard could be purged at appropriate times, or kept around for
> flavor.
> 2) Remove all dead units before their death event triggers. This
> would be simpler, but would stop the use of death events as a means of
> preventing death.
>
> Personally, I like 1. Hmm... I will have to see how difficult a
> graveyard would be to implement. But, don't wait for me, as it has
> been a long time since I have been free enough to work on Wesnoth.
Hmmm...interestingly enough, the resurrection events in NR don't depend
on the unit stats being stashed away somewhere. They recreate the unit
at its home keep.
Nor does the EventWML documentation say that the unit hangs around
in some sort of limbo. I think we can actually implement the simpler
behavior 2, keeping an eye on the possibility that it might break UMC
in some indirect way.
> To fix this, you will probably need to play with actions.cpp In
> particular around lines 1023 and 1246.
Looking...yeah, just moving the event firing to after the deletion
won't do what's needed because the event might want to find the unit
for something (like, dialogue). Still, it's a good place to start.
> Hope this helps
> Darth Fool
Hugely helpful -- Thanks a 10e6.
--
<a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>
_______________________________________________
Wesnoth-dev mailing list
Wesnoth-dev@gna.org
https://mail.gna.org/listinfo/wesnoth-dev
