Polishing up unit animation WML (timings/halos/etc.)

[Coffee]

Hello all artists

EDIT: changed thread title from only dealing with timings as it is now dealing with halos and such as well. I do not intend this thread to be for making any new sprites, just polishing up existing animation code and such.

After recently doing some work on the animationWML syntax for 1.11 I noticed that some of the default units animation timings are out. What do I mean by this -- some of the timings for attacks do not match the unit movement offsets. For example, the ruffian/thugs line sound in 1.10 plays the sound to hit way before the graphics show the unit hitting an opponent. Another example might be a unit that plays its attack frame after it has fully moved towards an opponent and is then moving backwards. Another, probably rarer example, might be a unit that plays part of its animation too quickly or too slowly -- for example in defense so it plays after it was suppose to dodge or something like this.

I've had some help from Bumbadadabum in identifying units such as the ruffian/thug line, but I am sure there are plenty of others, and it would be good to get a list of problematic units with these kind of off timings so that they can be fixed -- making the game look as nice and polished as they were intended to. The new syntax allows easier access to smooth frame offsets as well, so if there is any jerkiness that is not intended with something, this can fix that too.

So to summarise (somehow my posts always end up longer than intended), please list any problem units with timing issues here and they will be looked into.

[H-Hour]

Do the problems exist in the 1.11.4 release, or should we only be looking if we have a more recent checkout of the repo?

[Astoria]

Do the problems exist in the 1.11.4 release, or should we only be looking if we have a more recent checkout of the repo?

We haven't really changed anything since 1.11.4, so if the problem is there it most likely also is in the latest HEAD.

[Coffee]

Although not terribly exiting, some work has gone into polishing up the animation WML code and timings since the last post here by bumbadadabum.

I have a small outstanding issue with the red mage and white mage lines though.

For the red mage line, the fireball appears to be coming out of the chest of the attacking unit. To the artists -- is this supposed to be like this?

For the white mage line, the attack appears not to be directed by the mage, but happening before any staff is raised, etc. Can we change this?

[thespaceinvader]

I don't see any particular problems with fixing these sorts of issues.

[zookeeper]

For the red mage line, the fireball appears to be coming out of the chest of the attacking unit. To the artists -- is this supposed to be like this?

It's been that way forever; back then all ranged attacks were simply a projectile going from the center of one hex to the other. It could definitely be changed so that the fireball appears for example at the point of the staff or above the mage's head (preferably as a new fireball macro which takes x,y starting coords as well). Since such a big projectile appearing out of nowhere in one frame probably also looks a bit weird, one could also use ~SCALE() to make it scale in during the first 100ms or so (I don't know if using it as a progressive parameter would be exceptionally costly performance-wise, though), or ~O() to make it fade in. There's a lot that can be done with IPF to enhance these sorts of effects.

For the white mage line, the attack appears not to be directed by the mage, but happening before any staff is raised, etc. Can we change this?

Sounds definitely like someone's messed up the timing sometime recently (it hasn't always been that way).

[Coffee]

...It could definitely be changed so that the fireball appears for example at the point of the staff or above the mage's head (preferably as a new fireball macro which takes x,y starting coords as well). Since such a big projectile appearing out of nowhere in one frame probably also looks a bit weird, one could also use ~SCALE() to make it scale in during the first 100ms or so (I don't know if using it as a progressive parameter would be exceptionally costly performance-wise, though), or ~O() to make it fade in.

I can put something together that does this, but I am not an artist so someone else would probably have to check it looks good. After doing some refactoring of the animation code for 1.11.2+ I wouldn't think that it would be costly at all as the movement is just an offset that is now calculated over a continous line and the appropriate image matched from a discrete set and scaled when needed. If the animation is sped up, AFAICT then it wouldn't do the scaling at all unless that frame is shown.

For the white mage line, the attack appears not to be directed by the mage, but happening before any staff is raised, etc. Can we change this?

Sounds definitely like someone's messed up the timing sometime recently (it hasn't always been that way).

Well, it could be me that stuffed things up with syntax changes -- but I checked 1.10.7 on slow motion and the beam definitely comes down before the staff is raised and such. To me it doesn't look quite right.

[Coffee]

In recent commits I've changed the white mage timing slightly and made a new fireball macro with my best effort to get what zookeeper suggested to work.

I've attached a video of the red mage line attack (skip the first 2 seconds of menus). The X and Y coordinates should start the fireball from the centre of the staff.

EDIT: bug fixed with westwards animations. Cheers Zookeeper.

[Astoria]

I've committed a new halo for the level 1 Malin Keshar in DiD. Thanks to Coffee for the idea to use ~O.

[Crow_T]

Speaking of Halos, I have a request: to reduce the illuminate halo transparency by about 50%, it's currently very obtrusive.

[Coffee]

Speaking of Halos, I have a request: to reduce the illuminate halo transparency by about 50%, it's currently very obtrusive.

An interesting suggestion. This has bothered me in playing before a bit.

Here's my suggestion for an artist to comment on:

That is to change the opacity of the illuminates-aura image under data/core/halos to an 80% opacity version. I've attached the image I used to produce the screenshots.

I figure the change is small enough not to cause any issues, and at the same time increase the visibility of surrounding hexes.

[Astoria]

This looks great. I was afraid this change would mess with other things that might use this halo, but it's really not big enough to cause any trouble. It does make a difference regarding visibility. I think it's good to commit, but it won't be bad to wait for an artist to comment.

[Crow_T]

Here I shrank it and opacity is 60% of stock Wesnoth.

I'm glad that this is up for discussion, the current aura hurts my head

[Astoria]

I think 60% might be overkill. Although the surrounding hexes are better visible, it's much harder to recognize the actual aura in your screenshot. Perhaps something like 70% would be the middle ground?

[Crow_T]

70%, and still shrank down a bit, plus a regular size (edit: the pixel density affects it) These are just examples for discussion :