• 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

Nuthilo

Smash Cadet
Joined
Dec 6, 2016
Messages
34
If I remember correctly, Melee Code Manager only does Start.dol.

Try opening PiCo.dat with a hex editor and do the overwrite I posted.
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:

Ripple

ᗣᗣᗣᗣ ᗧ·····•·····
Joined
Sep 4, 2006
Messages
9,632
Punkline Punkline I changed /link's sword to be bigger but now the sword trail is off, how can I fix this?
 

The Cape

Smash Master
Joined
May 16, 2004
Messages
4,478
Location
Carlisle, PA
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
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
Go to that Offset and replace the Byte with what I posted. It's just a straight overwrite over whatever is there initially.
Did it, ty. One more question...How do you mod in stages? The ones in Scrumpy's vid look cool
 

Punkline

Dr. Frankenstack
Premium
Joined
May 15, 2015
Messages
423
Ripple 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:
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.
involved data:
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)

---

Sword Trail Timing with Subaction Events
@tatatat0 Itaru Itaru @MagicScrumpy UnclePunch UnclePunch Ripple 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:
  • -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.
The ID will increment by 1 each frame when not terminated, and will cap at 3.

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.

---

Generating vertices for Drawing Sword Trail
Achilles1515 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)

---

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.

(note that this and some of my other gifs are utilizing a code that uses the Melee Meter coefficient in order to quantize ranges of floats as single bytes, so the "trail parameters" above are custom, fabricated data)
 
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
Joined
Jun 22, 2014
Messages
263
Location
Mississippi
I have been trying to find where I can remove hurt bubbles. I would like to remove DK's Tie Hurtbox and Mewtwo's tail, but so far I can only find textures.

Please help.
Please tell me what you find. I am trying to do the same thing! Haha
 

The Cape

Smash Master
Joined
May 16, 2004
Messages
4,478
Location
Carlisle, PA
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.
 

UltiMario

Out of Obscurity
Joined
Sep 23, 2007
Messages
10,439
Location
Maryland
NNID
UltiMario
3DS FC
1719-3180-2455
I've extracted that code from 20XX 3.0.2, I'm sure the most recent version would have a better code (he said he improved most codes), but it does the job. Code in the spoiler.

Z button to toggle alternate characters in CSS (1.02) [Achilles1515]
C2262F48 0000002E
3E008048 62100830
89F00000 3E608046
6273B0FC 3A200000
A693000C 3A310001
3EA0804D 62B59274
3EC0803F 62D20DE4
1EB10024 7E52AA14
8AF20001 A2520002
3EA08043 62B52087
1DD10008 7EB57214
8AB50000 2C150021
408200F4 2C140010
408200EC 2C0F0000
418100DC 2C120C0C
418200B4 2C120F0F
41820040 2C120404
4182005C 2C120707
41820078 2C120303
408200BC A2B60B78
2C150505 40820010
3AA0051D B2B60B78
4800009C 3AA00505
B2B60B78 48000090
A2B60CC8 2C151212
40820010 3AA01213
B2B60CC8 48000078
3AA01212 B2B60CC8
4800006C A2B60B94
2C150C0C 40820010
3AA00C1C B2B60B94
48000054 3AA00C0C
B2B60B94 48000048
A2B60BE8 2C150000
40820010 3AA0001B
B2B60BE8 48000030
3AA00000 B2B60BE8
48000024 A2B60C74
2C150E0E 40820010
3AA00E20 B2B60C74
4800000C 3AA00E0E
B2B60C74 39E0000A
48000010 2C0F0000
41820008 39EFFFFF
99F00000 2C110004
4180FEB8 3CA0804A
60000000 00000000
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
Joined
Jun 18, 2007
Messages
3,211
Location
Cincinnati / Columbus OH
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.
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 Cjag
https://smashboards.com/threads/melee-gecko-codes-guide-and-discussion.327311/page-25#post-18159561
 
Last edited:

Ripple

ᗣᗣᗣᗣ ᗧ·····•·····
Joined
Sep 4, 2006
Messages
9,632
what isn't working? if you replace the .dol then all the FSMs you created should apply to the characters
 

FGUG2021

Smash Rookie
Joined
Mar 7, 2015
Messages
14
Location
Tampa, FL
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 Cjag Achilles1515 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 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 Cjag
https://smashboards.com/threads/melee-gecko-codes-guide-and-discussion.327311/page-25#post-18159561
 

FGUG2021

Smash Rookie
Joined
Mar 7, 2015
Messages
14
Location
Tampa, FL
Achilles1515 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
Joined
May 16, 2004
Messages
4,478
Location
Carlisle, PA
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.
 
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
 
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
 
Last edited:

Cdoggle

Smash Rookie
Joined
Jun 10, 2017
Messages
1
NNID
Cdoggle14
I was wondering if there was a 'taunt to grow' code out there. There prob is, I just can't find it.
 

AlanHaTe

Smash Ace
Joined
Feb 13, 2010
Messages
588
Location
Mexico
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.
 

oscat

Smash Journeyman
Joined
Apr 29, 2014
Messages
240
Location
So Cal
NNID
drlnklngmars
3DS FC
0318-9801-6641
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.
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.
 

Super4ng

Smash Journeyman
Joined
Jun 22, 2014
Messages
263
Location
Mississippi
Is there a code that fixes the invisible ceiling glitch? Also for the IC freeze glitch
 
Last edited:

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...
 

UnclePunch

Smash Ace
Joined
Nov 9, 2014
Messages
673
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...
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
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.
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)?
 
Last edited:

Dodoshian

Smash Rookie
Joined
Jul 7, 2016
Messages
21
UnclePunch 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
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)?
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.

UnclePunch 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?
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.
 

Dodoshian

Smash Rookie
Joined
Jul 7, 2016
Messages
21
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, 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:
Top Bottom