OBD talk:TRAM

From OniGalore
Jump to: navigation, search

more detailed explanations

Hello all ONI fans, This is not guide how to edit TRAM, it is only TRAM explained in more detail in order to help those who would like to modify it. I see it all the time that you discover already discovered and it is MY FAULT because I didn't share my knowledge X_X. Shame on me. --Loser 19:50, 20 August 2008 (CEST)

runloser.jpg

P.S.: And I am comguy (smart@$$ and coward), not striker ^_^

GENERAL:

  • We need hexeditor or OUP and some decimal to hex (Windows calculator) and decimal to float (see HERE) converters.
  • normal number are written as usual, when I want to write HEx number, I use prefix 0x. so 0x10 means 16.
  • Next here comes explanation of storage types (that is "type" column in table). Storage type is how this value is saved and how can be read by Oni. Types in TRAM which interests us are:
  • Offset: tells us that value points to the exact location in raw file where is something stored. Offset is a bit tricky. It is written in Little endian. So when in offset field is written A0|B4|80|00 , then something starts in raw at position 00|80|B4|A0 . See? Order of bytes is reversed. Keep this in mind. This can be helpful if we need to add some part to the TRAM which is originally not present for this TRAM (usually particles). You add this part (in correct form of course!) to the end of raw file, extending it (HEXeditor needed! Cannot do this with OUP!) and then you note where it begins (offset is usually written on the side) and write it into correct offset field in correct form for Oni(reverse bytes). A few examples of tricky offsets:
  • C5|A6|70|00 means 00|70|A6|C5, so something in raw starts at line 00|70|A6|C0 on the byte 05 (so it is 6th byte from the right, 0 is counted as well!!!).
  • 40|89|14|01 means 01|14|89|40, so something in raw starts at that line. Tricky part is the LAST byte when it is YOU who tries to reverse bytes in order to write them into TRAM ^_~.
  • Link: it tells us (and engine) that we should find some other file to use for something. Link contains internal number of the file we should search for,its res_ID. Usually first 4 bytes of file are this number.
  • Bitset: this is field of some optional possibilites. Each one has its own (hardcoded) number. Numbers are powers of 2 : 0,1,2,4,8,16 (0x10 in hex),32 (0x20 in hex),64 (0x40 in hex),128 (0x80 in hex)
  • Int: integer, it is some value written in hex (not generally, just for this purpose. Generally integer is defined as numeric value which can contain only whole numbers). Beware, again little endian. So if you want to change some "short" field, then type value you want into calculator, convert to hexadecimal. Then fill it in in reverse order (Little endian).
  • Float: field which can contain real number value. Beware, again Little endian. In order to decipher float, use some "float to decimal" converter (maybe the one I have suggested above? ^_^)
  • Char: some word, usually it is name of something. Howgh



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 unknown; always zero
0x00C offset A0 B4 80 00 00 80 B4 A0 at this position starts the "Y-positions of the pelvis" in the raw file.It looks like this:

Tram r01.gif

Offset Type Raw Hex Value Description
First element (black outline)
0x00 float 67 64 9B 40 4.856006 y-position of the pelvis in 0th frame of TRAM

This part contains Y-axis position (height) of pelvis in EACH frame of animation. If we need to "lower" or "elevate" character (we adopted some TRAM from other character and while performing, our char is "sinking" or "floating") this is place where we go. Beware: wrong values cause Oni to hang.

0x010 offset E0 B5 80 00 00 80 B5 E0 at this position starts the "X/Z - velocities of the pelvis" in the raw file. It looks like this:

Tram r02.gif

Offset Type Raw Hex Value Description
First element (black outline)
0x00 float EE D0 10 BE -0.141422 x-velocity of the pelvis
0x04 float 00 96 8F 3D 0.070110 z-velocity of the pelvis

Z+ is forward, Z- is back, X+ is left, X- is right

0x014 offset 60 B8 80 00 00 80 B8 60 at this position starts attack part in the raw file:

Tram r03.gif

