This topic is for the purpose of discussing #6908: liutao118121's NES Mega Man 3 in 30:04.88

For the record, this run uses the second controller glitches. I'm not sure if they're legal. FWIW: The movie looked pretty well executed and optimized throughout. That said, I didn't see anything unique from the current publication aside from the 2P glitches. I suppose it serves as a nice demonstration of what is possible if they were actually part of the game. I was well entertained watching, so based purely on the wording of the question, I'm voting yes. I still don't think the movie is publishable, however, due to the use of debug codes.

The TAS is taking full use of debugging features which is unfortunately for this case not allowed. There's a total of 550 frames of this input method being used. - 212 frames of Right for High Jump. - 337 frames of Up to slow Animations down - 1 frame featuring both. The currently Published movie for reference has a grand total of... zero.

For the record, this run uses the second controller glitches. I'm not sure if they're legal.

It has been tried before, and they are not.

Welcome to "Lei Pi," but this behavior seems not to be allowed. Some people have tried before, but they've all been turned down.

Encode (720p60 is available, always use 60fps for Mega Man): Link to video Looks interesting, seeing how the 2p controller exploits were used in the levels.

This TAS is be great, sadly debugging codes aren't allowed for submission. I wish they were since they technically are apart of the game itself, just the developers forgot to remove them. It's almost like not forgetting to patch a glitch with a easy fix. If the debug codes were allowed however it we would have probably already had a published TAS of it!

For the record, this run uses the second controller glitches. I'm not sure if they're legal.

It has been tried before, and they are not.

also to use a more recent example

The two main arguments against the second-player features (debug codes?) seem to be: - they weren't intended to be left in. I understand the sentiment but there's no consistency on this site for either. Developers did not intend to leave in glitches either, much less arbitrary code execution, but both get utilized to beat games. and - they use a second controller in a single-player game. This one doesn't really make sense given that it has no bearing on what the game is. Almost all TASes feature button presses faster than even a turbo controller, of which those aren't official either. One human player will never, ever be able to do most glitches seen in TASes as they require absolutely frame-perfect timing that a human is literally incapable of. I also recall at least one ACE video featuring another controller's input, or maybe even more than that, but I think it was for a playaround so the rules are probably a bit different. The actual argument should be if it changes the game much, and as outlined above, it does not for Mega Man 3. Less than 10 seconds of the video are influenced by the second controller features. It's a shame, these debug features would be incredible in say, Mega Man 4, where a lot more stages feature pits to moonjump out of, or something.

Mate, you're gonna have to defend better if you're going to use exploitable game mechanics and compare that to cheats/debugs being used. All your points make no sense here's the few I'll go over.

Developers did not intend to leave in glitches either, much less arbitrary code execution, but both get utilized to beat games.

Ah yes, the two extremes one of which is Pokemon and the other which is Pokemon. Wait, hang on. ONE of which is Bubsy 3D and the other is that of Super Mario Bros. 3. Glitches uses the mechanics of the game that is provided to abuse the game. Have you seen Crash 3? ACE well requires dismantling the game's code structure without accessing it and being able to jump to another point in the game.

Almost all TASes feature button presses faster than even a turbo controller, of which those aren't official either.

Even though turbo controllers is every other frame, you know... the same rate as mashing in the TASing world. Also don't forget the method of "turbo" is console verifiable on TASVideos with TASes that do feature them. So get your facts straight for that one.

One human player will never, ever be able to do most glitches seen in TASes as they require absolutely frame-perfect timing that a human is literally incapable of.

There's a term for this. It's called TAS-Only, and some RTA runners will go mad for doing a TAS only trick in real time cause my God. You know a good example to this is Super Mario World when they were finally able to crack ACE to the same route as the TAS. Just because it's frame perfect doesn't mean it's impossible. Why do you think runners who exclaim at GDQs who do the insane tricks during their runs in a marathon setting go THIS IS A ONE/TWO FRAME WINDOW during their runs? Please get a better example or point. --- You want a final example. Read the Japanese manual to the Famicom version of Zelda. You'll see a part where they mention making a noise in the second controller will kill a specific enemy type. You know, something that isn't mentioned in the manual of Mega Man 3 (or Rockman 3) where using the second controller allows this. Therefore an unintended mechanic left behind the developers (that was actually removed from the European version) therefore a debug feature left behind, therefore not allowed in runs.

Clearly there's a strong precedent here, so I don't see much chance of this obsoleting the current run, but I don't see why it can't be its own branch, assuming people like the video. Acumenium's argument may not have included some extraneous incorrect details, but it's correct in its main thrust, which is that the debug features exist on the shipped cartridge and are accessed via normal controller inputs. There's no principled way to distinguish "debug tools left in" from any other glitch or even normal behavior. It's fine to decide that we're mainly interested in runs that don't use them when we can identify them on a case-by-case basis, but there's no reason at all that a high-quality, entertaining run that does use them shouldn't be published on its own branch.

I will give my 2 cents about this whole ordeal. Let's take a look back at the site rules.

Cheats, debugging codes, and arcade continues are not allowed This includes any in-game codes[1], input sequences such as the Konami Code, as well as immediately accessible hidden menus. Note that, if the feature accessible in that way is suggested explicitly by the game itself or mentioned in the manual as a normal means of playing, such as level restart shortcuts in the Legend of Zelda or Metroid, it is usually allowed. If the code is not used, and the features it provides are accessed directly using game glitches, it is also allowed.

