Portal 2 Rules

This document aims to provide an overview of rules for speedrunning Portal 2 and its mods. Most rules are universally applicable, however, every category will have exceptions and/or additional rules. Every rule detailed in the "General Rules" section below may be overruled within a category - for this reason, you should make sure to read all rules relevant to the category you are running.

Also note that this set of rules is not exhaustive on lists of commands or more generally on banned actions. If anything seems at all ambiguous to you or you're not sure if something is allowed, please consult a board moderator for the category in question. Lists of moderators can be found in the category's section below.

Definitions

Commands

In the game's console, you can execute commands, as well as bind keys to execute commands. We define several classes of command.

"Functional Commands" are commands which have some effect on the run or the runner's ability to perform it. The vast majority of commands fit into this category - effectively the only ones that don't are ones which impact timing, such as sar_speedrun_result, and purely cosmetic ones, such as sar_hud_set_text.

"Action Commands" are a subset of functional commands defined as any command which has a direct effect on the game world. This includes all player movement commands (+forward, -forward, +duck, etc), as well as commands such as load.

Pause Abuse

Pause Abuse is defined as using game pauses (via the ESC key, gameui commands, or opening the developer console) to affect the chance of some event occurring, make an event possible, or otherwise contribute to the run. For instance, the Betsrighter jump in sp_a1_wakeup can be done far more consistently by console pausing as you land - as such, pausing at this moment in the run is considered pause abuse, as it affects your chances of getting the jump. More subtly, pausing while lining up a precise shot is also pause abuse, since the time you are paused can allow you time to read your coordinates and prepare to move your mouse correctly.

Save/Load Abuse (SLA)

Save/Load Abuse (SLA) is defined as using any unnatural load or level transition (i.e. anything other than touching a changelevel trigger in the map) in order to affect the chance of some event occurring or make an event possible. For instance, saveload clipping is considered SLA, since it achieves an effect which would otherwise be impossible. Similarly, loading saves to retry lucky door skip in sp_a2_bridge_the_gap is SLA, as it affects the overall chance of successfully getting through the door. Exceptions are made to this rule for physics RNG specifically, so that loading saves and getting different physics RNG is not considered SLA, since this RNG is prevalant to the point of being unavoidable.

Out of Bounds (OOB)

The Source Engine has a strict technical definition of whether a point is "out of bounds" based on its BSP world system (a point is out of bounds if it is in a CONTENTS_SOLID leaf and not within a brush). We define the player themselves as being out of bounds if a) the player's eye position goes out of bounds or b) all 8 vertices of the player's bounding box go out of bounds.

General Rules

Commands

IF YOU ARE UNSURE WHETHER A COMMAND IS ALLOWED, CHECK WITH A MODERATOR FOR YOUR CATEGORY BEFORE USING IT.

The game contains a wide array of commands and variables (cvars) which can be used to achieve various effects. Commands are banned or allowed considering several criteria. All commands accessible in normal gameplay (e.g. common movement commands, save/load) are allowed. Other commands receive rulings based on their interaction with the rest of the game, their similarity to other commands, and how they fit in with other rules. If you're not sure whether a command is allowed, you should speak to a moderator for the category you are running.

Allowed commands can be categorised as "action commands", "functional commands", and "non-functional commands" (note that all action commands are also functional commands). Any allowed command may be manually executed by typing it into the console at any point, including executing such commands indirectly through exec or aliases.

HUDs

SAR and the game itself provide various HUDs to the user, accessible through console commands. In general, a HUD provided by SAR is allowed only if there is an equivalent HUD allowed which the base game provides. The command list below exhaustively lists all known allowed HUDs.

HUDs containing unchanging, predetermined user-provided text or content - such as through sar_hud_set_text or sar_toast_create - are always allowed, even if they are giving information about the run, such as dialogue fades or lineups.

Graphics

Most commands affecting the game's graphics are allowed to be used, and are not classed as functional commands. This is because using these commands is sometimes required for good performance on lower-end hardware. This includes most commands starting r_ provided they do not make parts of the world invisible or cause other major differences to default behaviour.

Crosshairs

The game's default crosshair size (including quickhud) has a fixed pixel size. Custom crosshairs via sar_crosshair and sar_quickhud are permitted only with specific assets and parameters, to get a crosshair equivalent to the default on a different resolution. The crosshair used must may change throughout the run. If you wish to use a custom crosshair, ask a moderator for your category for an allowed configuration.

Command List

