URL:
<http://gna.org/bugs/?21697>
Summary: MP synchronization not tracked well, creates
minefield for add-on designers
Project: Battle for Wesnoth
Submitted by: elvish_pillager
Submitted on: Thu 20 Feb 2014 12:59:16 AM UTC
Category: Bug
Severity: 3 - Normal
Priority: 5 - Normal
Item Group: Networking
Status: None
Privacy: Public
Assigned to: None
Originator Email:
Open/Closed: Open
Discussion Lock: Any
Release: 1.11.9+dev
Operating System: Debian Linux
_______________________________________________________
Details:
Currently, we have
- No warnings for using random, synchronize_choice, or global_variables in
non-synced events, except for OOS errors, which aren't very readable and (for
random things) may show up much later.
- An RNG state that can become desynchronized - for *all* future uses - from
just a single misuse in a non-synchronized context.
- Stealth features that can silently desync the game without the add-on writer
referring to them directly: generate_name, random_traits and random_gender.
(They default to true, and they can be invoked variously by [unit],
wesnoth.put_unit, and wesnoth.create_unit (possibly [unstore_unit]? I don't
know). It's quite nonintuitive to be able to break the game by creating a
private unit just to check something about it)
- No way for a WML or Lua script to check whether it's currently in a
synchronized context.
Running into these can be a major stumbling block for an add-on designer.
Of course, the designer can always desync the game by basing conditionals on
timestamps or controller= or math.random, and I don't propose removing those
features. But the engine could certainly track whether the current event stack
should normally be synchronized or not - which an add-on writer cannot know
(consider that an attack event could be invoked by the
era/scenario/modification from inside a side_turn_end event - you could say
it's irresponsible for someone to do that, but that requires a sophisticated
understanding of the networking system that we cannot, and *should* not,
expect from the average WML writer).
In the add-on I'm currently developing, I *attempted* to track synchronization
by setting a global lua variable at the beginning of each synchronized event
and unsetting it at the end. However, this did *not work* because lua
functions can be invoked during ability filters, which can happen at arbitrary
times in the middle of other events, and as a result, a process that should
have been "safe" (because I made it check the sync state and behave
differently if it wasn't synced) became unsafe. Looking back on it now, I
could have put it in a local variable that is passed around through every
function I use (but that would be cluttered) or I could do something
complicated with metatables (but again, I want these features to be usable by
the average scripter, not just someone with mad skills.)
I propose:
1) Whenever rand=, random_gender=, random_traits=, or generate_name= is used
in a context the engine can know isn't synchronized, two things happen: One,
it gives a result based on a *local* RNG state, so that the game doesn't
completely desync. Two, it issues a warning message - with a stacktrace -
unless the user also specifies "allow_desynced=yes" in the [set_variable] tag
or unit table that invoked it. The warning message would say something like
"Warning: Using {key=value} in a non-synchronized context. If you know what
you're doing, set allow_desynced=yes"
2) A lua attribute "wesnoth.synchronized" so that scripts can check the sync
state.
_______________________________________________________
Reply to this item at:
<http://gna.org/bugs/?21697>
_______________________________________________
Message sent via/by Gna!
http://gna.org/
_______________________________________________
Wesnoth-bugs mailing list
[email protected]
https://mail.gna.org/listinfo/wesnoth-bugs
