This topic is for the purpose of discussing #8875: Reseren's GBA Metroid Fusion "save glitch" in 49:14.60

This was excellent. I'm so glad to finally see a submission for the memory corruption run. The gameplay was great. The optimization shows in every room, and I'll never get tired of seeing the zips. I still wish you could do the glitch earlier into the game, since it's so linear and you see so much from the full categories anyway, but either way, this run was fantastic. Great work!

Great work, I enjoyed this run and it's an easy "yes" vote. I don't mind that it is almost identical to a run without memory corruption up to the point when the glitch happens. I do have a question, though: Are there any improvements over the published runs in sections that follow the same route?

The oob clip in sector 6 after mega core is something I didn't have in the other TAS's. Also, I was able to cut out a frame for every jump when skipping SAX in sector 6, which saves 20-30 frames. Overall though there are a few frames saved in a lot of room throughout the run but not more anywhere specifically.

Ah cool, that's great to hear!

Cool glitch! I resynced to GBAHawk and managed to console verify: Link to video

I see that the branch was changed to "warp glitch" instead of "memory corruption". Could this be explained a bit more? I'm not sure I understand the reasoning, since the corruption changes the event to be 128, at which point the omega is already dead. The speedrun category is also called "memory corruption" which is why I submitted it as that.

I had a small discussion with another judge before making the branch name change. The site has a tag for publications that corrupt memory values rather than having it as the name of the movie branch. As the game doesn't immediately jump to the ending sequence directly, it's not quite "game end glitch" so I went with "warp glitch". It can also be called "save glitch" as the process to jump to the end involves messing with event flag values and I'm still not super solid on what the branch name should be. I would like some more feedback on a proper branch name. I'll be asking some more staff on what works for the branch name, and it would definitely help if there's more feedback here as well.

It's not really a warp, given that it just essentially edits the save data.

If save corruption is the main tech in the glitch, yeah we call those "save glitch".

It works differently from most save corruption glitches – normally save corruption glitches are done by turning off the console mid-save so that the save data isn't written properly, but this glitch instead overwrites the memory holding the save file directly. The effect is much the same, though (it's used to produce a save file in a state immediately before the game is beaten, which is then loaded, and the game beaten from there). I guess the philosophical problem here is "in a 'save glitch' branch, is the determining factor that the glitch changes the save file or that it exploits the process of saving?" This glitch doesn't do anything glitchy with respect to the process of saving (and the save produces a normal save file), but then uses a (somewhat constrained) memory corruption glitch in order to edit the save file (because we don't know how to use the glitch to win the game directly, and doing so may well not even be possible), and loads the edited save file as a means of warping to the end of the game. I don't think I've seen a glitch quite like this one used in any other game in the past (for most games which are capable of doing something like this, there's a much easier/simpler way to win the game directly and thus the roundabout method via using memory corruption targeting a save file isn't necessary and isn't even considered). As such, the question of how to categorise it hadn't really arisen prior to this run being submitte.

I don't think we need to come up with an overly strict definition because actual reality constantly destroys overly strict definitions. I always viewed "save glitch" as literally any way to corrupt a save (or the save system for that matter).

Another solution would me to use as label the name of the biggest glitch used. "X glitch"

Another solution would me to use as label the name of the biggest glitch used. "X glitch"

That would be memory/save corruption.

"Memory corruption" doesn't indicate what it's actually being used for in terms of gameplay. In RTA branch labels usually say which speed techniques are allowed in those branches, but that's still per-game, and other game communities can use the same labels for different things, and different names for the same things. So we can't globally rely on RTA branches. And it was a major problem for the viewers when we didn't indicate the gameplay nature of the branch for those "glitched" categories, so we started splitting them by their effect. If the major skip glitch skips straight to the ending, we call it "game end glitch". When it puts you somewhere that's not the end of the game and you need to complete it yourself, it's "warp glitch". If save corruption is involved, "save glitch". If the glitch comes from the game's demonstration of gameplay, "demo glitch". If it's something complicated and hard to explain in a few words, we invent a new name for it, like Super Metroid's "X-ray glitch". That way we can be consistent across all games and all types of major skip glitch.

Is there a reason to call it "save glitch" instead of "save corruption"? I do think the latter sounds fine.

"X glitch" is the branch used to communicate that a major skip glitch is used to skip a huge portion of the game. "Save corruption" is a movie tag.

This movie has been published. The posts before this message apply to the submission, and posts after this message apply to the published movie. ---- [5826] GBA Metroid Fusion "save glitch" by Reseren in 49:14.60

For what it's worth, part of the reason I care about the label given to the run is that I consider the reset-during-save technique to be somewhat illegitimate, in the sense that it's going outside the bounds of what the game can reasonably be expected to handle. In a way, doing a reset during a save is going beyond the realm of controller input, whereas normally for a TAS the whole selling point is "this can be achieved using only controller input!". Meanwhile, this run is not falling into the same grey area in terms of legitimacy: not only does it not reset during a save, it doesn't reset at all (the save is reloaded using a death, something which should be noted in the movie tags). As such, if someone is intentionally avoiding runs with reset-during-save glitches, they might nonetheless want to see this run. However, there's very little clue in the tags or category at present that that is the case (the tags are missing "Uses a game restart sequence", but that's hard to notice). Also, if I remember correctly what other people have said about this glitch, aren't the edits made to the save data via the memory corruption not persistent enough to survive a console reset (which is why a death has to be used)? If the edits to the save data aren't actually saved, then in a sense you haven't corrupted the save data after all.