bugBattle for Wesnoth - Bugs: bug #20826, Unit does not level up after...

Show feedback again

bug #20826: Unit does not level up after gaining 1 EP, other player loses connection

Submitted by:  Mark W <w4rumy>
Submitted on:  Fri 17 May 2013 07:00:26 PM UTC  
Category: BugSeverity: 3 - Normal
Priority: 5 - NormalItem Group: Multiplayer
Status: FixedPrivacy: Public
Assigned to: Daniel <gfgtdf>Open/Closed: Closed
Release: 1.10.2Operating System: Ubuntu 12.04

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)

Sun 11 May 2014 10:08:47 PM UTC, comment #6:

accidently changed 'status' no none instead of 'assigned to'

Daniel <gfgtdf>
Project MemberIn charge of this item.
Fri 04 Apr 2014 03:41:48 PM UTC, comment #5:

the Behaviour in this case was changed in 8617a02a88a38d8fe01ee0a3672d75fc5fe72924.

Daniel <gfgtdf>
Project MemberIn charge of this item.
Tue 25 Jun 2013 12:39:49 AM UTC, comment #4:

OK, so what you presented as a "how-to" is really a "how-did". That is, it looked like directions for how to reproduce it, but it is really a description of how it occurred (once), with lots of details that might or might not be relevant. (Lots of details are good, but it's also important to know when they have not been investigated. Saying they "need to be done" is highly misleading.)

In that case, I would conjecture that a more accurate list for "Bug occurs" might be:
1) Player 2 disconnects (not due to the game, not a bug).
2) The unit now has 28/28 EP, but does not level up (the bug).
3) Player 2 is told that the connection is lost.

So the issue at hand would be what should happen when a player disconnects between initiating an attack and the unit gaining a level. Skipping the advancement doesn't seem right to me, even if it were a case where the unit had a choice of advancements.

J Tyne <jamit>
Project Member
Mon 24 Jun 2013 02:14:00 PM UTC, comment #3:

I did not try to reproduce it, because it would take very long for me as a player to get in this situation again. Therefore, I can't say if the settings affect this behavior. However, I attached a replay file where the bug occurs.

Mark W <w4rumy>
Mon 24 Jun 2013 05:02:55 AM UTC, comment #2:

If player 2 loses connection before sending info about what to level the unit into this is 'expected behaviour'. The client taking over the side should check all its units for this case.

Disclaimer: This is just from the top of my head, I did not look at the code.

Gunter Labes <soliton>
Project Member
Mon 24 Jun 2013 12:25:59 AM UTC, comment #1:

Was this a one-time occurrence or were you able to reproduce it (even if unreliably)?

Which set of default settings did you use? (Each map can have its own defaults.) You imply that changing any of the settings prevents this from happening -- is that something you actually tested, or is that just how you reproduced it?

J Tyne <jamit>
Project Member
Fri 17 May 2013 07:00:26 PM UTC, original submission:

Difficult to reproduce for a player, because the following conditions need to be done. However, a developer may finds it easier to reproduce it:
- Player 1 starts server, Player 2 connects. They play a battle together, with default settings. Player 1 plays Loyalists, Player 2 plays Elfes.
- After some rounds playing, player 2 has a unit with 27/28 EP. He attacks a level 1 unit of player 1.

Bug occurs:
- The unit now has 28/28 EP, but does not level up.
- Player 2 gets connection lost.

Mark W <w4rumy>


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

Attach File(s):

Attached Files
file #17975:  Bug_Report.gz added by w4rumy (24kB - application/x-gzip)
file #17976:  Bug_Report_Replay.gz added by w4rumy (12kB - application/x-gzip)


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 (Posted a comment)
  • -unavailable- added by w4rumy (Posted a comment)
  • -unavailable- added by soliton (Posted a comment)
  • -unavailable- added by jamit (Posted a comment)
  • -unavailable- added by w4rumy

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

    Date Changed By Updated Field Previous Value => Replaced By
    Sun 12 Oct 2014 12:18:08 PM UTCshadowmasterOpen/ClosedOpen=>Closed
    Sat 19 Jul 2014 10:01:17 PM UTCgfgtdfStatusReady For Test=>Fixed
      Assigned toNone=>gfgtdf
    Sun 11 May 2014 10:08:47 PM UTCgfgtdfStatusNone=>Ready For Test
      Assigned togfgtdf=>None
    Sun 11 May 2014 10:07:54 PM UTCgfgtdfStatusReady For Test=>None
    Thu 17 Apr 2014 05:00:44 PM UTCgfgtdfAssigned toNone=>gfgtdf
    Fri 04 Apr 2014 03:41:48 PM UTCgfgtdfStatusNone=>Ready For Test
    Fri 17 May 2013 07:01:11 PM UTCw4rumyCarbon-CopyRemoved 20543=>-
    Fri 17 May 2013 07:00:26 PM UTCw4rumyAttached File-=>Added Bug_Report.gz, #17975
      Attached File-=>Added Bug_Report_Replay.gz, #17976
      Carbon-Copy-=>Added w4rumy
    Show feedback again

    Back to the top

    Powered by Savane 3.1-cleanup