Data Redundancy Errors Explained

What can happen when a game's variables get out of control and the system is put into an inconsistent state? It's all explained right here.
LINKS
INLINE LINKS
EXTERNAL LINKS
PATRONS
Thank you to all of my supporters on Patreon and SubscribeStar. Your help keeps the channel going!

[jarrod]

These conditions should never happen in the first place right?...
Said every programmer at some point ever.

[ds]

One obscure correction: At 21:58, you state that the reason Mario immediately drops the cork box while the bobomb thinks it's held is because the two objects are colliding, but the actual reason is unrelated and IMO somewhat interesting. When a bobomb is held normally, it has a fuse timer that counts up every frame. Once this timer is greater than a critical value, the bobomb sets a bit every frame telling Mario to drop whatever he's holding (expected to be the bobomb) so that it can explode. This forced drop only requires the bobomb to think it is being held, and so when you go to grab the cork box, the bobomb still tells Mario to drop it. This can be circumvented by overflowing the bobomb's fuse timer, at which point you can grab the cork box or any other object normally, and the bobomb will still be invisibly suspended in the air before Mario. Unfortunately, it takes over two *years* for this overflow to occur, so nobody's actually done it on a real console.

Everything else in the SM64 section seemed pretty accurate to me though, and is a great explanation of what's going on!

[jblackquill]

tbh I love that you put human-made captions on your videos, it's super nice for me as a hearing-impaired person, especially in the wake of YouTube removing community contributed captions

[frostyelkk]

The simple way to have perfect redundancy against errors;
Don't have data.

[Monody]

The list terminator literally *being* the CANCEL button in Pokémon is brilliant! They didn't have to include specific code to append that option.

[zeropointer]

My main question is why do objects that aren't meant to be thrown stop working when they are thrown.

Pannen describes these phenomenon as the "one touch rule" and that clones "can't send or receive signals".

Like those are nice colloquial explanations, but I was hoping for a more technical explanation.

Edit: So because I've yet to hear a sufficient explanation, I just looked at the disassembly source code and figured out myself.

In Mario 64, every object contains a behavior. This behavior is merely a pointer to an array of small scripts. As the game runs, each object runs through its list of scripts, most of which just call that objects loop function to update it's state.

How throwing objects work is by the method `obj_set_held_state` which takes an object and a BehaviorScript. The behavior scripts used (bhvCarrySomething3-5) in question actually do nothing: they begin, then immediately end.
What `obj_set_held_state` does is check if the object is holdable, then if it is, it checks if the passed BehaviorScript is any of those three. If it is, it sets that object's `HeldState` to either held, thrown, or dropped. This is done without every running the script
However, if the object is not holdable, it will overwrite that objects behaviour variable with the passed behaviour, which remember from above, does nothing.
For example, with the coin, this results is the coin not being able to perform its update loop, as its behaviour is now the do nothing behaviour.

Now despite this, why can we still "collect" the coin, and why doesn't it disappear. That is because collision is handled completely separately from an objects behaviour. When an object is initialize, it registers a hit-box along with an interaction type to it. A completely separate method is used to handle interactions. When Mario interacts with a coin, that coin's interacted flag is set to INTERACTED and it is here where Mario's coin counter is incremented, and 100 coin start spawns.

Normally during the coins update loop, it checks if it is interacted, and if so, spawns sparkles and unloaded. However because the coin's behaviour was overwritten, the loop never runs, hence never de-spawning.

Now why are you only allowed to touch it once, that's because the code to handle interactions completely ignore interactions between Mario and an object whose interacted flag is set to INTERACTED, and similarly to despawning, it is most object's update loop which un-sets this flag.

[najwan]

the sm64 part was really fascinating.
i've been watching pannenkoek2012's and his uncommentated channel videos explaining unintended mechanics and glitches in that game for quite a long time. while he did explained some things in great detail, the "cloning" mechanic and the whole "hands-free" ordeal weren't explored with this much detail. this video really clears things up. i went from "i.. kinda understand...?" to "oh, i see!".

good illustration, clear analogy, and great presentation. all around.

[mikebarr]

"But that's fine, right?"
[long pause]

[WaterGuns]

I appreciate you using the fonts / color schemes for the games you're talking about, as if the game itself was displaying this information to us.

[lior_haddad]

Ah yes, gen 1 Pokemon and SM64, what a great episode this is...

[MatthijsvanDuin]

For a spectacular example of things like this going wrong in a modern game, look up a Hollow Knight Any% All Glitches speedrun, which has example after example of game state being desynchronized intentionally to benefit the speedrun, breaking the game completely and allowing them to beat it in less than 15 minutes with no real bossfight along the way. (They only "fight" the Hollow Knight, and do so by duping a room from Crystal Peaks into his arena, causing him to commit suicide on the crystals.)

[proxy]

it would be interesting to have a modified ROM of Pokemon Red that has issues like these fixed.
then give them to speedrunners and see if they can find more exploits...
repeat this cycle until you have a near-bug free game.

[GameDevYal]

Nitpick: the item list in the first example contains 21 items, since you start it at ID 0 and end it at ID 20.

[marksmithwas]

(I'm around 4:46) oh, so the count variable comes first! That explains the weird glitch I did in Virtual Console with my transfer box 😅

I forget if it was Pokémon Gold or Crystal, but basically I discovered that if you change boxes to any box other than box 1, and turn the power off when it says not to, the Pokétransporter app will read Pokémon data from this box instead of box 1 (which it's hard coded to do), and will subtract the number of Pokémon in this new box from box 1. My box 1 is currently at a negative number I think and it's eating into the Pokémon Center Vs data table

[DarkonFullPower]

This exact issue appears in the Japanese version of the GameCube game "Megaman X Command Mission."

The Force Metal UI screen (the game's non-weapon equipment) is one box larger than what the list is programmed to be. The final box is "shared" with the Main Weapon list which is stored directly after it. Placing an item in the final slot will allow you to "take out" said item as a weapon on another screen.

Most famously, Force Metal #25 "Thunder Guard" becomes Weapon #25 "X-Buster Mk 3", which is X's best weapon.

[pasuk]

Congrats on the channel's 4 year anniverary :) Honestly one of my favourite channels with such well edited video's every time! (Even though I don't fully understand them all xD;; But they're still very enjoyable!)

[biscuitslash]

Over a decade ago I saw a glitch compilation where somebody teleported while holding the penguin, causing the penguin to be seemingly erased out of existence despite still crying away constantly and having its mother be thankful for their return (but not actually give a star for it).

Great to finally an in-depth and clear explanation as to what the heck was going on there!

[pixelator]

(shows wet-dry world background) "there's an infamous-"
me: (grabs popcorn)

[vaendryl]

your production quality was already stellar and this video and the previous one are again on an entirely different level.
you really deserve 10 times the number of subs you currently do, easily.

[jckf]

This is also what Stale Reference Manipulation in Ocarina of Time is. It is very similar to how grabbing an object in SM64 functions, except the actual object is being moved by updating its position relative to Link's position.