XML:TRAM: Difference between revisions

TRAM files — animation data for characters — are basically made of three chunks:

* Metadata or "header": animation type, state, flags, particle, sounds, etc.

* Attack data: damage, self-damage, extents (danger zones for AI awareness) and throws

* 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.

* Child TRACs usually omit some anims. For example, Elite Strikers don't have their own run anims, so they use the parent anims of normal Strikers. See [[XML:TRAC|TRAC]] page for details.

* A character always possesses a single animation state. This term derives from state machines, but you only need to know that states are the first point in the decision path determining what anims are actually allowed to play at a given moment.

* Here is the full decision path:

** event (user input, or engine input for the AI) -> [[XML_talk:StNA|context check]] -> anim '''type''' 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.

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.

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.

Use the search function in your browser to quickly find a tag.

| Look them up over [[XML:StNA#animation_types|HERE]]. The pool of valid TRAMs (animations a character can choose from) is built from the TRAC files registered in the ONCC. Most of the anim types are connected to player inputs.

| Look them up over [[XML:StNA#animation_types|HERE]]. The pool of valid TRAMs, and therefore TRASs (aiming screens a character can choose from) is built from the TRSC files registered in the ONCC.

: When FromState is set to None, some default behaviors are ignored and are replaced by Shortcuts.

|(misspelled because Oni misspells it) If unused, the tag will simply be "<Varient />", such as for non-combat animations. Otherwise it contains one of these values:

Shortcuts are accepted if their <Shortcut><FromState> value differs from the "primary" <Lookup><FromState> value. In other words, if you want to make a '''Shortcut''' that uses the '''same FromState''' value then you have to set '''primary FromState''' value to '''None'''. By doing that, the hardcoded interpolation frame length of about 8 frames can be overridden.

In the following example, the new interpolation length is 0. This will require the animation to match perfectly with the previous one. For a smooth transition to the next animation, set a suitable value at <Interpolation><End>.

[[Image:TRAM interpolation - standard case.jpg|thumb|400px|left|Scenario A: hardcoded interpolation of 8 frames. Scenario B: changeable interpolation frame number.]]

|Amount of interpolating frames. While interpolations of rotation are less noticeable, interpolations of different positions can cause drift (i.e. sliding).

This is especially observed for transitions from idle to movements and vice versa — basically any combination of animations with different accelerations at start and end. By default, animations without specified Shortcut interpolation give about 8 frames of interpolation. For moves starting or ending in idle, it's better not to use interpolation. Just give the start and end frames the same positions and rotation values as the idle. Interpolations should always be considered a ''last resort''.

This drift can be observed even in vanilla animations — most prominently in Konoko's comb_k. Konoko's left foot should be in a fixed position as the animation starts from from Konoko's idle pose. However, the interpolation is causing her left foot to drift noticeably to the right and a bit forward.

::Animations with an attack part have this turned on. It's unclear what it does, but it may enable the melee soft-lock (where the character turns a bit during the animation to face a nearby enemy).

::Unknown, but it looks like this is a hint for the AI about where an attack is aiming, from the player's point of view.

:::If you set the first attack part to be able to deal damage from the 1st to the 100th frame of the TRAM, and the second attack part to deal damage within that range (e.g. from the 25th to the 41st frame), then the first attack part will deal damage from the 1st to the 100th frame (as usual), but even if it hits, that second attack part can hurt the enemy as well during frames 25–41. Note that the second attack part must be executed within the first attack part's active "window", otherwise it won't work.

| Makes animation particle atomic?

| Character will not take melee damage during a time frame defined by the Start and End frames.

| Player cannot enter new inputs during this pause unless this animation is followed by a combo animation defined by <DirectAnimations><Link>.

* if the first follow-up animation is too short, it can continue to play even further (not observed with vanilla anims)

This was especially observed for transitions of idle to movements and vice versa — basically any combination of animations with different accelerations at the start and end. By default, animations without a specified Shortcut interpolation get about 8 frames of interpolation. For moves starting or ending in idle, it's better not to use interpolation. Just give the start and end frames the same positions and rotation values as the idle. Interpolations should always be considered a ''last resort''.

[[Image:TRAM interpolations - end interpolation bigger than next anim.jpg|thumb|400px|left|"End" interpolation covering multiple follow-up animations.]]

|valign="top"| Ending rotation in degrees. (During an animation, the camera is detached rotation-wise. If this value matches the body's final rotation, it will prevent a "glitchy" re-attaching.)

| ID of one of the [[XML:SNDD#step_1:_preparing_the_TRAM|SoundConstants in ONCC]]

| Frame number for any special events associated with this animation: weapon theft via disarm, weapon holstering, Mukade teleporting, items getting handed over to player, etc.

| frame number for particle to end (if the number exceeds frame count of animation, the particle will simply die at the end of the animation)

|Relative positions (delta values); the numbers represent the change in position from one frame to another.

| <PositionOffset> and <Positions> belong together. In the [[OBD:TRAM/raw0x30|binaries]], they are written in place. '''Seems unused; changing them has no effect in-game.'''

| seems to be unused (and when checking this with "chr_debug_sphere = 1", the spheres remain unchanged)

| Y offset of the vertical extent from character location  

*X - Side axis. Negative values move the target to the right and positive values move the target to the left.

*Y - Height axis. Negative values move the target downwards, but cannot make the target go below the floor. Positive values make the target go upwards — if the value is too big, the target will teleport upward and then immediately start falling, interrupting the target animation.

*Z - Forward axis. Negative values move the target backwards and positive values move the target forward.

| Activation distance. The throw can be triggered if it is within this range. However the value must be greater than the equivalent TRAM in the parent TRAC.

: "p"/"k" = triggered by punch or kick button ("p" is sometimes omitted)

: High - Blocker needs to stand; if both Low and High are set, blocker can block from both standing and crouching positions.

| Target gets knocked back by this amount.

| Number of frames that the target should remain in his hit animation state when he gets hit.

| Number of frames that the target should remain in his blocking animation state when he blocks the attack.

| Number of frames that the target should perform his stagger animation after a successful block.

| Explained below. Automatically calculated by OniSplit if there's a DAE file referenced in the XML.

| Horizontal extents, explained below. They create a "danger zone" around the attacker which the AI uses to try to dodge an attack.

Ignore them, as those files doesn't exist. (Someday we should remove them from the TRACs.)

[[Image:Vago_xml_plus_dae_extraction.png|thumb|200px|right|Combined extraction of DAE and XML.]]

'''Step 3:''' Check "Another TRAM" to choose a character animation file.

'''Step 1:''' Drag and drop the TRAM and ONCC into the [http://www.paradox.oni2.net/images/simpleOniSplitGui.png big field.] (One by one or simultaneously; the order doesn't matter.)

* Use the ONCC model in your 3D editor that will actually make use of the animations. This makes sure that the pelvis height will match and that the character's feet will not float in the air or go through the ground.  

* The first frame and last frames should match the probable previous and follow-up animations. This will reduce the necessity for long interpolations.

* When setting keyframes, each body part should have moved. This rule of thumb will give a more natural-looking animation.

* Watch out for pelvis rotations so that the XYZ rotations don't overlap too much, otherwise you will get into a [[wikipedia:Gimbal_lock|gimbal lock]].

Theoretically possible. Very difficult in practice and we don't have a tutorial on this one.

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.]]

s10k has created an XmlTools script that allows the speed-up of any existing TRAM by removing frames. More information and download link [http://mods.oni2.net/node/354 here.]

::<MinY> minimum height of this extent.

:Length, MinY and MaxY serve to create an invisible area in space which is "dangerous to be in". If an AI intersects with this area and notices it (refer to the Notice field in [[MELE]]), it will attempt to block or dodge according to its modifiers in its MELE profile.

::The number of <Extent>s is equal to the number of attack frames: <End> minus <Start> plus one (because the start frame counts too). For example, for TRAMKONCOMkick_low1: <End>30</End> minus <Start>22</Start> plus 1 = 9 <Extent>s.

:These extents are pretty impossible to guess, so leave them alone until Neo comes up with extent computation (probably from attack bones and bone rotations). However, always add at least one set of component tags, because those Length, MinY and MaxY components will be taken as the longest extent, the lowest Y value, and the highest Y value. Without those, a character won't react to this attack.

:However, if you extract this same animation using "-extract:xml dest_folder TRAMsomething.oni '''-anim-body ONCCtramuser.oni'''", the animation data will be placed in a DAE file along with the character model geometry. Be sure to pick a body with a size that's representative of the character classes that will actually use this TRAM, because the extents will be calculated from it. The XML file will be very short without the 3D data in it — this is how we want the non-attack TRAM to look. We do not know the extents information that should go in Extents or AttackRing, so we just want to add the part that distinguishes a DAE-extracted attack TRAM XML from a DAE-extracted non-attack TRAM XML. That part is the Attacks section, without the Extents under each Attack.

:5. If you need this information for a patch mod, run "-extract:xml" on the TRAMsomething.oni you've created <u>without</u> using "-anim-body". Now you can copy the Extents and AttackRing data to your XML patch. For an example of how the patch should look, see the [http://mods.oni2.net/node/311 Domino Knockdowns] mod.

The type and order of player input for triggering a given animation type (such as PPK) is hardcoded, and new animation types cannot be created. To assign an animation type to a specific combo attack, you set a corresponding value in <Lookup><Type>.

# It will increase the time for player input, meaning the next animation can be executed more easily. (In vanilla Oni, the Crescent Moon Kick has no link in KONCOMcomb_k_k_kfw and therefore is difficult to use.)

For short '''JF combos''' or '''JF anims'''. Created by Delano762, inspired by the game series Tekken. "JF" means that you have to press certain keys (W+K or W+P) at the exact same time, which is more difficult than it might sound. Delano's mod 54000 New Combat Moves for Konoko has a collection of animations which utilize existing animation types to create new combos.

Throw target animations are registered in the TRAC of the throw initiator (AKA the throw source). Target animations are forced onto the other character, removing the need to have that animation in the target's TRAC. Throw target (TRAM*tgt) animations can only cover up to 256 frames (0-255).

Scenario: You load two characters into Mod Tool and rotate (+/-180°) the throw target character because you need them to stand face to face as you work on an animation. When you are done animating, the target animation would need to be reversed again. This means multiplying the velocities by -1; the rotation also needs correcting. So it looks like you need *(-1) for the x rotation and -/+180° (depending on your initial change) for the Y rotation.

This is a Blender script for rotating -/+180° and adding PositionOffset to a forward throw Target animation. This was made by a hero from the Blender Discord named Danta. The add_object_offset_about_cursor_Z() function was written by Delano762.

For each frame in the range you specify, this script rotates the selected object by 180 degrees (or however many you want), and translates it by the offset found in the <TargetAdjustment> <Position> tag of the attacker's throw animation XML. It also has a frame-checking functionality that's buggy; ultimately there is no real reason at the moment to use it, but it may come in handy in the future, so it should be left in this snippet.

:1. Import a throw animation and its target animation into Blender.

:2. Open Scripting tab.

:3. Create a new text, and name it however you want with .py extension, e.g. TRAMAdjuster.py

:4. Paste the script.

:5. On the following lines…

…set ''start'' and ''end'' to the start frame of the animation (always 0 for vanilla anims, but if you're animating and starting from 1, you'll want it set to 1) and the ''end'' to the (end + 1) frame of your animation; e.g. if you have a 99 frame animation, set ''end'' to 100.

:6. On the following line…

…paste the values from the <Position> tag according to the order of the function arguments. The minus sign means the value should be inverted in the function. As an example, assuming you have the following <Position> tag…

…the function call should be as follows…

:7. Select the pelvis of the target animation.

:8. Press Shift+C to ensure your 3D cursor is in the center of the animation.

:9. Set the Transform Pivot Point to "3D Cursor".

:10. On the Scripting tab, run the script.

:11. The target should be now adjusted as expected.

:12. If you want to revert the target back to an exportable position and rotation, simply invert the Z argument in the add_object_offset_about_cursor_Z function and run the script again.

* Disable macro security if you don't want to have to click on the "Enable Content" button every time.

* If you are not afraid of VBA code, you can enter the dev environment by hitting Alt+F11. If you want to extend the attack library with more screenshots and settings, search for "LibraryThrows", " LibraryAttack", "Picture", and "CBAttackHelp.AddItem".

Here are all the known unused animations. These could be recycled in a new mod.

* KONOKOconsole_punch: What the name says (the engine can use that animation depending on the console's configuration, see [[OBD:BINA/OBJC/CONS|CONS]]) .

* KONOKOlev3_intro: Looks like she's placing something (bomb?) and then running away.

* KONOKOlev4_undress: From an aborted clothes-changing cutscene.

* KONOKOlev16_bomb: Planting a bomb.

* KONCOMsuper_kick: Now used in [[OTA]] as a spawn event, and by the fan-made character [[Shinatama Bot]].

* KONCOMsuper_punch: KONCOMpunch_heavy but without the shouted attack name, has HalfDamage flag, and does 10 less damage in its first attack part.

* COMPISidle_special1: Comguy checking environment and his gun; meant for a feature that would visually depict an elevation in the AI's level of alertness after, say, hearing a noise.

* STRPISidle_special1: Striker checking his his gun and communicating with an ally (another unused alertness-elevation animation).

* THUGlev1_direct: Thug probably directing a truck driver.

[[Image:female_stun.jpg|right|thumb|Char A and Char B performing stun animations.]]

===Special effects===

If the scene is overloaded by too many particles (including motion blur), these effects will cease being rendered. So don't overuse effects.

See also [[XML:ONCC]].