bugBattle for Wesnoth - Bugs: bug #5720, Making some animations to play in...

Show feedback again

bug #5720: Making some animations to play in the background

Submitted by:  Lari Nieminen <zookeeper>
Submitted on:  Fri 07 Apr 2006 03:44:31 PM UTC  
Category: Feature RequestSeverity: 2 - Minor
Priority: 5 - NormalItem Group: Graphics
Status: NonePrivacy: Public
Assigned to: Jérémy Rosen <boucman>Open/Closed: Open
Release: trunkOperating System: 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)

Tue 31 Aug 2010 02:38:42 PM UTC, comment #8:

There's a strong argument that could be made that movement animations shouldn't be allowed to happen at the same time. Otherwise it's unclear which hexes are occupied and which are not, which unit moved the shroud, etc.

The FR is just for "some" animations to play in the background.

j.w. bjerk <eleazar>
Project Member
Sun 29 Aug 2010 08:05:30 AM UTC, comment #7:

it's pretty tricky from a UI pont of view...

the problem is that multiple animations could take place simultaneously and we need to keep WML events in the proper order, some of the happens before animations, some happen after, and they all need to look good.

this is esp tricky with mvt animations

Jérémy Rosen <boucman>
Project MemberIn charge of this item.
Sun 29 Aug 2010 01:14:17 AM UTC, comment #6:

1.9 has come and i still find it annoying to have to wait for the recruit animation to finish before i'm allowed to recruit/recall another unit.

j.w. bjerk <eleazar>
Project Member
Sat 02 Feb 2008 03:48:06 PM UTC, comment #5:

complete background anims is planned for 1.5

Jérémy Rosen <boucman>
Project MemberIn charge of this item.
Mon 21 Jan 2008 05:50:46 PM UTC, comment #4:

During the animation loop mouse events are still being processed the normal way by calling events::pump(). However most actions are blocked by the command_disabler. This is not "true" backgrounding, of course.

Martin Renold <martinxyz>
Project Member
Sun 20 Jan 2008 09:28:11 PM UTC, comment #3:

I don't see how this help...

the code is still stuck in the animation loop during the move...

unfortunately it will be very tricky to have mvt anims be real background anims. This is post 1.4 stuff anyhow

Jérémy Rosen <boucman>
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 Member
Sun 20 Jan 2008 10:52:12 AM UTC, comment #1:

From looking at the code, it already is possible to select a different unit during a move (or attack). This could trigger an event. Currently players never do this because they learned that their unit will get deselected after a move. I'm about to change this.

Martin Renold <martinxyz>
Project Member
Fri 07 Apr 2006 03:44:31 PM UTC, original submission:

While a recruited unit is fading in or when a unit is still moving, it's not possible to select another unit and issue orders to it, which makes playing much less fluid in non-accelerated mode, especially if there are lots of units to move. Such animations should not block UI actions, like selecting another unit, and should therefore be moved to play "in the background".

If an action (like moving, selecting, recruiting or capturing) will trigger an event, it can be known before the actual animation is started, and so if an event will trigger, then the animation can "block" UI actions like selecting another unit and moving it (like it does now whether an event triggers or not). This kind of behaviour is needed to prevent a situation where, for example, the player moves a unit into a location which triggers a name=moveto event, while at the same time selecting another unit which triggers a name=select event.

Lari Nieminen <zookeeper>
Project Member


(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 shadowmaster (Updated the item)
  • -unavailable- added by eleazar (Posted a comment)
  • -unavailable- added by boucman (Posted a comment)
  • -unavailable- added by martinxyz (Posted a comment)
  • -unavailable- added by zookeeper (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.


    Error: not logged in



    Follow 2 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Sun 29 Jan 2012 10:04:02 PM UTCshadowmasterStatusPostponed=>None
    Sat 02 Feb 2008 03:48:06 PM UTCboucmanStatusNone=>Postponed
    Show feedback again

    Back to the top

    Powered by Savane 3.1-cleanup