-
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!
Request Green Overlay when in wait
- Thread starter ssknight7
- Start date
Punkline
Dr. Frankenstack
- Joined
- May 15, 2015
- Messages
- 423
Whipped this up really quick using the body aura event system. It uses a series of injections to qualify states by their button interrupt routines rather than by using any specific state IDs, so it should catch uninterrupted standing, jumping/falling, squatting, downed, and cliffcatch wait logic from any state that uses it. Only briefly tested it, but I made sure that it's frame perfect for what it detects.
Copy and paste it into your Mods Library in MCM to use it like any other DOL mod.
You can change the color that's used by modifying the RGBA_color value, which is pure green by default. (00FF00FF)
Edit: And here's a gecko code equivalent (source):
Copy and paste it into your Mods Library in MCM to use it like any other DOL mod.
You can change the color that's used by modifying the RGBA_color value, which is pure green by default. (00FF00FF)
Rich (BB code):
-==-
Green Overlay when in Wait State
Uses various wait interrupts to trigger a configurable color overlay.
Configure the color by editing the aura data in the <WaitAura> function
[Punkline]
<WaitAura> NTSC 1.02
RGBA_color = 0x00FF00FF
# modify this to change the color used by the aura
rGObj=3; rPlayer=4; rAuraData=5
xAuraTimer=0x408; xAuraPointer=0x410; xAuraPriority=0x430
lis r0, <<WaitAura>>+_aura_data@h
lwz rPlayer, 0x2C(rGObj)
ori rAuraData, r0, <<WaitAura>>+_aura_data@l
li r0, 0
stw rAuraData, xAuraPointer(rPlayer)
stw r0, xAuraTimer(rPlayer)
li r0, 100
stw r0, xAuraPriority(rPlayer)
addi r4, rPlayer, xAuraTimer
lis r0, 0x800bff34@h
ori r5, r0, 0x800bff34@l
b 0x80014258
# branch into color FX update to apply aura
_aura_data: .long /*
Frame 0:
*/ 0x48000000, RGBA_color, /* set overlay color...
*/ 0x2C000001, /* and wait for a frame...
Frame 1:
*/ 0x30000000, /* destroy overlay color...
*/ 0x28000000 /* and terminate aura*/
NTSC 1.02 --- 8008cdf4 ---- 80010024 -> Branch
# Air wait
cmpwi r3, 0
bne- _return
mr r3, r30
bl <WaitAura>
li r3, 0
_return:
lwz r0, 0x0024(sp)
.long 0
------------- 8008a630 ---- 8001001c -> Branch
# Stand wait
cmpwi r3, 0
bne- _return
mr r3, r31
bl <WaitAura>
li r3, 0
_return:
lwz r0, 0x001C(sp)
.long 0
------------- 800d6570 ---- 8001001c -> Branch
# Squat wait
cmpwi r3, 0
bne- _return
mr r3, r31
bl <WaitAura>
li r3, 0
_return:
lwz r0, 0x001C(sp)
.long 0
------------- 80098148 ---- 8001001c -> Branch
# Downed wait
cmpwi r3, 0
bne- _return
mr r3, r30
bl <WaitAura>
li r3, 0
_return:
lwz r0, 0x001C(sp)
.long 0
------------- 8009a958 ---- 8001001c -> Branch
# Cliffcatch wait
cmpwi r3, 0
bne- _return
mr r3, r31
bl <WaitAura>
li r3, 0
_return:
lwz r0, 0x001C(sp)
.long 0
#Edit: And here's a gecko code equivalent (source):
Code:
$Green Overlay when in Wait State [Punkline]
C208CDF4 00000012
48000070 7C0802A6
9421FFF0 90010014
48000049 7CA802A6
80010014 38210010
7C0803A6 8083002C
38000000 90A40410
90040408 38000064
90040430 38840408
3C00800B 6005FF34
3C008001 60004258
7C0903A6 4E800420
4E800021 48000000
00FF00FF 2C000001
30000000 28000000
2C030000 40820010
7FC3F378 4BFFFF89
38600000 80010024
60000000 00000000
C208A630 00000004
2C030000 40820010
7FE3FB78 4BFFFF61
38600000 8001001C
60000000 00000000
C20D6570 00000004
2C030000 40820010
7FE3FB78 4BFFFF39
38600000 8001001C
60000000 00000000
C2098148 00000004
2C030000 40820010
7FC3F378 4BFFFF11
38600000 8001001C
60000000 00000000
C209A958 00000004
2C030000 40820010
7FE3FB78 4BFFFEE9
38600000 8001001C
60000000 00000000
Last edited:
do you still have that iasa code??? im looking for one and cant find it
BlayzeEmAll
Smash Rookie
- Joined
- Mar 4, 2014
- Messages
- 13
- NNID
- AsceBlayze
from my slippi iso
$Optional: Turn yellow on IASA frames
C2071960 00000007
98032218 98030504
3C00437F 900304B8
900304BC 900304C4
38000000 900304C0
900304C8 900304CC
900304D0 900304D4
60000000 00000000
LunarySSF2
Smash Rookie
Hey I can't use your code
when adding it to the Melee Code Manager library, the software is tripping
I can't create a GCT file because I get this error :
could you convert it to a Gecko Code ?
when adding it to the Melee Code Manager library, the software is tripping
I can't create a GCT file because I get this error :
could you convert it to a Gecko Code ?
Punkline
Dr. Frankenstack
- Joined
- May 15, 2015
- Messages
- 423
Hey I can't use your code
when adding it to the Melee Code Manager library, the software is tripping
I can't create a GCT file because I get this error :
could you convert it to a Gecko Code ?
In short -- not without resorting to some unsafe or otherwise insane methods.
Gecko codes can only be made from very simple DOL mods.
You should not expect DOL mods to work as gecko codes unless all of the pieces are completely self-contained, and do not rely on the individual components “talking” to one another with any kind of shared information.
This code requires 5 injection points to function correctly, and includes a custom function and a custom data table to centralize the customizable aura code parsing behavior in a way that can be recalled from these 5 separate locations in the game. The injection codes therefor need to be aware of this function somehow, and gecko codes don’t have a means of doing that.
(This is why MCM was not allowing you to convert it automatically.)
In the past, I have used static addresses to sneak around this problem in order to provide gecko code compatibility with my DOL mods, but it’s becoming more apparent to me over time that this is a bad habit for general cases because it’s an increasingly dangerous solution.
In principle, relying on static addresses to get around the locality problem in gecko injection codes isn’t much different than “manually” installing a DOL mod.
Doing this can create code incompatibilities that lead to game crashes because it requires vandalizing some limited part of the static DOL that other codes can (and will want to) use for the same purpose.
Unlike other similar risks like competing injection hooks: completely unrelated codes that attempt to use the same valuable, limited, static address resources will create code conflicts that are difficult to trace without checking every one of your codes individually for compatibility errors. If each code is individually responsible for manually selecting its static address for this kind of work-around, then it is not safe.
It might be a suitable work-around if it were automated by some script that converted addresses or offsets into symbol names, and re-compiled them as necessary to avoid conflicts.
The reason I say it’s a bad habit to do this is because you can’t take it back once you’ve made a work-around like this. Static addresses never change, and if you’ve shared a code that uses them just to make it work as a gecko code, then that static address will forever cause problems in any other code that uses it with this code. If your purpose for using a work-around like this is simply connecting all of the pieces of a gecko code for little compatibility hacks, then you’re going to run out of static address space very quickly with no recourse besides abandoning your old codes.
This solution has the potential to build into a problem over time as new codes are made, because the areas that can be used safely in the DOL for this purpose are very limited; and the more addresses that are used up, the more likely they will be involved in conflicts in the future caused by new codes colliding with old ones.
Doing this can create code incompatibilities that lead to game crashes because it requires vandalizing some limited part of the static DOL that other codes can (and will want to) use for the same purpose.
Unlike other similar risks like competing injection hooks: completely unrelated codes that attempt to use the same valuable, limited, static address resources will create code conflicts that are difficult to trace without checking every one of your codes individually for compatibility errors. If each code is individually responsible for manually selecting its static address for this kind of work-around, then it is not safe.
It might be a suitable work-around if it were automated by some script that converted addresses or offsets into symbol names, and re-compiled them as necessary to avoid conflicts.
The reason I say it’s a bad habit to do this is because you can’t take it back once you’ve made a work-around like this. Static addresses never change, and if you’ve shared a code that uses them just to make it work as a gecko code, then that static address will forever cause problems in any other code that uses it with this code. If your purpose for using a work-around like this is simply connecting all of the pieces of a gecko code for little compatibility hacks, then you’re going to run out of static address space very quickly with no recourse besides abandoning your old codes.
This solution has the potential to build into a problem over time as new codes are made, because the areas that can be used safely in the DOL for this purpose are very limited; and the more addresses that are used up, the more likely they will be involved in conflicts in the future caused by new codes colliding with old ones.
---
In this case, I can rewrite the injections in a way that requires no communication between them as a way of avoiding static addresses all together; however it will cause you to have to write any customizations that you want to make to all 5 injections individually, and will blow the code up to half a kilobyte in size for all of the redundant definitions.
Normally this would be kind of insane, but it’s a reasonable enough solution for this code if you’re desperate to keep it mostly intact and still safely incorporate it in your GCT:
Rich (BB code):
-==-
GECKO - Green Overlay when in Wait State
Uses various wait interrupts to trigger a configurable color overlay.
You may edit the color by altering the symbols in each injection
[Punkline]
NTSC 1.02 --- 8008cdf4 ---- 80010024 -> Branch
# Air wait
cmpwi r3, 0
bne- _return
mr r3, r30
RGBA_color = 0x00FF00FF
# modify this to change the color used by the aura
rGObj=3; rPlayer=4; rAuraData=5
xAuraTimer=0x408; xAuraPointer=0x410; xAuraPriority=0x430
bl _aura_data
mflr rAuraData
lwz rPlayer, 0x2C(rGObj)
li r0, 0
stw rAuraData, xAuraPointer(rPlayer)
stw r0, xAuraTimer(rPlayer)
li r0, 100
stw r0, xAuraPriority(rPlayer)
addi r4, rPlayer, xAuraTimer
lis r0, 0x800bff34@h
ori r5, r0, 0x800bff34@l
lis r0, 0x80014258@h
ori r0, r0, 0x80014258@l
mtlr r0
blrl
li r3, 0
b _return
_aura_data: blrl
.long /*
Frame 0:
*/ 0x48000000, RGBA_color, /* set overlay color...
*/ 0x2C000001, /* and wait for a frame...
Frame 1:
*/ 0x30000000, /* destroy overlay color...
*/ 0x28000000 /* and terminate aura*/
_return:
lwz r0, 0x0024(sp)
.long 0
------------- 8008a630 ---- 8001001c -> Branch
# Stand wait
cmpwi r3, 0
bne- _return
mr r3, r31
RGBA_color = 0x00FF00FF
# modify this to change the color used by the aura
rGObj=3; rPlayer=4; rAuraData=5
xAuraTimer=0x408; xAuraPointer=0x410; xAuraPriority=0x430
bl _aura_data
mflr rAuraData
lwz rPlayer, 0x2C(rGObj)
li r0, 0
stw rAuraData, xAuraPointer(rPlayer)
stw r0, xAuraTimer(rPlayer)
li r0, 100
stw r0, xAuraPriority(rPlayer)
addi r4, rPlayer, xAuraTimer
lis r0, 0x800bff34@h
ori r5, r0, 0x800bff34@l
lis r0, 0x80014258@h
ori r0, r0, 0x80014258@l
mtlr r0
blrl
li r3, 0
b _return
_aura_data: blrl
.long /*
Frame 0:
*/ 0x48000000, RGBA_color, /* set overlay color...
*/ 0x2C000001, /* and wait for a frame...
Frame 1:
*/ 0x30000000, /* destroy overlay color...
*/ 0x28000000 /* and terminate aura*/
_return:
lwz r0, 0x001C(sp)
.long 0
------------- 800d6570 ---- 8001001c -> Branch
# Squat wait
cmpwi r3, 0
bne- _return
mr r3, r31
RGBA_color = 0x00FF00FF
# modify this to change the color used by the aura
rGObj=3; rPlayer=4; rAuraData=5
xAuraTimer=0x408; xAuraPointer=0x410; xAuraPriority=0x430
bl _aura_data
mflr rAuraData
lwz rPlayer, 0x2C(rGObj)
li r0, 0
stw rAuraData, xAuraPointer(rPlayer)
stw r0, xAuraTimer(rPlayer)
li r0, 100
stw r0, xAuraPriority(rPlayer)
addi r4, rPlayer, xAuraTimer
lis r0, 0x800bff34@h
ori r5, r0, 0x800bff34@l
lis r0, 0x80014258@h
ori r0, r0, 0x80014258@l
mtlr r0
blrl
li r3, 0
b _return
_aura_data: blrl
.long /*
Frame 0:
*/ 0x48000000, RGBA_color, /* set overlay color...
*/ 0x2C000001, /* and wait for a frame...
Frame 1:
*/ 0x30000000, /* destroy overlay color...
*/ 0x28000000 /* and terminate aura*/
_return:
lwz r0, 0x001C(sp)
.long 0
------------- 80098148 ---- 8001001c -> Branch
# Downed wait
cmpwi r3, 0
bne- _return
mr r3, r30
RGBA_color = 0x00FF00FF
# modify this to change the color used by the aura
rGObj=3; rPlayer=4; rAuraData=5
xAuraTimer=0x408; xAuraPointer=0x410; xAuraPriority=0x430
bl _aura_data
mflr rAuraData
lwz rPlayer, 0x2C(rGObj)
li r0, 0
stw rAuraData, xAuraPointer(rPlayer)
stw r0, xAuraTimer(rPlayer)
li r0, 100
stw r0, xAuraPriority(rPlayer)
addi r4, rPlayer, xAuraTimer
lis r0, 0x800bff34@h
ori r5, r0, 0x800bff34@l
lis r0, 0x80014258@h
ori r0, r0, 0x80014258@l
mtlr r0
blrl
li r3, 0
b _return
_aura_data: blrl
.long /*
Frame 0:
*/ 0x48000000, RGBA_color, /* set overlay color...
*/ 0x2C000001, /* and wait for a frame...
Frame 1:
*/ 0x30000000, /* destroy overlay color...
*/ 0x28000000 /* and terminate aura*/
_return:
lwz r0, 0x001C(sp)
.long 0
------------- 8009a958 ---- 8001001c -> Branch
# Cliffcatch wait
cmpwi r3, 0
bne- _return
mr r3, r31
RGBA_color = 0x00FF00FF
# modify this to change the color used by the aura
rGObj=3; rPlayer=4; rAuraData=5
xAuraTimer=0x408; xAuraPointer=0x410; xAuraPriority=0x430
bl _aura_data
mflr rAuraData
lwz rPlayer, 0x2C(rGObj)
li r0, 0
stw rAuraData, xAuraPointer(rPlayer)
stw r0, xAuraTimer(rPlayer)
li r0, 100
stw r0, xAuraPriority(rPlayer)
addi r4, rPlayer, xAuraTimer
lis r0, 0x800bff34@h
ori r5, r0, 0x800bff34@l
lis r0, 0x80014258@h
ori r0, r0, 0x80014258@l
mtlr r0
blrl
li r3, 0
b _return
_aura_data: blrl
.long /*
Frame 0:
*/ 0x48000000, RGBA_color, /* set overlay color...
*/ 0x2C000001, /* and wait for a frame...
Frame 1:
*/ 0x30000000, /* destroy overlay color...
*/ 0x28000000 /* and terminate aura*/
_return:
lwz r0, 0x001C(sp)
.long 0
#
Punkline
Dr. Frankenstack
- Joined
- May 15, 2015
- Messages
- 423
Recently, I have been working on some GNU Assembler macros that help make it easier to write PowerPC codes/functions for games like Melee in raw assembly.
One of the tools included in these macros simply allows gecko C2 codes (injection blocks) to be written serially as part of the same assembly. I’m realizing in retrospect that this offers a unique solution to the locality problem I mentioned in my previous post by allowing each of the individual injections to “see” each other using assembler labels.
Somebody pointed out to me a long time ago that this method would be unsafe in hacked gecko code handlers that break apart the injection containers into non-contiguous sections -- but this should not be the case for GCT files. It should be a reliable solution in the way gecko codes are commonly used today.
---
Here’s the source, using a snapshot of my macro libraries. I’ve updated my post here to include the assembled gecko code:
Rich (BB code):
.include "melee"
punkpc ppc, gecko
gecko 0x8008cdf4
# Air wait
b 0f
_WaitAura:
RGBA_color = 0x00FF00FF
# modify this to change the color used by the aura
rGObj=3; rPlayer=4; rAuraData=5
xAuraTimer=0x408; xAuraPointer=0x410; xAuraPriority=0x430
prolog
bl _get_aura_data
mflr rAuraData
epilog
lwz rPlayer, 0x2C(rGObj)
li r0, 0
stw rAuraData, xAuraPointer(rPlayer)
stw r0, xAuraTimer(rPlayer)
li r0, 100
stw r0, xAuraPriority(rPlayer)
addi r4, rPlayer, xAuraTimer
lis r0, 0x800bff34@h
ori r5, r0, 0x800bff34@l
; ba 0x80014258
# branch into color FX update to apply aura
_get_aura_data:
blrl
_aura_data: .long /*
Frame 0:
*/ 0x48000000, RGBA_color, /* set overlay color...
*/ 0x2C000001, /* and wait for a frame...
Frame 1:
*/ 0x30000000, /* destroy overlay color...
*/ 0x28000000 /* and terminate aura*/
0:
cmpwi r3, 0
bne- _return1
mr r3, r30
bl _WaitAura
li r3, 0
_return1:
lwz r0, 0x0024(sp)
gecko 0x8008a630
# Stand wait
cmpwi r3, 0
bne- _return2
mr r3, r31
bl _WaitAura
li r3, 0
_return2:
lwz r0, 0x001C(sp)
gecko 0x800d6570
# Squat wait
cmpwi r3, 0
bne- _return3
mr r3, r31
bl _WaitAura
li r3, 0
_return3:
lwz r0, 0x001C(sp)
gecko 0x80098148
# Downed wait
cmpwi r3, 0
bne- _return4
mr r3, r30
bl _WaitAura
li r3, 0
_return4:
lwz r0, 0x001C(sp)
gecko 0x8009a958
# Cliffcatch wait
cmpwi r3, 0
bne- _return5
mr r3, r31
bl _WaitAura
li r3, 0
_return5:
lwz r0, 0x001C(sp)
#
gecko.end
josephcarnec
Smash Rookie
- Joined
- Jun 17, 2023
- Messages
- 1
Hi,
Thanks for the code! I have been using it for weeks
I'd like to have the alpha changed so it is more transparent but I am not sure how to create a gecko code from the code above? I am on linux so I don't think I can use a mod manager for slippi?
Thanks for the code! I have been using it for weeks
I'd like to have the alpha changed so it is more transparent but I am not sure how to create a gecko code from the code above? I am on linux so I don't think I can use a mod manager for slippi?