bugBattle for Wesnoth - Bugs: bug #7132, The movement ranges / unit...

Show feedback again

bug #7132: The movement ranges / unit selection dismissed after an attack

Submitted by:  None
Submitted on:  Thu 21 Sep 2006 10:36:21 PM UTC  
Category: BugSeverity: 3 - Normal
Priority: 5 - NormalItem Group: User Interface
Status: FixedPrivacy: Public
Assigned to: Martin Renold <martinxyz>Originator Email: -unavailable-
Open/Closed: ClosedRelease: 1.1.10
Operating System: linux (all?)

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 20 Jan 2008 01:38:48 PM UTC, comment #15:

Fixed in SVN. You can select a unit and move the mouse to the destionation. But currently you have to wait with the final click that starts the next move/fight until the current is done. But this will not slow down your gameplay much because you have to wait that long anyway.

Please open a separate bug for the start-of-turn issue if it still exists and is annoying.

Martin Renold <martinxyz>
Project MemberIn charge of this item.
Sun 20 Jan 2008 01:12:14 PM UTC, SVN revision 23096:
  • deselect units before moving, not after moving
  • allow to prepare next move during move/fight
  • fine-tuned mouse code

fixes bug #6311, bug #7132 and partially bug #5720
makes bug #7028 more visible

(Browse SVN revision 23096)

Martin Renold <martinxyz>
Project MemberIn charge of this item.
Fri 16 Nov 2007 05:45:00 PM UTC, comment #13:

BenUrban says this bug is still present in 1.3.x, so I've updated the version field rather than marking it Wont Fix.

Eric S. Raymond <esr>
Project Member
Fri 10 Aug 2007 05:10:48 PM UTC, comment #12:

Boucman & alink, my two favourite coding heroes! I'm sure you'll find a solution. :-)

Boucman: In this report so far you've been talking with one anonymous person only.


I re-confirmed comment #9 today (selection dismissed at start of my turn).

Fri 10 Aug 2007 03:41:33 PM UTC, comment #11:

@ boucman : yes I have maybe idea about how to fix it. I am in this area of the code for the moment, i will look at it again. The problem is that i must also check/combine with the lost of the footsteps path, bug #6311 (for the moment i think i will try to fix the path, but allow+keep new selection of unit).

I didn't really start to code about this, it's just to say that i think about this bug when cleaning the mouse code ;-)

Ali El Gariani <alink>
Project Member
Fri 10 Aug 2007 03:07:15 PM UTC, comment #10:

no worry, it's just that I like to know if I am talking to a single of to multiple people...

Jérémy Rosen <boucman>
Project Member
Mon 06 Aug 2007 07:19:23 PM UTC, comment #9:

Boucman: I appreciate the anonymity, but apologise for the inconvenience caused to you. Despite the anonymity, I try to keep my input meaningful.


One thing I noticed today (similar phenomenon, possibly due to the same or an other cause) was that also at my turn's start, when I had a unit (my own unit) selected, the unit selection was dismissed, if I can trust my observation. (I didn't test for it thoroughly.)

Mon 06 Aug 2007 12:59:01 PM UTC, comment #8:

Btw, Anonymous...

if you had a Gna logging, I would appreciate if you logged in whenever possible,

it's hard to me to know how many people I am talking to in bugs when talking to anonymous...

Jérémy Rosen <boucman>
Project Member
Mon 06 Aug 2007 12:57:19 PM UTC, comment #7:

Alink, do you have any idea about this ? could this easily be changed ?

I could provide you some clues about the anim code, if you need (just use my mail)

Jérémy Rosen <boucman>
Project Member
Sat 04 Aug 2007 07:42:42 AM UTC, comment #6:

Boucman: For what it's worth, this is a regression from earlier versions. Testing with version 0.8 (to pick a random old version that was sufficiently free of bugs), there unit-selection is, in fact, disabled (i.e. blocked), until the first move has completed.

That way is preferable to allowing the player to select a unit and then dismissing that selection.

Can you revert this to "none", please, so this can perhaps be addressed somehow?

Sat 04 Aug 2007 07:20:13 AM UTC, comment #5:

I play fast, or then slow, depending on my mood.

The problem with this bug is that you get to select a unit, and then the game throws your selection away. It's not very good UI.

I can appreciate the fact that it may be hard to fix. However, even completely disabling the (mouse-)selection of the next unit until the first move has been completed, which would be a rather clumsy solution, would probably still be preferable to the current behaviour.

In other words, I think this is a legitimate issue. You're the animation expert, so... is there anything at all that can be done to address this?

Fri 03 Aug 2007 06:23:04 PM UTC, comment #4:

if you want to play fast, use turbo, having order "stack would be too complicated to implement properly

if your bug is about a loss of unit focus, drop me a note, and I'll reopen the bug

Jérémy Rosen <boucman>
Project Member
Sun 25 Mar 2007 08:01:24 AM UTC, comment #3:

See also bug #8792 ("Current unit loosing focus after the previous unit complets it's move").

Fri 22 Sep 2006 12:02:40 PM UTC, comment #2:

Well, true, the concern is the same. I wonder, though, if this is possible to fix for simple attacks, i.e. attacks not dismissing a previous choice of unit.

Sorry that I can't test right now how it was in 1.0.2, i.e. whether this is a regression, or whether it has always been like this.

Fri 22 Sep 2006 07:22:06 AM UTC, comment #1:

The "drag for gameplay" concern is pretty much the same as in bug #5720 (which is a bit more generic).

Lari Nieminen <zookeeper>
Project Member
Thu 21 Sep 2006 10:36:21 PM UTC, original submission:

If you choose a unit while an attack is ongoing, your choice is effectively ignored after the attack ends. You can't click to move, you can't click to attack. The game simply refuses to take your click until you choose the unit again.

This is a major drag for the gameplay, and would be nice to get fixed before 1.2.

This is probably related to bug #7028, which manifests itself a bit differently, or may even be the same bug.



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

Attach File(s):

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 martinxyz (Posted a comment)
  • -unavailable- added by esr (Posted a comment)
  • -unavailable- added by soliton (Updated the item)
  • -unavailable- added by alink (Posted a comment)
  • -unavailable- added by boucman (Posted a comment)
  • -unavailable- added by zookeeper (Posted a comment)

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

    Date Changed By Updated Field Previous Value => Replaced By
    Sun 27 Jan 2008 11:30:37 PM UTCesrOpen/ClosedOpen=>Closed
    Sun 20 Jan 2008 01:38:48 PM UTCmartinxyzStatusNone=>Fixed
      Assigned toalink=>martinxyz
    Fri 16 Nov 2007 05:45:00 PM UTCesrRelease1.1.10=>1.3.x
    Sun 09 Sep 2007 03:43:11 PM UTCsolitonSeverity4 - Important=>3 - Normal
    Mon 06 Aug 2007 12:57:19 PM UTCboucmanStatusWont Fix=>None
      Assigned toNone=>alink
    Fri 03 Aug 2007 06:23:04 PM UTCboucmanStatusNone=>Wont Fix
    Show feedback again

    Back to the top

    Powered by Savane 3.1-cleanup