-snip-

[Sponge]

-snip-

[Vega]

The rainbow function code (plus the various elements rainbow code) utlilize Mem81 (which autoclears after every race). I looked at future fly and I don't see any use of Mem81 in that code (The use of mem81 in mkwii codes wasn't really done til Bully came along the mkw coding scene in 2012). I noticed you changed the Mem81 addresses in the rainbow codes. There's no need for that, that won't fix your issue (unless you have other codes in your GCT also use Mem81).

None of the codes' memory/execution addresses are shared. I'm not sure how these would conflict each other. The future fly code makes plenty use of the Exception Vector area. Have you tested a GCT just using the two rainbow codes w/ future fly, nothing else added on.

[Sponge]

Tried a gct by itself and the same issue occurs, no idea why.

[Vega]

Btw regarding the discord convo, nice find on the r14 issue. That never crossed my mind. Someday, I'll need to rewrite the sources for mdmwii's future fly and stalking codes

[Vega]

Hey sponge, finally remembered to take another look at the Rainbow function code (for your request to fix the r14 issue).

I added some quick instructions to prevent r14 from effecting mdmwiis stalkin and future fly... let me know if this works...

Code:

stw r14, -0x4 (sp) #Store r14 to negative stack area

lis r12, 0x8000 #Set vector address
lwz r14, 0x0498 (r12) #Load current r14 for use of this code only, starts as 0

lis r15,-32400
addi r22,r22,1
cmpwi r22,5
blt- 0xA8
cmpwi r18,0
bne- 0x0C
li r20,255
li r18,1
cmpwi r18,1
bne- 0x14
addi r14,r14,1
cmpwi r14,255
bne- 0x08
li r18,2
cmpwi r18,2
bne- 0x14
subi r20,r20,1
cmpwi r20,0
bne- 0x08
li r18,3
cmpwi r18,3
bne- 0x14
addi r17,r17,1
cmpwi r17,255
bne- 0x08
li r18,4
cmpwi r18,4
bne- 0x14
subi r14,r14,1
cmpwi r14,0
bne- 0x08
li r18,5
cmpwi r18,5
bne- 0x14
addi r20,r20,1
cmpwi r20,255
bne- 0x08
li r18,6
cmpwi r18,6
bne- 0x14
subi r17,r17,1
cmpwi r17,0
bne- 0x08
li r18,1
li r22,0
stb r20,0(r15)
stb r14,1(r15)
stb r17,2(r15)
cmpwi r0,0

stw r14, 0x0498 (r12) #Update r14, for this code only

lwz r14, -0x4 (sp) #Retrieve old r14 from negative stack area

[Sponge]

Hey sponge, finally remembered to take another look at the Rainbow function code (for your request to fix the r14 issue).

I added some quick instructions to prevent r14 from effecting mdmwiis stalkin and future fly... let me know if this works...

Code:

stw r14, -0x4 (sp) #Store r14 to negative stack area

lis r12, 0x8000 #Set vector address
lwz r14, 0x0498 (r12) #Load current r14 for use of this code only, starts as 0

lis r15,-32400
addi r22,r22,1
cmpwi r22,5
blt- 0xA8
cmpwi r18,0
bne- 0x0C
li r20,255
li r18,1
cmpwi r18,1
bne- 0x14
addi r14,r14,1
cmpwi r14,255
bne- 0x08
li r18,2
cmpwi r18,2
bne- 0x14
subi r20,r20,1
cmpwi r20,0
bne- 0x08
li r18,3
cmpwi r18,3
bne- 0x14
addi r17,r17,1
cmpwi r17,255
bne- 0x08
li r18,4
cmpwi r18,4
bne- 0x14
subi r14,r14,1
cmpwi r14,0
bne- 0x08
li r18,5
cmpwi r18,5
bne- 0x14
addi r20,r20,1
cmpwi r20,255
bne- 0x08
li r18,6
cmpwi r18,6
bne- 0x14
subi r17,r17,1
cmpwi r17,0
bne- 0x08
li r18,1
li r22,0
stb r20,0(r15)
stb r14,1(r15)
stb r17,2(r15)
cmpwi r0,0

stw r14, 0x0498 (r12) #Update r14, for this code only

lwz r14, -0x4 (sp) #Retrieve old r14 from negative stack area

Tried this and it only cycles through red and yellow now. Also, it still freezes the color when activating future fly or stalking so it must be another reguster

[Vega]

After more analysis, r18 & r22 are some sort of a conditional-status trackers, while r14, r17, & r20 values are being altered depending on the 'status' of the conditional trackers. r15 is used for the mem81 address reference where r14/17/20 are stored and updated at. Other rainbow codes will thus use the mem81 values and adjust accordingly.

It's obviously a no-no to use the global variable registers like this.