Here's some other examples of codes in games: Kid Icarus has a code that allows you to begin with literally everything, I would wonder what a TAS of that nature looks like Mega Man 2 has a code that allows for you to start with all the weapons, I would also wonder what that would like However, these are all intended codes left into the game. Sonic 1 has a debug level select, theres a good chance it wasn't meant to be left in since developers wanted you to actually play their game. However it wouldn't be allowed since you can't really submit IL's here, and Sonic 1 is basically a big list of IL's since it's optimized for the in-game timer. It would really only be useful in doing IL's, maybe for a RTA segmented speedrun, of course this doesn't apply to a TAS setting so it's not fit here. This case however, is entirely different. These are totally unintended to be left in, no doubt in my mind about it (remember that statement by the way). However, there is a stipulation saying they aren't allowed in the rules of the site. It doesn't state exactly why however, but I will let that one go. I think we should be able to make a exception for this one, but in a certain way. When we take a look at the RTA leaderboards for Mega Man 3 it says

Timing starts on "game start" and ends on final hit on last boss. Turbo is not allowed. Second controller is not allowed.

This is similar to how the Konami Code is also not allowed. However, there is also something else Taking a look at the other categories, we find something. There is another branch that allows for the usage of these debug codes In my opinion, this would be a better idea, the already published TAS would give a insight into what a TAS using the normal any% rules, but wouldn't it also be interesting to see one using these debug codes? So far, the debug code branch on the RTA leaderboard only has 1 run: 38:06 by rattokissa This TAS is 8 minutes faster than that RTA run, which seems to also have a missing video. Seems that nobody really cared for it because it wasn't contested or really had any attention from a mainstream audience either. Nobody would have a single insight to what a run of that nature would look like. Even if the video was avaliable, its still 5 minutes slower than the any% RTA record. Infact, the same run is also on the any% branch chart. It was just a normal any% run! rattokissa submitted it to both branches since there is no rule stating you had to use the debug codes. There are essentially no insights into what a run of that nature would be. But here it is! A submission using it, of course it was submitted branchless since the author is possibly unaware of this Movie Rules, which isn't a good thing in lots of cases, but this time it may actually benefit us. Publishing this run under a specific branch would be a wonderful idea in my opinion, even if it's breaks movie rules. It's even stated that the rule is not too strict, so would this finally be the exception? This is good in my opinion because it introduce something new, this could inspire people to possibly want to improve upon it and getting into making tool-assisted runs. This has always been the motive of TASVideos, each publication needs to be meaningful. Something like 2nd controller debug codes accidently left in to create some side effects that save 20 seconds is pretty significant, since it's a totally new way of going about and 20 seconds is a pretty big time save for a 30 year old game. That seems pretty convincing enough, at least in my opinion. It also goes back to the old debate of glitch vs exploit. A glitch is a malfunction of the games code. While a exploit is abusing intended mechanics to get a unintended result. But isn't the debug codes unintended? They are, in a release stand point, but they were intended in a development stand point, they were just left in. Remember how I said "These are totally unintended to be left in, no doubt in my mind about it". Wait, there are unintended as a gameplay aspect, but intended as a development aspect. It isn't a glitch, because it's not a malfunction of the games code, as it was intended to be used during development. I got I got a answer, the key word is "left in". It was a intended mechanic, just not in the form of gameplay! But isn't what gameplay that matters? Well yes, but the intended debug codes that weren't meant to be left in affects gameplay. It wasn't intended as a gameplay mechanic, but it affects gameplay as a result of being left in. It's a exploit! It's a intended mechanic, even though it's not from a gameplay perspective, but it affects gameplay! It's really a exploit! It was a intended mechanic that was meant to help with development, making it not a exploit, but then was made a exploit by being abused because they left it in. Here's my final point: It's a intended mechanic used for development, but was then made unintended when it was released since it became redundant, except that it was left in and made a exploit purely from being left it. It's there, apart of the game, and can be abused, and affects it enough to became its own branch. Being against publication as a improvement to the any% run could be argued against, since the main RTA board also disallows them, but that leads to the rules in general being scrutinized. I still managed to do that even when arguing for a different branch. There really isn't a reason to be against publication when treated like a separate branch. The rules stating it isn't allowed also say it's not treated strictly. There are examples of exceptions you can find. That is really all I have to say about it.

There's a bit of an issue if you want to argue for this to be a different branch: Now, let's say this can be a separate branch. I don't think it would be able to be Vaultable, and would need to be subject to Moons. Which needs entertainment. Which the votes don't exactly show that happening.

Is the code even used for anything besides moon jumping? Most of the run looks like the same old (very laggy) MM3 aside from the player being able to jump high on demand. Are there any unique skips (ect) this enables, or does this just save a few seconds switching to rush coil every so often and make ladders faster? I'm of the opinion that any competitive branch for RT runners merits a TAS branch, as part of the point of TAS is to show the theoretical best time possible. However the only two controllers run on the megamanleaderboards site linked above shows this category is so unpopular only a single run is known, and that's old enough its time isn't in the DB and it's a full 4 mins+ slower than the codeless run. That suggests it's considerably less than competitive.

om, nom, nom... om, nom, nom... nom nom

Tiancaiwhr made a much-improved version of this TAS: Input file: https://tasvideos.org/UserFiles/Info/637943293710775261 Encode by Magical WizardRuby: Link to video