XML talk:StNA: Difference between revisions

← Older edit

XML talk:StNA (view source)

Revision as of 13:38, 30 March 2021

2,613 bytes added , 30 March 2021

moving talk here from main page

Iritscen

Bureaucrats, Interface administrators, Suppressors, Administrators

20,473

edits

@@ Line 1: / Line 1: @@
+==Unused types==
+If unused types are still recognized by engine we could try to apply new animations to them. For example additional throws with Thrown9, Thrown14, and Thrown17.
+==Console_Punch==
+* KONOKOconsole_punch (35 frames) is a stretched KONCOMcomb_p clone (16 frames)
+* the game doesn't use this file so the type could be also considered as "unused"
+* the question remains what this animation was used for; Loser suggests that it was "probably meant to be used for [[XML:BINA/OBJC/CONS#tags|''pushbutton'' type of consoles]]"
 ==Anim types bound to user input==
-For anim types, the series of anims is hardcoded. This is usually important for combos.
+Stages of type assignment:
+'''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
+|-
+|k + 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 quickly digest most 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
-: key strokes => Type
 :mouse left - StandingTurnLeft
 :mouse left - CrouchTurnLeft (obsolete, because can be replaced by StandingTurnLeft and anim will still play)
-:...
-: p => Punch
-: p, p => Punch2
+: crouch => in air? => Flip
-: p, p, p => Punch3
+<Flags>InAir
-: p, p, k => PPK
+: none/space => <FromState>FlyingBack? => Fly
-: p, p, k, k => PPKK
+<Flags>InAir
-: p, p, k, k, k => PPKKK
-: p, p, k, k, k, k => PPKKKK
+-->
-: c => Kick
-: c, c => Kick2
-: c, c, c => Kick3
-: k, k, fk => Kick3Fw
-: ...