I adjusted my source more... After debugging the code a tiny bit, all the global variable registers that are being used always start at 0. So ill just load up unused memory from the vector area for all custom global variable register values. Then update the vector area accordingly. mem81 will not be touched so other rainbow codes should still function right. In between all of this, a stack push will be done so the real variable register values don't get effected. Hopefully this will work unless I'm missing something super obvious here...

Code:

stwu sp, -0x50 (sp) #Stack push
stmw r14, 0x8 (sp) #Backup global variable values

lis r11, 0x8000 #Set vector address
lmw r14, 0x0498 (r11) #Load custom global variable values

addi r22,r22,1
cmpwi r22,5 #XX value in code for user to fill in, 5 used for compilation purposes
blt- 0xA8
cmpwi r18,0
bne- 0x0C
li r20,255
li r18,1
cmpwi r18,1
bne- 0x14
addi r14,r14,1
cmpwi r14,255
bne- 0x08
li r18,2
cmpwi r18,2
bne- 0x14
subi r20,r20,1
cmpwi r20,0
bne- 0x08
li r18,3
cmpwi r18,3
bne- 0x14
addi r17,r17,1
cmpwi r17,255
bne- 0x08
li r18,4
cmpwi r18,4
bne- 0x14
subi r14,r14,1
cmpwi r14,0
bne- 0x08
li r18,5
cmpwi r18,5
bne- 0x14
addi r20,r20,1
cmpwi r20,255
bne- 0x08
li r18,6
cmpwi r18,6
bne- 0x14
subi r17,r17,1
cmpwi r17,0
bne- 0x08
li r18,1
li r22,0

lis r12, 0x8170 #Set mem81 address

stb r20,0(r12) #Update mem81 values
stb r14,1(r12)
stb r17,2(r12)

stmw r14, 0x0498 (r11) #Update custom global variable values

lwz r14, 0x8 (sp) #Recover global variable values
addi sp, sp, 0x50 #Stack pop

cmpwi r0, 0 #Default instruction

[Sponge]

After more analysis, r18 & r22  are some sort of a conditional-status trackers, while r14, r17, & r20 values are being altered depending on the 'status' of the conditional trackers. r15 is used for the mem81 address reference where r14/17/20 are stored and updated at. Other rainbow codes will thus use the mem81 values and adjust accordingly.

It's obviously a no-no to use the global variable registers like this.

I adjusted my source more... After debugging the code a tiny bit, all the global variable registers that are being used always start at 0. So ill just load up unused memory from the vector area for all custom global variable register values. Then update the vector area accordingly. mem81 will not be touched so other rainbow codes should still function right. In between all of this, a stack push will be done so the real variable register values don't get effected. Hopefully this will work unless I'm missing something super obvious here...

Code:

stwu sp, -0x50 (sp) #Stack push
stmw r14, 0x8 (sp) #Backup global variable values

lis r11, 0x8000 #Set vector address
lmw r14, 0x0498 (r11) #Load custom global variable values

addi r22,r22,1
cmpwi r22,5 #XX value in code for user to fill in, 5 used for compilation purposes
blt- 0xA8
cmpwi r18,0
bne- 0x0C
li r20,255
li r18,1
cmpwi r18,1
bne- 0x14
addi r14,r14,1
cmpwi r14,255
bne- 0x08
li r18,2
cmpwi r18,2
bne- 0x14
subi r20,r20,1
cmpwi r20,0
bne- 0x08
li r18,3
cmpwi r18,3
bne- 0x14
addi r17,r17,1
cmpwi r17,255
bne- 0x08
li r18,4
cmpwi r18,4
bne- 0x14
subi r14,r14,1
cmpwi r14,0
bne- 0x08
li r18,5
cmpwi r18,5
bne- 0x14
addi r20,r20,1
cmpwi r20,255
bne- 0x08
li r18,6
cmpwi r18,6
bne- 0x14
subi r17,r17,1
cmpwi r17,0
bne- 0x08
li r18,1
li r22,0

lis r12, 0x8170 #Set mem81 address

stb r20,0(r12) #Update mem81 values
stb r14,1(r12)
stb r17,2(r12)

stmw r14, 0x0498 (r11) #Update custom global variable values

lwz r14, 0x8 (sp) #Recover global variable values
addi sp, sp, 0x50 #Stack pop

cmpwi r0, 0 #Default instruction

The game blackscreens upon booting the Title Screen

[Vega]

Ye i botched an instruction lol..

lwz r14, 0x8 (sp) #Recover global variable values

change that to...

lmw r14, 0x8 (sp)

[Sponge]

Ye i botched an instruction lol..

lwz r14, 0x8 (sp) #Recover global variable values

change that to...

lmw r14, 0x8 (sp)

Ok now it boots, but the game gets stuck on this weird shade of green now and doesn't change from that, even when I don't use future fly