Follow-up Comment #14, bug #21776 (project wesnoth):

(I agree this is a minor cause, probably not worth to work on it. Wesnoth has
much more serious problems. :) Like the lua environment that is not saved.
)

>Also becasue i currently believe that relaoding should not change the
gamestate

I understand that philosophy, but the problem is the WML/lua system is far
from perfect, and there are situations in which it is useful (see comment #7,
the text "that come to my mind").

And from a philosophical point of view, don't forget the save/load process
doesn't lead to an identical situation, since the controller may change. 
An example scenario: WML may help AI to cheat

>> IMO a replay should be an exact replay. 
>there are other events aswell which arent fired in the replay (select ... )
I see.
But still ... it is expected a select event won't be fired during a replay
because it is not synchronized. It is natural to expect that any stuff will be
replayed iff it is synchronized.
Also select events behave consistently in a replay. A preload event is fired
sometimes, sometimes it is not. (The situation would be more clean if the
events were distinguished, name=preload,save_and_reload )

Conquest Minus:
>which could maybe the be solved by moving all the "make some input" in the
"turn 2" event. But maybe you meant player actions (move, attack) while i
thought you meant right click menus, [message][option] and similar by input. 
Yes, I meant [message][option]. But in turn 1 players play the game, and in
turn 2 they decide whether the start is balanced enough. So the input must
stay within turn 2.


    _______________________________________________________

Reply to this item at:

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

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


_______________________________________________
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

Reply via email to