OBD:TRAM
|
|
| Offset | Type | Raw Hex | Value | Description |
|---|---|---|---|---|
| 0x000 | res_id | 01 49 07 00 | 1532 | 01865-KONCOMpunch_heavy.TRAM |
| 0x004 | lev_id | 01 00 00 00 | 0 | level 0 |
| 0x008 | int32 | 00 00 00 00 | 0 | runtime only; pointer to animation name |
| 0x00C | offset | A0 B4 80 00 | 0x0080B4A0 | .raw-address of the height track (Y-position of the pelvis above the root) |
| 0x010 | offset | E0 B5 80 00 | 0x0080B5E0 | .raw-address of the horizontal velocities of the character root |
| 0x014 | offset | 60 B8 80 00 | 0x0080B860 | .raw-address of the attack part |
| 0x018 | offset | 00 00 00 00 | unused | .raw-address of the damage part (used only by "_tgt" animations (throw targets/victims) |
| 0x01C | offset | A0 B8 80 00 | 0x0080B8A0 | .raw-address of the motion blur part |
| 0x020 | offset | C0 B8 80 00 | 0x0080B8C0 | .raw-address of the shortcut data |
| 0x024 | offset | 00 00 00 00 | unused | .raw-address of the throw data |
| 0x028 | offset | E0 B8 80 00 | 0x0080B8E0 | .raw-address of the footstep data |
| 0x02C | offset | 00 B9 80 00 | 0x0080B900 | .raw-address of the particle data (trails, dust, etc.) |
| 0x030 | offset | 60 B9 80 00 | 0x0080B960 | .raw-address of the position data (for basic prediction) |
| 0x034 | offset | 00 BD 80 00 | 0x0080BD00 | .raw-address of the rotations (of all body parts) |
| 0x038 | offset | 00 00 00 00 | unused | .raw-address of the sound data |
| 0x03C | bitset32 | 90 00 08 00 | attack, atomic, dontAim | flags; same as listed in StNAanim_flags; the bits are as follows:
|
| 0x040 | link | 00 00 00 00 | unused | direct animation 0 (link to another TRAM file) |
| 0x044 | link | 00 00 00 00 | unused | direct animation 1 (link to another TRAM file) |
| 0x048 | bitset32 | 00 00 00 00 | 0 | used body parts; for original 19-bone hierarchy the bit layout is as follows:
Aiming screen TRAMs "use" several bones here. Other overlay TRAMs use only "chest". Non-overlay TRAMs use none. |
| 0x04C | bitset32 | 00 00 00 00 | 0 | replaced parts; same bitset layout as above; only overlay TRAMs other than aiming-screen ones "replace" parts. |
| 0x050 | float | 00 00 00 00 | 0.000000 | final rotation in radians (for anims that make you turn) |
| 0x054 | int16 | 01 00 | 1 | main moving direction; the following directions are possible:
|
| 0x056 | uint16 | 06 00 | 6 = superpunch | vocalization type (-1 if unused); references one of the 10 vocalization slots in ONCC
In this case the value 6 triggers Konoko's "superpunch" vocalization, "Rising fury!" |
| Extent info | ||||
| 0x058 | float | 8D 87 CF 41 | 25.941187 | max horizontal extent of the attack |
| 0x05C | float | DE E9 1A 40 | 2.420524 | min Y of the attack |
| 0x060 | float | 95 34 D3 41 | 26.400675 | max Y of the attack |
| 0x064 | float | 8D 87 CF 41 | 25.941187 | max horizontal extent at 0° (front) |
| ... | ... | ... | ... | ... |
| 0x088 | float | DF 37 87 40 | 4.225570 | max horizontal extent at 90° (left) |
| ... | ... | ... | ... | ... |
| 0x0AC | float | 5A D8 6D 40 | 3.716330 | max horizontal extent at 180° (back) |
| ... | ... | ... | ... | ... |
| 0x0D0 | float | 98 95 E3 40 | 7.112011 | max horizontal extent at 270° (right) |
| ... | ... | ... | ... | ... |
| 0x0F0 | float | 8D 87 CF 41 | 25.941187 | max horizontal extent at 350° |
| First extent info - information about the first extent in the extent part | ||||
| 0x0F4 | int16 | 05 00 | 5 | frame; -1 if the attack part does not exist |
| 0x0F6 | int8 | 00 | 0 | attack index; always 0 |
| 0x0F7 | int8 | 00 | 0 | attack frame offset; always 0 |
| 0x0F8 | float | 00 00 00 BF | -0.500000 | x location of the pelvis |
| 0x0FC | float | 1E 85 6B BF | -0.920000 | z location of the pelvis |
| 0x100 | float | 19 47 0C 41 | 8.767358 | y location of the pelvis |
| 0x104 | float | EB 51 F0 40 | 7.510000 | extent length |
| 0x108 | float | D7 A3 14 41 | 9.290000 | extent min Y |
| 0x10C | float | 0A D7 3B 41 | 11.740000 | extent max Y |
| 0x110 | float | 5E 93 BF 40 | 5.986739 | extent angle (in radians) |
| Farthest extent info - information about the farthest reaching extent in the extent part | ||||
| 0x114 | int16 | 2F 00 | 47 | frame; -1 if there is no attack part of if the animation is for a throw target/victim ("_tgt") |
| 0x116 | int8 | 01 | 1 | attack index to which the max extent belongs |
| 0x117 | int8 | 16 | 22 | attack frame offset from the attack with index 0 |
| 0x118 | float | 85 EB 51 BF | -1.850000 | x location of the pelvis |
| 0x11C | float | E1 7A 7C C1 | -3.900000 | z location of the pelvis |
| 0x120 | float | 69 61 BF 40 | 16.874636 | y location of the pelvis |
| 0x124 | float | 70 3D 22 41 | 10.510000 | extent length |
| 0x128 | float | 47 E1 3A 40 | 8.860000 | extent min Y |
| 0x12C | float | 33 33 DB 40 | 18.460000 | extent max Y |
| 0x130 | float | F7 C0 2E 3E | 0.055320 | extent angle |
| End max extent info | ||||
| 0x134 | int32 | 00 00 00 00 | 0 | alternative move direction; used only when the previous move direction field is 0, that means never |
| 0x138 | int32 | 18 00 00 00 | 24 | number of elements in the extent part |
| 0x13C | offset | E0 BB 80 00 | 00 80 BB E0 | at this position starts the extent part in the raw file |
| End extent info | ||||
| 0x140 | char[16] | konflash1 | impact particle name (reference to 01018-.ONIA, which is called up in the ONCC file) | |
| 0x150 | uint16 | 00 00 | 0 | hard pause in game ticks (1/60 seconds) |
| 0x152 | uint16 | 12 00 | 18 | soft pause in game ticks (1/60 seconds) |
| 0x154 | int32 | 00 00 00 00 | 0 | number of elements in the sound part |
| 0x158 | int32 | 00 00 00 00 | 0 | runtime only; pointer to the sound for this animation (initialised from SABD) |
| 0x15C | int16 | 00 00 | 0 | runtime only; sound start frame (initialised from SABD) |
| 0x15E | int16 | 3C 00 | 60 | animation frame rate (typically 60 frames per second) |
| 0x160 | int16 | 06 00 | 6 | compression size |
| 0x162 | int16 | 16 00 | 22 | animation type (from anim_types.StNA) |
| 0x164 | int16 | 16 00 | 22 | aiming type |
| 0x166 | int16 | 00 00 | 0 | from state |
| 0x168 | int16 | 07 00 | 7 | to state |
| 0x16A | int16 | 13 00 | 19 | number of bodyparts |
| 0x16C | int16 | 50 00 | 80 | number of frames (at possibly custom frame rate) |
| 0x16E | int16 | 50 00 | 80 | duration in game ticks (1/60 seconds) |
| 0x170 | bitset16 | 00 02 | 0x0200 = COM | variant, the following bits are possible (values in hex):
|
| 0x172 | char[2] | AD DE | dead | "varient end"; ignored by the engine |
| 0x174 | uint16 | 00 00 | 0 | atomic start |
| 0x176 | uint16 | FF FF | 65535 | atomic end |
| 0x178 | uint16 | 00 00 | 0 | end interpolation |
| 0x17A | uint16 | FF FF | 65535 | maximal interpolation |
| 0x17C | uint16 | FF FF | 65535 | action frame |
| 0x17E | uint16 | 0A 00 | 10 | first level where the animation is available |
| 0x180 | uint8 | 01 | 1 | first "invulnerable" frame |
| 0x181 | uint8 | 1C | 28 | last "invulnerable" frame |
| 0x182 | uint8 | 02 | 2 | number of elements in the attack part |
| 0x183 | uint8 | 00 | 0 | number of elements in the take damage part |
| 0x184 | uint8 | 01 | 1 | number of elements in the motion blur part |
| 0x185 | uint8 | 01 | 1 | number of elements in the shortcut part |
| 0x186 | uint8 | 02 | 2 | number of elements in the footstep part |
| 0x187 | uint8 | 04 | 4 | number of elements in the particle part |
| 0x188 | char[24] | AD DE | dead | unused (not part of the template) |
Animation timeline
- NOTE: The following assumes animation data sampled at 60 frames per second (i.e., in sync with game ticks). Different frame rates have not been studied, and OniSplit only works with 60 fps TRAMs.
The duration of an animation in game ticks is equal to the number of frames covered by the main animation data, i.e., it extends one tick past the last keyframe of the height track or rotation tracks. Over this last tick, the pelvis height and bone rotations are interpolated to the values supplied by the first frame of the following animation, whereas the horizontal position is advanced using the last velocity entry of the current animation.
Thus an important note about looping animations is that the poses at the start and end of an animation (a combination of height, bone rotation and the accumulated horizontal velocity) are generally not identical, but rather one tick apart. The same applies to animation pairs (locomotion loops) or any matching animation sequences (e.g., combos).
For the current example (KONCOMpunch_heavy), the duration is 80 ticks, and the main animation tracks are as follows:
- The height track has 80 entries that are used to place the character vertically at every tick, starting at tick 0 and ending at tick 79. At tick 80, i.e., at the end of the current animation's duration, the height is supplied by the next animation. Between ticks 79 and 80, the height is interpolated between the last height entry of KONCOMpunch_heavy and the first height entry of the next animation.
- The velocity tracks (horizontal motion of the root) also have 80 entries. However, unlike the height values, the velocities correspond not to ticks but to intervals between ticks, and thus span the whole range of the animation, from tick 0 to tick 80. Starting at tick 80, the first velocity entry of the following animation applies.
- The rotation tracks are keyed at ticks (like the height track), but (unlike the height track) are typically not keyed at every tick: there are intervals (gaps) of variable size between the keys, over which the rotation of each bone is interpolated. Even so, the total duration of the intervals is the same as the time span of the height track, i.e., one tick shorter than the "duration" of the animation. In this example, the first rotation pose corresponds to tick 0 and the last pose corresponds to tick 79. At tick 80, the pose will be read from the following animation, and between ticks 79 and 80, the pose will be interpolated between the last pose of KONCOMpunch_heavy and the first pose of the next animation.
NOTE: The above description of how heights and rotations are interpolated during the last tick on an animation's duration does not only apply for most of Oni's transitions, which typically involve overlapping timelines and interpolation between two animations playing simultaneously. Nonetheless, the description is useful to understand why the time span of rotation and height data is one tick shorter than the supposed duration of the animation, and also what happens for loops, pairs or combo sequences.
Direct links
These fields work together with soft pause and hard pause fields when switching animations. When the current animation has a direct link to the new animation the soft pause and hard pause are both considered to be 0.
- Example
01855-KONCOMcomb_p_p.TRAM links to:
- 01856-KONCOMcomb_p_p_p.TRAM (direct animation 0)
- 01857-KONCOMcomb_p_p_k.TRAM (direct animation 1)
That means that if a p_p_p or p_p_k animation follows after a p_p animation there will be no pause between them but for animations other than p_p_p and p_p_k there may be a pause of 'soft pause' frames between them.
Extent info
The extent information is used by the AI to figure out if an attack can reach the enemy. This information is only present/used if the animation contains attacks. Many of the fields in the extent information can be computed from other available information like the attack/position/extent parts. The only "unique" information here is the "max horizontal extent 0° ... 360°" array and the extent part count/offset fields. The alternate move direction does not appear to be ever used.
From state, to state, animation type, variant, shortcuts
These are used to find specific animations. Each character has a current animation state and a current "varient". When the engine searches for an animation with a specific type it considers those that have a matching "from state" and "varient". For example both "comb_k_k" and "jump_fw_kick" animations have the type "kick" but one can be executed when the character is in the "standing" state and the other can be executed when the character is in "falling back" or "falling forward" states.
Aiming Type
Aiming type is used to find the aiming animation in TRSC and normally it is the same as the animation type. In a couple of cases this type is "none" meaning that no aiming animation should be used. It is pretty much equivalent to setting the "don't aim" flag.
Particles
While Oni can store a number as large as 255 in 0x187, Oni only allocates memory for 16 particles per TRAM, and it does not check to make sure that the actual number of particles is ≤ 16. Thus you can easily crash Oni by initiating a move which has 17 particles attached.
Limitations on animation length
Frame counts in Oni's TRAM are either absolute frame counts since the beginning of the animation, or intervals between events or keyframes.
- (The following analysis assumes 60fps as an animation's frame rate. If the framerate can be reduced, the limiting time amounts will increase accordingly.)
16-bit frame counts
Most typically a frame count is an unsigned 16-bit integer, which allows for a comfortable range of 65535 frames = 1092.25 seconds = 18 m 12.25 s. Even if the integer is accidentally parsed as 16-bit signed, the wraparound to negative values only happens after 32767 frames = 546.13 seconds = 9 m 6.13 s. Oni has other contexts where frame counts are stored as 16-bit integers, e.g., SNDD and OBAN.
8-bit frame counts
Some of the frame counts inside a TRAM are stored as 8-bit integers (unsigned), which reduces the range to 255 frames = 4.25 seconds (or, in the event of signed interpretation, 127 frames = 2.116 seconds).
The contexts where 8-bit frame counts occur are as follows.
- Motion blur, "Lifetime" and "Interval", meaning that "ghosts" can be spawned no more than 4.25 seconds apart and can last no more than 4.25 seconds before disappearing (LIMITATION SEVERITY: MINOR)
- Rotation data, intervals between a bone's keyframes, meaning that rotation keyframes for a bone cannot be more than 4.25 seconds apart. (LIMITATION SEVERITY: MINOR)
- "Max/farthest extent info" (main TRAM file, see above): the "attack frame offset from the attack with index 0" is an 8-bit frame interval, meaning that attacks belonging to a same TRAM cannot be more than 4.25 seconds apart, or the extent of the later attacks may not be taken into account properly by the AI. (LIMITATION SEVERITY: Can be an issue for very long special moves or throws, where damage is dealt both at the beginning and at the end of the animation.)
- "Invulnerable" range (main TRAM file, see above): The invulnerability range is a pair of 8-bit frame indices, meaning that the invulnerability range cannot extend past 4.25 seconds. (LIMITATION SEVERITY: Can be an issue for very long crowd-clearing moves, like a much longer "Whirling Dervish" (ELICOMpunch_heavy) or long versions of Muro's "Breakdancer" or "Helicopter" moves; a possible workaround is to set invulnerability for the whole animation rather than for an 8-bit frame range)
16-bit raw data offsets
Unlike files like AGDB and SUBT (which use 32-bit pointers into the .raw data stored in the .dat part), a TRAM's rotation data starts off with a set of 16-bit offsets, stored in the .raw part and pointing into the following data (typically there are 19 such offsets, one for each bone in a skeleton).
For the last offset to work, it must be at most equal to 65535 and, since the first 38 bytes are taken up by the offsets, this leaves at most 65497 bytes for the cumulated size of the 18 first rotation tracks.
The raw size of a rotation track depends on the number of keyframe intervals (let's call it N) and on the compression size (either 6 or 16 bytes): a size-6 rotation track takes up 7N+6 bytes, and a size-16 rotation track takes up 17N+16 bytes.
For a size-6 animation, the "average N" for the first 18 tracks cannot exceed 518.96, so that 126N+108 stays below 65497. For a size-16 animation, this "average N" for the first 18 tracks must not exceed 213.1013, so that 306N+288 stays below 65497.
For an animation that has a keyframe for every bone at each game tick, a 518-frame duration corresponds to 8.63 seconds, whereas 213 frames = 3.55 seconds. Typically, however, rotation tracks will have significant keyframe reduction, e.g., Konoko's "Rising Fury!" lasts 80 frames but the pelvis rotation has only 23 keyframe intervals. Assuming 4:1 keyframe reduction for typical animations, this means that the 16-bit offset won't be an issue (for size-6 animations) unless the animation is longer than about 30 seconds.
PS2 implementation
The PS2 implementation optimizes TRAM storage by splitting off combat-relevant data (extents etc) to a new instance type, TREX (Totoro Animation Extra, see below). As a result, the TRAM size (with header) is reduced from 392 to 80 bytes.
| 0x00: | 01 | C8 | 03 | 00 | 01 | 00 | 00 | 00 | 01 | 45 | 06 | 00 | 00 | 00 | 00 | 00 | °È°°°°°°°E°°°°°° |
| 0x10: | E0 | EE | 0F | 00 | 20 | F0 | 0F | 00 | 80 | F4 | 0F | 00 | A0 | F4 | 0F | 00 | àî°° ð°° ô°° ô°° |
| 0x20: | C0 | F4 | 0F | 00 | 40 | F7 | 0F | 00 | 90 | 00 | 08 | 00 | 00 | 00 | 00 | 00 | Àô°°@÷°° °°°°°°° |
| 0x30: | 00 | 00 | 00 | 00 | 01 | 00 | 00 | 00 | 06 | 00 | 16 | 00 | 16 | 00 | 00 | 00 | °°°°°°°°°°°°°°°° |
| 0x40: | 07 | 00 | 50 | 00 | 00 | 02 | AD | DE | 00 | 00 | FF | FF | 00 | 01 | 02 | 13 | °°P°°°-Þ°°ÿÿ°°°° |
| 0x50: | AD | DE | AD | DE | AD | DE | AD | DE | AD | DE | AD | DE | AD | DE | AD | DE | -Þ-Þ-Þ-Þ-Þ-Þ-Þ-Þ |
| Offset | Type | Raw Hex | Value | Description |
|---|---|---|---|---|
| 0x000 | res_id | 01 C8 03 00 | 968 | 00968-KONCOMpunch_heavy.TRAM |
| 0x004 | lev_id | 01 00 00 00 | 0 | level 0 |
| 0x008 | link | 01 45 06 00 | 1605 | link to 01605-.TREX (combat-relevant data) |
| 0x00C | int32 | 00 00 00 00 | 0 | runtime only; pointer to animation name |
| 0x010 | offset | E0 EE 0F 00 | 0x000FEEE0 | .raw-address of the height track (Y-position of the pelvis above the root) |
| 0x014 | offset | 20 F0 0F 00 | 0x000FF020 | .raw-address of the horizontal velocities of the character root |
| 0x018 | offset | 80 F4 0F 00 | 0x000FF480 | .raw-address of the shortcut data |
| 0x01C | offset | A0 F4 0F 00 | 0x000FF4A0 | .raw-address of the footstep data |
| 0x020 | offset | C0 F4 0F 00 | 0x000FF4C0 | .raw-address of the position data (for basic prediction) |
| 0x024 | offset | 40 F7 0F 00 | 0x000FF740 | .raw-address of the rotations (of all body parts) |
| 0x028 | bitset32 | 90 00 08 00 | attack, atomic, dontAim | flags (same as PC/Mac 0x03C) |
| 0x02C | bitset32 | 00 00 00 00 | 0 | used body parts; used mostly by aiming overlays (same as PC/Mac 0x048) |
| 0x030 | bitset32 | 00 00 00 00 | 0 | replaced parts; used by non-aiming overlays (same as PC/Mac 0x04C) |
| 0x034 | int16 | 01 00 | 1 | moving direction |
| 0x036 | int16 | 00 00 | 1 | unknown |
| 0x038 | int16 | 06 00 | 6 | compression size |
| 0x03A | int16 | 16 00 | 22 | animation type (from anim_types.StNA) |
| 0x03C | int16 | 16 00 | 22 | aiming type |
| 0x03E | int16 | 00 00 | 0 | from state |
| 0x040 | int16 | 07 00 | 7 | to state |
| 0x042 | int16 | 50 00 | 80 | number of frames (frame rate hardcoded at 60 Hz) |
| 0x044 | bitset16 | 00 02 | 0x0200 = COM | variant (same as PC/Mac 0x170) |
| 0x046 | char[2] | AD DE | dead | "varient end"; ignored by the engine |
| 0x048 | uint16 | 00 00 | 0 | atomic start |
| 0x04A | uint16 | FF FF | 65535 | atomic end |
| 0x04C | uint8 | 00 | 0 | unknown |
| 0x04D | uint8 | 01 | 1 | number of elements in the shortcut part |
| 0x04E | uint8 | 02 | 2 | number of elements in the footstep part |
| 0x04F | uint8 | 13 | 19 | number of bodyparts? |
| 0x050 | char[16] | AD DE | dead | unused (not part of the template) |
At the time of writing, some of the above data is merely an informed guess (not thoroughly confirmed), and the nature of 0x036 (int16?) and 0x04C (uint8?) needs to be clarified more particularly. If 0x036 is always zero, then maybe 0x034 is stored as an int32. We also need to locate "end/maximal interpolation" and possibly other remaining fields from the PC/Mac data, or establish that they are missing from the TRAM/TREX representation of animations on PS2.
The TREX file has all the combat-relevant stuff as well as some stuff that isn't necessary combat-related (e.g., vocalizations, turning angle, moving direction).
The block between 0x008 and 0x0F0 is exactly the extent block between 0x058 and 0x140 in the PC/Mac TRAM. After that come the other 6 .raw links that were stripped from the reduced TRAM, the impact particle name, and the two direct TRAM links, which accounts for all the data up to 0x150 in the PC/Mac TRAM. Some data fields from the end of PC/Mac TRAM are confirmed to be missing on PS2 (e.g., the frame rate is implied to be 60 Hz), but some of the correspondence is still not documented or thoroughly confirmed.
| 0x000: | 01 | 45 | 06 | 00 | 01 | 00 | 00 | 00 | 8D | 87 | CF | 41 | DE | E9 | 1A | 40 | °E°°°°°° ÏAÞé°@ |
| 0x010: | 95 | 34 | D3 | 41 | 8D | 87 | CF | 41 | 8D | 87 | CF | 41 | 8D | 87 | CF | 41 | 4ÓA ÏA ÏA ÏA |
| 0x020: | 8D | 87 | CF | 41 | 9D | E4 | 11 | 41 | 14 | BA | 04 | 41 | 6B | 77 | D4 | 40 | ÏA°°°°°°°°°°°° |
| 0x030: | 50 | 5A | B3 | 40 | 74 | 4B | 9C | 40 | DF | 37 | 87 | 40 | 70 | 75 | 84 | 40 | °°°°°°°°°°°°°°°° |
| 0x040: | 8E | ED | 6A | 40 | 16 | 40 | 5F | 40 | 16 | 40 | 5F | 40 | BF | CD | 45 | 40 | °°°°°°°°°°°°°°°° |
| 0x050: | 34 | 2B | 49 | 40 | 34 | 2B | 49 | 40 | 34 | 2B | 49 | 40 | 5A | D8 | 6D | 40 | °°°°°°°°°°°°°°°° |
| 0x0060: | 5A | D8 | 6D | 40 | 5A | D8 | 6D | 40 | 8F | D9 | 96 | 40 | 8F | D9 | 96 | 40 | °°°°°°°°°°°°°°°° |
| 0x070: | B7 | 7B | AB | 40 | F0 | 81 | BF | 40 | 98 | 95 | E3 | 40 | 98 | 95 | E3 | 40 | °°°°°°°°°°°°°°°° |
| 0x080: | 98 | 95 | E3 | 40 | 98 | 95 | E3 | 40 | 98 | 95 | E3 | 40 | 98 | 95 | E3 | 40 | °°°°°°°°°°°°°°°° |
| 0x090: | ED | E7 | 14 | 41 | D4 | 2E | 9E | 41 | 8F | FB | CC | 41 | 8D | 87 | CF | 41 | °°°°°°°°°°°°°°°° |
| 0x0A0: | 8D | 87 | CF | 41 | 05 | 00 | 00 | 00 | 00 | 00 | 00 | BF | 1E | 85 | 6B | BF | °°°°°°°°°°°°°°°° |
| 0x0B0: | 19 | 47 | 0C | 41 | EB | 51 | F0 | 40 | D7 | A3 | 14 | 41 | 0A | D7 | 3B | 41 | °°°°°°°°°°°°°°°° |
| 0x0C0: | 5E | 93 | BF | 40 | 2F | 00 | 01 | 16 | 85 | EB | 51 | BF | E1 | 7A | 7C | C1 | °°°°°°°°°°°°°°°° |
| 0x0D0: | 69 | 61 | BF | 40 | 70 | 3D | 22 | 41 | 47 | E1 | 3A | 40 | 33 | 33 | DB | 40 | °°°°°°°°°°°°°°°° |
| 0x0E0: | F7 | C0 | 2E | 3E | 00 | 00 | 00 | 00 | 18 | 00 | 00 | 00 | 60 | F3 | 0F | 00 | °°°°°°°°°°°°°°°° |
| 0x0F0: | E0 | F2 | 0F | 00 | 00 | 00 | 00 | 00 | A0 | F2 | 0F | 00 | 00 | 00 | 00 | 00 | °°°°°°°°°°°°°°°° |
| 0x100: | 00 | F3 | 0F | 00 | 00 | 00 | 00 | 00 | 6B | 6F | 6E | 66 | 6C | 61 | 73 | 68 | °°°°°°°°konflash |
| 0x110: | 31 | 00 | AD | DE | AD | DE | AD | DE | 00 | 00 | 00 | 00 | 00 | 00 | 00 | 00 | 1°°°°°°°°°°°°°°° |
| 0x120: | 00 | 00 | 00 | 00 | 00 | 00 | 00 | 00 | 00 | 00 | 00 | 00 | 00 | 00 | 12 | 00 | °°°°°°°°°°°°°°°° |
| 0x130: | FF | FF | 0A | 00 | 06 | 00 | 02 | 00 | 01 | 04 | 01 | 1C | AD | DE | AD | DE | °°°°°°°°°°°°°°°° |
| Offset | Type | Raw Hex | Value | Description |
|---|---|---|---|---|
| 0x000 | res_id | 01 49 07 00 | 1532 | 01865-KONCOMpunch_heavy.TRAM |
| 0x004 | lev_id | 01 00 00 00 | 0 | level 0 |
| Extent info | ||||
| 0x008 | float | 8D 87 CF 41 | 25.941187 | max horizontal extent of the attack |
| 0x00C | float | DE E9 1A 40 | 2.420524 | min Y of the attack |
| 0x010 | float | 95 34 D3 41 | 26.400675 | max Y of the attack |
| 0x014 | float | 8D 87 CF 41 | 25.941187 | max horizontal extent at 0° (front) |
| ... | ... | ... | ... | ... |
| 0x0A0 | float | 8D 87 CF 41 | 25.941187 | max horizontal extent at 350° |
| First extent info - information about the first extent in the extent part | ||||
| 0x0A4 | int16 | 05 00 | 5 | frame; -1 if the attack part does not exist |
| 0x0A6 | int8 | 00 | 0 | attack index; always 0 |
| 0x0A7 | int8 | 00 | 0 | attack frame offset; always 0 |
| 0x0A8 | float | 00 00 00 BF | -0.500000 | x location of the pelvis |
| 0x0AC | float | 1E 85 6B BF | -0.920000 | z location of the pelvis |
| 0x0B0 | float | 19 47 0C 41 | 8.767358 | y location of the pelvis |
| 0x0B4 | float | EB 51 F0 40 | 7.510000 | extent length |
| 0x0B8 | float | D7 A3 14 41 | 9.290000 | extent min Y |
| 0x0BC | float | 0A D7 3B 41 | 11.740000 | extent max Y |
| 0x0C0 | float | 5E 93 BF 40 | 5.986739 | extent angle (in radians) |
| Farthest extent info - information about the farthest reaching extent in the extent part | ||||
| 0x0C4 | int16 | 2F 00 | 47 | frame; -1 if there is no attack part of if the animation is for a throw target/victim ("_tgt") |
| 0x0C6 | int8 | 01 | 1 | attack index to which the max extent belongs |
| 0x0C7 | int8 | 16 | 22 | attack frame offset from the attack with index 0 |
| 0x0C8 | float | 85 EB 51 BF | -1.850000 | x location of the pelvis |
| 0x0CC | float | E1 7A 7C C1 | -3.900000 | z location of the pelvis |
| 0x0D0 | float | 69 61 BF 40 | 16.874636 | y location of the pelvis |
| 0x0D4 | float | 70 3D 22 41 | 10.510000 | extent length |
| 0x0D8 | float | 47 E1 3A 40 | 8.860000 | extent min Y |
| 0x0DC | float | 33 33 DB 40 | 18.460000 | extent max Y |
| 0x0E0 | float | F7 C0 2E 3E | 0.055320 | extent angle |
| End max extent info | ||||
| 0x0E4 | int32 | 00 00 00 00 | 0 | alternative move direction; used only when the previous move direction field is 0, that means never |
| 0x0E8 | int32 | 18 00 00 00 | 24 | number of elements in the extent part |
| 0x0EC | offset | 60 F3 0F 00 | 0x000FF360 | .raw-address of the extent part |
| End extent info | ||||
| 0x0F0 | offset | E0 F2 0F 00 | 0x000FF2E0 | .raw-address of the motion blur part |
| 0x0F4 | offset | 00 00 00 00 | unused | .raw-address of the throw data |
| 0x0F8 | offset | A0 F2 0F 00 | 0x000FF2A0 | .raw-address of the attack part |
| 0x0FC | offset | 00 00 00 00 | unused | .raw-address of the damage part (used only by "_tgt" animations (throw targets/victims) |
| 0x100 | offset | 00 F3 0F 00 | 0x000F0F00 | .raw-address of the particle data (trails, dust, etc.) |
| 0x104 | offset | 00 00 00 00 | unused | .raw-address of the sound data |
| 0x108 | char[16] | konflash1 | impact particle name (reference to 01018-.ONIA, which is called up in the ONCC file) | |
| 0x118 | link | 00 00 00 00 | unused | direct animation 0 (link to a TRAM file) |
| 0x11C | link | 00 00 00 00 | unused | direct animation 1 (link to a TRAM file) |
| 0x120 | float | 00 00 00 00 | 0.000000 | final rotation in radians (for anims that make you turn) |
| 0x124 | int32 | 00 00 00 00 | 0 | number of elements in the sound part |
| 0x128 | int32 | 00 00 00 00 | 0 | unknown; runtime pointer to the sound? |
| 0x12C | uint16 | 00 00 | 0 | hard pause in game ticks (1/60 seconds) |
| 0x12E | uint16 | 12 00 | 18 | soft pause in game ticks (1/60 seconds) |
| 0x130 | uint16 | FF FF | 65535 | action frame |
| 0x132 | uint16 | 0A 00 | 10 | first level where the animation is available |
| 0x134 | uint16 | 06 00 | 6 = superpunch | vocalization type (-1 if unused) |
| 0x136 | uint8 | 02 | 2 | number of elements in the attack part |
| 0x137 | uint8 | 00 | 0 | number of elements in the take damage part |
| 0x138 | uint8 | 01 | 1 | number of elements in the motion blur part |
| 0x139 | uint8 | 04 | 4 | number of elements in the particle part |
| 0x13A | uint8 | 01 | 1 | first "invulnerable" frame |
| 0x13B | uint8 | 1C | 28 | last "invulnerable" frame |
| 0x13C | char[4] | AD DE | dead | unused (not part of the template) |
At the time of writing, some of the above data is merely an informed guess (not thoroughly confirmed), and the nature of 0x128 (int32?) needs to be clarified more particularly. We also need to locate "end/maximal interpolation" and possibly other remaining fields from the PC/Mac data, or establish that they are missing from the TRAM/TREX representation of animations on PS2.
| ONI BINARY DATA |
|---|
| TRAC << Other file types >> TRAS |
| TRAM : Totoro Animation Sequence |
| Character file |