This list details the allowed values for every SAR command as well as a lot of base game commands. Please note that any category can override any of these rulings. An allowed value of - means that any value is permitted.

Scripting

Any time a key is pressed or released, an arbitrary amount of allowed commands may be executed. These may include up to one action command. Any functional commands in the sequence must be executed without delay. For other commands, delay is permitted, e.g. through SAR's hwait command. Note that scrolling the mouse wheel a single tick counts as pressing and immediately releasing the "key" of the mouse wheel.

Automation of commands may be achieved through mechanisms like the sar_on_load command. This is limited to non-functional commands during the run; however, note that in Challenge Mode, automatically running functional commands is allowed provided the command could have benn performed manually prior to the run with the same effect. Examples of this include changing sensitivity or mat_fullbright.

Pre-Run Setup

It is not allowed to perform any setup for a glitch or exploit before the run. For instance, you cannot use map logic or otherwise to modify the value of sv_allow_mobile_portals before the run, nor can you load into maps so as to set up EHM, nor prepare CM Wrong Warp.

External Modifications

Currently, the only permitted external modifications for use in runs are SourceAutoRecord (SAR) on the latest full release or a later pre-release, and pathmatch_cache for Linux users.

Custom builds of SAR are not allowed - only the releases from the official GitHub repository may be used. Other external modifications, such as game plugins or code injectors, are not allowed. Runs performed with SAR pre-releases may be retroactively banned if a pre-release is found to provide some advantage. While unlikely, you acknowledge that by using a SAR pre-release you are putting your runs at risk. When a new full release of SAR is made available, there is a grace period of 1 week in which the previous full release is still allowed.

Exceptions may be made on a case-by-case basis: if you think you have a legitimate case for using an external modification which isn't listed here, consult a moderator for the category you're running.

Asset Modifications

Texture modifications are allowed, with some caveats. The textures of portal surfaces must not be modified in any way. No textures can be modified to provide any visual assistance, such as help with a lineup. No texture may be modified to be more translucent than it was, with the exception of the player's viewmodel.

Modifying models is not allowed, with the exception of the portal gun (including both the viewmodel and the in-world model). Modifying audio files, captions or any other asset is not allowed.

OOB

Some categories are marked as "inbounds", which essentially means the player and all portals and props must stay inbounds at all times. More precisely, we say that the player, all portal origins, and all prop origins must remain inbounds at all times, except where the game requires otherwise (e.g. certain level transitions place the player temporarily OOB).

Exceptions can be made to this rule in accidental cases where the rule is briefly broken. In particular, if an extreme eye offset from a portal transition causes the player's eye to momentarily peek OOB, but this is not abused, it would not be grounds for even a high-level run to be rejected.

Cooperative Play

In any online cooperative run, both players (not just the host) must provide appropriate proof for the run. The proof requirements are unaffected for local splitscreen runs.

The network conditions used in online coop are regulated. Any use of packet loss which benefits the player is banned. Ping-based advantages, however, are allowed - you may artificially increase ping through external means, such as a VPN, but not through the net_fakelag command. Similarly, net_fakenoise, net_fakejitter, and net_fakeloss are not allowed under any circumstances.

Miscellaneous

• You cannot modify the game's tickrate, or any other part of the game unless explicitly allowed.
• You cannot play on alt accounts unless given permission by a category moderator.
• You cannot allow your FPS to increase over 1000 (fps_max can be used to limit it) or have it consistently fall under 30.
• Entity Handle Misinterpretation is banned, even if performed accidentally. sar_prevent_ehm is recommended.
• Custom vscripts may not be present in the game's directory, even if not advantageous or not used during the run. Base game vscripts may not be modified.

Timing

Most runs use demo time for timing (the main notable exception is Challenge Mode, which uses its integrated timer). Even when not recording demos, SAR's timer perfectly emulates demo timing (except in CM where it emulates the integrated timer), so is recommended for use most of the time. For video submissions, which are required to have a timer visible on-screen, the timer HUD from sar_sr_hud may be used. Alternatively, SAR's integrated timer may be linked to external speedrun timers such as LiveSplit or adrift, and these may be overlaid on the video.

If using pause abuse (in a category where it is allowed), the pauses in question must be timed. This can be done using sar_speedrun_time_pauses 1, or manually with video evidence.

To ensure the run is not affected by network conditions, cooperative runs are timed differently. The inter-level timing standard for coop is defined per-game.

Proof Standards

