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 Sep 21 22:36:21 2006  
 
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 Jan 20 13:38:48 2008, 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 Jan 20 13:12:14 2008, 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 Nov 16 17:45:00 2007, 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 Aug 10 17:10:48 2007, 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).

Anonymous
Fri Aug 10 15:41:33 2007, 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 Aug 10 15:07:15 2007, 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 Aug 6 19:19:23 2007, 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.)

Anonymous
Mon Aug 6 12:59:01 2007, 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 Aug 6 12:57:19 2007, 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 Aug 4 07:42:42 2007, 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?

Anonymous
Sat Aug 4 07:20:13 2007, 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?

Anonymous
Fri Aug 3 18:23:04 2007, 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 Mar 25 08:01:24 2007, comment #3:

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

Anonymous
Fri Sep 22 12:02:40 2006, 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.

Anonymous
Fri Sep 22 07:22:06 2006, 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 Sep 21 22:36:21 2006, 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.

Anonymous

 

(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 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 Jan 27 23:30:37 2008esrOpen/ClosedOpen=>Closed
    Sun Jan 20 13:38:48 2008martinxyzStatusNone=>Fixed
      Assigned toalink=>martinxyz
    Fri Nov 16 17:45:00 2007esrRelease1.1.10=>1.3.x
    Sun Sep 9 15:43:11 2007solitonSeverity4 - Important=>3 - Normal
    Mon Aug 6 12:57:19 2007boucmanStatusWont Fix=>None
      Assigned toNone=>alink
    Fri Aug 3 18:23:04 2007boucmanStatusNone=>Wont Fix
    Show feedback again

    Back to the top


    Powered by Savane 3.1-cleanup