bugBattle for Wesnoth - Bugs: bug #20871, [unstore_unit] advance=true still...

 
 
Show feedback again

bug #20871: [unstore_unit] advance=true still not always MP-safe

Submitted by:  Eli Dupree <elvish_pillager>
Submitted on:  Thu 06 Jun 2013 01:18:04 AM UTC  
 
Category: BugSeverity: 3 - Normal
Priority: 5 - NormalItem Group: WML
Status: FixedPrivacy: Public
Assigned to: Daniel <gfgtdf>Open/Closed: Closed
Release: 1.10.6Operating 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.

 

Fri 04 Apr 2014 03:34:57 PM UTC, comment #4:

Fixed in 8617a02a88a38d8fe01ee0a3672d75fc5fe72924. In 1.13.0-dev.
I didn't test it with unsotre unit but luas sync_choice during attack.. events.

Daniel <gfgtdf>
Project MemberIn charge of this item.
Sat 03 Aug 2013 06:35:33 PM UTC, comment #3:

i did some testing and found out that the error appears in attacker_hits as well and also with other things besides advancements for example wesnoth.synronizize_choice lua function. seems like currently the attack related events are
all mp unsafe.

i removed the attack events from the list of mp safe events in the wiki.

Anonymous
Thu 25 Jul 2013 07:36:26 PM UTC, comment #2:

EDIT: i have the same problem on 11.2

Anonymous
Thu 25 Jul 2013 02:03:55 PM UTC, comment #1:

i have the same problem

Anonymous
Thu 06 Jun 2013 01:18:04 AM UTC, original submission:

[unstore_unit] has been reported as MP-unsafe before, and "fixed"

https://gna.org/bugs/?func=detailitem&item_id=15560
https://gna.org/bugs/?func=detailitem&item_id=11359

The situations in those posts have been fixed. But in attack and attack_end events (at least), it is still broken.

[event]
name=attack end
[message]
message=test
[/message]
[store_unit]
[filter]
side=1
[/filter]
variable=foo
[/store_unit]
{VARIABLE foo.experience 800}
[unstore_unit]
variable=foo
advance=true
fire_event=true
[/unstore_unit]
[/event]

Insert this into any MP scenario and attack. The first error is "choice expected but none found".

The same code also causes sync errors if put in an "attack" event, but it's fine in a "side turn" event (and probably in most other synchronized events).

The error doesn't seem to change based on whether the unit being modified is involved in the attack or not - it's just the fact that it advanced during an attack_end or attack event at all that causes the problem.

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 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 7 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Wed 23 Apr 2014 12:48:10 AM UTCshadowmasterOpen/ClosedOpen=>Closed
    Thu 17 Apr 2014 02:01:14 AM UTCgfgtdfOpen/ClosedClosed=>Open
    Sat 12 Apr 2014 08:20:16 PM UTCgfgtdfOpen/ClosedOpen=>Closed
      Discussion LockLocked=>Unlocked
    Fri 04 Apr 2014 03:34:57 PM UTCgfgtdfStatusNone=>Fixed
      Discussion LockUnlocked=>Locked
    Tue 25 Mar 2014 03:25:04 PM UTCgfgtdfAssigned toNone=>gfgtdf
    Show feedback again

    Back to the top


    Powered by Savane 3.1-cleanup