OBD:TRAM: Difference between revisions

From OniGalore
Jump to navigation Jump to search
(important limitation to particles in TRAMs)
(basic documentation of frame counts that are stored as bytes, and the limitations that it entails; should probably be duplicated in some form on XML:TRAM)
Line 164: Line 164:
{{OBDtr| 0x188 | char[24] |CACAFF| AD DE      | dead        | unused }}
{{OBDtr| 0x188 | char[24] |CACAFF| AD DE      | dead        | unused }}
|}
|}


;Direct links
;Direct links
Line 176: Line 175:


: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.  
: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
;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.
: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, varient, shortcuts
;From state, to state, animation type, varient, 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.
: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
Line 192: Line 188:
: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.
: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.


;Eight-bit frame counts and limiting consequences thereof
:Frame counts in Oni's TRAM are either absolute frame counts since the beginning of the animation, or intervals between events of keyframes. Mostly they are 16-bit integer fields (allowing for a range of either 65535 frames = 1092.25 seconds, or 32767 frames = 546.1333... seconds, depending on whether it's interpreted as signed or unsigned by the engine). In some contexts, though, 8-bit integers (bytes) are used instead, which reduce the range to 255 frames = 4.25 seconds (or 127 frames = 2.11666... seconds if the engine reads the byte as signed).
:The following contexts involve 8-bit frame counts:
*[[OBD:TRAM/raw0x1C|Motion blur]]:
**the "Lifetime" parameter is an 8-bit frame count, meaning a "ghost" cannot last more than 4.25 frames before disappearing completely; (LIMITATION SEVERITY: MINOR)
**the "Interval" is an 8-bit frame interval, meaning that successive "ghosts" can be spawned no more than 4.25 seconds apart; (LIMITATION SEVERITY: MINOR)
**the undocumented final field also looks like it could be an 8-bit count or interval (hypothesis so far is "trailing in frames").
*[[OBD:TRAM/raw0x34|Rotation data]]:
**Intervals between a bone's keyframes are 8-bit fields, meaning that keyframes cannot be more than 4.25 seconds apart. (LIMITATION SEVERITY: MINOR)
*"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 their extent 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)
:The above information assumes 60fps as the animation's frame rate. If the framerate can be reduced, the limiting time amounts will increase accordingly.


{{OBD_File_Footer | type=TRAM | prev=TRAC | next=TRAS | name=Totoro Animation Sequence | family=Character}}
{{OBD_File_Footer | type=TRAM | prev=TRAC | next=TRAS | name=Totoro Animation Sequence | family=Character}}


{{OBD}}
{{OBD}}

Revision as of 16:41, 8 September 2020

ONI BINARY DATA
TRAC << Other file types >> TRAS
TRAM : Totoro Animation Sequence
switch to XML:TRAM page
Overview @ Oni Stuff
OBD.png


