darkeye.bsky.social
@darkeye.bsky.social
I think you're right to be skeptical; it just seems ridiculous. But that's exactly why I appreciate the decomp projects; having reverse-engineered source code can settle a lot of questions. I figured I should post the code for the other two I mentioned just for transparency's sake:
June 4, 2025 at 4:45 PM
I probably wouldn't believe it either without the code. But here's a picture from a more accurate emulator showing it too. From what I can tell, there are only three checks:
- the Zelda's hair one
- fish will always let go after 50 frames
- the bars in the Ganon's Castle escape sequence won't open
June 4, 2025 at 4:34 PM
They deliberately and specifically blew up Zelda's hair (there are multiple different variations of Zelda in the code, and it only affects the one that shows up in this cutscene). They even had to remove it for the GameCube versions. You can see the code responsible in the OoT decompilation project:
June 4, 2025 at 4:05 PM
It sounds like they're using some sort of software compatibility layer? www.nintendo.com/us/whatsnew/...

Specifically, "the process of converting game data for Switch to run on Switch 2 is performed on a real-time basis as the data is read in." Wouldn't surprise me if there are bugs as a result
Ask the Developer Vol. 16: Nintendo Switch 2 — Part 4 - News - Nintendo Official Site
This article has been translated from the original Japanese content. This interview was conducted before the system was released. In this 16th volume of Ask the Developer, an interview series in which...
www.nintendo.com
April 2, 2025 at 7:34 PM
In this video, I set the blue dog's position to be the same as before, but I also update their "race status" variable to act as if they've passed the appropriate points. This allows me to cheat egregiously but still win. (4/4): www.youtube.com/watch?v=pSZY...
1511249640909602820 jQMW QGi7iS wp0m
YouTube video by darkeye14
www.youtube.com
November 23, 2024 at 9:17 AM
To be more specific, a dog must pass through points 9 and 11 (in that order) to finish the race. These numbers are a bit strange, because the racetrack has a total of 45 points! (3/4)
November 23, 2024 at 9:17 AM
This is because the racetrack is effectively just a bunch of points that the dogs run along, and there's a system in place to make sure that only dogs that have crossed specific points are allowed to finish the race. (2/4)
November 23, 2024 at 9:17 AM
As a result, if an Eeno is in the middle of submerging when it's time to combine, it will have a target scale of 15, which is 1500x larger than intended. If it absorbs other Eenos, it will grow into a Mega Eeno (6/6)
November 23, 2024 at 9:06 AM
When the Eenos start combining, the game usually sets this variable to 0.01, which is their normal scale. But, bizarrely, they specifically go out of their way *not* to do this when an Eeno is in the middle of submerging underground when they all start combining (5/6)
November 23, 2024 at 9:06 AM
You probably noticed that before they started combining, the target scale was 6 and 15. This is because the two variables I've talked about are actually *the same variable*. They reused the same float to hold both the animation frame numbers and the target scale (4/6)
November 23, 2024 at 9:06 AM
The Eeno also has a variable that keeps track of its "target scale" when the split-up Eenos all combine into one. The Eenos that get absorbed have a target scale of 0 (which makes them shrink and disappear), while the large Eeno has a target scale of 2x the normal scale (3/6)
November 23, 2024 at 9:06 AM
The Eeno has a variable that tracks which frame in its animation it should do something with its snowball. This video shows that on frame 6 of its snowball making animation, the snowball appears in its hand, and on frame 15 of the throwing animation, the snowball leaves its hand (2/6)
November 23, 2024 at 9:06 AM
This is either a classic off-by-one oversight, or it's intentional on the developer's part to introduce even more variance into the race. It's impossible to say without asking a developer, though the same behavior *is* present in MM3D. (9/9)
November 23, 2024 at 8:56 AM
The end result of this is that there are two "lying dogs". One dog says it's in good condition, but is actually in normal condition. Another dog says it's in normal condition, but is actually in bad condition. (8/9)
November 23, 2024 at 8:56 AM
I made a mod that makes it so dogs that are actually in bad condition are magenta. As you can see, I picked up a dog that indicates it's in normal condition (since the text starts with "Rrr-Ruff!"), but when the race starts, you can clearly see it's in bad condition. (7/9)
November 23, 2024 at 8:56 AM
In particular, it adds the "condition value" to 0x3539. This is off-by-one compared to EnDg! The same ranges shown in my third tweet still apply to EnRacedog, so a dog that *says* it's in normal condition when you pick it up can *actually* be in bad condition when racing. (6/9)
November 23, 2024 at 8:56 AM
However, there are actually two separate dog actors. When you're picking your dog, you're interacting with EnDg. When the dog race is going, you're watching EnRacedog run around. And EnRacedog has its own way of determining a dog's condition. (5/9)
November 23, 2024 at 8:56 AM
To make the race more variable, the condition of the dogs is decided randomly when you load into the racetrack. To determine what text to show when you pick them up, they add this "condition value" to 0x3538 (the first text ID used for racing dogs). (4/9)
November 23, 2024 at 8:56 AM
As you can see, text IDs 0x3538 to 0x353D indicate good condition, text IDs 0x353E to 0x3541 indicate normal condition, and text IDs 0x3542 to 0x3546 indicate bad condition. They're just three simple contiguous blocks of text. (3/9)
November 23, 2024 at 8:56 AM
The dogs can either be in good, normal, or bad condition. They indicate this in their text; the text that starts with "Ruff!" indicates good condition, the text that starts with "Rrr-Ruff!" indicates normal condition, etc. (2/9)
November 23, 2024 at 8:56 AM