OniGalore

XML:TRAM: Difference between revisions

XML Discussion

XML:TRAM (view source)

Revision as of 15:57, 10 October 2023

5,748 bytes added ,  10 October 2023
moved in the deeper explanation of anim lookup from the talk page; broke out explanations of Weight and idle timer into sep. sections; moved "Open questions" up and added other questions found on the talk page; consolidated notes about "varient" misspelling
mNo edit summary
(moved in the deeper explanation of anim lookup from the talk page; broke out explanations of Weight and idle timer into sep. sections; moved "Open questions" up and added other questions found on the talk page; consolidated notes about "varient" misspelling)
Line 14: Line 14:
The term '''animation''' is often shortened to '''anim''' by modders, following the naming of commands in BSL: chr_wait_animstate, chr_wait_animtype, env_anim, etc.
The term '''animation''' is often shortened to '''anim''' by modders, following the naming of commands in BSL: chr_wait_animstate, chr_wait_animtype, env_anim, etc.


TRAMs used in Oni follow a naming pattern. A list of all combat TRAMs in-game and their naming can be found [[Combat moves|here.]]
Oni's code and debugging messages tend to spell the word variant as "varient". Blame the programmers for that one. Typically we use the correct spelling here, but OniSplit's XML follows Oni's misspelling, so you may see "varient" creep into the wiki here and there.


==Decision path of animation lookup==
TRAMs used in Oni follow a naming pattern. A list of all combat TRAMs in-game and their naming can be found [[Combat moves|here]].
 
==Open questions==
* If the never-used Thrown type can be applied as type 18 the table looks much more complete. "Restoring" forward tackles (face-to-face, src run + tgt run) can be omitted as the AI would most often stop movement for actual combat?
 
* All important header data of STRCOMrun_thw_fw_p and STRCOMrun_thw_fw_pl is identical. That means the engine picks the correct TRAM by using an unknown context, possibly this is similar or part of the distinction of "forward" (face-to-face) and "backward" (face-to-back).
: '''Maybe the algorithm checks always tgt's rotation and relative position to src at the same time but for most cases only tgt's rotation (facing) is relevant.'''
 
* Also, STRCOMrun_thw_fw_p(l) routing to Thrown5 and Thrown6 shows that Thrown anim types might be used however we like. A src-tgt-anim-type-pairing might be simply a ''convention''. Well, someone could check the source code...
 
* The existence of STRCOMrun_thw_fw_p(_tgt) and STRCOMrun_thw_fw_pl(_t) means that we need extra research to understand the full extent of the throw system.
* The variant pickup system is not clear yet: is a RIFCOM idle and a RIFNAT idle both possible?
** Or do rightpistol, leftpistol, rightrifle and leftrifle variants count as subsets of combat?
 
==Summary of animation lookup logic==
* First the game builds a pool of anims a character can use. They are loaded from the TRAC file registered in [[ONCC]], including parent TRACs.
* First the game builds a pool of anims a character can use. They are loaded from the TRAC file registered in [[ONCC]], including parent TRACs.
* Anims from a child TRAC override those of the parent if their combination of state, type and variant is exactly the same.
* Anims from a child TRAC override those of the parent if their combination of state, type and variant is exactly the same.
Line 23: Line 37:
* Here is the full decision path:
* Here is the full decision path:
** anim '''state''' check
** anim '''state''' check
** event (user input, or engine input for the AI) -> [[XML_talk:StNA|context check]] -> anim '''type''' check
** event (user input, or engine input for the AI) -> [[XML talk:StNA|context check]] -> anim '''type''' check
** anim '''variant''' check
** anim '''variant''' check
** TRAC '''weight''' check
** TRAC '''weight''' check


Detailed example: Let's say that we shapeshifted to a Ninja ONCC, we are in the state Standing, and we hit the action key to perform a taunt. The engine recognizes the context (a hostile character to interact with) and looks up anims of type Taunt. Since we are in combat mode, the next anim must be of variant Combat if possible. These lookups boil down to two valid possible anims: NINCOMtaunt1 and NINCOMtaunt2. If there are multiple anims available at this point, the engine picks one of them randomly.
===Elaboration===
Animations never stop – they flow from one to another. (See the concept of [[wp:State machine|state machines]] in gaming.) The default case is a character getting spawned and then just standing there: he idles forever. This brings us to the core attributes of every animation: '''type, state, variant'''.
 