Offset Type Raw Hex Value Description
First element (black outline)
0x00 bitset32 00 60 06 00 0, 96, 6, 0 damage-dealing bones; these are "dangerous ones";the following bits are possible:
0x01000000 - pelvis
0x02000000 - left thigh
0x04000000 - left calf
0x08000000 - left foot
0x10000000 - right thigh
0x20000000 - right calf
0x40000000 - right foot
0x80000000 - mid
0x00010000 - chest
0x00020000 - neck
0x00040000 - head
0x00080000 - left shoulder
0x00100000 - left arm
0x00200000 - left wrist
0x00400000 - left fist
0x00800000 - right shoulder
0x00000100 - right arm
0x00000200 - right wrist
0x00000400 - right fist
0x04 float 00 00 00 41 8.000000 knockback aka "how much is enemy pushed back by attack", only works if attack sucesfully damaged enemy
0x08 bitset32 08 00 00 00 8, 0, 0, 0 raw attack part bitset; the following bits are possible:
0 - nothing special, attack can be blocked by any stance of defender (crouch, stand) and deals no damage when blocked
1 - attack is unblockable
2 - attack is high; can be blocked only if defender plays an animation which have "BlockHigh" bit (see 0x3C TRAM bitset), otherwise hits
4 - attack is low; can be blocked only if defender plays an animation which have "BlockLow" bit (see 0x3C TRAM bitset), otherwise hits
8 - attack deals 1/2 damage when blocked + while blocking, it does not use blue "blocked" impact effect but hit impact effect
0x0C int16 14 00 20 hit points; how much it steals from enemy's HP if sucessfully hits
0x0E int16 05 00 5 start frame of attack part; 0 is start of TRAM
0x10 int16 0F 00 15 stop frame of attack part 0 is start of TRAM
0x12 int16 50 00 80 anim_type ID for opponent's animation if attack is sucessful (80 = hit_foot), see THIS file for Anim types, beware, you have to subtract 1 as list starts with 1 but should start with 0
0x14 int16 0A 00 10 number of frames for how long should victim remain in hit anim when he gets hit, if value exceeds about 25 frames, it automatically makes victim play stagger animation instead of its proper one written above
0x16 int16 0A 00 10 number in frames for how long should defender remain in "block" animation, if you set it a bit higher (about 0x10), then AI2 considers that technique with this move causes "blockstun"
0x18 int16 00 00 0 number of frames for how long should defender play stagger animation if defender blocked sucessfully; when set, then AI2 considers that technique with this move causes "block stagger"
0x1A int16 00 00 0 apparently garbage
0x1C int32 00 00 00 00 0 apparently garbage
0x018 offset 00 00 00 00 unused at this position starts the damage part in the raw file; only tgt (target) animations use it, BEWARE, without ThrowTarget bit (see 0x3C TRAM) it causes Loser's bug No.1 (Oni crashes). Raw:

Tram r04.gif

Offset Type Raw Hex Value Description
First element (black outline)
0x00 int16 14 00 20 damage taken by character
0x02 int16 29 00 41 frame of the animation, when damage is dealt
0x1C offset A0 B8 80 00 00 80 B8 A0 at this position starts the motion blur in the raw file, nothing intersting here for us, it is just eye candy
0x20 offset C0 B8 80 00 00 80 B8 C0 at this position starts the shortcut part in the raw file:

Tram r06.gif

Offset Type Raw Hex Value Description
First element (black outline)
0x00 int16 2F 00 47 from state; (see Molten's PDF for anim states) this tells us from which anim states can this animation be called and vice versa
0x02 int16 06 00 6 shortcut length in frames
0x04 int32 00 00 00 00 0 replace an atomic animation (0 - no, 1 - yes), see TRAM flags at 0x3C

This is important part. thanks to this we can perform specials as well as other movements (run, sprint). If you are messing around with TRAM and it does NOT want to be performed while all other things see OK, try to think if it has correct shortcut or if another animation related to this one has correct shortcut.

0x24 offset 00 00 00 00 unused at this position starts throw part in the raw file:

Tram r07.gif

Offset Type Raw Hex Value Description
First element (black outline)
0x00 float 8A 39 2C BF -0.672752 X axis adjustment; when throw is sucessful, used to move "teleport" victim left/right in order to set some distance between participants so throw looks good. If victim cannot move, throw is performed "as is".

X+ is left, X- is right

0x04 float 10 39 B4 3F 0.793839 Y axis adjustment; when throw is sucessful, victim is moved "teleported" up/down by this in order to set some distance between participants so throw looks good.

Curious is that if you "lift" enemy (you set it high Y+) enemy is lifted as if je jumped, bounding box is lifted! Usually when executing TRAMs, Y+ just stretches bounding box of character, that is why you cannot throw them over fences. But this one lifts character completely. Weird, isn't it? Y+ is up, Y- is down

0x08 float 44 2D 1C 41 9.761051 Z axis adjustment; same as X axis, only it is forward/backward

Z+ is forward, Z- is backward

0x0C float DB 0F 49 40 3.141592 angle adjustment; when throw is sucessful, victim is turned around his axis for this angle in order to make throw look good. (3.141 = pi)

P.S.: If you mess it, you can get that victim is performing correct thrown animation, but he turns around and is facing wrong way. Looks goofy :)

