Follow-up Comment #4, bug #21776 (project wesnoth):
I named it a bug because I expected the replay should replay the game exactly
how it went in reality.
> people would have to check wether their envoronment is already loaded in
every preload event then.
I cannot imagine how any problem could happen then.
If the real game had no problem and the replay is equal to the real game then
the replay must be problem-free too, musn't it?
_______________________________
Problems in Conquest Minus
This is a minor problem for Conquest Minus. I created a walkaround, which is
not perfect from several points of view, but it is sufficient.
>is there a special reason why they have to reload a game to agree and not
pressing a right click menu button to do so?
In Conquest Minus, after the point of the first save and before the reload,
the game continues one more turn so that the players can make some input. If
the game continued (without a reload) then there would be one additional dummy
turn, which would increase a natural turn numbering. This is why the game must
be reloaded.
______________________________
Other problems
There are other scenarios in which you expect a reload event not only loads
constants (Lua constants), that couldn't be saved, but does a real job:
example:
Lua variables are not saved. Imagine you transform a table into a WML
container (this transformation would be somewhat opposite to
wesnoth.get_variable), so that it is saved. Then a reload event loads this
table from the WML container.
This way you can work a full-featured way with Lua tables, and you are not
limited to WML tables only.
_______________________________________________________
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
