bugBattle for Wesnoth - Bugs: bug #21697, MP synchronization not tracked...

Show feedback again

You are not allowed to post comments on this tracker with your current authentification level.

bug #21697: MP synchronization not tracked well, creates minefield for add-on designers

Submitted by:  Eli Dupree <elvish_pillager>
Submitted on:  Thu Feb 20 00:59:16 2014  
Category: BugSeverity: 3 - Normal
Priority: 5 - NormalItem Group: Networking
Status: FixedPrivacy: Public
Assigned to: Daniel <gfgtdf>Open/Closed: Closed
Release: 1.11.9+devOperating System: Debian Linux

(Jump to the original submission Jump to the original submission)

Thu Apr 17 00:02:03 2014, comment #6:

ok the last part is now fixed in 11c33d6e44743c5d0967e1d842820d9dba5a77f1

Daniel <gfgtdf>
Project MemberIn charge of this item.
Sat Mar 15 19:11:41 2014, comment #5:
Daniel <gfgtdf2>
Tue Mar 11 19:46:25 2014, comment #4:

For random numbers in ability filters specifically, it is probably wrong to use them, but if my ability filter is complicated and calls other parts of my code, and one of those parts uses random numbers, I want to see that as a warning message right away rather than having it show up as an unexplained combat OOS several turns later.

For random numbers in synchronize_choice (which is legitimate), it's possible to use math.random currently, but it would be nice (and less confusing for add-on developers) to be able to use the same syntax as for synced random numbers.

Eli Dupree <elvish_pillager>
Tue Mar 11 19:33:37 2014, comment #3:

Another one: You could have a complex menu that allows you to create and customize a unit (possibly with some legitimately random elements), then passes the unit to the other players as the return value of wesnoth.synchronize choice.

Eli Dupree <elvish_pillager>
Tue Mar 11 19:30:38 2014, comment #2:

Simple: For some filter, I have a unit table (not a proxy unit) and I want to check its movement cost on a particular hex using wesnoth.unit_movement_cost. So I make a proxy unit with wesnoth.create_unit(), but that (by default) desyncs the RNG.

Eli Dupree <elvish_pillager>
Tue Mar 11 18:57:19 2014, comment #1:

so you want to be able to call random or [unit] from lua filters?
the nomral rule is that you shall not change the gamestate during an (possibly) unsynced event, which [unit] normaly does.
i argee that wesnoth.synchronized would be a useful feature, but could you please give an example where "lua functions can be invoked during ability filters, which can happen at arbitrary times in the middle of other events"

Thu Feb 20 00:59:16 2014, original submission:

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.

Eli Dupree <elvish_pillager>


No files currently attached


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -unavailable- added by shadowmaster (Updated the item)
  • -unavailable- added by gfgtdf (Updated the item)
  • -unavailable- added by gfgtdf2 (Posted a comment)
  • -unavailable- added by elvish_pillager (Submitted the item)

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.


    Error: not logged in



    Follow 6 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Wed Apr 23 00:51:31 2014shadowmasterOpen/ClosedOpen=>Closed
    Thu Apr 17 02:00:44 2014gfgtdfOpen/ClosedClosed=>Open
    Thu Apr 17 00:02:03 2014gfgtdfStatusNone=>Fixed
    Mon Mar 17 15:27:51 2014gfgtdfAssigned togfgtdf2=>gfgtdf
    Sat Mar 15 19:11:41 2014gfgtdf2Assigned toNone=>gfgtdf2
    Show feedback again

    Back to the top

    Powered by Savane 3.1-cleanup