Submerge anim buggy in BfW 1.9.5

Having trouble with the game? Report issues and get help here. Read this first!

Moderators: Forum Moderators, Developers

Forum rules
Before reporting issues in this section, you must read the following topic:
Post Reply
Scaeb
Posts: 96
Joined: April 14th, 2011, 3:21 pm

Submerge anim buggy in BfW 1.9.5

Post by Scaeb »

Hi, related to the other bug reported (http://forums.wesnoth.org/viewtopic.php?f=4&t=33588), the visuals of [animation] ... submerge=... [/animation], when used with progressive float, are buggy.

OS: Mac OSX 10.5.8
BfW: 1.9.5 {English}
Reproducability: 100% (always)
Reproduction steps: Use a progressive float on submerge= (with a terrain filter; as documented in AnimationWML)
Effect: ugly graphical effect: main sprite is not animated, ellipse wiggles around crazily (even for high ms values).
stdout: nothing.

e.g. when

Code: Select all

submerge=0~1:500,1~0:500
or (differently)

Code: Select all

submerge 0~0.1:50,0.1~0:50
you'll see ugly effects, but not the desired ones.

Boucman
Inactive Developer
Posts: 2119
Joined: March 31st, 2004, 1:04 pm

Re: Submerge anim buggy in BfW 1.9.5

Post by Boucman »

Ok, I can reproduce, and it's quite tricky to solve.

I have fixed (locally) the infinite loop, but the animation doesn't work as it's supposed to. I'll look into it some more and keep you posted...
Fight key loggers: write some perl using vim

Scaeb
Posts: 96
Joined: April 14th, 2011, 3:21 pm

Re: Submerge anim buggy in BfW 1.9.5

Post by Scaeb »

You seem to know that section of code well.

Could you look into the other bug reported as well (see link in the first post)?
That other one actually freezes my Wesnoth.

Thanks!

Boucman
Inactive Developer
Posts: 2119
Joined: March 31st, 2004, 1:04 pm

Re: Submerge anim buggy in BfW 1.9.5

Post by Boucman »

Ok, the freeze is easy to fix, but I will probably mark the rest as "won't fix"

what's happening is that the duration of the submerge= line is longer than the duration of the animation as far as [frame] duration is concerned. In that case the [frame] take precedence, and thus the submerge part is shortened greatly (shortened to 0 in case of non-animated units)

Code: Select all

[standing_anim]
    start_time= -50
    terrain_type=Ww*,Chw,S*
    [frame]
      image="slau/boatman-Ww.png"
      # duration=50
    [/frame]
    submerge=0~1:50,1~0:50
  [/standing_anim]
here submerge is supposed to be up for 50ms then down for 50ms but [frame] has no duration. Add a duration of 100 and it should work properly.

This is not related to the terrain filter afaict, and the halo is supposed to go up and down with the submerge animation.

I'll commit a fix for the freeze, but could you test and report if this fixes your other issue ?
thx
Fight key loggers: write some perl using vim

Scaeb
Posts: 96
Joined: April 14th, 2011, 3:21 pm

Re: Submerge anim buggy in BfW 1.9.5

Post by Scaeb »

Thank you very much for picking this up as a bug, and thanks for the efforts made to fix it!

If I re-download the 1.9.5 devel version, will that be in there, or do I have to go via svn+build myself? (I haven't done that in years, and I don't think I'll go there now, lack of time to figure it all out and get it right).

The WIKI should say something about this relationship you describe. It's particularly intransparent, as the overall duration of the animation (on which, appearantly the submerge progressive float depends) is not even a single value, but the sum of the duration values of potentially several frames! --> maybe change WML syntax or the progressive float synchronization (by the latest for 1.10.x)?

Boucman
Inactive Developer
Posts: 2119
Joined: March 31st, 2004, 1:04 pm

Re: Submerge anim buggy in BfW 1.9.5

Post by Boucman »

no, you have to go the svn route or wait for 1.9.6 to come out eventually...

there is nothing special with progressive float (compared to other progressive params, just to make clear)

however it's true that the duration of an animation is calculated in a complicated way. it's the sum of the duration of each frame, I'm not sure how each frame's duration is calculated, though. IIRC it's either the duration if it is specified or the longest progressive param within the frame if it isn't....

and yes the documentation isn't very clear, i'll have a look...
Fight key loggers: write some perl using vim

Post Reply