It's interesting because almost every FE game has some mechanism to prevent empty levels. The Switch ones will literally rig it so that you get at least two stat gains. This "high" you get from getting a good level is so fundamental to the game that they manipulate probability to force it to happen
Code from the OoT decomp project for the metal bars in Ganon's Castle. This code demonstrates that the developers put a check in the game to prevent the bars from opening under certain circumstances. Unlike the anti-piracy check with Zelda's hair, this one does *not* check the CIC chip.
Code from the OoT decomp project showing the anti-piracy check involved with fishing. Specifically, if the code detects that the game has been pirated, it sets sReelLock to a non-zero value, which will cause problems in another part of the code (specifically `Fishing_UpdateFish`)
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:
A picture of Zelda's hair scaled weirdly on the ares emulator, a modern and accurate N64 emulator. To produce this image, I modified the code so that the matrix scaling in my previous post would always occur.
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
Source code from the Ocarina of Time matching decompilation project. It shows a matrix involved with Zelda's hair being scaled differently if the anitpiracy check fails.
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:
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
A chart showing Majora's Mask decompilation percentage over time. As of December 10th, every single metric is at 100% for the US N64 version
Happy to announce the Majora's Mask decompilation project reached 100% completion for the US N64 version! Still tons of work to be done (other versions, more documentation, fixing fake matches, etc.), but an incredibly satisfying end to years of work. Thanks to everyone who has contributed to this!
We just released v4.6.1 of Universal Pokemon Randomizer ZX (surprise!)
It's a pretty small changelog, but importantly "Fix Music" for static Pokemon works in BW2 again, among a few other changes.
github.com/Ajarmar/univ...
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...
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)
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)
The dog race in Majora's Mask has a very rudimentary form of anti-cheat. In this video, I edit the blue dog's position to be inside the goal shortly after the race begins, but I still lose (1/4): www.youtube.com/watch?v=GX2o...
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)
An image of decompiled source code for Majora's Mask. It shows strange behavior described in the post as it exists in the code.
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)
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)
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)
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)
You may have seen this video from indextic showing off the Mega Eeno glitch, but why does it happen? I did some research and I think I know what's going on (1/6): www.youtube.com/watch?v=EI__...
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)
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)
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)
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)
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)
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)
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)
A screenshot of a text dump of Majora's Mask, showcasing the various dog messages
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)
Found some very strange behavior regarding the dogs in the Doggy Racetrack in MM that's either an oversight or some bizarre intended behavior. (1/9)
An image of Link holding a Deku Stick in Ocarina of Time 3D. A striped pattern is visible on the stick, similar to the pattern seen in the first image in this thread.
One last thing: to my eyes, it looks like Grezzo drew some inspiration from the glitchy Ocarina of Time stick when they were remaking the game for the 3DS. What do you think? (8/8)
Link holding a Deku Stick close to the camera after the aforementioned bug has been fixed. The stick has a uniform texture and partially blends in with the background.
That explains why the sticks look different, but what would the stick look like if you fixed these glitches? Behold, the glitch-free stick. It looks...kind of boring? I can see why they kept the bug in place, since it looks pretty bland without it (7/8)
Despite being unused in Majora's Mask, these joint tables still remain, and the table used for Child Link with the Hylian Shield happens to be the first thing after the Deku Stick texture. Thus, MM treats some limb rotations as if they were part of the Deku Stick texture (6/8)
When you change equipment in the pause menu, the image of Link can change as well. These are *not* static images loaded from the ROM; they are created dynamically by positioning Link's limbs using something called a "joint table", which tell the game how to rotate his limbs (5/8)
