How to prevent animation when unit moves only 1 hex

[Helmet]

I made a custom "running" animation for a bug. The animation looks fine when the bug moves 2 or more hexes. Unfortunately, the animation looks odd when the unit moves only 1 hex. Consequently, I would prefer that the unit not employ its running animation when simply moving 1 hex. How would I do that? Thanks.

[Pilauli]

What sort of running animation? If the movement animation contains any sort of one-time wind-up effect, you could use a pre-movement animation.

Otherwise, of course, looking at what the wiki says about animations is a good starting point. I'll pick out the part that looks most useful:

value= contains the number of steps already taken

value_second= contains the number of steps left

This process seems to work:

• Leave your current movement animation working normally.

• Add another animation with more specific filters so it only happens when the unit is moving only one hex.

  Code: Select all

  [movement_anim]
  	value=0
  	value_second=0
  	[frame]
  		image= # the normal baseframe or whatever else you want in your short movement frame
  		duration=200
  	[/frame]
  [/movement_anim]
  

[Helmet]

Thanks, Pilauli. My animated unit has a pre-movement animation and a post-movement animation, in addition to the usual running animation. That's why it looks odd when it only moves one hex. There's a lot of motion for such little travel.

Your code was an improvement. Thanks for writing it. Your code stopped the main "running" animation, but it didn't stop the pre-movement and post-movement animation. The bug-unit is still animated, therefore, but not as much. It looks much better now, I think.

I don't see anything in the Wiki about how to stop the pre-movement animation and post-movement animation when moving one hex. That would be ideal.

[Pilauli]

It looks like the pre- and post-movement animations don't use value= and value_second=, so there's probably no way to make those animations situational.

Depending on what your pre- and post-movement animations are, would it work to change them into alternate movement animations? (I mean, would it look okay if the unit did them while moving?) If so, then you could probably replace the pre-/post-movement animations with movement anims like this:

Code: Select all

[movement_anim]
	value=0
	# Frames for a modified pre-movement animation
[/movement_anim]
[movement_anim]
	value_second=0
	# Frames for a modified post-movement animation
[/movement_anim]

That ought to provide the following conditions and results (remember that if multiple animations could fit a situation, WML takes the animation which is most specifically defined for the situation:
Unit is starting and finishing a journey at the same time (only moving 1 hex):
--> the first animation I suggested (previous post)
Unit is starting but not finishing a journey:
--> the first animation suggestion in this post
Unit is finishing but not starting a journey:
--> the second animation suggestion in this post
None of the above:
--> the default/unfiltered movement animation

If your pre- and post-movement animations wouldn't work as regular movement animations, or if my suggested code doesn't work, then I don't know what else to do.

(As an example of a potentially-incompatible pre-movement animation, if your pre-movement animation includes crouching and then jumping into the air, like Drakes do, then doing it while moving would look quite odd. On the other hand, an alternate method of taking off - like running along the ground a little bit to gather speed before taking off - might work just fine as part of a movement animation.)

And thinking about this gives me ideas about how to implement a unit that I've had in my head for a bit, so it's helpful that your question prompted me to think about it. Thanks!

[Helmet]

That's a good idea, I'm going to keep it in mind for any future animations, but I don't think it can be applied to this unit. Basically, the bug-unit curls into a ball, rolls to its destination hex, then uncurls.

Yes, my animated unit is a giant roly poly.

roly_poly-standing.png (5.8 KiB) Viewed 425 times

And thinking about this gives me ideas about how to implement a unit that I've had in my head for a bit, so it's helpful that your question prompted me to think about it. Thanks!

Hey, you're welcome!

[Pilauli]

Cool!

How long is your pre-movement curling up animation? It's actually possible to change the speed it moves across the screen at, something like this:

Code: Select all

[movement_anim]
    value=0 # only play this animation when beginning to move
    offset="0:50,0~1:150" # hold still for 50ms, then move across the screen slightly faster than normal for 150ms

    # frames to spend 50ms curling up
    
    # frames to spend 150ms rolling
    
[/movement_anim]

I did some very crude testing, and reached the conclusion that trying to cram 200ms worth of movement in only 100ms doesn't look good, but putting 200ms' movement in 150 ms looks mostly okay.

Especially if your curling up animation has it hunch its front up, then push off with its tail, I think might work. (Because logically, it wouldn't take very long to hunch up, and then pushing off would make it start with more momentum.)

[Helmet]

The pre-movement animation is one frame at 250; it shows the roly poly in mid-curl. The post movement animation is a slightly different image for uncurling. It is one frame at 125. The running animation is a spinning ball, three frames, 150, 150, 150.

Right now, when the roly poly moves only 1 hex -- so minus the running animation -- it hunches up, then straightens out to it's normal length. It's an odd sort of movement, I guess. It kind of looks like an inchworm movement. But it's quick and fairly subtle. I may add another frame to post movement before adjusting the timing with your tip, to smooth out the transition. That might help.