Allow for scheduling actions during animations (GNA #5720) about wesnoth HOT 16 OPEN

Modified on 2008-01-20

martinxyz wrote:

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.

from wesnoth.

Modified on 2008-01-20

boucman wrote:

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

from wesnoth.

Modified on 2008-01-21

martinxyz wrote:

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.

from wesnoth.

Modified on 2008-02-02

boucman changed status: None -> Postponed

boucman wrote:

complete background anims is planned for 1.5

from wesnoth.

Modified on 2010-08-28

eleazar wrote:

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.

from wesnoth.

Modified on 2010-08-29

boucman wrote:

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

from wesnoth.

Modified on 2010-08-31

eleazar wrote:

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.

from wesnoth.

Modified on 2012-01-29

shadowmaster changed status: Postponed -> None

from wesnoth.

The underlying issue behind the request doesn't appear to be an issue in 1.14 - recruitment/recalling doesn't block animations such as unit idle animations and village flag waving, nor does it block selection of other units. Not that I could tell, anyway.

@ln-zookeeper Is this one of yours?

from wesnoth.

@Wedge009 It's possible to select unit B while unit A is moving, but it's not possible to issue orders to unit B until unit A has finished moving. For example:

1. Create three Gryphon Masters
2. Select one of them
3. Click on a hex that's 10 hexes away from the selected unit
4. The unit starts moving. Before it reaches its destination, select another Gryphon Master and click on an empty hex.

In step 4, the selection succeeds but clicking on a empty hex does nothing. It could, instead, schedule a move to after the current move finishes... and, I guess, if the original move triggers an event (say, moveto), then the scheduled moves could be canceled, same as the "Cancel pending actions" setting in the Load Game dialog.

from wesnoth.

Ah, okay. I understand the issue better with the instructions given. Confirmed in 1.14.7.

from wesnoth.

Given things can happen in moveto, enter_hex, and exit_hex events, being able to move multiple units at the same time seems undesirable.

from wesnoth.

Given things can happen in moveto, enter_hex, and exit_hex events, being able to move multiple units at the same time seems undesirable.

Well maybe if Wesnoth detects that there are possible events of such type in the scenario code, it could transform the cursor into a little "🚷" symbol (and prevent clicking) while hovering over units while another is moving, but otherwise, if there are no such events, it could allow them? I personally have wished to be able to get other moves started while current move animations are still playing myself, personally...

from wesnoth.

Given things can happen in moveto, enter_hex, and exit_hex events, being able to move multiple units at the same time seems undesirable.

In theory this could be implemented in a way that ordered tasks are just intererrupted when such an event occurs, similar to how currently sighted events interrupt the current movement.

The plan by the third post and which i think is also the plan of the first post, is a bit difference since it is to run the animations asynchronously from the event executions, meaning that the animations are queued and that the event execution thus happens immidiateley (since they don't have for the animation to end), such an implementation would sure have its advantages, but i imagine it to be very difficult to implement since its simply just a huge change.

from wesnoth.

I was thinking about situations like:

• Unit 1 moves.
• While Unit 1 is moving, Unit 2 is selected and starts moving somewhere else.
• Unit 1 reaches the hex at the end of its movement, which triggers a moveto event that is supposed to kill any unit on the hex that Unit 2 started on, or changes the terrain that Unit 2 needs to move through, etc.

You'd essentially need to know beforehand if any event triggered by the first unit's movement would possibly have any effect on the second unit or its movement.

from wesnoth.

The units wouldn't really move at the same time, the issue is just about "scheduling" the move, the actual movement wouldn't start after the first move is finished if i undestood the request correctly.

from wesnoth.