XML:TRAM

TRAM : Totoro Animation	XML modding tips See HERE to start learning about XML modding. See HERE if you are searching for information on how to handle object coordinates. See HERE for some typical modding errors and their causes.
XML TRAC << Other file types >> TRAS switch to OBD page

General information

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

• Metadata or "header": animation type, state, flags, particle, sounds, etc.
• Animation data: pelvis heights, pelvis velocities (root motion), bone rotations
• Attack data: damage, self-damage, extents (danger zones for AI awareness) and throws

Root motion: a character moves by changing the position of its root bone (pelvis). The animated legs just create the illusion for the player that they are responsible for the motion.

Bones: Each character has 19 separate body parts which get animated (rotated) relative to each other. Compared to modern games Oni's bone system is deprecated. The body doesn't get deformed by following animated bones. Oni modders often use the terms mesh and bone interchangeably. Only the pelvis has translation data (heights and velocities) besides rotations. The hierarchy of the body parts (or bones) is determined by TRIA.

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

Decision path of animation lookup

• 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 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:
  • anim state check
  • event (user input, or engine input for the AI) -> context check -> anim type check
  • anim variant 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.

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.

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%).

List of tags, types, and flags

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

tag	type	description
<Lookup>	parent tag
<Type>	flag	Look them up over 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.
<AimingType>	flag	Look them up over 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.
<FromState>	flag	Primary <FromState> in <Lookup> uses about 8 interpolating frames by default. Use Shortcut's <FromState> to override this frame number. Look them up over HERE. When FromState is set to None, some default behaviors are ignored and are replaced by Shortcuts. Shortcuts extend the number of states from which an animation can be played and under what conditions (replacing this atomic yes/no).
<ToState>	flag	Look them up over HERE.
<Varient>	flag	(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: Combat LeftPistol LeftRifle Panic RightPistol RightRifle Sprint
<FirstLevel>	int16	Number of first level in which move becomes available to the player ("0" to make it available from the start).
<Shortcuts>	parent tag	Works as an alternative FromState collection. 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>. <Lookup> ... <FromState>None</FromState> ... <Shortcuts> <Shortcut> <FromState>Standing</FromState> <Length>0</Length> <ReplaceAtomic>no</ReplaceAtomic> </Shortcut> </Shortcuts> Scenario A: hardcoded interpolation of 8 frames. Scenario B: changeable interpolation frame number.
<Shortcut>	parent tag
<FromState>	flag	Look them up over HERE.
<Length>	int16	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. The reason this happens is because the interpolation "mixes" two animations. When one animation transitions into another via interpolation, part of the animation system continues playing the initial animation, and part of it is playing the follow-up animation, with all the rotations and positions getting linearly interpolated.
<ReplaceAtomic>	flag	yes no
<Flags>	flag	These are top-level flags on the whole animation. See the other <Flags> for flags on an attack part. RuntimeLoaded (This bit is not stored on disk; it is used at runtime to mark that the animation was loaded.) Invulnerable While playing this animation, the player is invulnerable to melee damage and also cannot be thrown. Damage from particles and fall damage still hurt. BlockHigh While playing this animation, the player is invulnerable to high or undefined attacks within some arc in front of him. If you set this flag on an animation where the player character is spinning, then the character can still be kicked in the back or thrown. BlockLow Same as above, only it can block low or undefined attacks. Attack 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). DropWeapon If the player is armed, he drops his weapon when this animation plays. InAir Something to do with jumps; not investigated. Atomic The whole animation must be played; player cannot interrupt it once it starts. NoTurn Player cannot turn by mouse while performing this animation. AttackForward 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. AttackLeft Same as above. AttackRight Same as above. AttackBackward Same as above. Overlay Not a standalone animation; it just overwrites part of an already-playing one, e.g. the weapon-holstering animation. DontInterpolateVelocity Unknown, but maybe it has something to do with {x,y,z} velocities and the fact that directional jumps, for example, take information about their direction vector from the {x,z} velocity part of the TRAM (the vertical Y component is in the ONCC). ThrowSource Unknown, but throws use it. Probably a developer relic. Throws work in animation pairs: whenever a throw source is played, the other character must perform the throw target animation. See throw(n) types: TRAM <TargetType> StNA (First used throw starts at #96.) Characters have only their own pool of animations available. And since enemy's TRAC might not contain the necessary animation the information must be provided by the throw source TRAC. Since every throw animation must have a throw animation type the ThrowSource flag is actually redundant. ThrowTarget Animation can hurt anybody with its attack part, including teammates. The player can even hurt himself with the TRAM's damage part (whereas a player cannot hurt himself with his own animation's attack part). It also allows two attack parts to be executed instead of only one (maybe a bug? more than two will result in a crash). 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. RealWorld It appears this flag was used to create a TRAM and an OBAN from one animation source. The OBAN is supposed to store pelvis rotations and positions, allowing a character to move over obstacles/gaps. The vast majority of them are used in cutscenes. DoAim Applies the aiming animation overlay (PIS/RIF) if the player has a weapon. DontAim An aiming overlay will not be applied. CanPickup Player can pick up an item during this animation if he intersects with one during his movement. Aim360 Unknown. DisableShield If the player has an active supershield (chr_super "name" 1), this forces him to disable it (chr_super "name" 0) NoAIPickup AIs are not permitted to pick up items with this animation.
<Atomic>	parent tag	Makes animation particle atomic?
<Start>	int16
<End>	int16
<Invulnerable>	parent tag	Character will not take melee damage during a time frame defined by the Start and End frames.
<Start>	int16	First frame of character being invulnerable.
<End>	int16	Last frame of character being invulnerable.
<Overlay>	parent tag
<UsedBones>	flag	Simply contains "<UsedBones />" if no bones are involved, otherwise: Pelvis LeftThigh LeftCalf LeftFoot RightThigh RightCalf RightFoot Mid Chest Neck Head LeftShoulder LeftArm LeftWrist LeftFist RightShoulder RightArm RightFist
<ReplacedBones>	flag	"<ReplacedBones />" if unused, otherwise: Pelvis LeftThigh LeftCalf LeftFoot RightThigh RightCalf RightFoot Mid Chest Neck Head LeftShoulder LeftArm LeftWrist LeftFist RightShoulder RightArm RightFist
<DirectAnimations>	parent tag
<Link>	link	First slot. "<Link />" if unused.
<Link>	link	Second slot. "<Link />" if unused.
<Pause>	parent tag
<Hard>	int16	In ticks. The Hard and Soft pause values are ignored if this animation has a direct link (above) to another animation.
<Soft>	int16	In ticks. As mentioned above, the player cannot enter new inputs during this pause unless this animation is part of a combo animation defined by <DirectAnimations><Link>. Examples: COMcomb_p, (no pause) COMcomb_p_p COMcomb_p, (pause) COMcomb_k The difference between the hard and soft pause is that you can block during the soft pause and not the hard pause.
<Interpolation>	parent tag
<End>	int16	interpolates first X frames of next animation if the first follow-up animation is too short, it can continue to play even further (not observed with vanilla anims) While interpolations with rotations are less noticeable, interpolations of different positions can cause an additional drift. 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. "End" interpolation covering multiple follow-up animations.
<Max>	int16	unused
<FinalRotation>	float	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.)
<Direction>		Used by AI melee system. None Forward Backward Left Right
<Vocalization>	int	ID of one of the SoundConstants in ONCC
<ActionFrame>	int	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.
<Impact>	link	"<Impact />" if unused.
<Particles>	parent tag	serves as group element
<Particle>	parent tag	holds individual particle data
<Start>	int	frame number for particle to start
<End>	int	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)
<Bone>	flag	Pelvis LeftThigh LeftCalf LeftFoot RightThigh RightCalf RightFoot Mid Chest Neck Head LeftShoulder LeftArm LeftWrist LeftFist RightShoulder RightArm RightFist
<Name>	link	particle name in ONCC-ONCP
<MotionBlur>	parent tag
<MotionBlur>	parent tag	sequence element
<Bones>	flag	Pelvis LeftThigh LeftCalf LeftFoot RightThigh RightCalf RightFoot Mid Chest Neck Head LeftShoulder LeftArm LeftWrist LeftFist RightShoulder RightArm RightFist
<Start>	int16	Start frame of motion blur sequence
<End>	int16	End frame of motion blur sequence
<Lifetime>	int8	Lifetime of each "ghost" in frames.
<Alpha>	int8	Transparency of "ghosts".
<Interval>	int8	Frame interval between each rendered "ghost".
<Footsteps>	parent tag
<Footstep>	parent tag
<Frame>	int16
<Type>	flag	Left Right
<Sounds>	parent tag	"<Sounds />" if unused.
<Sound>	parent tag
<Name>	char[32]	OSBDfile.imp.oni (don't use resource type's prefix or suffix)
<Start>	int16	The frame when the sound starts to play.
<Heights>	parent tag
<Height>	float	Absolute position.
<Velocities>	parent tag
<Velocity>	2 x float	Relative positions (delta values); the numbers represent the change in position from one frame to another.
<Rotations>	parent tag
<Bone>	parent tag	There are 19 bone tags, one for each body part.
<EKey>	int8 + 3 * float	For normal animations. The first value is the number of frames for which the rotation is maintained; the sum of all of these first EKey components always equals the total number of frames for the animation.
<QKey>	int8 + 4 * float	For overlay animations used by TRAS aiming screens. OniSplit v0.9.54.0 produces <QKey>s (quaternions) instead of <EKey>s (Euler rotations) for normal animations.
<PositionOffset>	parent tag	<PositionOffset> and <Positions> belong together. In the binaries, they are written in place. Seems unused; changing them has no effect in-game.
<X>	int16
<Z>	int16
<Positions>	parent tag
<Position>	float	seems to be unused (and when checking this with "chr_debug_sphere = 1", the spheres remain unchanged)
<Height>	float	vertical extent
<YOffset>	float	Y offset of the vertical extent from character location
<ThrowSource>	parent tag	"<ThrowSource />" if unused.
<TargetAdjustment>	parent tag	Used to position targets during throws, relative to the position of the character executing the throw.
<Position>	3 * float	Contains XYZ values, which position the target character: 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.
<Angle>	float	In radians - adjusts the rotation of the target in Oni's Y axis; most of the time (if not always) it's set to 3.14159274 radians in vanilla anims, equaling 180 degrees - which effectively rotates the rotates by those 180 degrees; if it was set to 0, the target would face the throw source character with his back.
<Distance>	float	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.
<TargetType>	flag	The flags are part of the animation type list. (static throws) Thrown1 = ###COMthrow_fw_p_tgt Thrown2 = ###COMthrow_fw_k_tgt Thrown3 = ###COMthrow_bk_p_tgt Thrown4 = ###COMthrow_bk_k_tgt (running throws) Thrown5 = ###COMrun_throw_fw_p_tgt Thrown6 = ###COMrun_throw_fw_p_tgt Thrown7 = ###COMrun_throw_bk_k_tgt Thrown8 = ###COMrun_throw_bk_k_tgt (not tested) (tackle throw = catching) Thrown9 = ###COMrun_tkl_fw_p_tgt (not tested) Thrown10 = ###COMrun_tkl_bk_p_tgt (pistol disarms) Thrown11 = ###PISthrow_fw_p_tgt Thrown12 = ###PISthrow_fw_k_tgt Thrown13 = ###PISthrow_bk_p_tgt (rifle disarm) Thrown14 = ###PISthrow_bk_k_tgt (not tested) Thrown15 = ###RIFthrow_fw_p_tgt Thrown16 = ###RIFthrow_bk_p_tgt Thrown17 = ###RIF? = (not tested) About the naming: "fw" = face-to-face throw "bk" = thrower is facing victim's back "throw" inside TRAM names is sometimes shortened to "thr" "p"/"k" = triggered by punch or kick button ("p" is sometimes omitted)
<SelfDamage>	parent tag	"<SelfDamage />" if unused. Works only with specific, hardcoded AnimTypes (mainly ThrownX, it's unknown if any other types work - that remains to be investigated). Using SelfDamage on an AnimType that wasn't intended for it will cause the game to crash. (ToDo: Checked if <Flag>ThrowTarget is enough to explain this. Modify a simple kick? For more please link to and use talk page.) From a practical standpoint, this means SelfDamage can be used only on ThrowTarget animations.
<Damage>	parent tag	sequence element
<Points>	int16	Damage taken by character.
<Frame>	int16	Frame of the animation when damage is dealt.
<Attacks>	parent tag
<Attack>	parent tag	Only 2 attack parts per file are allowed. Normally the target gets only one hit. But if the attack frame ranges of both attack parts are overlapping, then the target can be hit by both of them.
<Start>	int16	First frame where damage can be inflicted on an opponent.
<End>	int16	Last frame where damage can be inflicted on an opponent.
<Bones>	flag	The bones which can inflict damage.
<Flags>	flag	These are flags on an attack part, inside an <Attacks><Attack> element. See the previous <Flags> for general flags on the TRAM. Unblockable Low - Target of attack needs to crouch in order to block this attack. High - Blocker needs to stand; if both Low and High are set, blocker can block from both standing and crouching positions. HalfDamage - Blocker receives half of the normal damage.
<Knockback>	float	Target gets knocked back by this amount.
<HitPoints>	int16	Damage points inflicted by attack.
<HitType>	flag	Animation type for opponent's animation when the attack isn't blocked. The flags are part of the animation type list.
<HitLength>	int16	Number of frames that the target should remain in his hit animation state when he gets hit.
<StunLength>	int16	Number of frames that the target should remain in his blocking animation state when he blocks the attack.
<StaggerLength>	int16	Number of frames that the target should perform his stagger animation after a successful block.
<Extents>	parent tag	Explained below. Automatically calculated by OniSplit if there's a DAE file referenced in the XML.
<Extent>	parent tag	One tag per attack frame. Number of <Extent> tags = <Attack><End> - <Attack><Start> + 1
<Angle>	float	In degrees.
<Length>	float
<MinY>	float
<MaxY>	float
<AttackRing>	parent tag	Always contains 36 <Length> tags, explained below. Automatically calculated by OniSplit if there's a DAE file referenced in the XML. (AttackRing was formerly known as "horizontal extents" in older versions of OniSplit.)
<Length>	float	Horizontal extents, explained below. They create a "danger zone" around the attacker which the AI uses to try to dodge an attack.

Export

TRAM files can be extracted A) as pure XML files or B) as a pair of XML and DAE files. For editing the actual animation, you will want to use method B. While exporting an ONCC, you might see errors such as:

Cannot find instance 'TRAMKONCOMthrow_rev'
Cannot find instance 'TRAMKONCOMthrow_rev'
Cannot find instance 'TRAMKONRIFturn_right'
Cannot find instance 'TRAMKONOKOlev18_ZomStand'
Cannot find instance 'TRAMKONOKOcorner_hide'
Cannot find instance 'TRAMKONPIScorner_hide'

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

Via command line

To export a single TRAM:

onisplit -extract:xml output_path -anim-body:path_to\TRBS_or_ONCCname.oni path_to\TRAMname.oni

To export merged TRAMs:

onisplit -extract:xml output_path -anim-merge -anim-body:path_to\TRBS_or_ONCCname.oni path_to\TRAMname1.oni  path_to\TRAMnameN.oni

Via Vago

Combined extraction of DAE and XML.

Change to Characters tab and follow these steps.

Step 1: Select "TRAM ONI" as input format ("From").

Step 2: Select "XML / XML & DAE" as output format ("To").

Step 3: Tick checkbox "Extract with TRBS / ONCC". It's important this is done before adding a TRAM file.

Step 4: Set full path of ONCC or TRBS.

Step 5: Add TRAM file.

Step 6: Click "Convert".

Via Simple OniSplit GUI

There was a long-standing problem with combined ONCC/TRAM files where the textures would be missing.

