Turret attacking_animation speed?

[Deadlock989]

For turrets like the gun turret which have an attacking_animation layer in stripes (e.g. a rotating gun barrel), the animation_speed property seems to be ignored. For the the life of me, I can't seem to get an animation which doesn't alternate every frame, and I can't get it to use more than the first two frames - if I supply three frames per direction, it just alternates the first two every frame, which just results in a blur. Is this hard-coded behaviour or am I missing something?

I guess my question is, how is the animation speed derived for this turret property?

[posila]

What values have you tried?

Turrets work like following (I don't know exactly why it's not done same way as animations in other entities):

Code: Select all

// in update:
animation_progress = min(animation_progress + animation_speed, 1);
if (animation_progress == 1)
  move_to_next_state(); // resets animation_progress to 0
  
// in render:
frame_index = min(animation.frame_count * animation_progress, animation.frame_count - 1)

So if you have attacking animation with 3 frames and attacking_speed = 1/3, it should show each frame for one tick.

[Deadlock989]

So if you have attacking animation with 3 frames and attacking_speed = 1/3, it should show each frame for one tick.

Thanks, that was what I was missing. I assumed that attacking_speed was to do with the actual rate of fire.

[posila]

Speaking of rate of fire ... the animation lenght has an effect on how fast the turret can shoot. It loops through states Prepared -> StartingAttack -> Attacking -> EndingAttack -> Prepared and each of the states can have an animation, and the turret shoots only at the end of the Attacking state and only once. We ran into this recently when working on tooltips.

[Deadlock989]

Speaking of rate of fire ... the animation lenght has an effect on how fast the turret can shoot. It loops through states Prepared -> StartingAttack -> Attacking -> EndingAttack -> Prepared and each of the states can have an animation, and the turret shoots only at the end of the Attacking state and only once. We ran into this recently when working on tooltips.

... Dammit. The turret in question can go up to 30 shots a second when its ammo rate of fire research is maxed, i.e. one bullet every two ticks. So capping the animation speed to show three frames is going to nerf the attack speed?

[posila]

Correct. I'll put to my todo to see if option that would override that can be added.

[Deadlock989]

Correct. I'll put to my todo to see if option that would override that can be added.

Thanks. I can see why it would be useful to link the tick-of-firing to the animation in some cases - cannon recoil etc. - but there are other situations like this one where it's a big limitation (and as you say, makes the rate-of-fire tooltip info wrong).

[Honktown]

Correct. I'll put to my todo to see if option that would override that can be added.

Might it be wise to tie the animation speed to the firing rate? A naive assumption would be you increase the firing rate, it animates faster. Depending on optimizations this might not be possible, but like I said, naive assumption.

[Deadlock989]

Might it be wise to tie the animation speed to the firing rate? A naive assumption would be you increase the firing rate, it animates faster. Depending on optimizations this might not be possible, but like I said, naive assumption.

You post too much.

[Deadlock989]

Correct. I'll put to my todo to see if option that would override that can be added.

Would an option here revolve around (optionally) using the max_advance property? Vehicles like cars use this in sheets definitions to cap the advancement of frames per tick. I tested it on a turret that fires more rounds per second than the frame rate set by attacking_speed would allow, it doesn't currently work, whereas on a car animation it nicely caps the frame rate for you.

[posila]

animation_speed and max_advance are completely ignored. max_advance is only ever considered if an entity stores exact frame counter;
But lot of times animation is played based on the tick (and possibly small random offset, or even the "random" offset is calculated from drawing position), in which case only animation_speed applies. Crafting machines use variation of this where it's counting how much work it did, and base off of that frame indices for animation and working visualizations are calculated (that way animation can change speed, and there is only one counter for many animations on single machine, but they don't all need to play in-sync).

Turrets are completely different in that they are a state machines, where you could look at it as state transition having some durating, during which animation is played (base off of the percentage of transition duration that already passed). When transition finishes, the turret does something (based off of a state it just transitioned into) and then starts transition to the next state. So for it to be able to play animation longer than duration of its state transition, it needs to be changed.

(In code snippet I posted before, animation_speed is not animation_speed in animation definition, but "turret_state"_speed property of turret: attacking_speed, ending_attack_speed, prepared_speed, starting_attack_speed, ... etc.)