If you have an opinion on this, please let me know.

The general consensus on this seems to be that a run is considered “tool assisted” if it cannot be done with the physical console, the original game, and a regulation controller (one that came bundled with the system).

If a player has access to information that cannot be accessed in the original console, if the technology intended to mimic the original hardware or software is enhanced in any way, or if a player interacts with a game in any manner other than through gameplay, the run is considered “tool assisted” and should be placed in a separate category from those that are not tool assisted.

Common examples of this are the use of hex editors to edit input stream segments, using a precise timer to count individual frames, using save states to undo unwanted actions, and using an autofire or turbo-fire controller that did not come originally bundled with the console. This should be distinguished from players that use tools that do not affect the game itself, such as a notebook to keep track of menus or a calculator to keep track of experience points. If the item a player is using to help him play the game does not interfere with the game itself, it is ¤not¤ considered tool-assisted.

The use of third-party controllers is generally allowed as long as only features present on a standard controller are used. If a run uses a controller input that is not possible with the standard controller, such as hitting both up and down on a SNES D-pad at the same time, it is considered tool-assisted.

The use of a turbo-fire function will almost always be considered tool-assisted. The only exception to this rule is for systems such as TurboGrafx-16 that featured turbo-fire controllers in the official release. If you feel that it is a gray area for a certain console or game, consider why the use a turbo controller is preferred over a regular controller. If it gives an unfair advantage over players using a standard controller, use of a turbo-fire controller is considered tool-assisted.

A run that takes advantage of additional hardware or software is considered tool-assisted if it alters game parameters in a fashion that would give that player an unfair advantage over those using the original console, including the enhancement of audio or visual output. However, the use of the use of hardware that doesn’t alter gameplay from the original, such as modchips or boot disks commonly used to play imported games or officially released add-ons, such as the PS2 HDD, are not considered tool-assisted.

A run where game settings are changed during the run is ¤not¤ considered tool-assisted if it can be done using the commands accessible through the game or in-game menus. The exception to this rule is the use of cheat codes. Runs that use cheat codes that give an advantage over those that don’t use the code are considered tool-assisted. However, runs that use cheat codes that do not give the player an advantage, such as a code that simply changes the character’s outfit, is not considered tool-assisted. It should be noted that even cosmetic changes can create shorter load times if the sprite used requires less memory than the default sprite. In this case, a run that uses this code would be considered “tool-assisted”, even though the change only appears cosmetic, because it gives the player an advantage over those that didn’t use the code.

A run that uses glitches is ¤not¤ considered tool-assisted if it can be reliably performed on the original console with a standard controller. A glitch that can be reliably performed on an emulator, but not on the original console ¤is¤ considered tool-assisted. In this situation, the emulator itself is the tool being used, because it is functioning is a way that the original console does not, creating an unfair advantage for those using the emulator over those using the original console.

[QUOTE]The general consensus on this seems to be that a run is considered “tool assisted” if it cannot be done with the physical console, the original game, and a regulation controller (one that came bundled with the system). [/QUOTE] Some games have emu only categories that exist because emu does weird things to a game that console does not that allows for various things to be possible (Link's Awakening DX ACE as an example). These types of runs are not tool assisted, but are usually given a Misc. category due to their limitation of being emu only.

Also, 3rd Party controllers/adapters to use controllers on a different console are fine and do not make a run tool assisted (of course as long as you don't use something like a turbo button on it).

Your definition is on the right track, but not quite exactly it. Original/physical hardware really has nothing to do with a run being tool assisted or not. What makes a run tool assisted is simply using some kind of tool that gives you an advantage over someone playing the game without access to those tools (which is often on physical hardware but not always the case).

As always, the TASVideos definition of Tool Assisted is still the best (http://tasvideos.org/Glossary.html#ToolAssistedSpeedrunTas): A run is a TAS if it uses a tool of some kind. Your post covered the most common examples of what some tools can be.

The only thing I can think of that could be considered controversial when it comes to the definition of tool assisted is the use of a broken cross bar on a D-pad. This allows people to press up+down or left+right when the official controllers aren't supposed to allow that. There are some games where this allows a trick to be executed that shouldn't.

[quote]A run that uses glitches is ¤not¤ considered tool-assisted if it can be reliably performed on the original console with a standard controller. A glitch that can be reliably performed on an emulator, but not on the original console ¤is¤ considered tool-assisted. In this situation, the emulator itself is the tool being used, because it is functioning is a way that the original console does not, creating an unfair advantage for those using the emulator over those using the original console.[/quote]

From what I can gather the use of emulation bugs in a TAS is generally frowned upon on tasvideos as their goal is to console verify runs.

I think literally the only reason you've made this thread is because of the other thread, and in that context it's completely asinine that you're even carrying this on.

A run is tool-assisted if you're using features that aren't available on original console hardware. Simple as that. If you're using an emulator to perform slowdown, load states, watch memory values or RNG seeds, it's a tool-assisted run. Someone in the original thread said something to the effect of "Just using a savestate doesn't make it a tool-assisted run" and they're dead wrong. It absolutely does. I can only assume they're equating it with the general understanding of 'tool-assisted speedrun', the extremely optimised superplays hosted on TASvideos, but even THEN they're wrong. A speedrun that uses a couple of savestates is still a TAS. It's just a really shitty one.

The reason I made this thread is because there seems to be an increase lately in people caring about who is the best rather than their own personal achievement. Naturally, this will pressure people into using borderline strategies to gain an edge, and I think it is important to make that line clear to minimize these kinds of arguments and keep the playing field fair for everyone.

Yeah, I agree with both of you. I think maybe using the phrase "tool-assisted" isn't the right way to go here since it has a negative connotation. I don't mean to say that one type is inferior, just that runs using these kinds of things should be separated from those that don't.

The D-pad issue was one I came across in a forum for one of the runs to "The Legend of Zelda: A Link to the Past". I don't remember the specifics, but the game had unusual behavior when up and down was hit at the same time.

I created several runs for a game called Door Kickers that when I'm recording through OBS and ONLY when I'm recording it causes rendering issues in the game and makes the walls shift 90 degrees so you can shoot through them. I would assume this is considered TAS because it has an outside source running it? If so I'll remove my runs but I can't seem to get any other program to be able to record Door Kickers without this issue.