XML talk:StNA

Anim types bound to user input

Stages of type assinment:

User input detection

Visible with chr_debug_characters = 1

Action for pickups

Context check and processing

Logical context: Was previous type a combo type?

Temporal context: Was player's input within a valid timeframe?

Spatial context: What is the position and angle of nearest interactive CJBO?

Type assignment

E.g. PickupObjectMid

Since there are also some TRAM files for prone mode, sitting and hiding against a wall, we can assume some geometry awareness (edge detection) - at least during the game dev stage.

For sit animations the Action event was probably used in FURN context as it belongs to CJBO just like the other interactive objects CHAR, CONS, DOOR, PWRU and WEAP.

For anim types, the series of anims is hardcoded. This is usually important for combos.

Bindings:

fw - forward
p - punch input
k - kick input
...

input	context	type
p	previous type within timeframe: Stand	Punch
p (accumulated: p, p)	previous type within timeframe: Punch	Punch2
p (accumulated: p, p, p)	previous type within timeframe: Punch2	Punch3
k (accumulated: p, p, k)	previous type within timeframe: Punch2	PPK
k (accumulated: p, p, k, k)	previous type within timeframe: PPK	PPKK
k (accumulated: p, p, k, k, k)	previous type within timeframe: PPKK	PPKKK
k (accumulated: p, p, k, k, k, k)	previous type within timeframe: PPKKK	PPKKKK
k	previous type within timeframe: Stand	Kick
k (accumulated: k, k)	previous type within timeframe: Kick	Kick2
k (accumulated: k, k, k)	previous type within timeframe: Kick2	Kick3
fw (accumulated: k, k, k + fw)	previous type within timeframe: Kick2	Kick3Fw

[...]

Besides finishing this table, a further objective could be to create graphics with combo and state cycles, like running and walking cycles.

In theory visual representation of states cycles allows a modder to diggest the crucial information when he wants to create new animations and/or cycles.