Unless otherwise noted in category rules, all runs most have some form of proof associated with them, which could be in the form of a video or of demo(s). Most categories will require demo proof for runs above a certain rank. Demos are generally encouraged over videos as they have several tangible advantages.

Videos submitted as proof must have an accepted timer visible on the screen. They must always be submitted as a single continuous video, and must not have any severe quality or framerate issues which impact viewability.

Demos must be submitted for every segment of the run, in the correct order, with none missing. You must start recording demos before the run begins where possible, or otherwise as soon as you can - it is recommended to use sar_record_at to achieve this. On runs with multiple segments, demos must be recorded across loads - this is normally expected to be achieved via the sar_autorecord command, but categories may define different methods.

For any category other than Challenge Mode, any custom .vpk files active during the run must be included in the run submission. They can be uploaded to a site such as Google Drive along with the demo files.

Games

Portal 2

General

When running a non-splitscreen cooperative category, progress must be entirely reset before every run. It is recommended to do this using sar_coop_reset_progress. Alternatively, it can be achieved by running mp_coop_mark_all_maps_incomplete and mp_coop_lock_all_taunts, followed by returning to the main menu and re-inviting your partner.

Timing

The singleplayer campaign is timed as follows:

• Timing begins on the tick the player gains control at the start of Container Ride, on the camera_intro.TeleportToView entity input.
• Alternatively, Vault Save may be used. In this case, timing starts on the @glados.RunScriptCode(GladosRelaxationVaultPowerUp()) entity input with an offset of 18980 ticks.
• Alternatively, Container Ride Save may be used. In this case, timing starts on the camera_1.TeleportPlayerToProxy entity input with an offset of 16868 ticks.
• Timing ends on the tick the player shoots the moon in Finale 4, on the @glados.RunScriptCode(BBPortalPlaced()) entity input.
• Dying during the end cutscene is allowed since the run is over.

The cooperative campaign is timed as follows:

• Each level begins timing when the ss_force_primary_fullscreen command is first executed after stop_transition_videos_fadeout.
• Each level ends timing when the playvideo_end_level_transition command is executed.
• Timing for the run begins when the players are teleported to the droppers, on the teleport_start.Enable entity input.
• Timing for runs ending in Course 5 ends when the cutscene starts playing, on the vault-movie_outro.PlayMovieForAllPlayers entity input.
• Timing for runs ending in Course 6 ends when the cutscene starts playing, on the movie_outro.PlayMovieForAllPlayers entity input.

Unless otherwise specified, partial campaign runs (e.g. chapter runs) are timed as a subset of the relevant campaign, so e.g. Chapter 9 runs begin timing as soon as the player loads into Finale 1 and end timing when the player shoots the moon.

Portal 2 Speedrun Mod

Timing

Most categories are timed as follows:

• Timing begins on the tick the player gains control in Container Ride, on the camera_intro.TeleportToView entity input.
• Timing ends on the tick the player shoots the moon in Finale 4, on the @glados.RunScriptMode(BBPortalPlaced()) entity input.

Reverse Mod is timed as follows:

• Timing begins on the tick the player gains control in Finale 4, on the ending_vehicle.ExitVehicle entity input.
• Timing ends on the tick the player activates the bed in Container Ride, on the rev_sleep_button.Use entity input.

Portal Stories: Mel

General

Demos are not recorded in any Mel category, since they cause some maps to break. SAR or SourceSplit must be used for accurate timing.

Timing

• Timing begins on the tick the player gains control in the tram, on the Intro_Viewcontroller.Disable entity input.
• Timing ends on the tick the ending cutscene is activated in Finale, on the soundscape.Kill entity input.

Portal Reloaded

General

All Portal Reloaded categories ban the developer 1 command due to an unnatural advantage it provides on some maps.

Timing

• Timing begins on the tick the player gains control in the second map, on the announcer1.Trigger entity input.
• Alternatively, the Tube Ride Save can be used. In this case, timing starts on the @wportal1.Open entity input with an offset of 2394 ticks.
• Timing ends on the tick the player loses control when being sucked into the tube, on the finale-finale_vc.Trigger entity input.
• Alternatively, for the escape ending, timing ends on the tick when the elevator doors close, on the finale-escape_ending.EnableRefire entity input.

Aperture Tag

Timing

• Timing begins on the tick the crosshair appears, on the tele_out_shower.Enable entity input.
• Timing ends on the tick the credits appear, on the credits_video.PlayMovie entity input.
• Alternatively, for the good ending, timing ends on the tick the elevator door closes, on the ele_exit_door.Close entity input.