0x10 float 00 00 40 41 12.000000 throw distance, beware, if TRAM belong to TRAC which is inheriting some moves from parent TRAC, throw distance MUST be same or longer than throw distance of the same throw in parent TRAC. Otherwise, you will see Loser's bug No.2 ^_^.
0x14 int16 60 00 96 type / aming type; that's the ID (Anim type, se Molten's PDF) for the animation of the target, if you mess this, Oni will play wrong animation or crash.

Loser's bug No.2: Wrong throw animation is ocasionally performed. That is caused by fact that parent throw is IN distance for throw but our TRAC's throw is not. So engine iniciates throw and plays parent's TRAC throw animation and our TRAC thrown animation. Mess ^_^

0x28 offset E0 B8 80 00 00 80 B8 E0 at this position starts the footstep part in the raw file. Nothing to add.
0x2C offset 00 B9 80 00 00 80 B9 00 at this position starts the particle part in the raw file:

Tram r09.gif

Offset Type Raw Hex Value Description
First element (black outline)
0x00 int16 00 00 0 start frame of this particle
0x02 int16 30 00 48 stop frame of this particle
0x04 int32 0D 00 00 00 13 bodypart number; the particle is fixed to this bodypart; look to the TRIA file for a bodypart number
0x08 char[16] contrail ONCP particle name; the first 00 is the stop-byte; reference to 01017-.ONCP, otherwise it plays nothing and put up warning into dev console

Beware of the fact that ONCP particle name is NOT general name of the particle. "Kontrail" is ONCP particle name. "h2h_strtrail_e01" is general name of the particle.

0x30 offset 60 B9 80 00 00 80 B9 60 at this position starts the position part in the raw file. Don't mess with it.
0x34 offset 00 BD 80 00 00 80 BD 00 at this position starts the bodyparts animation part in the raw file. Read its section if you want. Until we can export/import animations and edit them in some program, I encourage you to leave this part alone. I know that sometnig CAN be done by hand work, but it is too time consuming.
0x38 offset 00 00 00 00 unused at this position starts the sound part in the raw file. Howgh
0x3C bitset32 90 00 08 00 144, 0, 8, 0 TRAM bitset collection; the following bits are possible /values in hex):
0x01000000 - private1 (this bit is not animation related, it is used at runtime to mark that the animation was loaded)
0x02000000 - invulnerable, while playing this animation user is invulnerable to melee damage AND cannot be thrown, PAR3/height still hurts him
0x04000000 - blockHigh, if set then while playing this animation user can block high or undefined attacks within some arc which is before him, so if you set this to some animation where user spins, then he can still be legaly kicked to the @$$ and he can be thrown
0x08000000 - blockLow, same as before only it can block low or undefined attacks
0x10000000 - attack, animations with attack part have it, unknown what it does, IMO it turns on soft lock (characters turns with animation a bit in order to hit nearby enemy), but didn't checked
0x20000000 - dropWeapon, if user is armed, he drops weapon when he plays this animation
0x40000000 - inAir, something with jumps, didn't checked
0x80000000 - atomic, whole animation must be played, user cannot interrupt it once it starts
0x00010000 - noTurn, cannot turn by mouse while performing this animation
0x00020000 - attackForward,unknown, looks like this is rough info for AI2 about where attack aims from user's point of view
0x00040000 - attackLeft, same as above
0x00080000 - attackRight, same as above
0x00100000 - attackBackward, same as above
0x00200000 - overlay, these are not standalone animatios, they just overwrite part of already playing one, for example holstering weapon is such an animation
0x00400000 - dontInterpolateVelocity, unknown, but maybe it has something to do with X,Y,Z velocities and fact that for example directional jumps take info about direction vector from X-Z velocity part of TRAM (Y vector is in ONCC)
0x00800000 - throwSource, unknown, throws use it
0x00000100 - throwTarget, if set, then animation can hurt anybody, with its attack part, including teammates. User of TRAM can even hurt himself with "damage part" (user cannot hurt himself with own attack parts). It also allows two (try more, get crash ^_^) attack parts to be executed instead of only one (maybe bug?).
-If you set first attack part to be able to deal damage from 1st to 100th frame of TRAM, and second attack part to deal damage within that limit (e.g. from 25th to 41st frame, it can be again from 1 to 100), than first attack part an hurt from 1st to 100th (as usual), but even if it hits, that second one attack part (25th to 41st) can hurt enemy as well during "its lifetime". So two attack parts are allowed to execute. Note that second attack part MUST be executed while first attack part has active "window", otherwise it won't work.
0x00000200 - realWorld, something with Y-velocities part
0x00000400 - doAim, forces aim animation (PIS/RIF) if user has weapon
0x00000800 - dontAim, forces not to aim
0x00001000 - canPickup, can pickup items in this animations, not like it plays pickup one, but like it "takes" the item if you have this animation on and you collide with item.
0x00002000 - aim360, dunno
0x00004000 - disableShield, if user had active supershield (chr_super "name" 1), this forces him to disable it (chr_super "name" 0)
0x00008000 - noAIPickup, AI2 are not permitted to pick up items with this animations


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), these two do NOT ensure that this animation can link, they only allow you to write two animations which can follow immediately, without applying soft pause, see below for more.
0x048 bitset32 00 00 00 00 0 used parts; Aiming screen TRAMs "use" several bones here. Other overlay TRAMs use only "chest". Non-overlay TRAMs use none. So we can ignore this part.
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), note that if you are hurt and this animation stopped, you are immediately forced back into your original direction. So if you make Konoko's running punch throw that thrown victim can be hurt and then you punch him, he reverses back to original rotation, "slides on his spin". Looks awful.
0x054 int16 01 00 1 move direction; the following directions are possible:
0 - nothing
1 - forward
2 - backward
3 - left
4 - right
I don't know why it is here, but it is good idea to set it correctly
0x056 int16 06 00 6 attack sound ("Rising fury!"); the number belongs to the sound slot in the ONCC file
0x058 float 8D 87 CF 41 25.941187 max horizontal extent of the attack