Tram all.gif


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 00 80 B4 A0 at this position starts the y-position part (heights) of the pelvis in the raw file
0x010 offset E0 B5 80 00 00 80 B5 E0 at this position starts the x-z-position part of the pelvis in the raw file
0x014 offset 60 B8 80 00 00 80 B8 60 at this position starts the attack part in the raw file
0x018 offset 00 00 00 00 unused at this position starts the damage part in the raw file; only tgt throws use it (tgt = target)
0x1C offset A0 B8 80 00 00 80 B8 A0 at this position starts the motion blur part in the raw file
0x20 offset C0 B8 80 00 00 80 B8 C0 at this position starts the shortcut part in the raw file
0x24 offset 00 00 00 00 unused at this position starts the throw part in the raw file
0x28 offset E0 B8 80 00 00 80 B8 E0 at this position starts the footstep part in the raw file
0x2C offset 00 B9 80 00 00 80 B9 00 at this position starts the particle part (trails, dust, etc.) in the raw file
0x30 offset 60 B9 80 00 00 80 B9 60 at this position starts the position part in the raw file
0x34 offset 00 BD 80 00 00 80 BD 00 at this position starts the bodyparts animation part in the raw file
0x38 offset 00 00 00 00 unused at this position starts the sound part in the raw file
0x3C bitset32 90 00 08 00 144, 0, 8, 0 flags; they're stored in the anim_flags.StNA file; the following bits are possible (values in hex):
0x01 00 00 00 - private1 (this bit is not animation related, it is used at runtime to mark that the animation was loaded)
0x02 00 00 00 - invulnerable
0x04 00 00 00 - blockHigh
0x08 00 00 00 - blockLow
0x10 00 00 00 - attack
0x20 00 00 00 - dropWeapon
0x40 00 00 00 - inAir
0x80 00 00 00 - atomic
0x00 01 00 00 - noTurn
0x00 02 00 00 - attackForward
0x00 04 00 00 - attackLeft
0x00 08 00 00 - attackRight
0x00 10 00 00 - attackBackward
0x00 20 00 00 - overlay
0x00 40 00 00 - dontInterpolateVelocity
0x00 80 00 00 - throwSource
0x00 00 01 00 - throwTarget
0x00 00 02 00 - realWorld
0x00 00 04 00 - doAim
0x00 00 08 00 - dontAim
0x00 00 10 00 - canPickup
0x00 00 20 00 - aim360
0x00 00 40 00 - disableShield
0x00 00 80 00 - noAIPickup
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 parts; legend is for original 19-bone chars; the following bits are possible (values in hex):
0x01 00 00 00 - pelvis
0x02 00 00 00 - left thigh
0x04 00 00 00 - left calf
0x08 00 00 00 - left foot
0x10 00 00 00 - right thigh
0x20 00 00 00 - right calf
0x40 00 00 00 - right foot
0x80 00 00 00 - mid
0x00 01 00 00 - chest
0x00 02 00 00 - neck
0x00 04 00 00 - head
0x00 08 00 00 - left shoulder
0x00 10 00 00 - left arm
0x00 20 00 00 - left wrist
0x00 40 00 00 - left fist
0x00 80 00 00 - right shoulder
0x00 00 01 00 - right arm
0x00 00 02 00 - right wrist
0x00 00 04 00 - right fist

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 legend 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 attack direction; the following directions are possible:
0 - none
1 - forward
2 - backward
3 - left
4 - right
0x056 uint16 06 00 6 attack sound ("Rising fury!"); the number belongs to the sound slot in the ONCC file
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 the attack part doesn't exist or the attack part exists and it's a tgt animation (tgt = target)
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 1/60 seconds
0x152 uint16 12 00 18 soft pause in 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 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 6 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
0x16E int16 50 00 80 duration in in 1/60 seconds
0x170 bitset16 00 02 0, 2 varient, the following bits are possible (values in hex):
0x00 01 - SPRint animation
0x00 02 - COMbat animation
0x00 08 - PIStol animation
0x00 10 - NINja PIStol animation (left-handed)
0x00 20 - RIFle animation
0x00 40 - NINja RIFle animation (left-handed)
0x00 80 - PANic or SCRamble animation
0x172 char[2] AD DE dead "varient end"; ignored
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
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, varient, 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.
Eight-bit frame counts and limiting consequences thereof
Frame counts in Oni's TRAM are either absolute frame counts since the beginning of the animation, or intervals between events of keyframes. Mostly they are 16-bit integer fields (allowing for a range of either 65535 frames = 1092.25 seconds, or 32767 frames = 546.1333... seconds, depending on whether it's interpreted as signed or unsigned by the engine). In some contexts, though, 8-bit integers (bytes) are used instead, which reduce the range to 255 frames = 4.25 seconds (or 127 frames = 2.11666... seconds if the engine reads the byte as signed).
The following contexts involve 8-bit frame counts:
  • Motion blur:
    • the "Lifetime" parameter is an 8-bit frame count, meaning a "ghost" cannot last more than 4.25 frames before disappearing completely; (LIMITATION SEVERITY: MINOR)
    • the "Interval" is an 8-bit frame interval, meaning that successive "ghosts" can be spawned no more than 4.25 seconds apart; (LIMITATION SEVERITY: MINOR)
    • the undocumented final field also looks like it could be an 8-bit count or interval (hypothesis so far is "trailing in frames").
  • Rotation data:
    • Intervals between a bone's keyframes are 8-bit fields, meaning that keyframes cannot be more than 4.25 seconds apart. (LIMITATION SEVERITY: MINOR)
  • "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 their extent 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)
The above information assumes 60fps as the animation's frame rate. If the framerate can be reduced, the limiting time amounts will increase accordingly.
ONI BINARY DATA
TRAC << Other file types >> TRAS
TRAM : Totoro Animation Sequence
Character file