Recently I've seen many submissions on TASVideos that challenges the very principles of common sense and defies whether or not something done in a run should be allowed or not.
I know some of the stuff below have long since been resolved here and others not, even though they are not explicitly stated in the rules. In any case, I was wondering what your various personal opinions are about whether the following should be allowed in a TAS:
- Pressing Up+Down or Left+Right on controllers that don't normally allow it
- Pressing buttons that don't exist on normal controllers but that are still read through the controller port
- Streaming arbitrary data through an external port
- Partially disconnecting a cartridge
- Swapping discs when not prompted
- Swapping discs with a completely different game
- Witnessing the ending without completing the normal game's objective
- Getting a game beaten state in memory but without witnessing the normal ending
- Resetting during a save operation
- Starting a run with dirty memory (excluding save data)
That's all I can think for now. I'm going to give my own opinion later on those topics, but I wanted to see a few replies first to avoid any bias from me.
Depends on the nature of the port. If it allows bus-master DMA or something else game can't defend against that allows trivial exploitation, definitely not.
SmashManiac wrote:
Starting a run with dirty memory (excluding save data)
The way volatile RAM often works, the bits initialize randomly (with probabilities depending on temperature and manufacturing) on power-on.
Gets considerably iffier with dirty non-volatile RAM...
- Pressing Up+Down or Left+Right on controllers that don't normally allow it
- Pressing buttons that don't exist on normal controllers but that are still read through the controller port
- Streaming arbitrary data through an external port
- Partially disconnecting a cartridge
- Swapping discs when not prompted
- Swapping discs with a completely different game
- Witnessing the ending without completing the normal game's objective
- Getting a game beaten state in memory but without witnessing the normal ending
- Resetting during a save operation
- Starting a run with dirty memory (excluding save data)
My thoughts:
1. Allowed, since it's a hardware limitation, not an actual impossible thing to do ingame.
2. I have no clue what you're talking about. Can you link a run that's published and does this?
3. Are you talking about packet spoofing? Won't that usually just get you kicked out of the game? Or banned form there?
4. Other than for the N64, I'm not sure how to even do that. Also, I got no idea how emulators emulate this behavior, so I have no real thoughts about it.
5. Sure why not? I mean, it's just abusing the disk swapping feature to skip cutscenes and probably other stuff. To me, it's like using hard resets.
6. Idk, does that even have a benefit for TAS's (Superplays included)?
7. Sure. After all, isn't that how the Chrono Trigger New Game + run reach the credits despite it defeating the final boss in a battle way before the script says it's supposed to. Also, see the GBA Lttp TAS.
8. Case by case, since not all games have the final input at the ending. For example, in the Spongebob movie TAS, I skipped the credits because if I didn't, the game would be stuck at the password screen, which would never go away.
9. Accept. It's not like it's a TAS-only trick; the famous Pokemon Silver/Gold/Crystal dupe was done like this.
10. Sure, just get a verification movie since it's possible for runs to mysteriously desync despite using a save file with seemingly the same amount of progress. Also as evidence that the progress was legit for cases where the save file contains glitched up items/stats/etc.
- Pressing Up+Down or Left+Right on controllers that don't normally allow it
As I know, this is possible on a real console if you modify the controller. There is one similiar thing to this: The range of control sticks is more limited on the real hardware.
- Partially disconnecting a cartridge
Crooked cartridge? I thought this isn't possible to emulate?
- Witnessing the ending without completing the normal game's objective
Can you define the "normal objective"? Would it be physically killing the final boss? Getting the last story item, if this happens after the boss? Pressing A at the last text box that activates the credits?
- Getting a game beaten state in memory but without witnessing the normal ending
If the Pokémon run was rejected because the game wasn't in its "post credits state", should reaching this state become the requirement? In my opinion: Yes. So this would mean, that a pokémon run would at least need to end up with a file that can be started and has the unknown dungeon unlocked. Games that don't unlock anything are a bit harder to define, though.
- Resetting during a save operation
I think this should be a different category, but not completely banned.
Current project: Gex 3 any%
Paused: Gex 64 any%
There are no N64 emulators. Just SM64 emulators with hacky support for all the other games.
- Pressing buttons that don't exist on normal controllers but that are still read through the controller port
- Streaming arbitrary data through an external port
My thoughts:
2. I have no clue what you're talking about. Can you link a run that's published and does this?
3. Are you talking about packet spoofing? Won't that usually just get you kicked out of the game? Or banned form there?
2. The new SMW glitched run (3957S).
3. I presume that refers to using port that isn't controller port (expansion port, network port, link port, etc...) to input data.
Expansion ports sometimes/often(?) allow bus-master DMA or similar tricks that the game just can't defend against.
And even if expansion port doesn't allow bus-master DMA, it might still allow creating memory conflicts that could alter what game loads from ROM (or some other read-only media).
With network port / link port, bus-master DMA and similar is never(?) found, but it is fairly likely that the game could be made to react very badly to suitably crafted input...
After all, witness the amount of security holes in various server software... And that was written by ones knowing about that hostile input is expected. Most games are probably not written with that mindset and as such, one would have field day with all sorts of glitching caused by arbitrary datastreams.
With network port / link port, bus-master DMA and similar is never(?) found, but it is fairly likely that the game could be made to react very badly to suitably crafted input...
After all, witness the amount of security holes in various server software... And that was written by ones knowing about that hostile input is expected. Most games are probably not written with that mindset and as such, one would have field day with all sorts of glitching caused by arbitrary datastreams.
After all, witness the amount of security holes in various server software... And that was written by ones knowing about that hostile input is expected. Most games are probably not written with that mindset and as such, one would have field day with all sorts of glitching caused by arbitrary datastreams.
I have expressed these opinions several times in the past, but I'll allow myself to repeat them here (and perhaps expand a bit.) Note that these are my personal opinions, and I fully accept the fact that not everybody agrees with every single point.
The "spirit" of tool-assisted speedrunning should be to show what it would look like if a perfect being would play a videogame. A being that's not encumbered with limited reflexes and reaction speed, and who knows and sees exactly what the game is doing, byte by byte and bit by bit.
Emphasis on playing the videogame. Playing a videogame constitutes, in my opinion, taking the controller and pressing its button to control the game. Hardware abuse does not constitute playing the game. It's hardware abuse. Pulling the plug from the console is not playing the game; resetting while the game is saving is not playing the game; ejecting the CD when the game is not prompting you to do so is not playing the game; smashing the console with a sledgehammer is not playing the game.
(Yes, I know that there are like two games in existence where resetting the console is a gimmicky part of the gameplay itself. I would be fully ready to make an exception with those few games. I have never opposed the idea of accepting exceptional circumstances applied to some individual games.)
If it were up to me, saving in a videogame would be considered a no-no, for the simple reason that it's a waste of time. (Of course there may be some games were not saving isn't a choice, but that's just something inevitable then.)
An argument could be raised that if I oppose hardware abuse, what about pressing left+right or up+down on controllers that don't normally physically allow that to be done (due to how their D-pad is physically designed.) If it were a question of all-or-nothing, ie. either accept D-pad abuse as well as every other possible hardware abuse, or accept none of those, I would choose the latter. (I wouldn't lose any sleep if D-pad abuse were allowed but not any other form of hardware abuse, though.)
For what it's worth, I agree with Warp on virtually every point he made here. Potentially there are limitless ways to abuse a game's code or the hardware of its platform, but ultimately none of them are as interesting to me as abusing its gameplay. While these other kinds of abuse should be represented in some way, I feel that they should always be secondary.
Of course, people would always want a clear line defining what constitutes the "true" spirit of whatever activity they enjoy, and be frustrated about not seeing that line, but apparently, while it cannot be seen or sometimes even properly expressed, it can still be felt, and thus debated and upheld.
Warp wrote:
Edit: I think I understand now: It's my avatar, isn't it? It makes me look angry.
1. Pressing Up+Down or Left+Right on controllers that don't normally allow it
2. Pressing buttons that don't exist on normal controllers but that are still read through the controller port
1. I think this is possible on very worn out D-pads, so you don’t have to go as far as actually modding a controller to make this possible…
2. I don’t really understand this, but this seems retarded to me, does it basically mean that you can’t do it on console using a/multiple controller(s)? I don’t see how that could be accepted, SDA would’ve been right in calling us cheaters if we start doing things that aren’t possible on real hardware
- Pressing Up+Down or Left+Right on controllers that don't normally allow it
Maybe I am completely wrong, but I'll simply throw this thought out:
Let's say a game runs with 60 input frames per second and 30 visual frames per second. That means you have 2 frames of input for each visual frame. Wouldn't it be possible on a real console to hold right on frame 1 and left on frame 2 with light speed reflexes to make the game register this as pressing left-right at the same time?
I only TAS the N64 Zelda games and as far as I can tell such a logic would not work for either of them, the game would simply use the input given for frame 2. But couldn't this work for some games out there? Just wondering.
Joined: 3/31/2010
Posts: 1466
Location: Not playing Puyo Tetris
Me, I say take full advantage of any trick. Make that game suffer.
The Chrono Trigger run that abused subframes is a good example of inhuman play. NO human can accurately do that.
If it can be reproduced, it should be considered valid unless proven to be a fault of emulation error.
When TAS does Quake 1, SDA will declare war.
The Prince doth arrive he doth please.
Let's say a game runs with 60 input frames per second and 30 visual frames per second. That means you have 2 frames of input for each visual frame. Wouldn't it be possible on a real console to hold right on frame 1 and left on frame 2 with light speed reflexes to make the game register this as pressing left-right at the same time?
That would happen only if the console polls the controller 60 times per second and buffers the pressed buttons until the application wants to read their state. It doesn't sound like anything that any console or game would do (although that's only a guess from my part.)
@MrGrunz: that’s a good point, does anyone know if it would work? basically pressing left then right so fast that the game registers them at the same time
Those who don't understand point 2, it's like this, if I understood the discussion in the new SMW submission properly.
The SNES's controller ports can read 16 bytes of data at once, but the controllers themselves only transmit 12 bytes (4 face buttons, Start and Select, L and R, 4 directions, each taking 1 byte.) Since the controller ports can read more than the controllers can transmit, that means the 4 "blank" bytes can be used for other purposes; in the case of the recent glitched SMW submission, in combination with memory corruption, they help brute-force the game into running the ending sequence.
Pressing buttons that don't exist on normal controllers but that are still read through the controller port
If talking about the latest SMW submission, like a lot of people here seem to imply, where are those non-existing button talk coming from?
Edit: Just got my answer from IRC, so the above is useless. I should've looked at the controller data more extensively. The "impossible" buttons are right there.
A lot of your other debate point already been debated extensively on this forum.
@MrGrunz: that’s a good point, does anyone know if it would work? basically pressing left then right so fast that the game registers them at the same time
No, it would not work. There's common convention to poll joypad input by "strobing", which is reading input port only once per frame and storing the current state in memory. So it doesn't matter if you manage to press/release any buttons between two strobes, the game will only register those buttons that were held at the very moment of making a strobe.
[20:23] <Ilari> feos: In fact, multitap would allow reading even more than 16 buttons (unless it does something odd), but the controllers don't give anything interesting after 16 (and the autopoller never reads more than 16).
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
For what it's worth, there's a video on YouTube somewhere (and every time I mention this I wish I'd saved the link) of someone pulling off a L+R glitch on an unmodded SNES controller.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
Joined: 8/14/2009
Posts: 4083
Location: The Netherlands
Derakon wrote:
For what it's worth, there's a video on YouTube somewhere (and every time I mention this I wish I'd saved the link) of someone pulling off a L+R glitch on an unmodded SNES controller.
http://www.youtube.com/Noxxa
<dwangoAC> This is a TAS (...). Not suitable for all audiences. May cause undesirable side-effects. May contain emulator abuse. Emulator may be abusive. This product contains glitches known to the state of California to cause egg defects.
<Masterjun> I'm just a guy arranging bits in a sequence which could potentially amuse other people looking at these bits
<adelikat> In Oregon Trail, I sacrificed my own family to save time. In Star trek, I killed helpless comrades in escape pods to save time. Here, I kill my allies to save time. I think I need help.
Thankee kindly, Mothrayas.
For what it's worth, I think that the recent SMW TAS is hilarious and an excellent demonstration of taking a game to its limits. However, I also think that it no longer qualifies as "playing" the game. But that's beside the point.
Our audience is here for multiple things. Some enjoy the kinds of detailed hardware/software analysis needed to pull off what amount to incredibly precise security attacks. Many enjoy watching a game be played in a "theoretically perfect" manner that nonetheless stays within the bounds of how they (the audience) played the game. I don't see why we should try to artificially limit our audience.
Really the biggest problem we have is that (I assume) most casual TAS watchers fall into the latter camp, while most TAS creators fall into the former camp. Making a good TAS requires a really strong understanding of the game, and that occasionally leads to discovering exploits that a normal player, even one of high skill, would never discover. Limiting yourself (as the TAS creator) to not use a difficult and obscure trick, especially when you're the one who discovered it, is probably pretty painful. So then they create these movies that they spent months or years working on, and the comments are all "Well, that was interesting, but does it really count as beating the game?" or "Man, all these glitches really ruin the gameplay." Which is perhaps a little bit ungrateful on the part of the audience. :)
Frankly as far as I'm concerned, if you make an awesome movie using TAS tools, then it should be publishable on this site. Does it really "complete" the game? Who cares! Does it use inputs that a normal player would never be able to access? Who cares, so long as they're repeatable! Was the movie enjoyable to watch, that's what matters.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
Joined: 3/9/2004
Posts: 4588
Location: In his lab studying psychology to find new ways to torture TASers and forumers
boct1584 wrote:
Those who don't understand point 2, it's like this, if I understood the discussion in the new SMW submission properly.
The SNES's controller ports can read 16 bytes of data at once, but the controllers themselves only transmit 12 bytes (4 face buttons, Start and Select, L and R, 4 directions, each taking 1 byte.) Since the controller ports can read more than the controllers can transmit, that means the 4 "blank" bytes can be used for other purposes; in the case of the recent glitched SMW submission, in combination with memory corruption, they help brute-force the game into running the ending sequence.
The problem with this logic is that there isn't just one SNES controller. The SNES has a Super Scope, a mouse, and dozens of third party add-ons, some licensed, some not. These different controllers are all equally valid, even though a game may not have been designed with some of them in mind. These other controllers do take advantage of different input bits than the standard controller, and it is perfectly legal to make your own controller.
I agree with Warp that smashing the console, or anything else modifying the console itself is wrong. But manipulating the input to a black box is fair game. And before someone says games should only be played with their official controllers, some people only play their favorite consoles with custom controllers. I personally only play on my SNES with an asciiPad, the controller is more comfortable and has some other nice features.
Things like u+d and l+r at once are only blocked with a "specific controller", it is not a limitation of the console itself. Even on those controllers, you could if you so desired just press the contacts directly too.
Warning: Opinions expressed by Nach or others in this post do not necessarily reflect the views, opinions, or position of Nach himself on the matter(s) being discussed therein.
I agree with Warp that smashing the console, or anything else modifying the console itself is wrong. But manipulating the input to a black box is fair game.
I also would say that exploits that can't be defended against (like bus-master DMA or address conflicts) are also wrong.
Very dubious:
- Mapping stuff onto normally open bus that the game nevertheless uses for some reason.
- Mapping stuff onto normally open bus and then making game somehow use it (reading / executing).
Both of these can be technically defended against (by not using open bus addresses and not having bugs causing memory reads / executes from wrong address).
Joined: 3/9/2004
Posts: 4588
Location: In his lab studying psychology to find new ways to torture TASers and forumers
Ilari wrote:
Nach wrote:
I agree with Warp that smashing the console, or anything else modifying the console itself is wrong. But manipulating the input to a black box is fair game.
I also would say that exploits that can't be defended against (like bus-master DMA or address conflicts) are also wrong.
Very dubious:
- Mapping stuff onto normally open bus that the game nevertheless uses for some reason.
- Mapping stuff onto normally open bus and then making game somehow use it (reading / executing).
Both of these can be technically defended against (by not using open bus addresses and not having bugs causing memory reads / executes from wrong address).
Those types of things though are more akin to placing a cheating device between the cart and the console. Sure, there's lots of ways to screw with the input to the console. But there are standard input ports, and what is sent to them should be fare game. I'm less inclined to allow screwing with special input ports which don't have official applications in the wild, or in ways intentionally designed to be considered modifying the game itself.
Warning: Opinions expressed by Nach or others in this post do not necessarily reflect the views, opinions, or position of Nach himself on the matter(s) being discussed therein.
