Yeah, I was holding out hope that this problem would go away once the dev team better understood when STOP is bugged. But whatever it is, not working on console is pretty conclusive. :/ That doesn't mean this branch is doomed, because I DID find a way to avoid executing a STOP at all. If I activate the glitch while standing at course 5, Wario's Y position will be the start of a 3-byte instruction, which reaches just far enough to get past the STOP. Unfortunately that instruction is [LD SP,1054], which is a pretty awful one to have to work around. It also seems to be the only option, at least as far as standing at different courses goes. I haven't figured out a setup that'll fix SP on top of activating the debug mode, but I've got a few ideas. This isn't over yet.
imo the argument that the factory flashed FFs to carts is probably bullshit. Considering that you have to assemble the carts before you could do that and the process of writing FFs to SRAM is not exactly efficient to do at that point. It's fairly likely SRAM was just whatever "pattern" is left behind when it isn't powered (said patterns that Alyosha is referring to).
The use of the display mechanism for "Absolute Zero" and "Invisible Emulation" seems to be targeting different places within the bizhawk application. 1. It appears that "client.invisibleEmulation" is not tied to the DisplayConfig.cs. Is InvisibleEmulation a lower level access to cut of more updates to get faster speeds? 2. Absolute Zero is in fact tied to DisplayConfig.cs, but I don't have any way to access via lua. I would like to have this feature added for use with lua. My reason for bring this up is due to an "crash" that I receive when using client.invisibleemulation(true). So, instead...I have been manually selecting Absolute Zero to turn on/off the emulator display. I have looked at the lua examples in bizhawk and I don't see anything special about its use. When I use client.invisibleemulation, am I experiencing a bug or misuse? Also, does this in fact have a lower level of control on updates? I like this feature, as it would solve a problem that I'm trying to automate. Any information on this would be greatly appreciated.
But is it a legitimate demand? I see the demand mostly coming from people who are probably younger than a DMG, they probably never played these games on a DMG, they don't get how it subtly different.
Yet I don't see how that's a reasonable reason to use a platform the game was not originally designed for in our TASs.
Unlike elsewhere, we place high stock on original legitimacy, at least we did till now. We know things aren't perfect, but haven't we always preferred playing things in the most accurate and legitimate fashion?
Satisfy the audience's expectations.
Since when has TASVideos kowtowed to how some other site handled things? TASVideos has also never been about how easy or difficult it is to capture something. The nature of most early devices are going to be hard to capture, unless you directly wire them up to something. It is possibly to modify the original Gameboy to do stuff with it, and there actually is a large community now around modifying Gameboys and adding on all sorts of new features to them or swapping out various components.
But how do we ensure heavy glitches aren't used in a given run? That sounds like something impossible to really check, because there could be glitches we don't even know about, not obvious, but affecting important stuff. Also limiting something in the rules to "slight glitches only" feels kinda arbitrary.
Or maybe someone could say, the only glitches that are possible in this mode are insignificant and unimportant? I'm not a GB expert for such a call. As I said, it would be much better if we had examples of glitches that obviously break things.
It does not explain how a judge allowed this to be published this way.
Ganon has a variety of attacks, and the fight is just picking a random one every time (much like in Missingno.) When Solgryn tested a particular attack, he just made a button to start that attack immediately, so he doesn't have to wait for it to show up randomly. He forgot to remove it before the release: every time you press 1 you'll put Ganon in "your face will die" attack. By "main board" I mean "not numpad". This glitch is also allowed in RTA runs. I agree that it can be interpreted as a debug code, but in TAS the same result can be achieved just by getting a good attack, like "join me and be the greatest": he stays in place for long enough.
Playing a single episode or individual game to completion, or all episodes or games, is considered game completion. Playing multiple, but not all, episodes or games is not considered completion.
I will do an exhaustive search for late menu/map/screen transition presses and get back to you on that. Edit 2020-09-11: Still working on this, by the way.