The first thing came up in my mind after reading the code is the lack of sending the "reset" input. As far as I know you can't send it via controller, so my question would be that can you make an attachment/external device to handle the reset button?
I'm still of the opinion that resetting is not valid input in TASes and should be banned. and this only strengthens that opinion.
I'm still of the opinion that resetting is not valid input in TASes and should be banned. and this only strengthens that opinion.
You mean TASes using the "reset" button or using a restart sequence by pressing various button combinations on the controller (1/2)? Also "strengthens that opinion": I think you wrote this for the unaccessibility of the reset button through the controller, right? Well, I think the reset button is on the same "level" like the power on button/switch (since you have to control the console to start a game and not the controller), however I don't know the consistency of it on a real console.
PhD in TASing 🎓 speedrun enthusiast ❤🚷🔥 white hat hacker ▓ black box tester ░ censorships and rules...
I'm still of the opinion that resetting is not valid input in TASes and should be banned. and this only strengthens that opinion.
And I think the reset button is one of the input keys, with games supposed to be designed to handle it in certain way. The key just is not located physically in the same place as the other inputs, but it is still an input button.
Resetting during save might be questionable, though, because it is nearly impossible to program it "properly"...
You mean TASes using the "reset" button or using a restart sequence by pressing various button combinations on the controller (1/2)?
I'm talking about the reset button on the console.
In my opinion "playing a game" consists of supplying input to the game which the game reads and interprets. "Playing a game" does not consist of shutting down the console and restarting it (which is what resetting essentially is). Just because you can shut down the console, and just because many emulators have support for emulating this, doesn't make it a valid form of playing. (IMO it's no different from using gamegenie codes: Just because you can do it with a real console and just because many emulators support it, doesn't make it a valid form of playing.)
You mean TASes using the "reset" button or using a restart sequence by pressing various button combinations on the controller (1/2)?
I'm talking about the reset button on the console.
In my opinion "playing a game" consists of supplying input to the game which the game reads and interprets1. "Playing a game" does not consist of shutting down the console and restarting it2 (which is what resetting essentially is). Just because you can shut down the console, and just because many emulators have support for emulating this, doesn't make it a valid form of playing. (IMO it's no different from using gamegenie codes: Just because you can do it with a real console and just because many emulators support it, doesn't make it a valid form of playing.)
So according to your logic, it's valid to press various button combination to reset the game1 which should be nearly (or exactly) the same as pressing the reset button, but it's invalid to press the reset button2 ? Feel free to correct me, I'm just guessing. I also think that this is about "verifying the consistency of emulators/tases on the real valid console" and not "making the console to act as the emulator".
PhD in TASing 🎓 speedrun enthusiast ❤🚷🔥 white hat hacker ▓ black box tester ░ censorships and rules...
So according to your logic, it's valid to press various button combination to reset the game1 which should be nearly (or exactly) the same as pressing the reset button, but it's invalid to press the reset button2 ?
There's a difference between the game quitting to its main menu and the console shutting down. This even if we disregard how it's done. (I don't think the NES even supports shutting down or resetting via software. That's a relatively modern phenomenon in consoles.)
Likewise there's a difference between, for example, the game corrupting its own save data due to a programming error (which is triggered by some unusual untested situation) and the save data becoming corrupted because the console was shut down while the game was writing the data. The former abuses programming errors, the latter abuses hardware (which IMO should not be part of TASing, or even speedrunning in general). There is a clear distinction.
If I were going to try to play back videos on the console using a reset, I would play back the movie up until the the reset, then stop playback and manually reset the console, and let the bot continue from there. If the bot held no buttons while waiting for me to reset the console, and started playback fine after the reset, how many movies would this work for? I'm assuming this wouldn't work for games that use save corruption, since this is based on precisely timing the reset to "corrupt" the memory into a favorable state. But how many games would it work for?
Theoretically for any game that doesn't use a global frame timer for its RNG seed that is carried through the reset. Practically… who knows. Try the least random games first.
Warp wrote:
Edit: I think I understand now: It's my avatar, isn't it? It makes me look angry.
Recca has a button code to unlock Zanki mode (all enemies fire bullets on death) which includes resetting the game. The reset button is assuredly a valid input for that game. I have found a counterexample; your argument is invalid.
EDIT: another counterexample: Zanac's stage select code requires you to reset the game 13 times.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
Joined: 11/18/2006
Posts: 2426
Location: Back where I belong
Warp wrote:
In my opinion "playing a game" consists of supplying input to the game which the game reads and interprets. "Playing a game" does not consist of shutting down the console and restarting it (which is what resetting essentially is)
That X-men game for the Genesis would disagree with you there, since it required you to hit the reset button to continue playing a certain level.
If I were going to try to play back videos on the console using a reset, I would play back the movie up until the the reset, then stop playback and manually reset the console, and let the bot continue from there. If the bot held no buttons while waiting for me to reset the console, and started playback fine after the reset, how many movies would this work for? I'm assuming this wouldn't work for games that use save corruption, since this is based on precisely timing the reset to "corrupt" the memory into a favorable state. But how many games would it work for?
I suggest you to try TASes that "uses a game restart sequence" by pressing a combination of buttons. This means you don't need to manually press the reset button since the game will handle the button combination required for the specific game so it will sync perfectly theoritically. However, most of the games requires a 2nd controller for this.
Also... manually... I don't think you will have enough patience and extreme rhythm sense to pull this out, the press and release have to take for exactly 1 frame, not to mention TASes with multiple restarts in a row.
Now back to real life. As far as I know, the reset routine heavily depends on the actual hardware version. However, if you develop another NESBot (since I think you have to for another controller or modify the existing one, I don't know the correct specification atm), then try these, they are much likely to sync than other TASes (they use Up+A on the 2nd controller):
[1082] NES Zelda II: The Adventure of Link "warp glitch" by Inzult in 05:43.47[1144] NES Metroid by Lord Tom in 08:19.32
I couldn't find TASes using restart sequence without using a 2nd controller or the reset button.
edit: also sorry for this debate/off topic on the verifying thread.
PhD in TASing 🎓 speedrun enthusiast ❤🚷🔥 white hat hacker ▓ black box tester ░ censorships and rules...
...for example, the game corrupting its own save data due to a programming error (which is triggered by some unusual untested situation) and the save data becoming corrupted because the console was shut down while the game was writing the data. ...abuses hardware (which IMO should not be part of TASing, or even speedrunning in general).
I understand that this is only an opinion, but really... unusual untested situation? 90% of the TASes makes use of this. The first thing came up in my mind reading this line was the Up+Down and Left+Right combination. It's impossible to press on regular gamepads, you have to dissassemble them and of course they will work, and it's heavily abused in TASes. One of the greatest "unusual untested situation". So this also counts as an invalid gameplay?
The save corruption is really questionable since it's depends on the hardware version (according to various technical documentation regarding NES consoles), but it's a part of speedrunning, this is a fact. SDA also uses it for example NES Clue.
Don't think that I want to change your opinion or something like this, I just found your thoughts interesting.
PhD in TASing 🎓 speedrun enthusiast ❤🚷🔥 white hat hacker ▓ black box tester ░ censorships and rules...
...for example, the game corrupting its own save data due to a programming error (which is triggered by some unusual untested situation) and the save data becoming corrupted because the console was shut down while the game was writing the data. ...abuses hardware (which IMO should not be part of TASing, or even speedrunning in general).
I understand that this is only an opinion, but really... unusual untested situation? 90% of the TASes makes use of this. The first thing came up in my mind reading this line was the Up+Down and Left+Right combination. It's impossible to press on regular gamepads, you have to dissassemble them and of course they will work, and it's heavily abused in TASes. One of the greatest "unusual untested situation". So this also counts as an invalid gameplay?
I think you misread what I wrote. I didn't say that errors caused by "unusual untested situations" constitute invalid gameplay. I said that there's a clear difference between savedata being corrupted because of a programming error in the game (and which is triggered by controller input) and savedata being corrupted because of shutting down the console while it's being written. In fact, I was implying the exact opposite of how you understood what I wrote: In other words, gamedata being corrupted because of a programming error in the game itself is ok in my books (because it's just regular bug abuse) while gamedata being corrupted because of shutting down the console is not (because it's hardware abuse).
(The "unusual untested situation" was simply a reference to why such a bug might happen in a game: The situation where it happens was never properly tested and was never caught, or was deemed too implausible to be triggered by regular play. That's why the majority of bugs exist in games.)
Emulator Coder, Site Developer, Site Owner, Expert player
(3599)
Joined: 11/3/2004
Posts: 4739
Location: Tennessee
Bisqwit wrote:
And I think the reset button is one of the input keys, with games supposed to be designed to handle it in certain way. The key just is not located physically in the same place as the other inputs, but it is still an input button.
Joined: 5/1/2004
Posts: 4096
Location: Rio, Brazil
Yep, I think the same. Saying that "only controller input is allowed" sounds really arbitrary. There's no reason for that at all, there are other buttons the player can use for a speedrun.
Now, if it is emulated properly is an entirely different reason.
Who's to say that the controller is the only valid method of input? If someone did a run of an Atari 2600 game by the rules proposed, he/she wouldn't be able to use the switches on the console - only the joystick and the fire button. There are a number of games that make use of the difficulty and TV switches for various gameplay-related purposes, usually to make up for the lack of buttons on the controller. Would these inputs not be allowed because they don't come from an external controller?
Rayas wrote:
Dunno if I'm really clear. I need to drink more.
<br>
adelikat wrote:
The idea was to kill off my family to avoid lost time to them getting sick and other inconvenient things.
And I think the reset button is one of the input keys, with games supposed to be designed to handle it in certain way. The key just is not located physically in the same place as the other inputs, but it is still an input button.
I agree completely with Bisqwit on this issue.
How exactly do games "handle it in certain way"? AFAIK NES (and for that matter most other console) games cannot hook to nor detect that the reset button is being pressed and act accordingly. Granted, I don't know the exact details of the NES hardware, but I'm assuming that when you press the reset button, it's tantamount to pulling the plug: The program just stops right where it was (simply because the CPU stops working), without giving it any chance to do anything. The reset button is not input to the game.
FODA wrote:
Yep, I think the same. Saying that "only controller input is allowed" sounds really arbitrary. There's no reason for that at all, there are other buttons the player can use for a speedrun.
It's not arbitrary at all. The game reads input, you supply it input. Shutting down the console is not input. That's pretty unambiguous.
Tanooki Teabag wrote:
Who's to say that the controller is the only valid method of input? If someone did a run of an Atari 2600 game by the rules proposed, he/she wouldn't be able to use the switches on the console - only the joystick and the fire button. There are a number of games that make use of the difficulty and TV switches for various gameplay-related purposes, usually to make up for the lack of buttons on the controller. Would these inputs not be allowed because they don't come from an external controller?
You are misreading what I wrote. I was talking about the NES controller for the simple reason that on the NES it happens to contain all the buttons that the game can read (and hence the buttons that can supply input to the game). The physical location of the buttons are not the issue here. Even if the reset button was on the controller it wouldn't make any difference. You are missing the point.
Granted, I don't know the exact details of the NES hardware, but I'm assuming that when you press the reset button, it's tantamount to pulling the plug: The program just stops right where it was (simply because the CPU stops working), without giving it any chance to do anything. The reset button is not input to the game.
Translation: I don't know, nor do I give a rats ass to figure out, so let me make some bullshit up to support my point.
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.
Granted, I don't know the exact details of the NES hardware, but I'm assuming that when you press the reset button, it's tantamount to pulling the plug: The program just stops right where it was (simply because the CPU stops working), without giving it any chance to do anything. The reset button is not input to the game.
Translation: I don't know, nor do I give a rats ass to figure out, so let me make some bullshit up to support my point.
Wow, great counter-argument! You totally destroyed my arguments and pointed out that they are completely incorrect.
Of course if I were wrong you would have pointed out my mistake instead of resorting to an ad hominem, so I assume I am right in my assumption.
(I already know you don't like me. There's no need to repeat that over and over. Just get over it.)
By the way, there's some discussion in the Arcade Metal Slug X thread about what constitutes making the run easier by affecting hardware and whether it could be considered legitimate, which I think is interesting and could be considered related to this topic.
How exactly do games "handle it in certain way"? AFAIK NES (and for that matter most other console) games cannot hook to nor detect that the reset button is being pressed and act accordingly. Granted, I don't know the exact details of the NES hardware, but I'm assuming that when you press the reset button, it's tantamount to pulling the plug: The program just stops right where it was (simply because the CPU stops working), without giving it any chance to do anything. The reset button is not input to the game.
Warp, I think you are confusing Reset Button with Power Button (maybe because in modern PCs these buttons are fused into one: when you tap the button it's "customizable reset", when you hold it for 5 seconds it's "forced power off").
But intrinsically these are two different buttons. Power button is hardware trigger, reset button is software signal.
Reset button never removes power from device.
The button acts more like non-maskable interrupt - it just changes program counter (pointer to next instruction) to some predefined address. (Well, there are also some platform-dependent hardware reinitializations, but what's important - CPU/memory/chips don't lose power)
In case with NES games it's even more game-friendly: as NES doesn't have BIOS, programmer must define the address of "reset interrupt" and write all the code that will be executed every time player presses reset button. So it's quite possible to recover from reset, and some NES games actually use reset button as "Return to menu" (not to title screen), without resetting score and other gaming data.
And theoretically it's possible to completely disregard Reset button (just return from the reset subroutine to next frame iteration), although it would look strange - player pushes Reset and game freezes, player releases Reset and game continues.
That said, I also think Reset button is kinda arbitrary (somewhat close to memory/CPU status editing), but well, it's TASing, not normal speedrunning. Until it delivers fun it's all for good.