Simple OniSplit GUI post-edits the DAE to fix missing textures. The character-related .oni files must be all in one folder. Usually the level0_Final folder does the trick.

Step 1: Drag and drop the TRAM and ONCC into the big field. (One by one or simultaneously; the order doesn't matter.)

Step 2: Hit "Convert".

Editing 3D data

Blender

See the Blender article for a general tutorial on using the free program to create animations for Oni. It also contains a Blender addon for automating certain tasks, troubleshooting advice, and links to an animation rig that makes animation much easier.

XSI

In the past, the community's preferred tool for any 3D modeling and animation was (formerly "XSI") Mod Tool. However, this free program was discontinued in 2014, and modders did not want to be tied to an aging (not to mention Windows-only) program. Thus, we have generally moved to using Blender (see next section). The following information is preserved for historical purposes.

---

For the correct Mod Tool settings, see HERE.

Here are some hints for creating animations when there is no rigging available:

• 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.
• The first body part to be animated is always the pelvis.
• Watch out for pelvis rotations so that the XYZ rotations don't overlap too much, otherwise you will get into a gimbal lock.

Also see our OCF thread.

Import

onisplit -create output_path path_to\TRAMname.xml

Common operations on animations by the community

Speeding up existing animations

s10k has created an XmlTools script that allows the speed-up of any existing TRAM by removing frames. More information and download link here.

Selected notes on animation types

Attacks

Extents and XML

As a regular modder you don't need to know how the attack ring and the extents get calculated. If you just want to create an attack animation then add an appropriate <Attacks> code block to your XML as seen in the section below.

How attack ring (horizontal extents) and extents get calculated

Ever wondered how the AI can recognize incoming attacks and block or dodge them? Extents (found by geyser and fully uncovered by Neo) are the key. Imagine the character looked at from above, and visualize a circle with this character being at the center of the circle. Now divide this circle into 10° segments, and those are the 36 units of horizontal extents (that is, the lateral reach of the attack). The 0° point is directly in front of the character and 180° is behind the character. The segments run clockwise around the character. So the first Extent tag is the horizontal reach on the 0° line, the second tag is for the line 10° clockwise, and so on. Note that a frontal attack like a simple kick could hit a target not only if he's standing at 0° (directly in front), but also at 10° or 20° to the right, and also at 340° and 350° (a bit to the left). When setting these manually, you should guess the inner and outer ranges of the reach of the attacker's bones that have damage attached to them. Test these values with an AI that blocks often. If you did it right, your attack will often be blocked, but if the extent length is too high, the AIs will react when too far from you, which does not look good.

There are two types of extents:

• <Extents> stores this info:

<Angle> at which this extent radiates from the character.

<Length> of this extent.

<MinY> minimum height of this extent.

<MaxY> maximum 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.

• <AttackRing> (formerly known as <HorizontalExtents> stores this info:

36 fields (exactly 36, otherwise it won't compile back into a .oni file), which correspond to areas in 10° intervals around the character as described above.

Using OniSplit to calculate extents

Let's say that you want to convert a non-attack animation to a damage-dealing animation. Non-attack TRAMs do not have extents information used to notify the AIs about incoming attacks, so how do you generate this information from the animation?

1. Export the animation to XML with a body attached. If you extract using just "-extract:xml dest_folder TRAMsomething.oni", you'll get the 3D animation data inside the XML (namely, the tags Heights, Velocities, Rotations, PositionOffset, and Positions; for an attack animation, you'll also get Attacks and AttackRing, and inside Attacks' elements, each Attack element will have Extents at the end of it).

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.

2. First, consider whether the TRAM should have something added to its Flags section, like Attack or ThrowTarget.

3. Now add to the XML of the non-attack TRAM data in the following format (after the <SelfDamage /> section, typically):

       <Attacks>
           <Attack>
               <Start>1</Start>
               <End>10</End>
               <Bones>RightWrist RightFist</Bones>
               <Flags />
               <Knockback>4</Knockback>
               <HitPoints>10</HitPoints>
               <HitType>KnockdownHead</HitType>
               <HitLength>5</HitLength>
               <StunLength>8</StunLength>
               <StaggerLength>0</StaggerLength>
           </Attack>
       </Attacks>

Do not add an AttackRing section after Attacks.

4. Import this with "-create dest_folder TRAMsomething.xml". The Extents sections and the AttackRing will be calculated by OniSplit from the attached DAE.

5. If you need this information for a patch mod, run "-extract:xml" on the TRAMsomething.oni you've created without 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 Domino Knockdowns mod.

Combos

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. That being said, Oni has unused combo animation types, such as PKP, PKK, KPK, KPP, etc. that work perfectly fine and can be used to create new combos. To assign an animation type to a specific combo attack, you set a corresponding value in <Lookup><Type>.

Setting a value in the <Link> of <DirectAnimations> will do two things:

1. It will increase the time window 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.)
2. It disables <Interpolation><End> for the next combo anim.
3. It enables <Pause><Soft> and <Pause><Hard>.

Just Frame input

Implemented by Delano762, inspired by the game series Tekken, a Just Frame ("JF") move 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 states differently to create new moves.

Example 1:

• new forward kick = TRAMKONCOMkick_fw_JF <FromState>Standing
  • key strokes: w + k
• old forward kick = TRAMKONCOMkick_fw <FromState>RunStart
  • key strokes: w, k

Example 2:

• new forward punch = TRAMKONCOMpunch_fw_JF <FromState>Standing
  • key strokes: w + p
• old forward punch = TRAMKONCOMpunch_fw <FromState>RunStart
  • key strokes: w, p

Note that these animations are referred to as JF moves, not JF combos. The Crescent Moon Kick, as mentioned above, is an unintentional JF combo found in vanilla Oni.

Throws

Throw target animations are registered in the TRAC of the throw initiator (AKA the throw source). Target animations are forced onto the other character. Throw target (TRAM*tgt) animations can only cover up to 256 frames (0-255). These animations of type ThrownX are like slots. They can be used freely, although it might be a good idea to follow the traditional slot arrangement whenever possible: first the normal throws, then run, the catch, then disarm, and so on.

The first anim state of source (src) and target (tgt) is the "primary" <FromState>. The others <FromState> entries are located in <Shortcut>.

Throw table

Source and target anim types (pairs) aren't named in an intuitive pattern: Using "forward" and "backward" in throw names can be ambiguous for newbies. For example Konoko can throw a foe seemingly backwards by her throw forward kick (TRAMKONCOMthrow_fw_k). Therefore we should also describe throws how "source" and "target" are facing each other.

names	key combo	context				anim type		image
		varient	src state	tgt state	facing setup	src	tgt
normal throws a.k.a. static throws
static throw forward punch TRAMKONCOMthrow_fw_p TRAMKONCOMthrow_fw_p_tgt	P + ↑	COM	Standing RunStart	Standing Crouch Stunned	face-to-face	ThrowForwardPunch	Thrown1
static throw forward kick TRAMKONCOMthrow_fw_k TRAMKONCOMthrow_fw_k_tgt	K + ↑	COM	Standing RunStart	Standing Crouch Stunned	face-to-face	ThrowForwardKick	Thrown2
static throw backward punch TRAMKONCOMthrow_bk TRAMKONCOMthrow_bk_tgt	P + ↑	COM	Standing RunStart	Standing Crouch WalkingLeftDown WalkingRightDown Stunned	face-to-back	ThrowBackwardPunch	Thrown3
static throw backward punch TRAMKONCOMthrow_bk_k TRAMKONCOMthrow_bk_k_tgt	K + ↑	COM	Standing RunStart	Standing Crouch WalkingLeftDown WalkingRightDown Stunned	face-to-back	ThrowBackwardKick	Thrown4
run throws
run throw forward punch (forward "lariat") TRAMKONCOMrun_throw_fw TRAMKONCOMrun_throw_fw_tgt	P + ↑(↑)	COM	None RunningLeftDown RunningRightDown	Standing RunningLeftDown RunningRightDown Stunned WalkingLeftDown WalkingRightDown	face-to-face	RunThrowForwardPunch	Thrown5
run throw forward kick TRAMKONCOMrun_thw_fw_k TRAMKONCOMrun_thw_fw_k_tgt	K + ↑(↑)	COM	None RunningLeftDown RunningRightDown	Standing RunningLeftDown RunningRightDown Stunned WalkingLeftDown WalkingRightDown	face-to-face	RunThrowForwardKick	Thrown6
run throw backward punch (backward "lariat") TRAMKONCOMrun_throw_bk TRAMKONCOMrun_throw_bk_tgt	P + ↑(↑)	COM	None RunningLeftDown RunningRightDown	Standing RunningBackLeftDown RunningBackRightDown WalkingRightDown WalkingLeftDown Stunned	face-to-back	RunThrowBackwardPunch	Thrown7
run throw backward kick TRAMREDCOMrun_thw_bk_k TRAMREDCOMrun_thw_bk_k_tgt	K + ↑(↑)	COM	None RunningLeftDown RunningRightDown	Standing RunningBackLeftDown RunningBackRightDown Stunned	face-to-back	RunThrowBackwardKick	Thrown8
catching throws a.k.a. tackle throws
tackle throw backward kick? (never used)							Thrown9
tackle throw backward punch TRAMKONCOMrun_tkl_bk_p TRAMKONCOMrun_tkl_bk_p_tgt	P + ↑(↑)	COM	None RunningLeftDown RunningRightDown	None RunningLeftDown RunningRightDown	face-to-back	RunThrowBackwardPunch	Thrown10
disarm throws
pistol disarm throw forward punch TRAMKONPISthrow_fw_p TRAMKONPISthrow_fw_p_tgt	P + ↑	PIS	Standing RunStart	Standing Crouch Stunned	face-to-face	ThrowForwardPunch	Thrown11
pistol disarm throw forward kick TRAMKONPISthrow_fw_k TRAMKONPISthrow_fw_k_tgt	K + ↑	PIS	Standing RunStart	Standing Crouch Stunned	face-to-face	ThrowForwardKick	Thrown12
pistol disarm throw backward punch TRAMKONPISthrow_bk TRAMKONPISthrow_bk_tgt	P + ↑	PIS	Standing RunStart	Standing Crouch WalkingLeftDown WalkingRightDown Stunned	face-to-back	ThrowBackwardPunch	Thrown13
(never used)							Thrown14
rifle disarm throw forward punch TRAMKONRIFthrow_fw_p TRAMKONRIFthrow_fw_p_tgt	P + ↑	RIF	Standing RunStart	Standing Crouch Stunned	face-to-face	ThrowForwardPunch	Thrown15
rifle disarm throw backward punch TRAMKONRIFthrow_bk_p TRAMKONRIFthrow_bk_p_tgt	P + ↑	RIF	Standing RunStart	Standing Crouch Stunned	face-to-back	ThrowBackwardPunch	Thrown16
(never used)							Thrown17

Looks like there was/is support for running disarms. Though unused types for new ThrownN would be needed.

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

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.

BlenderOni Throw Adjust

There is a Blender script implemented within the BlenderOni addon for rotating and adding PositionOffset to a forward throw Target animation. It is capable of adjusting both forward and back throws. The script's old version can be accessed HERE.

Run animations

Here's a breakdown of the Striker's run animations, meant as an illustration for what would be needed to make new run TRAMs.

Run cancel:

• STRIKEidle1 / another idle animation
• STRIKErun1stepa
• STRIKErun1stepb
• STRIKEidle1 / another idle animation

Run – a minimal cycle:

• STRIKEidle1 / another idle animation
• STRIKErun1stepa
• STRIKErunstart
• STRIKErun_rt
• STRIKErun_lt (optional)
• STRIKErunstop
• STRIKEidle1 / another idle animation

Follow the images below from right to left.

• 

  STRIKErunstop

• 

  STRIKErun_lt

• 

  STRIKErun_rt

• 

  STRIKErunstart

• 

  STRIKErun1stepa

List of unused animations

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

From the original game

• KONOKOconsole_punch: What the name says (the engine can use that animation depending on the console's configuration, see 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 Evolved.
• 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.

From modders

Char A and Char B performing stun animations.

• http://mods.oni2.net/node/376
  • StrikerKneeStepKickThrow.zip
  • REDCOMjump_fw_crouch--double_flip--dae.zip
  • KONprone_getup--dae.zip
  • KONRIF_k_bk_throw.zip
  • female_stun--dae.zip

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.

Color trails

Open the XML-accompanied TRAM, search for the "Particles" tag, and insert your markup.

First example: TRAMSTRCOMcomb_p_p.xml

       <Particles>
           <Particle>
               <StartFrame>0</StartFrame>
               <EndFrame>12</EndFrame>
               <Bone>LeftFist</Bone>
               <Name>contrail</Name>
           </Particle>
       </Particles>

"contrail" is looked up by the character class (ONCC) that emits the actual particle; here it is "h2h_strtrail_e01".

This second example is about creating two different contrails in a TRAM at the same time. The animation is "TRAMSTRCOMpunch_heavy.xml".

       <Particles>
           <Particle>
               <Start>0</Start>
               <End>54</End>
               <Bone>RightWrist</Bone>
               <Name>contrail</Name>
           </Particle>
           <Particle>
               <Start>0</Start>
               <End>54</End>
               <Bone>LeftWrist</Bone>
               <Name>contrail_2</Name>
           </Particle>
       </Particles>

Note that you need to register the second contrail in the ONCC as well. Using your own contrail particle is also possible; just insert its name between the <Type> tags.

           <ONCPParticle>
               <Name>contrail</Name>
               <Type>h2h_strtrail_e01</Type>
               <BodyPart>-1</BodyPart>
           </ONCPParticle>
           <ONCPParticle>
               <Name>contrail_2</Name>
               <Type>h2h_murtrail_e01</Type>
               <BodyPart>-1</BodyPart>
           </ONCPParticle>

Motion blur

Motion blur in Oni works much like ghosting/onion skinning features in any animation software: In the frame range specified by <Start> and <End> an additional instance of body parts specified in <Bones> are rendered for additional extra frames specified by <Lifetime>, with transparency set by <Alpha>, and every <Interval> frames within the frame range. Example snippet from KONCOMcomb_p_p_k:

       <MotionBlur>
           <MotionBlur>
               <Bones>RightThigh RightCalf RightFoot</Bones>
               <Start>20</Start>
               <End>28</End>
               <Lifetime>4</Lifetime>
               <Alpha>127</Alpha>
               <Interval>1</Interval>
           </MotionBlur>
       </MotionBlur>

The one noteworthy thing is that you can have multiple motion blur sequences. If you wanted to add an extra motion blur to the above animation, you could do something like this:

       <MotionBlur>
           <MotionBlur>
               <Bones>LeftThigh LeftCalf LeftFoot</Bones>
               <Start>10</Start>
               <End>18</End>
               <Lifetime>4</Lifetime>
               <Alpha>127</Alpha>
               <Interval>1</Interval>
           </MotionBlur>
           <MotionBlur>
               <Bones>RightThigh RightCalf RightFoot</Bones>
               <Start>20</Start>
               <End>28</End>
               <Lifetime>4</Lifetime>
               <Alpha>127</Alpha>
               <Interval>1</Interval>
           </MotionBlur>
       </MotionBlur>

Impact effect

Impact effects - mostly particle - are picked by logic made within ONIE. Furthermore particles must be registered in ONCC: You probably want to look at ONIA instead of ONCP.