Now then, the idle animation does not link to a specific follow-up animation – it rather links to a follow-up ''state''.
: Ironically all anims have a <FromState> and a <ToState> field, but no obvious <CurrentState> which can cause confusion on what the current anim's state actually is. This gives us two options of how to think about the situation: either consider <FromState> as usually being the <CurrentState>, or states exist only ''between'' anims and serve as ''transition rules''.
 
Linking to a follow-up state allows for multiple choices of what specific anim comes next. An anim is picked up randomly from a pool of valid anims. Their probability or <Weight> is determined by the anim listing in the TRAC – the anim collection (see "Weights" section for an explanation of exactly how <Weight> is handled).
 
Anyway, to let an character flow from one anim state to another, the <ToState> is used. Let's say an SBG grenade hits Konoko. The particle's '''damage type''' is '''blownup'''; this and the direction of the incoming damage force an anim of type '''Blownup''' or '''BlownupBehind''' to play, such as TRAMKONOKOblownup1.
 
Thus, Konoko falls to her back, going into the FallenBack state. The engine picks up the next anim which has <FromState>FallenBack. Also, receiving damage puts a character into combat mode, so further anims will be of variant Combat. But if the player gives no input, Konoko will remain on the ground, as <ToState>FallenBack creates a loop.
 
So here's a question: why isn't a getup anim like KONCOMgetup_lt played automatically since it also has <FromState>FallenBack and <Varient>Combat? Answer: it differs in its <Type>. Most [[XML_talk:StNA|anim types are bound to user input]] and therefore are excluded from the automatically created pool of valid anims which can follow.
 
Now let's consider what happens upon user input. A leftward movement of the mouse tells the engine to use an anim of type StandingTurnLeft. There are two anims with that type, KONOKOcomb_turnlt and KONCOMgetup_lt, but only the latter matches the current <FromState> condition.
: In fact, KONOKOcomb_turnlt has <Varient> Combat – the "comb" here stands for "combat", not "combo". Following Oni's naming convention, the file ''should'' have been named KONCOMturn_lt.
 
Knowing this behavior, we can deduce that anim types registered to user input will make the engine ignore all the automatic anims inside the pool, therefore breaking the loop of KONCOMfallen_back. And since KONCOMgetup_lt has <ToState>Standing and Konoko is still in combat mode, the following idle anim must also have <Varient>Combat. So the next anim played will be KON'''COM'''idle1 or KON'''COM'''idle2.
 
Konoko will eventually calm down when her ONCC <FightModeTimer> runs down, and then KON'''OKO'''idle1 or KON'''OKO'''idle2 will be played instead. (Actually, the COMidle will continue until a non-combat anim such as running breaks that loop. You won't ever see Konoko drop from combat readiness to her regular idle animation. Instead she will go from combat idle to running, to stopping, then standing at ease.)
 
Note the fallback behavior of anim lookup: if the engine cannot find an anim for the active variant (or "mode") of the character, it will choose the normal (non-variant-matching) version. Anims can be in the following variants: Combat, LeftPistol, LeftRifle, Panic, RightPistol, RightRifle and Sprint.
 
As for combinations of variants, it's possible, yes, but rarely and only Sprint and one weapon variant at a time.
 
==Weights==
Let's say that we're playing as a Ninja, we are in the state Standing, and we hit the action key to perform a taunt. The engine recognizes the context (no console to interact with), places the character in combat mode, and looks up anims of type Taunt. Since we are in combat mode, the next anim must be of variant Combat if possible. These lookups boil down to two valid possible anims: NINCOMtaunt1 (a spin) and NINCOMtaunt2 (the [[wp:Moon walk|moon walk]] Easter egg). The engine picks one of them randomly.
 
However, NINCOMtaunt1 has a TRAC Weight (probability) of 100 while NINCOMtaunt2 has a TRAC Weight value of just 5. So the chances are quite high that we will not see the moon walk taunt.
 
            <TRACAnimation>
                <Weight>100</Weight>
                <Animation>TRAMNINCOMtaunt1</Animation>
            </TRACAnimation>
            <TRACAnimation>
                <Weight>5</Weight>
                <Animation>TRAMNINCOMtaunt2</Animation>
            </TRACAnimation>


However, NINCOMtaunt1 has a TRAC Weight (probability) of 100 while NINCOMtaunt2 has a TRAC Weight value of just 5. So the chances are quite high that we will not see the Moon Walk taunt.
If there is only one anim to choose from, it will always play no matter what its Weight, even if it is zero. When it comes to multiple anims being a valid choice, the calculation is: weight of anim / sum of all valid anim weights. For NINCOMtaunt2, this means 5 / 105 = 0.047, or a 4.7% chance of a moon walk.


Keep in mind that if the engine cannot find an anim of a specific variant, it will fall back to a non-variant anim instead.
==Idle timer==
There's a semi-famous Easter egg where [https://www.youtube.com/watch?v=qbo2Q-VD6dc Konoko will sneeze] if she stands still for a long time. The timer for this is so long that most players never see it unless they step away from the game and leave it running without hitting F1. You might think that the way the sneeze is triggered is to set a low weight for it so that it's very unlikely a repeating idle cycle will choose the anim. But here's the sneeze anim in the TRAC with a Weight of 100:


Confused by how Weights work? Apparently, the Weight value is only one part of the equation — otherwise NINCOMtaunt2 would never execute. If there is only one anim to choose from, it will always play no matter what its Weight, even if it is zero. When it comes to multiple anims being a valid choice, the calculation seems to be: weight / sum of all weights. For NINCOMtaunt2, this means 5 / 105 = 0.047 (4.7%).
            <TRACAnimation>
                <Weight>100</Weight>
                <Animation>TRAMKONOKOidle_spec3</Animation>
            </TRACAnimation>
 
What's going on here? All regular idle anims are in fact of '''type Stand''', while Konoko's idle_spec3 anim above is of '''type Idle'''. Anims of '''type Idle''' are played every time the idle animation timer expires. This is found in ONCC as <IdleAnimation1Timer> and <IdleAnimation2Timer>. These timers are set to 30,000 for every character. The number is in ticks, so if we convert to minutes – 30,000 / 60 / 60 = 8.3̅ – we find that the secret idle anim for Konoko (or any character) will play every 8⅓ minutes.


==List of tags, types, and flags==
==List of tags, types, and flags==
Line 1,160: Line 1,217:
|}
|}


Looks like there was/is support for [[OBD:BINA/OBJC/MELE/MoveList/Throw|running disarms]]. Though unused types for new Thrown''N'' would be needed. On a second thought one should checked if we can't simply make a '''running (tgt + src) variant''' of disarms.
Looks like there was/is support for [[OBD:BINA/OBJC/MELE/MoveList/Throw|running disarms]]. Though unused types for new Thrown''N'' would be needed. On second thought, one should check if we can't simply make a '''running (tgt + src) variant''' of disarms.
 
====Open questions====
If the never used Thrown type can be applied as type 18 the table looks much more complete. "Restoring" forward tackles (face-to-face, src run + tgt run) can be omitted as the AI would most often stop movement for actual combat?
 
All important header data of STRCOMrun_thw_fw_p and STRCOMrun_thw_fw_pl is identical. That means the engine picks the correct TRAM by using an unknown context, possibly this is similar or part of the distinction of "forward" (face-to-face) and "backward" (face-to-back).
: '''Maybe the algorithm checks always tgt's rotation and relative position to src at the same time but for most cases only tgt's rotation (facing) is relevant.'''
 
Also, STRCOMrun_thw_fw_p(l) routing to Thrown5 and Thrown6 shows that Thrown anim types might be used however we like. A src-tgt-anim-type-pairing might be simply a ''convention''. Well, someone could check the source code...


====Forward throws====
====Forward throws====
Line 1,317: Line 1,366:


===Impact effect===
===Impact effect===
Impact effects - mostly particle - are chosen based on logic written within [[XML:BINA/ONIE#Visual_guides:_weapon.2C_melee.2C_environment|ONIE]]. Furthermore particles must be registered in [[XML:ONCC|ONCC]]: You probably want to look at ONIA instead of ONCP.
Impact effects – mostly particle – are chosen based on logic written within [[XML:BINA/ONIE#Visual guides: weapon, melee, environment|ONIE]]. Furthermore particles must be registered in [[XML:ONCC|ONCC]]: You probably want to look at ONIA instead of ONCP.


[[Image:XML_TRAM_KONCOMkick_fw_with_ninflash1.jpg|thumb|200px]]
[[Image:XML_TRAM_KONCOMkick_fw_with_ninflash1.jpg|thumb|200px]]


{{XML}}
{{XML}}
Retrieved from "https://wiki.oni2.net/Special:MobileDiff/41236"