Nuthilo
Smash Cadet
- Joined
- Dec 6, 2016
- Messages
- 34
Where is 0xA3A8?
Edit:
I did this, but I can't put PiCo back into the iso, at least I don't know how. It's too big to put in at PICo
Last edited:
-
Welcome to Smashboards, the world's largest Super Smash Brothers community! Over 250,000 Smash Bros. fans from around the world have come to discuss these great games in over 19 million posts!
You are currently viewing our boards as a visitor. Click here to sign up right now and start on your path in the Smash community!
Melee Gecko Codes + Guide and Discussion
- Thread starter Achilles1515
- Start date
Edit:
I did this, but I can't put PiCo back into the iso, at least I don't know how. It's too big to put in at PICo
The Cape
Smash Master
Go to that Offset and replace the Byte with what I posted. It's just a straight overwrite over whatever is there initially.
Nuthilo
Smash Cadet
- Joined
- Dec 6, 2016
- Messages
- 34
Did it, ty. One more question...How do you mod in stages? The ones in Scrumpy's vid look cool
Punkline
Dr. Frankenstack
- Joined
- May 15, 2015
- Messages
- 423
Ripple
for your case with Link, try modifying these:PlLk.dat offsets:
0x35F8 - bone ID -- <- try setting this to the bone you’re scaling to see if it makes the trail scale properly.
0x35FC - vertex 1 -- base of sword trail <- try messing with these if necessary
0x35A0 - vertex 2 -- tip of sword trail
alternatively, with code--
internal player data offsets:
0x2498 - bone ID
0x249C - vertex 1
0x24A0 - vertex 2
---
So--speaking of sword trails, I’ve had this mostly written for about a month and have been meaning to post it here.
For anyone interested, here’s just about everything I know about the subject:
Creating sword trails requires running accumulated parameter-driven data through about 4 processes that ultimately generate a pile of XYZ,RGBA trianglestrip vertices to “draw” each frame the draw function is allowed to run.
1- sword trail file data is instantiated in a block of character-specific values that follow the internal player data table. There is a table like this for each character; each is different, and sword users store their sword trail parameters in it. The parameters create a specification needed for drawing non-beamsword trails, and can be easily modified in the form of code or file data modifications.
2- the [C4] subaction event defines untimed windows in a character’s action state animation in which the render status and beamsword trail flags are manipulated to start/stop sword trails being drawn according to the above parameters. In addition, the [B4] subaction event can be used to animate beamsword length. These can both be manipulated with Crazy Hand.
3- in order to actually create the sword trail -- each frame, if the render status (operated on by the above [C4] event) has been assigned a value >=0, then origin/transformation data is inherited from the bone instance specified by the sword trail boneID parameter and stored in the player entity data where it can be referenced as needed. While >=0, the render status increments by 1 each frame, and caps at 3. The trail does not draw until increment 2; as increments 0 and 1 are used to wipe old keyframe data before starting the actual drawing on status 2+ (presumably as a way of preventing keyframe artifacts.)
4- If the render status is >=2, then the draw function will actively use 3 poles generated from an accumulated 3 frames of “keyframe” data to calculate a trianglestrip made out of XYZ,RGBA data that interpolate color and alpha across the resulting arc.
involved symbols:
involved data:
1- sword trail file data is instantiated in a block of character-specific values that follow the internal player data table. There is a table like this for each character; each is different, and sword users store their sword trail parameters in it. The parameters create a specification needed for drawing non-beamsword trails, and can be easily modified in the form of code or file data modifications.
2- the [C4] subaction event defines untimed windows in a character’s action state animation in which the render status and beamsword trail flags are manipulated to start/stop sword trails being drawn according to the above parameters. In addition, the [B4] subaction event can be used to animate beamsword length. These can both be manipulated with Crazy Hand.
3- in order to actually create the sword trail -- each frame, if the render status (operated on by the above [C4] event) has been assigned a value >=0, then origin/transformation data is inherited from the bone instance specified by the sword trail boneID parameter and stored in the player entity data where it can be referenced as needed. While >=0, the render status increments by 1 each frame, and caps at 3. The trail does not draw until increment 2; as increments 0 and 1 are used to wipe old keyframe data before starting the actual drawing on status 2+ (presumably as a way of preventing keyframe artifacts.)
4- If the render status is >=2, then the draw function will actively use 3 poles generated from an accumulated 3 frames of “keyframe” data to calculate a trianglestrip made out of XYZ,RGBA data that interpolate color and alpha across the resulting arc.
involved symbols:
Code:
Symbols:
--Sword Trail Update--
8006d1ec $?_player_bodyArticle_update?
800c2fd8 $!_SwordTrail_placeKeyframeFromBone
802852b8 $!_Beamsword_writeVertexData (writes to internal player 0x20F8 and 0x20FC)
8000b1cc sins_Spawn_Article (used to update body article positions from bone matrix data?)
80373078 $?_relatedTo_boneTransformation? (updates bone + parents with new matrix data?)
--Sword Trail Draw--
80390fc0 $?_unk_blrl_relatedTo_GFX? (includes the following function as a blrl link)
80390ed0 $?_unk_blrl_loop_relatedTo_GFX? (loop may be related draw process)
80080e18 $?_unk_link_callsPlayerDisplayState_Draw_Logic
800805c8 $!_playerDisplayState_Draw_Logic (draws things like hitboxes and stuff too)
800c2600 $!_SwordTrail_Draw
80285300 $!_Beamsword_returnDrawData (used to fetch sword trail parameters for item)
Body Articles seem to just work by inheriting coordinates from player bones.
Code:
Character/Item-specific Sword Trail Parameters:
-internal player data offset
0x2D4 -> 0x78 = Marth/Roy (0x2498, as used by costume dependant sword trail codes)
0x2D4 -> 0x64 = Link/YLink (0x2484)
-internal item data offset
0xC4 -> 0x4 -> 0x1C = Held Beamsword (color/taper coefs only)
(See call @800c3058 for more info about rtoc values used for beamsword verts)
Structure:
-- For draw update --
0x00 float Trail End Taper Coefficient 1 (assumed to be % of player 0x20F8)
0x04 float Trail End Taper Coefficient 2 (assumed to be % of player 0x20FC)
0x08 AOB[2] Starting Alpha, Ending Alpha
0x0A AOB[3] R1, G1, B1 (color channels for gradient color in vertex 1)
0x0E AOB[3] R2, G2, B2 (color channels for gradient color in vertex 2)
(bytes missing from this specification appear to be unparsed)
-- For keyframe update, non-beamsword only--
0x14 word Player Bone attachment (ID)
0x18 float pole vertex 1 (used for 0x20F8 assignment in non-beamsword trails)
0x1C float pole vertex 2 (used for 0x20FC)
---
Sword Trail “Keyframes”
Player Sword Trail Keyframes:
internal player data offset
0x20B0 float[6] Keyframe 0 slot (array of 6 floats)
0x20C8 float[6] Keyframe 1 slot (see slot struct below)
0x20E0 float[6] Keyframe 2 slot
0x20F8 float Current Pole Vertex 1 (create a length for trianglstrip)
0x20FC float Current Pole Vertex 2 (modified differently depending on player or item data)
0x2100 byte sign extended, render status; IDs are as follows:
-1 = Termination status (no keyframe article update, no draw)
0, 1 = Initialization (clobber old keyframe artifacts with new data from bone, no draw)
2, 3+ = Draw (create new keyframes and draw)
2+ = int is used in calculation for drawing trianglestrip vertices
(when between 0 and 2, status will increment each frame. Caps at 3)
0x2101 (FE000000) - 7-bit keyframe incrementer (decides which slot to use for keyframe; >2=overflow )
0x2101 (01000000) - use beamsword trail from held item instead of default trail
The 7-bit incrementer stored in player 0x2101 is used to designate which of these 3 keyframe slot allocations to use for the current frame update--leaving the other 2 frames to be used as a part of a decaying trail.
Sword Trail Keyframe Slot:
0x00 float Global X position (inherited directly from bone_0x50)
0x04 float Global Y position (bone_0x60)
0x08 float Global Y position (bone_0x70)
0x0C float X Shear? Rotation? (bone_0x44)
0x10 float Y Shear? Rotation? (bone_0x54)
0x14 float Z Shear? Rotation? (bone_0x64)
---
Sword Trail Trianglestrips
$!_SwordTrail_Draw 0x74(sp) array of vertices:
0x00 float Global X position
0x04 float Global Y position
0x08 float Global Z position
0x0C AOB[4] RR, GG, BB, AA (color channels for this vertex)
---
Note: sins_spawn_article is used to generate the keyframe data.
In this case, this function essentially just updates the target bone and passes the updated transformation data to something else.
A set of 2 XYZ floats are pulled from the "matrix" values listed below in order to create a position/scale/direction for the keyframe pole origins.
(Common?) Bone Instance Structure:
0x00 pointer data in DOL created on instantiation?
0x04 word? unk
0x08 point next sibling bone
0x0C point parent bone
0x10 point child bone?
0x14 word 32-bit Flag field:
0x14 (10) This sometimes appears to control whether children bones have accessories displayed
0x15 (80) Matrix Freeze (transformations cease until unflagged, causes bone to stay in place)
0x15 (60) 2-bit - 1,2 value freeze game? 3 value does nothing? No freeze when matrix isn't updating
0x15 (04) display accessory (sometimes seems to affect something else)
0x15 (01) display accessory specular highlights
0x16 (40) related to accessory? seems to hide model
0x16 (10) related to animation? freezes bone and screws up other bones that use it in animation
0x16 (08) rotate accessory to face camera (inconsistent between accessories)
0x16 (04) rotate accessory pitch (?) to face camera (will freeze game if used together with 08 flag)
0x16 (02) rotate accessory pitch+yaw (?) to face camera (will freeze game if used with 08 flag)
0x17 (80) disable accessory ambient light? reflective material?
0x17 (40) matrix frame udate flag (0=needs update this frame, 1=already updated this frame)
0x17 (20) related to accessory? freezes game, but not if accessory is hidden
0x17 (10) related to accessory? seems to hide model
End of flags
0x18 point accessory pointer (to instantiated object--material/mesh displayed in addition to this bone)
-- ex, think Marth's princess tiara
0x1C float X rotation (these appear to be relative to parent bone)
0x20 float Y rotation
0x24 float Z rotation
0x28 float ?? (0 for most actions...)
0x2C float X scale
0x30 float Y scale
0x34 float Z scale
0x38 float X translaion
0x3C float Y translaion
0x40 float Z translaion
0x44 float X Shear? Rotation? (start of matrix?)
0x48 float ??
0x4C float ??
0x50 float X Global Position <-(relative to stage, very useful)
0x54 float Y Shear? Rotation?
0x58 float ??
0x5C float ??
0x60 float Y Global Position <-
0x64 float Z Shear? Rotation?
0x68 float ??
0x6C float ??
0x70 float Z Global Position <-
0x74 point unk, only observed null (5.0 errors)
0x78 point unk, pointer to array of floats
0x7C point current animation interpolation timer instance (shapeAnim?)
0x80 point unk, only observed null (5.0 errors)
0x84 point inherited DAT bone struct
0x88+ ?? Allocation garbage?
0xA0 end of struct
Animation Interpolation Timer Structure:
0x00 ??
0x04 float Current frame of interpolation
0x08 ??
0x0C float Final frame of interpolation
0x10 float frame-rate of interpolation
0x14 float pointer to interpolation parse
Animation Interpolation Parse Structure:
0x00 point next interpolation parse?
0x04 point parse pointer
0x08 point body of data to be parsed
0x0C word length of body to be parsed
0x10 ?? (floats and flags)---
Sword Trail Parameters -- Instantiated File Data
Sword trail parameters describe variables that can be used to change the way sword trails are calculated and drawn. Similar data structures exist for drawing beamsword trails, though the keyframe data is handled a bit differently in order to animate the length of the trail vertices.
For normal player sword trails, a silly ctr-based structure exists in both the draw/keyframe update functions and is responsible for designating where in the player entity default sword trail article data has been loaded. The list is keyed to the internal character index, but only for the range that includes sword users.
The non-sword users included in this list will causes erroneous/inappropriate use of the C4 event to potentially read arbitrary data in place of a real structure; which may end up crashing if forced. With some small steps however, this routine can be exploited to read data from wherever; thereby allowing (in theory) for every character to have a “normal” sword trail so long it can be reliably pointed to during the course of each update.
The following absurd ctr-based pointer structure could feasibly be exploited to give a wide selection of characters default handles for these fake “normal” sword trail parameters; though without a bit of function surgery, this would exclude the 6 characters at the beginning of the internal character roster, as well as all boss/wireframe characters. (if anyone’s interested, I have details on some tested methods of getting around this)
![]()
The point of this mess is to produce a pointer to a formatted character-specific data structure that can be handled by a single routine. This messy control structure exists in both the sword trail keyframe update and draw functions, where the resulting routine handles the keyframe/draw according to the provided parameters.
I’ve been calling this common data structure “Sword Trail Parameters” and they are comprised of 2 tables used separately for each routine.
The game uses the pointer at internal player data offset 0x2D4 to access these character-specific parameters for sword users after a player has been properly instantiated. My understanding is that Dantarion’s notes describe these as “Article Floating Points.”
---
Inside of a player entity, vanilla sword trail parameters can be accessed like so:
Marth/Roy = internal player data offset 0x2D4 -> 0x78
Link/YLink = internal player data offset 0x2D4 -> 0x64
As proven effective by codes like costume dependent marth sword trail colors, the functionally equivalent internal player data offsets seem to be:
0x2498 = Marth/Roy sword trail data
0x2484 = Link/Ylink sword trail data
-- These can be accessed via Achilles’s custom character data modification subaction event.
The data is formatted like so:
-- For draw update --
0x00 - float - Trail End Taper Coefficient 1 (assumed to be % of player 0x20F8)
0x04 - float - Trail End Taper Coefficient 2 (assumed to be % of player 0x20FC)
0x08 - AOB[2] - Starting Alpha, Ending Alpha (opacity of trail from newest to oldest keyframe)
0x0A - AOB[3] - R1, G1, B1 (color channels for gradient color in vertex 1)
0x0E - AOB[3] - R2, G2, B2 (color channels for gradient color in vertex 2)
(bytes missing from this specification appear to be unparsed)
-- For keyframe update, non-beamsword only--
0x14 - word - Player Bone attachment (boneID)
0x18 - float - pole vertex 1 (used for 0x20F8 assignment in non-beamsword trails)
0x1C - float - pole vertex 2 (used for 0x20FC)
For normal player sword trails, a silly ctr-based structure exists in both the draw/keyframe update functions and is responsible for designating where in the player entity default sword trail article data has been loaded. The list is keyed to the internal character index, but only for the range that includes sword users.
The non-sword users included in this list will causes erroneous/inappropriate use of the C4 event to potentially read arbitrary data in place of a real structure; which may end up crashing if forced. With some small steps however, this routine can be exploited to read data from wherever; thereby allowing (in theory) for every character to have a “normal” sword trail so long it can be reliably pointed to during the course of each update.
The following absurd ctr-based pointer structure could feasibly be exploited to give a wide selection of characters default handles for these fake “normal” sword trail parameters; though without a bit of function surgery, this would exclude the 6 characters at the beginning of the internal character roster, as well as all boss/wireframe characters. (if anyone’s interested, I have details on some tested methods of getting around this)
The point of this mess is to produce a pointer to a formatted character-specific data structure that can be handled by a single routine. This messy control structure exists in both the sword trail keyframe update and draw functions, where the resulting routine handles the keyframe/draw according to the provided parameters.
I’ve been calling this common data structure “Sword Trail Parameters” and they are comprised of 2 tables used separately for each routine.
The game uses the pointer at internal player data offset 0x2D4 to access these character-specific parameters for sword users after a player has been properly instantiated. My understanding is that Dantarion’s notes describe these as “Article Floating Points.”
---
Inside of a player entity, vanilla sword trail parameters can be accessed like so:
Marth/Roy = internal player data offset 0x2D4 -> 0x78
Link/YLink = internal player data offset 0x2D4 -> 0x64
As proven effective by codes like costume dependent marth sword trail colors, the functionally equivalent internal player data offsets seem to be:
0x2498 = Marth/Roy sword trail data
0x2484 = Link/Ylink sword trail data
-- These can be accessed via Achilles’s custom character data modification subaction event.
The data is formatted like so:
-- For draw update --
0x00 - float - Trail End Taper Coefficient 1 (assumed to be % of player 0x20F8)
0x04 - float - Trail End Taper Coefficient 2 (assumed to be % of player 0x20FC)
0x08 - AOB[2] - Starting Alpha, Ending Alpha (opacity of trail from newest to oldest keyframe)
0x0A - AOB[3] - R1, G1, B1 (color channels for gradient color in vertex 1)
0x0E - AOB[3] - R2, G2, B2 (color channels for gradient color in vertex 2)
(bytes missing from this specification appear to be unparsed)
-- For keyframe update, non-beamsword only--
0x14 - word - Player Bone attachment (boneID)
0x18 - float - pole vertex 1 (used for 0x20F8 assignment in non-beamsword trails)
0x1C - float - pole vertex 2 (used for 0x20FC)
---
Sword Trail Timing with Subaction Events
@tatatat0
Itaru
@MagicScrumpy
UnclePunch
Ripple
Sword trails are initialized by the C4 subaction event (like those used to modify character movesets in Crazy Hand.)
The event writes to a signed byte in the player entity that stores a value I’ve been calling the “Render Status ID” in my notes. Each frame, a pair of update functions read this ID (for each player) in order to determine whether or not to set up and draw a sword trail.
The full subaction event syntax looks like this:
![]()
(FC000000) - “C4” opcode
(02000000) - Beamsword trail flag
(01FFFFFF) - 25-bit signed int -- render status
(0000000FF) - 8-bit signed int that is parsed in place of above int
The entity data that holds the extracted SINT is only 8-bit; so the extra bits in this int are completely uninterpreted. Since the value is signed, these unused bits reflect the sign; creating an 18-bit sign flag. I believe we can take advantage of this in the future to create a custom subaction event index -- perhaps dedicated to generating and managing primitives like sword trails.
The SINT is used in the draw calculation as a loop count number, as well as a few other things. The number also serves as a logical threshold for actually drawing the sword trail. It goes like this:
Upon action state transitions, the ID is automatically set to -1 (terminate.)
This all means that setting it to 0, 1, 2, or 3+ will have roughly the same effect for the duration of an action state--with the difference involving only 2 (currently understood) things:
Examples:
C4000000 - “Set render status to 0, use normal trail”
C6000000 - “Set render status to 0, use beamsword trail”
C5FFFFFF - “Set render status to -1, terminating the trail before action state transition”
C4000003 - “start drawing without wiping last known trail positions”
---
The beamsword flag optionally included in the [C4] subaction event syntax will determine whether or not to use player article data over data pulled from the beamsword item entity held by a player. This relies on the beamsword item actually being held by the player, and will not work otherwise.
![]()
-- a side note: the [B4] player subaction event seems to adjust the length of a held beamsword item. I have not investigated this syntax yet.
The event writes to a signed byte in the player entity that stores a value I’ve been calling the “Render Status ID” in my notes. Each frame, a pair of update functions read this ID (for each player) in order to determine whether or not to set up and draw a sword trail.
The full subaction event syntax looks like this:
(FC000000) - “C4” opcode
(02000000) - Beamsword trail flag
(01FFFFFF) - 25-bit signed int -- render status
(0000000FF) - 8-bit signed int that is parsed in place of above int
The entity data that holds the extracted SINT is only 8-bit; so the extra bits in this int are completely uninterpreted. Since the value is signed, these unused bits reflect the sign; creating an 18-bit sign flag. I believe we can take advantage of this in the future to create a custom subaction event index -- perhaps dedicated to generating and managing primitives like sword trails.
The SINT is used in the draw calculation as a loop count number, as well as a few other things. The number also serves as a logical threshold for actually drawing the sword trail. It goes like this:
- -1 == termination; no trail updates are performed while trail status is like this
- 0, 1 == initialization; the trail is active but not drawn. This increments by 1 each frame
- 2, 3+ == draw; the trail is active, and this number is used in the draw calculation.
Upon action state transitions, the ID is automatically set to -1 (terminate.)
This all means that setting it to 0, 1, 2, or 3+ will have roughly the same effect for the duration of an action state--with the difference involving only 2 (currently understood) things:
- Trail keyframe placements use initialization frames (status 0 and 1) to wipe old keyframes from memory by updating 2/3 of them without draw frames. Without these initialization frames, the trail will have leftover keyframe artifacts from the last time it was active.
- As the render status number increases, the trail becomes more and more opaque. Setting it too high above 3 seems to potentially crash the game or have strange effects on the trail drawing.
Examples:
C4000000 - “Set render status to 0, use normal trail”
C6000000 - “Set render status to 0, use beamsword trail”
C5FFFFFF - “Set render status to -1, terminating the trail before action state transition”
C4000003 - “start drawing without wiping last known trail positions”
---
The beamsword flag optionally included in the [C4] subaction event syntax will determine whether or not to use player article data over data pulled from the beamsword item entity held by a player. This relies on the beamsword item actually being held by the player, and will not work otherwise.
-- a side note: the [B4] player subaction event seems to adjust the length of a held beamsword item. I have not investigated this syntax yet.
---
Placing and Transforming sword trails on the Stage
@Geranimo @SinsOfApathy
The 2 functions that access sword trail parameters seem to use the top and bottom halves separately.
The “Keyframe” update function (@800c2fd8 1.02) works with the bottom half of the data (pole vertices and bone ID.)
In all characters, 3 “keyframe” slots in the player entity store a pair of XYZ float coordinates denoting global position and some kind of transformation for sword trails belonging to that player.
I’ve been calling these “Keyframes” in my notes because an accompanying incrementer value counts each new player frame, overflowing back to 0 once it reaches 3. This is to indicate which of the 3 keyframe slots is the active keyframe, and which (in descending order) are the latter 2 frames of a decaying trail.
At all times, these keyframes can be used to draw sword trails--but if the previous 2 garbage keyframes have not been cleared, then doing so will display keyframe artifacts:
![]()
Internal player data offsets:
0x20B0 - start of Keyframe 0 slot [array of 6 floats] (XYZ position, XYZ transformation)
0x20C8 - start of Keyframe 1 slot [array of 6 floats]
0x20E0 - start of Keyframe 2 slot [array of 6 floats]
0x20F8 - float - Current Pole Vertex 1 (usually base) -- these are just a length from inversion point
0x20FC - float - Current Pole Vertex 2 (usually tip)
0x2100 - signed byte - Render Status (C4 event writes to this)
0x2101 - 7-bit int (mask 0xFE) - Keyframe Incrementer
0x2101 - 1-bit flag (mask 0x01) - Beamsword Trail Flag (C4 event writes to this)
The XYZ position and XYZ transformation floats are used together with the vertices to create a position, scale, and direction for 3 poles that come together in the draw function to create a complex trianglestrip calculation.
These floats are pulled directly from player bones after running a transformation update on the specified bone if it hasn’t already updated this frame. It uses flags to determine if these transformations are necessary, and can be used with code to control precisely when any given bone will be animated:
gfycat - controlling transformation updates (indefinitely)
gfycat - controlling transformation updates (on per-frame basis)
The actual values pulled seem to come from a kind of transformation matrix that exists in every bone:
0x44 - float - X unk transformation
0x48 - float - ??
0x4C - float - ??
0x50 - float - X Global Position <-(relative to stage, very useful)
0x54 - float - Y unk transformation
0x58 - float - ??
0x5C - float - ??
0x60 - float - Y Global Position <-
0x64 - float - Z unk transformation
0x68 - float - ??
0x6C - float - ??
0x70 - float - Z Global Position <-
-- see the bone instance offsets in my first spoiler for more
It would seem that many things in this game that “attach” to a bone somehow work by directly inheriting floats from this matrix, and they use 8000b1cc sins_spawn_article to do so.
The “Keyframe” update function (@800c2fd8 1.02) works with the bottom half of the data (pole vertices and bone ID.)
In all characters, 3 “keyframe” slots in the player entity store a pair of XYZ float coordinates denoting global position and some kind of transformation for sword trails belonging to that player.
I’ve been calling these “Keyframes” in my notes because an accompanying incrementer value counts each new player frame, overflowing back to 0 once it reaches 3. This is to indicate which of the 3 keyframe slots is the active keyframe, and which (in descending order) are the latter 2 frames of a decaying trail.
At all times, these keyframes can be used to draw sword trails--but if the previous 2 garbage keyframes have not been cleared, then doing so will display keyframe artifacts:
Internal player data offsets:
0x20B0 - start of Keyframe 0 slot [array of 6 floats] (XYZ position, XYZ transformation)
0x20C8 - start of Keyframe 1 slot [array of 6 floats]
0x20E0 - start of Keyframe 2 slot [array of 6 floats]
0x20F8 - float - Current Pole Vertex 1 (usually base) -- these are just a length from inversion point
0x20FC - float - Current Pole Vertex 2 (usually tip)
0x2100 - signed byte - Render Status (C4 event writes to this)
0x2101 - 7-bit int (mask 0xFE) - Keyframe Incrementer
0x2101 - 1-bit flag (mask 0x01) - Beamsword Trail Flag (C4 event writes to this)
The XYZ position and XYZ transformation floats are used together with the vertices to create a position, scale, and direction for 3 poles that come together in the draw function to create a complex trianglestrip calculation.
These floats are pulled directly from player bones after running a transformation update on the specified bone if it hasn’t already updated this frame. It uses flags to determine if these transformations are necessary, and can be used with code to control precisely when any given bone will be animated:
gfycat - controlling transformation updates (indefinitely)
gfycat - controlling transformation updates (on per-frame basis)
The actual values pulled seem to come from a kind of transformation matrix that exists in every bone:
0x44 - float - X unk transformation
0x48 - float - ??
0x4C - float - ??
0x50 - float - X Global Position <-(relative to stage, very useful)
0x54 - float - Y unk transformation
0x58 - float - ??
0x5C - float - ??
0x60 - float - Y Global Position <-
0x64 - float - Z unk transformation
0x68 - float - ??
0x6C - float - ??
0x70 - float - Z Global Position <-
-- see the bone instance offsets in my first spoiler for more
It would seem that many things in this game that “attach” to a bone somehow work by directly inheriting floats from this matrix, and they use 8000b1cc sins_spawn_article to do so.
---
Generating vertices for Drawing Sword Trail
Achilles1515
Another--much bigger--update function (@ 800c2600) uses the top half of sword trail parameters (color data, alpha data, taper coefficients) along with the resulting keyframe structure that was updated by the previous function. This function is responsible for actually drawing the trianglestrip that becomes a sword trail.
It is called 3 times per player/frame, and only runs on the 3rd call (passed r4 keeps track of a loop count that appears to handle displaying a handful of other types of primitives.) On this 3rd call, the draw only runs after the render status has incremented up to “02” in order to allow for initialization frames written by the keyframe update to wipe old keyframe data between separate sword trail swings.
The draw function that creates lines that illustrate ragdoll bones in developer mode also uses this loop, and some of the behavior of the code suggests that this loop might be involved with some kind of Z-index for rendering player entity stuff.
The function first goes to town calculating a list of vertices based off of the given keyframe data and trail parameters. After the calculating is done, a buffer in the stack containing all of the XYZ,RGBA data is written to GX FIFO in order to finally draw the resulting shape.
@800c2da4 the function is preparing to draw the vertices as a trianglestrip. From a hook at around this area, you can control how many vertices are drawn with the int in r24, and manipulate the final XYZ,RGBA array in the stack from offset 0x74(sp)
![]()
$!_SwordTrail_Draw 0x74(sp) array of vertices:
0x00 - float - Global X position
0x04 - float - Global Y position
0x08 - float - Global Z position
0x0C - AOB[4] - RR, GG, BB, AA (color channels for this vertex)
It is called 3 times per player/frame, and only runs on the 3rd call (passed r4 keeps track of a loop count that appears to handle displaying a handful of other types of primitives.) On this 3rd call, the draw only runs after the render status has incremented up to “02” in order to allow for initialization frames written by the keyframe update to wipe old keyframe data between separate sword trail swings.
The draw function that creates lines that illustrate ragdoll bones in developer mode also uses this loop, and some of the behavior of the code suggests that this loop might be involved with some kind of Z-index for rendering player entity stuff.
The function first goes to town calculating a list of vertices based off of the given keyframe data and trail parameters. After the calculating is done, a buffer in the stack containing all of the XYZ,RGBA data is written to GX FIFO in order to finally draw the resulting shape.
@800c2da4 the function is preparing to draw the vertices as a trianglestrip. From a hook at around this area, you can control how many vertices are drawn with the int in r24, and manipulate the final XYZ,RGBA array in the stack from offset 0x74(sp)
$!_SwordTrail_Draw 0x74(sp) array of vertices:
0x00 - float - Global X position
0x04 - float - Global Y position
0x08 - float - Global Z position
0x0C - AOB[4] - RR, GG, BB, AA (color channels for this vertex)
---
With all of this information, it's possible to create codes that have powerful handles over the data that goes into creating sword trail visuals.
Last edited:
AsrielMemeurr413
Smash Rookie
- Joined
- Dec 22, 2016
- Messages
- 4
These are really cool! Would it be possible for you to make a code that makes taunting slow opponents down, kind of like Bayonetta's Witch Time in Smash 4?
Super4ng
Smash Journeyman
Please tell me what you find. I am trying to do the same thing! Haha
The Cape
Smash Master
I found it in their data. Send me a PM and I can send you the two edited .dat files where that is all I changed.
The Cape
Smash Master
Not sure where the best place to ask this is, but here seems as good a place as any. When I recompile an ISO, to add a stage or something of that nature, I have to then reinstall the frame speed mod and the frame speed changes. Where is this stored at so I can properly back up the file? I already backed up Start.dol and PiCo.dat in addition to the character and stage files.
The Cape
Smash Master
So what would I need to extract from my ISO to ensure I have the FSMs on a rebuilt ISO?
UltiMario
Out of Obscurity
I went to use this code but entering a game as Giga Bowser causes a crash. It looks like 20XX solves the issue by making GB not spawn from a spawn platform, but it doesn't look like that code is available anywhere.
I've actually found posts going back to 2005 asking for this issue to be fixed (obviously from AR codes that put GB on CSS) while looking up this issue so if someone can figure out the code used to fix this that'd be great.
Achilles1515
Smash Master
Code:
Giga-Bowser and Sandbag Fall on Match Start (1.02) [Achilles]
C2069328 00000006
807E0004 2C03001F
4182000C 2C030020
40820014 3C608006
60639350 7C6803A6
4E800021 887E000C
60000000 00000000
Code:
Bowser and Sandbag Fall Instead of Warp Entry
inject @ 80069328
- AllocateAndInitPlayer function
lwz r3,4(r30) # load internal char ID
cmpwi r3,0x1f # Giga-Bowser?
beq- FALL
cmpwi r3,0x20 # Sandbag?
bne- WARP
FALL:
lis r3,0x8006 # branch back to inject function, and enter Fall
ori r3,r3,0x9350
mtlr r3
blrl
WARP:
lbz r3,0xc(r30) # default code line, load port number
Code:
-==-
Giga-Bowser & Sandbag Always Fall On Match Start
- so the game doesn't freeze
[Achilles]
Version -- DOL Offset ------ Hex to Replace ---------- ASM Code
1.02 ----- 0x80069328 --- 887E000C -> Branch
807E0004 2C03001F
4182000C 2C030020
40820014 3C608006
60639350 7C6903A6
4E800420 887E000C
48000000
-==-
Cjag
https://smashboards.com/threads/melee-gecko-codes-guide-and-discussion.327311/page-25#post-18159561
Last edited:
Cjag
Smash Cadet
Oh! Never knew there was a code for that. I'll update the patch with that code right now before I forget. Thanks, Achilles! ^^
Ripple
ᗣᗣᗣᗣ ᗧ·····•·····
- Joined
- Sep 4, 2006
- Messages
- 9,633
just the mail.dol or start.dol , whatever its called
The Cape
Smash Master
Start.dol generally doesn't work. I can try again though
By any chance is there a revision to this code that simulates 20XX 4.05's? The only ones that seem to be missing are Pichu=Crazy Hand/Pikachu=Master Hand which are the ones I seek for the Z Button code
Cjag
Achilles1515
Cjag
Achilles1515
Code:Giga-Bowser and Sandbag Fall on Match Start (1.02) [Achilles] C2069328 00000006 807E0004 2C03001F 4182000C 2C030020 40820014 3C608006 60639350 7C6803A6 4E800021 887E000C 60000000 00000000Code:Bowser and Sandbag Fall Instead of Warp Entry inject @ 80069328 - AllocateAndInitPlayer function lwz r3,4(r30) # load internal char ID cmpwi r3,0x1f # Giga-Bowser? beq- FALL cmpwi r3,0x20 # Sandbag? bne- WARP FALL: lis r3,0x8006 # branch back to inject function, and enter Fall ori r3,r3,0x9350 mtlr r3 blrl WARP: lbz r3,0xc(r30) # default code line, load port numberCode:-==- Giga-Bowser & Sandbag Always Fall On Match Start - so the game doesn't freeze [Achilles] Version -- DOL Offset ------ Hex to Replace ---------- ASM Code 1.02 ----- 0x80069328 --- 887E000C -> Branch 807E0004 2C03001F 4182000C 2C030020 40820014 3C608006 60639350 7C6903A6 4E800420 887E000C 48000000 -==-
https://smashboards.com/threads/melee-gecko-codes-guide-and-discussion.327311/page-25#post-18159561
Achilles1515
P.S. Which part of the code executes the Z Button and how can I add to the code to make it so that Pichu/Pikachu=Master Hand and Crazy Hand, and maybe even Link=Dark Link for costume purposes
Last edited:
The Cape
Smash Master
I would still like to see something that makes Mewtwo's reflector work like all the others and a way to create windboxes.
Also ideas:
Set up ledge options depending on the button you press. Example:
Under 100 getup attack: A
Over 100 getup attack: B
Then maybe X or Y, L or R, and standing could be maybe up or Z?
Able to hold up or down during a forward smash to get the angled ala Brawl and Smash 4.
Also ideas:
Set up ledge options depending on the button you press. Example:
Under 100 getup attack: A
Over 100 getup attack: B
Then maybe X or Y, L or R, and standing could be maybe up or Z?
Able to hold up or down during a forward smash to get the angled ala Brawl and Smash 4.
Last edited:
UnclePunch
Smash Ace
- Joined
- Nov 9, 2014
- Messages
- 673
Did some landing lag investigating today. Here's what I found:
Landing Notes
All landing action states go to the same function essentially. You can say there exists 2 action states hidden in "Landing". There's normal landing (land from a jump) in which the IASA function states you can interrupt after 4 frames,
and then theres a psuedo "SpecialLand". "SpecialLand" uses the same IASA function but after 4 frames, it looks for a flag set by the method of entering SpecialFall. If this flag is set to 0, you can NOT act out after 4 frames and must wait for the animation to end. Landing mid-airdodge,
landing post-airdodge,
and in most cases, landing post-UpB,
all put the character into this "helpless" landing state.
The flag is the same as the "hitstun counter" as labelled on the data sheet (0x2340). This is the value compared upon landing but it comes from 0x2358. This is where the flag is changed, and is copied into the hitstun value down the line. I've labelled this offset "Act out of Landing Flag" although it may do more.
Two of the functions that set these flags are 80099bd0,
http://i.imgur.com/EJJlMQF.png
and 800e7e78,
http://i.imgur.com/jFHjXz0.png
and are branched to from the Animation Interrupt blrl at 8006ab74. It should be noted that most characters have their own version of these functions that set the "Act Out of Flag" as well as landing speed modifier. Here's falcons for example,
http://i.imgur.com/FeW4pyS.png
Landing Speed modifier is read globally from player offset 0x2354 and is written on a per character basis. This offset is used to calculate landing lag. Dividend is usually 30, so 30 divided by this value gives you the number the animation speed will be DIVIDED by. Quotient smaller numbers = longer animation.
Summary:
http://i.imgur.com/vISyqq6.png
Landing Notes
All landing action states go to the same function essentially. You can say there exists 2 action states hidden in "Landing". There's normal landing (land from a jump) in which the IASA function states you can interrupt after 4 frames,
and then theres a psuedo "SpecialLand". "SpecialLand" uses the same IASA function but after 4 frames, it looks for a flag set by the method of entering SpecialFall. If this flag is set to 0, you can NOT act out after 4 frames and must wait for the animation to end. Landing mid-airdodge,
landing post-airdodge,
and in most cases, landing post-UpB,
all put the character into this "helpless" landing state.
The flag is the same as the "hitstun counter" as labelled on the data sheet (0x2340). This is the value compared upon landing but it comes from 0x2358. This is where the flag is changed, and is copied into the hitstun value down the line. I've labelled this offset "Act out of Landing Flag" although it may do more.
Two of the functions that set these flags are 80099bd0,
http://i.imgur.com/EJJlMQF.png
and 800e7e78,
http://i.imgur.com/jFHjXz0.png
and are branched to from the Animation Interrupt blrl at 8006ab74. It should be noted that most characters have their own version of these functions that set the "Act Out of Flag" as well as landing speed modifier. Here's falcons for example,
http://i.imgur.com/FeW4pyS.png
Landing Speed modifier is read globally from player offset 0x2354 and is written on a per character basis. This offset is used to calculate landing lag. Dividend is usually 30, so 30 divided by this value gives you the number the animation speed will be DIVIDED by. Quotient smaller numbers = longer animation.
Summary:
http://i.imgur.com/vISyqq6.png
Last edited:
donko
Smash Rookie
- Joined
- Aug 20, 2015
- Messages
- 5
could the arduino mods Hax is putting out be made into gecko codes?
i know there's a 2 frame dashback window code already, but how about those shield drop and perfect angle values?
edit: oh also the 1.0 dash speed area extension
i know there's a 2 frame dashback window code already, but how about those shield drop and perfect angle values?
edit: oh also the 1.0 dash speed area extension
Last edited:
UnclePunch
Smash Ace
- Joined
- Nov 9, 2014
- Messages
- 673
Working on it right now.
I have an app(?) called Cheat Manager on my SD card. I can use it to manage cheat codes directly on my Wii so I can load the game with the generated .gct code.
It allways works for Brawl, but now I tried it with these Melee Codes but they didn't work. I only want to be able to play with all characters even not having a memory card(hard to get here) with a saved game.
I hope anyone could help me solve this issue.
It allways works for Brawl, but now I tried it with these Melee Codes but they didn't work. I only want to be able to play with all characters even not having a memory card(hard to get here) with a saved game.
I hope anyone could help me solve this issue.
oscat
Smash Journeyman
I think gecko codes don't work with gamecube discs, only iso's. However, there's a modified version of Gecko OS that works with gamcube discs.
UnclePunch
Smash Ace
- Joined
- Nov 9, 2014
- Messages
- 673
Gotcha bud
Code:
$Disable Subcolors [UnclePunch]
C2033354 00000002
3BE00000 9BE30046
60000000 00000000Thanks!!!!!!!!
I'm making "Falco!"
Super4ng
Smash Journeyman
Is there a code that fixes the invisible ceiling glitch? Also for the IC freeze glitch
Last edited:
The Cape
Smash Master
I think their freeze glitch was removed in the PAL version.
Super4ng
Smash Journeyman
It was, but the data is stored in the DOL, so I cant exactly take the character from PAL and put it into 1.02
The Cape
Smash Master
Well if you can find the change in the DOL we can convert it to an injection mod at least.
Dodoshian
Smash Rookie
- Joined
- Jul 7, 2016
- Messages
- 21
I have been modding this game (or at least trying to learn how to) for about a year and a half. I do not understand mods like this. How was this done, and how did you learn this type of coding? Are you editing the Hex directly or converting it into some other format to better understand it? When I look at any file, I just see letters and numbers. Furthermore, while I would like to learn coding in college, I feel like it wouldn't help me with melee modding in any way whatsoever. How did the melee modding community gain all of this knowledge, and why is the knowledge so restrictive? I feel as though my hundreds of hours of research on melee modding has been in vain.
Pls Help...
Pls Help...
UnclePunch
Smash Ace
- Joined
- Nov 9, 2014
- Messages
- 673
These in-depth mods are actually replacing part of the game's code inside its executable file (start.dol). You can only get so far editing the data melee's code uses (hex editing character files). Editing the code itself yields much more powerful changes.
Dolphin has a debugger that transcribes the hexadecimal machine code into readable assembly code. From there you poke around with memory addresses, see what codelines/functions do what, label what you know, and from there you can make function calls as if you had the source code.
What you see above is what is written. Programs like ASMWiird and CodeWrite convert this to hexadecimal aka gecko code format.
If you're looking to learn, I highly suggest using Dan Salvato's tutorial series here. This is what I used to learn, as well as asking questions, so if you choose to pursue this don't be afraid to ask for help.
As for why it's so "restrictive", its very time consuming and has a high barrier of entry (much like melee itself). Only a few people put in the time because they feel the reward (being able modifying the best game in the world) is worth the time.
Last edited:
Dodoshian
Smash Rookie
- Joined
- Jul 7, 2016
- Messages
- 21
Ok, so I have another question. How are gecko codes able to be added into the ISO (for example, through Melee Code Manager) if they are not actually changing the Hexadecimal code directly? It sounds like more of a hardware (Gamecube) mod than a Software (Melee) mod. I will definitely check out the tutorial by Dan Salvato as well. In the meantime, should I begin learning an actual programming language (I just started learning C a few days ago)?These in-depth mods are actually replacing part of the game's code inside its executable file (start.dol). You can only get so far editing the data melee's code uses (hex editing character files). Editing the code itself yields much more powerful changes.
Dolphin has a debugger that transcribes the hexadecimal machine code into readable assembly code. From there you poke around with memory addresses, see what codelines/functions do what, label what you know, and from there you can make function calls as if you had the source code.
What you see above is what is written. Programs like ASMWiird and CodeWrite convert this to hexadecimal aka gecko code format.
If you're looking to learn, I highly suggest using Dan Salvato's tutorial series here. This is what I used to learn, as well as asking questions, so if you choose to pursue this don't be afraid to ask for help.
As for why it's so "restrictive", its very time consuming and has a high barrier of entry (much like melee itself). Only a few people put in the time because they feel the reward (being able modifying the best game in the world) is worth the time.
Last edited:
Dodoshian
Smash Rookie
- Joined
- Jul 7, 2016
- Messages
- 21
UnclePunch
Okay, so I watched the guide by Dan Salvato. From looking at your assembly code, I think that you made the game think you are grounded while airborne so that you can grab and throw? Is this correct? Did you find these values by trial and error, or are they posted somewhere like here?
Last edited:
UnclePunch
Smash Ace
- Joined
- Nov 9, 2014
- Messages
- 673
MCM inserts the gecko codehandler (a chunk of code that parses a gecko codelist and applies the changes each frame) into the iso. I do recommend learning the basics of C although it's not 100% necessary. Only the base concepts apply to coding assembly and it's a lot less user friendly.
Yeah, that's correct. I allowed z to enter the grab action state mid air, and hot swapped the move logic for grabbing to allow for the character to fall correctly and land correctly. This same process had to be done for every grab related action state, such as grab wait, pummel, throws, etc which is why the code is so long. As for how I knew to do that, the concept of move logic functions were discovered by Magus I believe. After seeing that, I looked into their code, where they were called from, made minor changes and observed what happened until I had a good understanding of how to go about changing it. To my knowledge there is no collection of info about doing stuff like that, it mainly comes from poking around in game code for extended periods of time. Like I said, if you're curious about how a certain aspects of the game engine works, I'm here to answer any questions I know the answer to.
Okay, so I watched the guide by Dan Salvato. From looking at your assembly code, I think that you made the game think you are grounded while airborne so that you can grab and throw? Is this correct? Did you find these values by trial and error, or are they posted somewhere like here?
Dodoshian
Smash Rookie
- Joined
- Jul 7, 2016
- Messages
- 21
Okay, thank you very much for the reply! I don't know how much you know about MCM, but if I wanted to convert a gecko code into a format that MCM can read, would I need the assembly code too? For example, this code that you made; how would one typically go about inserting it directly into the start.dol? I tried looking at some codes in the MCM mods library and comparing them to other gecko codes and machine codes to figure out the format, but it is a little confusing. Also, you said that MCM inserts the gecko codehandler into the iso...does this mean that the game is able to run the gecko 'engine' in-game on its own, allowing for any gecko code to be run independently, or does it mean that the codes themselves are put into some format that the game reads as if it was in the game's code originally?
I think my biggest question is how a game can actually run a code. Is the PowerPC processor really able to do thousands of computations every frame? I understand how it can execute code through moving and manipulating values, but how is the processor able to know when something happens in-game (like a character landing, for example)? When it knows that a memory value changes, does it know from checking to see if it changed, or is it 'told' by memory? Is the game constantly scanning every single value all the time to determine when something changes? This is a concept that I don't understand. Sorry if I am not making much sense.
Last edited: