anim picks wrong distance file

[devakm]

While testing many different animations, I've noticed that the automatic distance selection (which is supposed to pick the best jb2a file to match the distance from caster to target) is not working.

For example, standing 61ft away from target and using:

/anim ScorchingRay_01_Regular_Orange \\/wait 1000 \\/anim ScorchingRay_01_Regular_Orange_15ft

I get the same animation on both commands.

At 15ft away from target I get different results between the two using the command above. Autoselect used 05ft file.

The 15ft file seems to be the max it will pick until I move 77ft away and then I finally get the 30ft file.

Maybe this is intentional for some reason, but it results in poor quality results.

[crnormand]

Actually the "ft" suffix in the JB2A filename is a "guess". The /anim code actually looks at the size of the animation, and tries to determine the animation file that will the least amount of re-sizing to fit.

When you execute the animation, you get the diagnostic information:

And you can see the "Dist" determined between the source and target tokens as "578.6743471072481". And looking through the animations, the "5ft" animation is 600x400. The "15ft" animation is 1000x400, etc.

So it picks the 600 pixel wide animation.

Now, the biggest issue with animations is they don't completely fill the rectangle. The starting point of the animation is most likely NOT on the exact edge. And the destination of the animation is most likely NOT on the other edge (since you might like an explosion effect to surround the target).

So to do this, you need to add offsets to the /anim command. If you type /anim by itself you get a lengthy help message, but basically you need to add a starting "offset" and a "stretch" value.

For testing purposes, I set up the source token on the left, and the target is on the right. Start entering negative offset numbers (which can be from -1.0 to -0), will shift the start of the animation more and more to the left.

For me, -0.25 moves the animation back enough to just be outside the edge of the source token: /anim Sc*Ray_01_Reg*Orange -0.25

Now we need to stretch the animation so that it extends to the target token. Unfortunately, the "target" of the animation seems to be near the actual middle of the rectangle... so we have to stretch it a bit to get it to even touch the target token. Which, unfortunately, shifts the starting location.

I found: /anim Sc*Ray_01_Reg*Orange -0.4 +2 looks ok (but not great).

And this is a known weakness with our current /anim command. The image is actually getting larger when it is being stretched, and so, in the final analysis, one of the larger animations may have worked better, since even though the animation is 600 pixels wide, when being stretched and shifted, we might only be using 300 or less pixels. At which point, the 1000 pixel wide animation may have worked better.

I'll look into re-arranging the distance calc to take that into effect.

[crnormand]

YUP... that works a lot better. Now that I take the "stretch" factor into account, it is much better at selecting the appropriate animation.

Bummer... it will mess up people's current animations... hopefully not a lot. But oh well.. it has to be done.