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

 
 
Show feedback again

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

Submitted by:  Eli Dupree <elvish_pillager>
Submitted on:  Thu 20 Feb 2014 12:59:16 AM UTC  
 
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

Add a New Comment (Rich MarkupRich Markup):
   

You are not logged in

Please log in, so followups can be emailed to you.

 

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

Thu 17 Apr 2014 12:02:03 AM UTC, comment #6:

ok the last part is now fixed in 11c33d6e44743c5d0967e1d842820d9dba5a77f1

Daniel <gfgtdf>
Project MemberIn charge of this item.
Sat 15 Mar 2014 07:11:41 PM UTC, comment #5:
Daniel <gfgtdf2>
Tue 11 Mar 2014 07:46:25 PM UTC, 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 11 Mar 2014 07:33:37 PM UTC, 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 11 Mar 2014 07:30:38 PM UTC, 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 11 Mar 2014 06:57:19 PM UTC, 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"

Anonymous
Thu 20 Feb 2014 12:59:16 AM UTC, 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>

 

(Note: upload size limit is set to 1024 kB, after insertion of the required escape characters.)

Attach File(s):
   
   
Comment:
   

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.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 6 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Wed 23 Apr 2014 12:51:31 AM UTCshadowmasterOpen/ClosedOpen=>Closed
    Thu 17 Apr 2014 02:00:44 AM UTCgfgtdfOpen/ClosedClosed=>Open
    Thu 17 Apr 2014 12:02:03 AM UTCgfgtdfStatusNone=>Fixed
      Open/ClosedOpen=>Closed
    Mon 17 Mar 2014 03:27:51 PM UTCgfgtdfAssigned togfgtdf2=>gfgtdf
    Sat 15 Mar 2014 07:11:41 PM UTCgfgtdf2Assigned toNone=>gfgtdf2
    Show feedback again

    Back to the top


    Powered by Savane 3.1-cleanup