XML talk:StNA: Difference between revisions
Jump to navigation
Jump to search
Paradox-01 (talk | contribs) (Anim types bound to user input, WIP) |
Paradox-01 (talk | contribs) (This table requires quite some diligence and research for less known types. However we don't have many active modders, making this a non-priority 'construction site'. For now, most "added value" was realizing that there is a "context check".) |
||
| Line 1: | Line 1: | ||
==Anim types bound to user input== | ==Anim types bound to user input== | ||
For anim types, the series of anims is hardcoded. This is usually important for combos. | 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 | |||
... | |||
{|class="wikitable" width="100%" | |||
|- | |||
!width=33,3%| input | |||
!width=33,3%| context | |||
!width=33,3%| 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 | |||
|} | |||
[...] | |||
An further objective could be to finish this table for creating 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. | |||
<!-- | |||
some notes | |||
: none => Special1 [Cutsceen associated] | |||
: action => ActGive | |||
: action => ActNo | |||
: action => ActShout | |||
: action => ActShrug | |||
: action => ActTalk | |||
: action => ActYes | |||
: ? => Sit | |||
:mouse left - StandingTurnLeft | :mouse left - StandingTurnLeft | ||
:mouse left - CrouchTurnLeft (obsolete, because can be replaced by StandingTurnLeft and anim will still play) | :mouse left - CrouchTurnLeft (obsolete, because can be replaced by StandingTurnLeft and anim will still play) | ||
: | : crouch => in air? => Flip | ||
<Flags>InAir | |||
: none/space => <FromState>FlyingBack? => Fly | |||
<Flags>InAir | |||
: | |||
--> | |||
Revision as of 08:34, 28 July 2019
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 |
[...]
An further objective could be to finish this table for creating 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.