OBD:TRAM

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

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, 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)
• "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.

ONI BINARY DATA
TRAC << Other file types >> TRAS
TRAM : Totoro Animation Sequence
Character file