Skip to content

Decompile revision 0xA changes for wireless_communication_status without fakematch#744

Open
AZero13 wants to merge 1 commit into
pret:masterfrom
AZero13:fixthematch
Open

Decompile revision 0xA changes for wireless_communication_status without fakematch#744
AZero13 wants to merge 1 commit into
pret:masterfrom
AZero13:fixthematch

Conversation

@AZero13

@AZero13 AZero13 commented Mar 24, 2026

Copy link
Copy Markdown
Contributor

So one of the emerald UBFixes mentions that 0xFF can happen, and mentions that GROUPTYPE_NONE is 0xFF, and shouldn't be used as an index into groupCounts. It mentions that int theory the only activity with this group type (ACTIVITY_SEARCH) wouldn't satisfy the condition below, but not necessarily.

Well, revision A of FRLG fixes this but has an even broader check, by skipping ALL invalid values by adding a range check. For this reason, I have also opted to do || UBFIX.

@AZero13 AZero13 force-pushed the fixthematch branch 3 times, most recently from 976776a to 651e84f Compare March 24, 2026 17:20
@AZero13 AZero13 changed the title Fix fake match introduced by Revision 0xA in wireless_communication_status Decompile revision A changes for wireless_communication_status without fakematch Apr 2, 2026
@AZero13 AZero13 changed the title Decompile revision A changes for wireless_communication_status without fakematch Decompile revision 0xA changes for wireless_communication_status without fakematch Apr 2, 2026
@AZero13

AZero13 commented Apr 27, 2026

Copy link
Copy Markdown
Contributor Author

Whole 0xA version should be UBFix because none of this seems emulation related and Nintendo wouldn't change a line of code without a reason.

@AZero13 AZero13 force-pushed the fixthematch branch 2 times, most recently from 2f3c5a7 to 5db9393 Compare May 28, 2026 00:02
@AZero13

AZero13 commented Jun 1, 2026

Copy link
Copy Markdown
Contributor Author

Should I just put the entire Revision A version of this function under UBFix or BUGFIX?

…tatus

So one of the emerald UBFixes mentions that 0xFF can happen, and mentions that GROUPTYPE_NONE is 0xFF, and shouldn't be used as an index into groupCounts. It mentions that int theory the only activity with this group type (ACTIVITY_SEARCH) wouldn't satisfy the condition below, but not necessarily.

Well, revision A of FRLG fixes this but has an even broader check, by skipping ALL invalid values by adding a range check. For this reason, I have also opted to do || UBFIX.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant