For what it's worth, people doing save corruption runs of GBA Pokémon games on console (using a GameCube) cut the power to it, because it detects the reset button and doesn't reset for a couple of seconds until after it's pressed, making it basically impossible to time correctly.
In my opinion, save corruption via disconnecting during a save should be considered a separate category, but not disallowed outright. Runs can be interesting both ways.
I think there's still some misunderstanding left. I'm not talking about abusing luck or glitches in the game. I'm just talking about doing it via gameplay (rather than via external influence such as the reset or power buttons.)
If we continue with the football game metaphor, abusing luck in the game would be like in the football game a perfect player making a one-in-a-trillion shot from one end of the field to the other, which has just the right amount of spin and velocity, and bounces ten times from the ground, other players and goalposts, and might even fly 50 meters high at some point, and ends up in the opponents' goal through astronomically small chance. There's nothing wrong with that.
Zipping through a wall is like the ball suddenly quantum-teleporting through a player, a chance that's so astronomically small that it just doesn't happen normally.
Again, I'm not sure I follow your metaphor unfortunately. I'm really bad at interpreting metaphors.
But from what I understand, it appears that I misunderstood your previous explanation about what the various elements in your metaphor were representing. I thought you were doing a comment about banning emergent gameplay, not about banning non-game factors.
My last comment indeed does not quite make sense in that context. I thought you were more of an abstract gameplay purist than an emergent gameplay purist. :)
Glitches are done for entertainment value.
Fairly often the glitch is more entertaining then a playthrough that foregoes it.
Extreme glitches (that remove 75% or more of the game or so) tend to get their own "glitched" branch.
Using heavy luck manipulation to level insanely fast only gets you so far in the entertainment tree. Dragon warrior is probably the best example of doing that.
Rockman doesn't have a separate glitched branch, because a non zipping no lay run wouldn't look significantly different from a realtime speed run. Therefore, the main movie glitches heavily to save time and be more entertaining.
I do think save corruption generally needs it's own branch, or the general "glitched" branch, and should not obsolete a run that doesn't use it, but since it's such a time honored tradition on pokemon games to do this on real game boys, it gets a free pass for those games. :)
AS for pressing non existent buttons... Well the super mario world example they aren't non existent. multitaps were plugged in. :) God can instantly transform a normal controller into two populated multitaps. :) Normally it's arcade games that respond to buttons that aren't normally present. Yie Ar Kung Fu is on such example (the low arc jump button is missing from the control panel but does function). I believe if it's doable by plugging in a licensed peripheral, it's fair game. (super scope, zapper, power pad, etc)
Streaming arbitrary data through a port. not okay, in my book. Controller port, reset, and power button only. Expansion bus on ps1 is NOT okay, for example (it's the gameshark port) But if there's an actual first party peripheral for that port, then it might be okay.
As for disk swapping, if the result is easily reproduced in real time, it's not very entertaining. But if it' a one in a million chance to pull off that glitch, or works only with a very specific alternate disc that no one would ever guess on their own, then i think it's okay.
As for starting a run with dirty memory, if the time to get that state of dirty memory (done in the warped arkanoid run, for example) is counted in the time, then it's okay. Game over during the demo dirties memory, allowing a continue, hence the warp.
Streaming arbitrary data through a port. not okay, in my book.
Btw, I don't understand why anyone would even think it's ok. I see little difference between that and streaming arbitrary data through the game cartridge connection (thus effectively allowing you to modify the game in any way you want.)
AS for pressing non existent buttons... Well the super mario world example they aren't non existent. multitaps were plugged in. :)
A standard multitap cannot reproduce the controller inputs seen in the super mario world run. Indeed, no physical control device in existence besides the bots (that we know of) can, although it would be relatively simple to design a 32 button controller that could.
GameTrailers recently released their new PopFiction episode 35, and it's relevant to this discussion. Basically they take a Famicom and a NES-101, boot Super Mario Bros, swap the cartridges while the power is still on with Tennis or Family BASIC, reset, do stuff, swap back to Super Mario Bros, reset, and use the continue trick to access random worlds.
The reason it works is because the continue data is not initialized after a reset, and the way it checks if a reset was done is by comparing a test value in RAM. So basically, the same trick could be used with dirty RAM instead of cartridge swapping.
I think it's pretty cool that dirty RAM allows for something like this and I would definitely allow it (while keeping a separate clear RAM category as well). As for the cartridge swapping... well it's cool but unlike disc swapping I'm pretty sure it damages the cartridges and system on the long run so I wouldn't allow it even for a TAS.
zaphod77 wrote:
Streaming arbitrary data through a port. not okay, in my book. Controller port, reset, and power button only. Expansion bus on ps1 is NOT okay, for example (it's the gameshark port) But if there's an actual first party peripheral for that port, then it might be okay.
I didn't know you could use a cheating device on a PSX that exclusively used the extension port. That's very interesting. I agree that if it's possible to overwrite arbitrary addresses through such a port, it should not be allowed for use except when connected to official products. But as far as I know, that's the exception. I don't see why not use such a port otherwise (at least in its own category) if it's limited to a reserved section in memory.
zaphod77 wrote:
As for starting a run with dirty memory, if the time to get that state of dirty memory (done in the warped arkanoid run, for example) is counted in the time, then it's okay. Game over during the demo dirties memory, allowing a continue, hence the warp.
Sorry, but that's not what dirty memory means. It's when residual values are still in RAM at power on. The idea of timing how long it takes to create the dirty RAM is interesting, but I don't think that makes much sense. Somebody correct me if I'm wrong, but I think RAM can contain data even if it has never been used.
Discs from a different game are just that, not from the game you should actually play. If a game has 2 discs, it's another thing, then both discs are part of the game. But in this example Tennis has nothing to do whatsoever with Super Mario Bros. The obvious choice, if that was allowed, would be to make the game you switch discs/cartridges with yourself, so that it gets the desired effect in the absolutely least time possible.
AS for pressing non existent buttons... Well the super mario world example they aren't non existent. multitaps were plugged in. :)
A standard multitap cannot reproduce the controller inputs seen in the super mario world run. Indeed, no physical control device in existence besides the bots (that we know of) can, although it would be relatively simple to design a 32 button controller that could.
If there is no way to reproduce it with any peripheral that was in existence at the time, then the legality of the movie does seem questionable. Even a human with perfect reflexes would need to construct additional hardware to do this, which makes it a hack instead of a TAS i think. it's quite entertaining and amazing from a technical standpoint, but if you really have to build your own controller just to input it...
I do think the run should stay as a concept demo, as it's just too creative and impressive technically to be lost.
AS for dirty memory, it simply mans memory that has not been initialized by the game pack. Some software has been known to use it s a seed for the RNG. But emulators tend to pre-initialized dirty memory, because they simply cannot store the state at power off and emulate the decay. But if you could swap games without cutting power in the emulator, and store that in the movie file, then i'd call that legit.
But if you could swap games without cutting power in the emulator, and store that in the movie file, then i'd call that legit.
Why do I get the feeling that we are getting farther and farther away from what speedrunning actually is, by bending definitions and artificially moving goalposts of what's "allowed" and what's not...
I have a question about what you think whether it should be allowed or not:
I recently discovered a use for deactivating the 3rd controller from the SNES in Secret of Mana. The way it works is - if you want to plug in a 3rd controller in your SNES, you need use an additional adapter. Those adapters have a switch to 'activate' the 3rd controller, whether an additional controller is physically plugged in or not. So the only thing to do to deactivate the 3rd controller is flipping that switch.
Secret of Mana allows for 3 players simultaneously. It has a - what I assume is a safety/fallback - mechanic that will automatically deactivate and redirect control to the AI if the controller is unplugged, and the other active controller(s) gain control over the event(s) the 3rd character started.
The interesting part here is, you can talk to people with the 3rd controller, then deactivate it and freely walk around while the textbox is still open. While a textbox is still open you can not trigger new events anymore.
Now, it has no practical use as of now for an actual speedrun/route, but I think it has a lot of potential. Combining open textboxes with the invisibility glitch for example let's you walk through walls. Up to now we were limited to needing to talk to an NPC every time we want to go through walls, with this the textbox can simply be kept open and make a straight line from A to B.
Joined: 3/31/2010
Posts: 1466
Location: Not playing Puyo Tetris
What about having an analog stick at a non-neutral status when the console is turned on? Would that allow for games to be given values higher then expected?
When TAS does Quake 1, SDA will declare war.
The Prince doth arrive he doth please.
I always disagreed with L+R for its impossibility. The fact taht you can do it on a third party controller is also meaningless to me since I find it reasonable to assume a game was designed with only the official hardware specs in mind. So I find it very logically easy to file pressing impossible buttons, pressing L+R (same thing imo), and using an actionreplay or gamegenie all under the same category. To me they're all advantages not enjoyed during a legitimate use of the game and console. A game design oversight (they didnt think you could reach this ledge this early in the game) is not the same as a game not handling multiple directions correctly. You're redefining the environment the game is played in. Same with screwing with the cartridge.
On the other hand I see no issue with abusing what happens when the console is power cycled or reset, since this falls within the universe the game was designed in. People taking apart their controllers to press four cardinal directions simultaneously or building custom controllers/peripherals is clearly a different level and type of game abuse.
I agree that well written software handles the unlikely and the improbable with grace. Software written to console specifications has the obligation of doing that. It has no obligation to anticipate the impossible. I believe the following list is completely reasonable to file as impossible: inputs that cannot be generated by correctly functional hardware, input from devices that never existed, cheating devices changing bytes in memory.
Imagine that someone makes a PC game that behaves normally upon any input from some standard 101 key keyboard, but has amazing and unexpected results when fed ASCII characters lower than the keyboard can produce. That's on the game designers for not anticipating an unlikely but possible case. Now imagine the same game was made for a private, proprietary system where the only officially documented input devices were a few specific keyboards incapable of producing those game-breaking ASCII characters. That's a different case. My PC game could be broken just by binding a few hotkeys to produce 0x0F characters. My game for the proprietary system, it is not reasonable to assume I should have anticipated the possibility of generating the 0x0F is there is no way to do that according to specification. Someone coming along afterwards with custom 3rd party hardware that I didnt know about at the time of production, or someone modifying their equipment to be able to produce the special character... how are those any different than a cheat device, or a crooked cartridge, or soldering a resistor somewhere onto the physical hardware to change its properties for the better? All of those things are modifying parameters that were perfectly sane for the designers and programmers to treat as constants. It's not a programming oversight when we press L+R+D all at once, it's us cheating the system. So too when we use invented multitaps or take advantage of an emulator inaccuracy to achieve a result. But not so if we are truly outsmarting the programmer by finding something he didn't anticipate. L+R doesn't feel the same way because it is not an oversight; it could have very easily been accounted for and handled in the veritable menagerie of games for which it allows unexpected behavior. It was instead intentionally ignored and optimized around in the coding of these games because it was rightly treated as a hardware impossibility.
I should also mention that I'm all for runs that take total control of a game and find exploits to directly write to memory. Just not if they have to cheat to obtain that goal by imagining that any hardware modification is cool.
My opinion is sane but proves unpopular here, and I understand why. I understand that emulators have long had L+R U+D capabilities and it was one of the first interesting properties ever discovered in games. So I understand how familiar and used to it we are and how we take it for granted as acceptable.
I am actually not sure how I feel about the fact that in, say, mupen, you can press a stick 100% forward, and it is not possible to press that far on real hardware. Because I suspect the real hardware is not consistent.
Joined: 4/17/2010
Posts: 11475
Location: Lake Chargoggagoggmanchauggagoggchaubunagungamaugg
I agree that pressing cardinal directions is a different universe than the games were written for. I agree that it's not an oversight of a developer. But here we have to deal with the reality that already exists, and while not being okay with it, we still always need to investigate it to find the internal flaws if they exist.
The concept that exists now for almost 10 years and that no one of the actual TASers disagreed with so far is:
- Game code can not be modified, it is taken as is.
- Controls the game can handle are all considered legal.
I mention that not because I think so personally (though I do), it is just how it is for all these years. I now also see that there is a huge similarity between using the buttons not present on the primary controller and by using the ones that are present but can't be pressed at once. The legality of these 2 cases seems equal to me. But there are 2 ways to merit this very legality.
1.1. Abstraction says that nothing can be taken with absolute seriousness, since then it will always contradict something else. And if 2 different people take 2 contrary things with absolute seriousness, they will always argue hard with no constructive result. So sometimes we need to shut our eyes to some minor improbability to achieve something much more enjoyable and important.
For example, the game determinism as we completely rely on here does not exist in reality. "TASing became feasible because of general assumption that behavior of a game is always determined by its initial state and player's input, and nothing else". In fact, the game behavior can depend also on how much dust covers a disc, what is the room temperature, and whatever else. There are enough factors that can break the console syncability, games can behave differently even from load to load with all the similar timing. But it all has no way to be accounted, so our emulators only account for the initial state and user input, and if they match, the game does the same as well. This is where perfect emulation starts contradicting perfect determinism. At TASVideos we need both hard, so we can't actually achieve both equally perfect. Some will need to be sacrificed (accuracy most likely).
1.2. Abstraction is critical for actual users (TASers), because they need something to rely on completely before they start serious work. Note how many problems people have with sync unstable emulators. Determinism is what provides them a comfortable environment for productive work. Accuracy is a bonus we can afford as emulation is being developed.
It is also a paradigm of creating TASes. We must abstract from the internal game rules as much as possible, because then we could find the tricks that are improbably to discover playing by the intended rules. And there are 2 ways to make the game do something: hacking its memory/code (illegal) and sending it controls it can handle (legal). TASers are in fact dealing with the stripped game code and ignore a good portion of the rest.
There always can appear a TAS that refuses to use simultaneous presses, reset+saving, zipping, whatever. It would always have a right to be published if the viewers like it. But not to degree of banning the use of what it refuses to use. All are happy.
2. Technically, there are official Nintendo controllers that allow pressing any amount of buttons at once, and have more buttons than the primary controllers:
http://en.wikipedia.org/wiki/Power_Pad
So when banning some aspect we may easily discover it is actually not worth banning and is acceptable. And here abstraction once again pops up: nothing can be considered 100% perfect.
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.
Not to sound flip-floppy on opinion, but I don't think I can disagree with much of that post. I guess I asked for it by thinking about the problem of analog input, too. If I may attempt to condense what you said... all valid input to a controller input port must be accepted for TASing to make any sense under certain (and widespread) ideas about what a TAS is.
From your point of view the other items on the list must be much more interesting to discuss.
You can do L+R or U+D on official hardware with an official standard controller if the D-Pad is worn down enough. (Or does that count as 'hardware modification'?)
Joined: 3/18/2006
Posts: 971
Location: Great Britain
If the power button, turning off the console, is not considered part of gameplay, and therefore shouldn't be allowed, what about turning on the console?
Is that part of gameplay? (triggered by File - Open ROM- <game>, in emulators).
I would really like to have some input from the TASvideos-regulars on what you think about the case of "deactivating" or "unplugging" components during gameplay. I now found at least a minor case of it being useful in SoM which would save roughly half a second. I'm sure there are other application possibilities, but the point is - it would be useful in an actual run.. (If at any point someone dares to improve the current TAS that is)
For reference, my original post:
Yagamoth wrote:
I have a question about what you think whether it should be allowed or not:
I recently discovered a use for deactivating the 3rd controller from the SNES in Secret of Mana. The way it works is - if you want to plug in a 3rd controller in your SNES, you need use an additional adapter. Those adapters have a switch to 'activate' the 3rd controller, whether an additional controller is physically plugged in or not. So the only thing to do to deactivate the 3rd controller is flipping that switch.
Secret of Mana allows for 3 players simultaneously. It has a - what I assume is a safety/fallback - mechanic that will automatically deactivate and redirect control to the AI if the controller is unplugged, and the other active controller(s) gain control over the event(s) the 3rd character started.
The interesting part here is, you can talk to people with the 3rd controller, then deactivate it and freely walk around while the textbox is still open. While a textbox is still open you can not trigger new events anymore.
Now, it has no practical use as of now for an actual speedrun/route, but I think it has a lot of potential. Combining open textboxes with the invisibility glitch for example let's you walk through walls. Up to now we were limited to needing to talk to an NPC every time we want to go through walls, with this the textbox can simply be kept open and make a straight line from A to B.
I personally have no issue with plugging/unplugging controllers that the game is designed to support. I think it's more of a problem if you're attaching unexpected controllers to the game, or things it likewise wasn't designed to support (although possibly still acceptable), but if the game has clearly been written with the expectation that a player might use three controllers and detach one, exploiting a bug in the game's routines for doing that is acceptable.
(Pressing the 0, 1, 2, 3 'buttons' on an SNES controller) is only as valid as left+right and pressing a button at 30 fps is.
For 30Hz button pressing, why does this particular rate of frequency become invalid? Clearly some amount of Hz is valid input - is 29Hz okay? 28Hz? How are you defining what is valid here? I don't understand this line of reasoning.
For left+right/up+down, I have often thought of this as valid via the reasoning in this post. However, today, I saw an old response I missed previously (in this thread, which is why I'm posting here):
AnS wrote:
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.
I have a question about response. If the "moment of making a strobe" lasts X amount of time, couldn't you press left for X/2 units of time, and right for X/2 units of time, to make both the strobe's poll of left and of right both return "on"? Even if the strobe is a nanosecond, it's still a finite amount of time which could, in theory, be divided by 2.
(Note: I have since read an old thread about how the SNES mouse could be used to generate the 0, 1, 2, 3 SNES input, so my opinion on this has changed since the SMW thread, but I still am interested in how 30Hz and L+R are considered on the same level of validity as this, before having learned about the SNES mouse.)
<Swordless> Go hug a tree, you vegetarian (I bet you really are one)
Joined: 4/17/2010
Posts: 11475
Location: Lake Chargoggagoggmanchauggagoggchaubunagungamaugg
JXQ wrote:
For 30Hz button pressing, why does this particular rate of frequency become invalid? Clearly some amount of Hz is valid input - is 29Hz okay? 28Hz? How are you defining what is valid here? I don't understand this line of reasoning.
I consider them all (and L+R) valid. See here why.
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.
I consider them all (and L+R) valid. See here why.
Thanks, that is a very well-written post.
Edit: I sincerely mean this - as I read it back it sounds like it could be mistaken for sarcasm, but that's not my intent here.
<Swordless> Go hug a tree, you vegetarian (I bet you really are one)
I have a question about response. If the "moment of making a strobe" lasts X amount of time, couldn't you press left for X/2 units of time, and right for X/2 units of time, to make both the strobe's poll of left and of right both return "on"? Even if the strobe is a nanosecond, it's still a finite amount of time which could, in theory, be divided by 2.
No, that is not how hardware works.
At each "probe", the system will read the inputs, or more precisely, it will let the signals from the controller pass through the "gates". These gates tend to at some time t0, let through the signal at its input. Then for some time t, it will block the input from propagating through it until t time units have passed again.
Therefore, if you change inputs at t0 + t/2, it will not be reflected in the output. Only the input signal at the time t0 + k*t will be registered.
This is how "gates" (typically known as flip-flops) works. There is no middle-ground (in this "probing" context).
However, if you were very very fast, you could move the D-pad from one side to the other in the difference between length of time it takes the electricity to move through the wire to one side of the D-pad, and to the other, thus causing both sides to be pressed at the moment that the latch samples them. Not only would this likely require relativistic speeds, it probably wouldn't work in practice even avoiding that issue because there wouldn't be time for enough current to flow along the second side for the latch to be able to detect it.
An alternative plan would be to move the D-pad back and forth very very rapidly so that both wires would be at half voltage due to the capacitance of the wires; although both would be polled at the same time, with some methods of building the hardware, the half-voltage on both sides of the D-pad would read as "on". This would depend on the particular components that happened to make up the controller.
