If hard resets are allowed then i don't see why opening the disc tray wouldn't be allowed.
I agree - I think that if we allow a player to arbitrarily hit the reset button during a TAS, then we should allow the disc tray to be arbitrarily ejected. As far as I'm concerned, while playing, you can arbitrarily rip the game out of the console, drop it in orange juice, and then put it back in (arbitrarily), if that gets you to end sooner.
In theory, if you had god-like powers in real life (the ones that would be required to play a game perfectly), you could scratch the game disc just in the right places so that reading the FMVs would cause reading errors, possibly causing FFIX to skip them. This can perfectly well be emulated (simply make the emulator emulate reading errors at certain parts of the disc image).
However, that doesn't constitute playing the game. That's hardware abuse at its finest.
I don't see all that much difference with ejecting the disc, really. Rather than scratching the disc just on the right places, you are simply disallowing the machine from reading the disc at the right places by ejecting it. It sounds to me like the same type of hardware abuse. I want to see the game pwned via gameplay, not via kicking the console and dropping it on the floor.
We have 2 Super Mario Brother runs that lack running. The primary goal here is to make TAS videos that entertain the user.
Left+right? Sure. No left+right? Sure. Make it entertaining and the other rules suddenly matter less.
The primary goal here is to make TAS videos that entertain the user.
Yet we have rules for a reason. We don't allow gamegenie codes, rom hacking, we require pure keypress files with no embedded savestates (and thus things like making the run look faster by video editing is completely out of question) and so on. It's not solely about entertainment. It's about quality and standards.
Sage advice from a friend of Jim: So put your tinfoil hat back in the closet, open your eyes to the truth, and realize that the government is in fact causing austismal cancer with it's 9/11 fluoride vaccinations of your water supply.
I don't think we could ever "console-verify" any TAS that uses FMV-skipping, unless someone builds a robot that manually opens and closes the disc's tray.
There are some PSX games in which you can save time if you connect/disconnect a gamepad at certain places, like in Metal Gear Solid and in Blaze and Blade, and there are secret music tracks in other games such as Bust a Groove that I once found by opening the tray and that can't be found in any other way.
On one hand, I've heard of people that uses these tricks while they're playing the game as usual, and some of the results would look cool in a TAS. Maybe if there's a robot that physically attaches/dettaches gamepads and open/closes disc trays, I would allow it.
Afterall, it's just exploiting "error handling code" that is programmed in the ROM, and most games won't allow saving time this way.
The whole idea of TASing a game is to see what a game would look like being played with superhuman skill... This theoretical person should not only be able to press buttons on the controller with frame accuracy, but also buttons on the console.
Yeah, I bet every one of us has this fantasy on what a superhuman would do if they were playing a videogame (the only solid answer to which is, of course, "not play it"). There's a particular problem with this line of thought, in that it could be continued indefinitely, up to and including "brainwashing the audience to vote for their speedrun"; hence why you see useful markers such as "superhuman skill" in the phrasing. Nothing superhuman about disc removal, I can do it blindfolded.
Warp wrote:
Edit: I think I understand now: It's my avatar, isn't it? It makes me look angry.
If hard resets are allowed then i don't see why opening the disc tray wouldn't be allowed.
Agreed.
because you aren’t letting the console read the game anymore? it’s the same as partly removing N64 catridges to get weird effects, I don’t think that should be allowed
I also think we should move away from "if situation A is allowed, then (partly or completely different) situation B should be allowed too" style of reasoning.
Warp wrote:
Edit: I think I understand now: It's my avatar, isn't it? It makes me look angry.
Emulator Coder, Site Developer, Site Owner, Expert player
(3599)
Joined: 11/3/2004
Posts: 4739
Location: Tennessee
I dont' see it as reasoning that B be allowed because of A. It is more like that situation B is similar to situation A which is allowed for reasons X.
It is a new situation, but it is helpful to try to compare it to some similar precedent. And I see this situation less as cartridge removal, and maybe closer to the act of resetting during saving for ram corruption perhaps.
Also cartridge removal isn't something that "isn't allowed", it is something that isn't emulated that we could record.
Well, hardware manipulation glitches are a grey area where it becomes progressively harder to draw a line between "superhuman" gameplay and quite ordinary hardware tampering, which many gaming communities recognize as a common form of cheating.
If it were up to me, I would draw it at cutting off power supply/connection/physical access to game medium. All of this implies physical interaction rather than soft input, and consequently can't be console-verified. I'm more interested in gameplay.
Warp wrote:
Edit: I think I understand now: It's my avatar, isn't it? It makes me look angry.
Emulator Coder, Site Developer, Site Owner, Expert player
(3599)
Joined: 11/3/2004
Posts: 4739
Location: Tennessee
moozooh wrote:
Well, hardware manipulation glitches are a grey area where it becomes progressively harder to draw a line between "superhuman" gameplay and quite ordinary hardware tampering, which many gaming communities recognize as a common form of cheating.
If it were up to me, I would draw it at cutting off power supply/connection/physical access to game medium. All of this implies physical interaction rather than soft input, and consequently can't be console-verified. I'm more interested in gameplay.
That would invalidate the Final Fantasy TAS we have currently published.
Well, that means we should have had this discussion sooner, probably back in 2005 when the first TAS using hard resets was submitted. Back then it went under the radar, but I wouldn't like inoptimal decisions to be made now because of uninformed ones in the past. It's something that we should consider very delicately, as the issue touches on subjects such as what constitutes TASing, what separates TASing from cheating, and how would we want TASing to develop further. For instance, I am inclusive for concepts that bring variety into gameplay, but I like in-game problems to be solved by in-game means, rather than any kind of arbitrary "divine interventions".
Though as far as I understand, the FF TAS could be fixed without a major time loss (less than a minute, I believe?).
Warp wrote:
Edit: I think I understand now: It's my avatar, isn't it? It makes me look angry.
I think that any trick allowed by SDA should also be allowed here.
I still hold that only penalizing a reset 1 frame is unreasonable, as real game systems have startup screens, which most emulators simply skip.
I wouldn't blindly accept foreign practices. For instance, in the published Diablo run groobo alt-tabs during the Lazarus cutscene to skip it, which is a very dubious trick in my opinion. But, given the irregularity of human performance and their verification system, SDA's approach is more case-by-case than what we have now (and likely ever), so that trick wasn't given much importance.
Warp wrote:
Edit: I think I understand now: It's my avatar, isn't it? It makes me look angry.
I think that any trick allowed by SDA should also be allowed here.
I still hold that only penalizing a reset 1 frame is unreasonable, as real game systems have startup screens, which most emulators simply skip.
If it simply skips it in a run, then it's bad emulation and the run most likely won't be accepted.
I don't think we could ever "console-verify" any TAS that uses FMV-skipping, unless someone builds a robot that manually opens and closes the disc's tray.
To say nothing about the fact that multi-disc PSX game run exchange discs inhumanly fast; that would be pretty difficult to console-verify in and of itself.
Anyways, I'm thinking that FMV skipping would probably be best avoided, for the sake of accuracy. An alternative encode should definitely be made available, however, where the FMVs are edited out.
First a movie gets submitted, and ends up accepted despite breaking rules other runs have been rejected for. And when I vote less than spectacularly on this movie, I become the victim of harassment and threats.
Yay, favoritism.
If it simply skips it in a run, then it's bad emulation and the run most likely won't be accepted.
What, skipping unskippable startup screens means the run won't be published? Without commenting on whether that "should" be done, I'd just like to say that there's clearly sufficient evidence to show: that isn't done.
http://tasvideos.org/Movies-GBA.html
If hard resets are allowed then i don't see why opening the disc tray wouldn't be allowed.
Agreed.
Then perhaps we shouldn't allow hard resets either... ;)
Anyways, let me give you a good reason why resets and opening the disc tray are not comparable: A reset can be emulated at frame-perfect accuracy, while opening the disc tray, which produces a mechanical action, cannot.
The speed at which the physical disc tray moves is non-deterministic, independent of the CPU or any other timed hardware, and may depend on the individual console (the speed might vary by several frames between consoles, and even from ejection to ejection within the same console, especially if it's done often; it may also depend on the age of the console, as the physical components involved degrade physically).
An emulator can guesstimate the delay when opening and closing the disc tray, but it will most probably not correspond to the delay in a real console (measured in frames). How much should the delay be? If this were an option in the emulator (ie. there was an option where you can set how long the emulated delay of opening and closing the disc tray is), it's then up to the author to set it. To what value should he set it? If he sets it to too small of a value (eg. 0 seconds) that's tantamount to cheating. No different from speeding up the CPU.
So should we allow disc tray opening and closing in TASes? Definitely not.
The speed at which the physical disc moves in the disc tray is also non-deterministic, but I don't think we have a problem with that. Also its position, which is slightly different based on how you first put the disc in when starting the game, etc.
Most video game controllers would be hard-pressed to register actual 30Hz pounding by a sufficiently-drugged-up human or a robot because of mechanical limitations such as the spring on the buttons etc.
I don't think real-world physical constraints are an important factor in determining what a TAS should be allowed to do.
Disc reading affects loading times, which are gameplay. Some games may have players choose different routes depending on loading times associated with them. Think Resident Evil door openings, or Ocarina of Time pause screens, or even what real time runners do in Metroid Prime. Sometimes, disc reading is so important, a mini game to keep you entertained while you wait is presented (think Oblivion tip screens, or the dragon ball bouncy thing for one of the more recent DBZ fighting games on 360/PS3)
It's probably most noticeable in Metroid Prime 3; the current SDA speedrun actually ends up going into hypermode during loading to avoid taking damage waiting for doors to open. (One of the effects of hypermode is that you're immune to damage unless you take enough of it to break you out of the mode; and if you don't attack during it, you get the energy tank you spent to enter hypermode back again when you leave it.)
They're all inputs. How fast you can open the lid isn't an issue. A bot would just hook directly into the "is the lid open" sensor. How fast you can swap discs isn't an issue; a bot would hook into the disc reader and just start feeding it a different image. Similarly, the physical limitations of buttons aren't really an issue, because bots don't need buttons. There's no need to physically connect and disconnect controllers; a bot can just report "there's no controller connected". TAS is about perfect inputs without human limitations, so it makes no sense to include human limitations here. How fast is the robot allowed to pull the plug out before it's too fast for a human?
Scratching the disc is changing the game program. Pulling the cartridge out is changing the program*. Using a Game Genie is changing the program. Telling the program that the lid is open isn't changing it. Telling it that suddenly, a different disc is present isn't changing it. Pressing the reset button or power button** isn't changing it. It's always been my understanding that a TAS is about playing the game as fast as possible within the rules defined by its program (even if they're obviously not what the designers intended), and that changing the program would be cheating. As long as you don't do that, all's fair.
*Pulling the cartridge out isn't the same as removing the disc. In the latter case, you just tell it the disc is no longer present. There's just a switch under the lid that tells whether it's open, and the reader will report back "I can't see any disc here" when asked to read. The program isn't changed by removing a disc; it's just told that it can't get that file right now.
The cartridge is a part of the circuitry, and the program is usually being read from it during execution, so pulling it out drastically alters the program. I'm counting game resources as program here (no fair editing the levels either).
**If you want to be really pedantic, yes, turning the power off causes RAM contents to erode, which changes the program. But that doesn't matter, because as soon as you turn it back on again, it's going to re-load the program from the original medium. The program modifications are an unavoidable side effect and the modified program is never used.
Hophoolio wrote:
subanark wrote:
I still hold that only penalizing a reset 1 frame is unreasonable, as real game systems have startup screens, which most emulators simply skip.
If it simply skips it in a run, then it's bad emulation and the run most likely won't be accepted.
This would invalidate every Game Boy, GBA and DS run that use resets. Keep in mind that the hardware state is exactly what it would be after running the boot ROM; it just skips the actual running part. It's essentially loading a save state of the exact CPU cycle the boot ROM finishes.
Would it be better to include the bootup logo every time? Perhaps it'd be easier to synchronize inputs, but it sure wouldn't be as fun to watch.
They're all inputs. How fast you can open the lid isn't an issue. A bot would just hook directly into the "is the lid open" sensor. How fast you can swap discs isn't an issue; a bot would hook into the disc reader and just start feeding it a different image. Similarly, the physical limitations of buttons aren't really an issue, because bots don't need buttons. There's no need to physically connect and disconnect controllers; a bot can just report "there's no controller connected".
But then you would be modifying the original hardware. Where do you stop these modifications?
You could speed up the CPU clock just by a little. Or by more than just a little. After all, since we are making modifications to the hardware, why stop at the disc tray or the controller? We could also modify the interface between the game cartridge and the cartridge reader so that we can insert whatever data we want. This is not a problem for a bot any more than it is for it to send the console a signal that "tray open" or "this button was pressed".
I don't think hardware modifications (even if the hardware is only emulated) is any more valid than modifying the game ROM itself.
(Edit: By the way, I do not oppose the idea that a special exception would be made for changing discs in a multi-disc game, as long as this is used only to proceed in the game normally. This should be specifically written as a special exception which does not set a precedent.)
