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 May 17 19:00:26 2013  
 
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 May 11 22:08:47 2014, comment #6:

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

Daniel <gfgtdf>
Project MemberIn charge of this item.
Fri Apr 4 15:41:48 2014, comment #5:

the Behaviour in this case was changed in 8617a02a88a38d8fe01ee0a3672d75fc5fe72924.

Daniel <gfgtdf>
Project MemberIn charge of this item.
Tue Jun 25 00:39:49 2013, 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 Jun 24 14:14:00 2013, 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 Jun 24 05:02:55 2013, 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 Jun 24 00:25:59 2013, 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 May 17 19:00:26 2013, 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):
   
   
Comment:
   

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 Oct 12 12:18:08 2014shadowmasterOpen/ClosedOpen=>Closed
    Sat Jul 19 22:01:17 2014gfgtdfStatusReady For Test=>Fixed
      Assigned toNone=>gfgtdf
    Sun May 11 22:08:47 2014gfgtdfStatusNone=>Ready For Test
      Assigned togfgtdf=>None
    Sun May 11 22:07:54 2014gfgtdfStatusReady For Test=>None
    Thu Apr 17 17:00:44 2014gfgtdfAssigned toNone=>gfgtdf
    Fri Apr 4 15:41:48 2014gfgtdfStatusNone=>Ready For Test
    Fri May 17 19:01:11 2013w4rumyCarbon-CopyRemoved 20543=>-
    Fri May 17 19:00:26 2013w4rumyAttached 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