Follow-up Comment #9, bug #15560 (project wesnoth):

My interpretation of r39404 is that it was thought this change would move the
decision to an R context, as if the advance occurred during play. It doesn't,
as we know, but that isn't obvious initially.

I agree that S won't work: your analysis is right, mine was wrong - I had
lost track of the detail that it is also an actual replay, not just data in a
multiplayer game.

It doesn't seem that moving it to W (no player selection) is such an issue
however: this would always have failed under any version of the code, but
that has not reported (I think?). I interpret this to mean that no current
scenario uses it. 

I agree that S' cannot be removed, because doing so will break existing
campaigns (message actions are the problem).

I don't think that start/prestart events work with S' as is. I have tried
this, but if you try the sandbox with this modification, you get a trace that
looks like this on the remote machine:


20100406 21:21:51 info engine: fire event: prestart
...
20100406 21:21:51 info engine: handling command 'unstore_unit' from cfg
0x8BD9630
20100406 21:21:51 debug engine: unstore_unit entered
20100406 21:21:51 debug engine: Extract unit 3
20100406 21:21:51 debug engine: Adding unit 3 - sc1_enemies to location:
(16,3)
20100406 21:21:51 debug engine: entering wait for choose
20100406 21:21:51 debug replay: Replay data at end
20100406 21:21:51 debug engine: leaving wait for choose
20100406 21:21:51 debug engine: unstore_unit exited
20100406 21:21:51 debug engine: done handling command...


That is: there was no replay data. So we'd need to change something, and I
don't _think_ this is trivial, because prestart happens outside of the normal
flow of turns. I'm not clear on the situation with start. 

We could restrict when this action could occur, but it seems that might be
worse than removing the (unused?) feature we have presently of non-random
player-side character advancement on the currently playing side?

    _______________________________________________________

Reply to this item at:

  <http://gna.org/bugs/?15560>

_______________________________________________
  Message sent via/by Gna!
  http://gna.org/


_______________________________________________
Wesnoth-bugs mailing list
[email protected]
https://mail.gna.org/listinfo/wesnoth-bugs

Reply via email to