Undocumented fields in module_animations.py

Users who are viewing this thread

["reload_crossbow", 0, amf_priority_reload|amf_use_weapon_speed|amf_play,
  [1.0, "anim_human", combat+1700, combat+1750, arf_blend_in_8|arf_make_custom_sound, pack2f(0.40, 0.94)],
],
["horse_pace_4", acf_enforce_lowerbody, amf_use_cycle_period|amf_client_prediction,
  [0.5, "anim_horse", 150, 165, arf_cyclic|arf_use_walk_progress|arf_make_walk_sound,pack4f(0.4,0.31,0.79,0.94), (0, 0, 0), 0.2],
],
Does anyone know what the values in pack2f and pack4f represent?
In both cases they are related to sound; I think the two values in the first example mean that the first sound (snd_reload_crossbow) will be played 40% into the animation and the second sound (snd_reload_crossbow_continue) will be played 94% into the animation. Inverting them inverts the sounds played.
I'm not sure about the values in pack4f though... is it the same, just for 4 separate sounds? Or is it something else?

The functions (pack2f and pack4f) themselves are unimportant, they are merely used to store the values in a format the game engine expects.

Also, what about that 0.2 in the end? I have no clue on that one.
 
I'd think that the (0,0,0) is for a 3d position but that is just a guess. Also, it looks like it is in a trigger format so the first number in the brackets is the check interval and the 0.2 is a rearm interval. Try testing my theory out.
 
ithilienranger said:
I'd think that the (0,0,0) is for a 3d position but that is just a guess.
That's the displacement offset (used together with acf_displace_position). I was asking about the values before and after it (the ones highlighted in red and blue).
ithilienranger said:
Also, it looks like it is in a trigger format so the first number in the brackets is the check interval and the 0.2 is a rearm interval. Try testing my theory out.
Just because there are decimal numbers it doesn't have to be a trigger. :grin:
And no, it's not. It's just a regular entry in the animations list.
MadocComadrin said:
Actually, it looks like a python function to me. Try checking out header_animations or process_animations for more info.
Err...
cmpxchg8b said:
The functions (pack2f and pack4f) themselves are unimportant, they are merely used to store the values in a format the game engine expects.
 
Some other people may be curious  :oops:  :wink: Anyway...


Yep, I was right! These two functions are defined in header_animations. They take a number of floating point numbers, encode them into integers, then use those integers to make a bit-mask (by shifting and ORing).

Code:
def get_byte(f):
  if f == 0.0:
    return 0
  i = int(f * 255.0)
  if (i< 1):
    i=1
  elif (i > 255):
    i = 255
  return i

def pack2f(a,b):
  ai = get_byte(a)
  bi = get_byte(b)
  return ((bi << 8) | ai)

def pack4f(a,b,c,d):
  ai = get_byte(a)
  bi = get_byte(b)
  ci = get_byte(c)
  di = get_byte(d)
  return ((di << 24) | (ci << 16) | (bi << 8) | ai)
 
MadocComadrin said:
For all intents and purposes, it's a bit mask.
Nope, a bit-mask is a value used in bitwise operations to control the state of individual bits. The packed value in the functions above is just the result of a bitwise operation, but no bit-masks were involved in it.
 
Could we stop the discussion about if or if it isen't a bitmask?

I'm also interested what exactly these params mean, I did found out this;

The first param in the pack2 means how far into the animation the sound starts,
I had it on the crossbow reload as 0.1 so when you run and hold the crossbow fire button you won't start 1000 reload sounds but when you stand still and start the reload it starts the sound about 0.1-0.3 seconds into the animation. (I know weird right!) Maybe your right that it is a percent.

About the rest? I don't know.
 
Vincenzo said:
Could we stop the discussion about if or if it isen't a bitmask?
Heh, no harm in that... unknown values in animations doesn't seem to be a popular subject. :grin:
Vincenzo said:
The first param in the pack2 means how far into the animation the sound starts,
I had it on the crossbow reload as 0.1 so when you run and hold the crossbow fire button you won't start 1000 reload sounds but when you stand still and start the reload it starts the sound about 0.1-0.3 seconds into the animation. (I know weird right!) Maybe your right that it is a percent.
If you look at the function, the value is multiplied by 255 and then stored in 8 bits... that means anything below 0 or over 1 will get clamped. So yeah, 0 = start of animation, 1 = end of animation.

I did a few tests with the reload_crossbow animation:
pack2f(0.4, 0.94) - snd_reload_crossbow plays at 40%, snd_reload_crossbow_continue plays at 94%
pack2f(0.94, 0.4) - snd_reload_crossbow plays at 94%, snd_reload_crossbow_continue plays at 40%
pack2f(0.4, 0) - snd_reload_crossbow plays at 40%, snd_reload_crossbow_continue doesn't play
pack2f(0, 0.94) - snd_reload_crossbow doesn't play, snd_reload_crossbow_continue plays at 94%

So yeah, I'm pretty sure what I said in the first post holds true.

I tried doing similar tests with the horse animations that use pack4f, but I couldn't get consistent results (e.g. leaving only the 3rd and the 4th value on one anim resulted in no sounds played).
 
I asked a dev;

He responded;
Those values are used for different walk speeds in horses, and also water splash sounds are related with that. It is kinda dirty code,
so it is hard to explain all the details.
All values are related with sounds though

If they find time they will add some comments on them in the next patch.
 
Sorry to raise up such a long since dead post, but I'm curious if anyone can illuminate  on the last potential list member? This thread helped a lot being the best one I could find, but things are still a bit unclear to me. From what I can find the documentation for module_animations.py is still pretty poor.
 
Back
Top Bottom