-extents are for AI2s. Thanks to these AI2 knows reach of technique (general and then in represented ranges around body) and can attack with it or guard it correctly. You can adjust it a bit if you feel it really needs to, but I don't recommend it as you cannot directly see what changed and if it is for good or for bad.

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°
0x0F4 int16 05 00 5 unknown; indicator for the seven floats below; always -1 if the attack part doesn't exist
0x0F6 int8 00 0 unknown; always zero
0x0F7 int8 00 0 unknown; always zero
0x0F8 float 00 00 00 BF -0.500000 unknown; always zero if the indicator is -1
0x0FC float 1E 85 6B BF -0.920000 unknown; always zero if the indicator is -1
0x100 float 19 47 0C 41 8.767358 unknown; always zero if the indicator is -1
0x104 float EB 51 F0 40 7.510000 unknown; always zero if the indicator is -1
0x108 float D7 A3 14 41 9.290000 unknown; always zero if the indicator is -1
0x10C float 0A D7 3B 41 11.740000 unknown; always zero if the indicator is -1
0x110 float 5E 93 BF 40 5.986739 unknown; always zero if the indicator is -1
0x114 int16 2F 00 47 unknown; indicator for the two bytes and seven floats below; always -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 unknown
0x117 int8 16 22 unknown
0x118 float 85 EB 51 BF -1.850000 unknown; always zero if the indicator is -1
0x11C float E1 7A 7C C1 -3.900000 unknown; always zero if the indicator is -1
0x120 float 69 61 BF 40 16.874636 unknown; always zero if the indicator is -1
0x124 float 70 3D 22 41 10.510000 unknown; always zero if the indicator is -1
0x128 float 47 E1 3A 40 8.860000 unknown; always zero if the indicator is -1
0x12C float 33 33 DB 40 18.460000 unknown; always zero if the indicator is -1
0x130 float F7 C0 2E 3E 0.055320 unknown; always zero if the indicator is -1
0x134 int32 00 00 00 00 0 unknown; always zero
0x138 int32 18 00 00 00 24 amount of elements of the extent part; only used if the attack part exists
0x13C offset E0 BB 80 00 00 80 BB E0 at this position starts the extent part in the raw file; only used if the attack part exists.
-Extent part stores the finest description of attack's path. Thus when you do an attack, AI2 can for example read that it starts going up, goes left a bit, then goes right and down again. How it is stored is still mystery for me.
0x140 char[16] konflash1 impact particle name (reference to 01018-.ONIA, which is called up in the ONCC file)
0x150 int16 00 00 0 hard pause in 1/60 seconds
0x152 int16 12 00 18 soft pause in 1/60 seconds, this pause is forced after animation ends. You simply stand, cannot do a thing. Only if this animaton links to some other one (links means it has correct ID Anim Type so it CAN be followed) this pause is ignored
0x154 int32 00 00 00 00 0 amount of packages of the sound part
0x158 int32 00 00 00 00 0 runtime: pointer to the sound for this animation (initialised from SABD)
0x15C int16 00 00 0 runtime: 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. See Molten's PDF. This number determines which keypress combination is required to call this animation, if animation can link to other one and many more
0x164 int16 16 00 6 aiming animation type from anim_types.StNA
0x166 int16 00 00 0 from state, this tells engine from which state this animation can be called. Thanks to this you can perform kick, getup kick and crouch kick. All done by same action, only animation state differs.
0x168 int16 07 00 7 to state, this is state in which animation ends. Should correspond so next animation transits smoothly. ^_^
0x16A int16 13 00 19 bodyparts
0x16C int16 50 00 80 frames, you cannot extend frames (Oni will hang) but you can shorten animation if you need. Only be aware that there are some parts of TRAM which can be harmed by shorting TRAM below their end frame.
0x16E int16 50 00 80 duration in in 1/60 seconds, the same as above
0x170 bitset16 00 02 0, 2 varient, the following bits are possible:
0x0001 - SPRint animation
0x0002 - COMbat animation
0x0008 - PIStol animation
0x0010 - NINja PIStol animation (left-handed)
0x0020 - RIFle animation
0x0040 - NINja RIFle animation (left-handed)
0x0080 - PANic or SCRamble animation
Beware, looks like PAN/SCR varient is somewhat messed up. Crashes happen sometimes.
0x172 char[2] AD DE dead varient end; unused
0x174 int16 00 00 0 atomic start, you can set only part of the TRAM to be atomic (cannot be affected by user)
0x176 int16 FF FF -1 atomic end, same
0x178 int16 00 00 0 end interpolation, in frames, beware, too big interpolation looks bad.
0x17A int16 FF FF -1 maximal interpolation
0x17C int16 FF FF -1 action frame, frame where action happens. Action is weapon theft in disarm animations, action is when Mukade actually teleports(changes place), and many other things
0x17E int16 0A 00 10 first level
0x180 uint8 01 1 first "invulnerable" frame, you can set only part of the TRAM to be invulnerable
0x181 uint8 1C 28 last "invulnerable" frame, same
0x182 uint8 02 2 amount of elements in the attack part
0x183 uint8 00 0 amount of elements in the take damage part
0x184 uint8 01 1 amount of elements in the motion blur part
0x185 uint8 01 1 amount of elements in the shortcut part
0x186 uint8 02 2 amount of elements in the footstep part
0x187 uint8 04 4 amount of elements in the particle part
0x188 char[24] AD DE dead unused

Beware, setting wrong values in those "amount of elements" fields may make Oni crash/hang.

--Loser 19:50, 20 August 2008 (CEST)