As some of you know, today was my last day as a moderator for the Alien: Isolation speedrun leaderboard. Due to real life time constraints, it is no longer possible for me to devote the same energy and effort toward the game and this great community. Although it is bittersweet for me to move on, the past five and a half years have been truly remarkable. What began as a shared dream of simply beating the game in under three hours has been more than achieved, including (among many examples) improvements to the Any% route that reduced the total run duration by more than two hours.

This evolution was only possible through thousands of hours of collective effort, elevating the game to heights we never could have contemplated when we started our journey. It has been a privilege to have been part of that journey, and particularly to have met so many amazing people along the way. Thank you for being awesome, and feel free to message me on Discord if you ever feel like chatting.

Best Regards,

Info

The community recently learned that certain very high end GPUs (e.g., Nvidia GTX 1070/1080) can cause certain missions (or portions thereof) to run significantly faster than previously possible on other hardware. Curbstompers discovered and demonstrated this, using a GTX 1080 to achieve a time of 2:53 in Mission 1:

Based on our testing, it appears that this "speed glitch" is the result of (or at least directly related to) the extremely high FPS values that those specific GPUs are capable of producing. Furthermore, this glitch does not appear to be reproducible on other hardware. Therefore, in the interest of fairness, this glitch will be disallowed in runs until and unless some method is discovered to permit reproduction on other hardware.

For runners that experience this glitch, please use Rivatuner Statistics Server, MSI Afterburner, NVIDIA Control Panel (GeForce Driver 441.87 and later), or a comparable tool to limit your game's maximum FPS to 275 (or less) so that this glitch does not occur.

Use of such tools to limit maximum FPS will not be considered a violation of existing rules, including those that preclude "third-party programs that affect gameplay," provided that the tools are used only (1) to prevent the speed glitch discussed above, and/or (2) for other legitimate reasons that do not provide an unfair advantage over other runners (reducing GPU load/heat would be permissible; enabling the Mission 17 "console exclusive" skip would not).

Cliffs discovered that it is possible to see certain use prompts during the animation of placing/planting items (i.e. lit flares), resulting in a substantial time save in Mission 10's first segment ().

Using and refining this mechanic, Cliffs and I were able to find various skips in additional missions:

M3 (Skips Ion Torch Panel for Medikit v.2)

M8 (Skips Gas Torch + Panel)

M10 (Shortcut to Server Hub)

M14 (Skips Ion Torch Panel)

M4/M16 (Skips Ion Torch Panel)

By popular request, the PC AI speedrun community has decided to revisit use of the Crouch-Clipping and related glitches (V-Sync Toggling, Resolution Toggling) in any/all categories of runs.

Crouch-Clipping has been treated as permissible under one of our early rules, which allowed runners to rebind their mousewheel to function as the "use" key.

By extension, V-Sync Toggling and Resolution Toggling have been treated as permissible as mid-run manipulation of an in-game option without the use of a third-party program.

Over the past few months, a number of concerns have been expressed as to the use of each of these glitches, and specifically whether and to what extent they should be permissible in any/all runs. Therefore, we as a community must consider the following options:

(1) Do Nothing

Preserve the status quo: Crouch-Clipping, V-Sync Toggling, and Resolution Toggling continue to be permissible in non-legacy category runs. Third-party programs continue to be impermissible in all runs.

(2) No Resolution Toggling

Crouch-Clipping and V-Sync Toggling continue to be permissible in non-legacy category runs. Resolution Toggling and third-party programs become or continue to be impermissible in all runs.

For context, please see my previous post at http://www.speedrun.com/ai/thread/nio77

TL;DR - Resolution Toggling was an effort to level the playing field among runners whose hardware could not produce the 200+ FPS required for V-Sync Toggling, specifically needed for one clip in Mission 11 and simplifying the elevator clip to Mission 18. It quickly became apparent that Resolution Toggling enabled many more clips than were previously thought to be possible without the use of a third-party program.

The main expressed concerns with Resolution Toggling have been that (1) it requires "hacking" the game's configuration file to add a custom resolution high enough to provide a sufficient drop in FPS for these and other clips; and (2) it requires swapping resolutions to actually achieve the FPS drop, which feels - and looks - messy. Additionally, Resolution Toggling is not a perfect solution; runners with better computers are still able to "toggle" faster between resolutions because of the time it takes for GPU drivers to refresh the display between toggles.

If we decide that Resolution Toggling should not be permitted, it may renew concerns about V-Sync Toggling, which is only possible for certain machines capable of running the game at 200+ FPS.

While most PC speedrun communities do not ban glitches simply because they cannot be performed on low end or older hardware, the communities may take steps to make those glitches possible even where the runner's hardware does not. See (5) below.

(3) No Resolution Toggling or V-Sync Toggling

Crouch-Clipping continues to be permissible in non-legacy category runs. Resolution Toggling, V-Sync Toggling and third-party programs become or continue to be impermissible in all runs.

The initial concerns with Crouch-Clipping focused on perceived randomness or luck of certain clips. Through extensive testing across a diverse range of hardware, it became apparent that Crouch-Clipping is highly FPS dependent. Certain clips do not work consistently if the game is running above or below a specific FPS, or outside a specific FPS range. As noted above, a few of those clips (M11 and M18) were determined to be either impossible or demonstrably less consistent without use of V-Sync Toggling. Thus, certain runners whose hardware could not produce 200+ FPS could not take advantage of V-Sync Toggling.

If we decide that Resolution Toggling and V-Sync Toggling should not be permitted, it may renew concerns about the difficulty or inconsistency of certain clips (M18) absent use of either. It may also be difficult for runners with low end or older hardware, or conversely very high end or new hardware, to achieve optimal FPS for specific clips.

(4) Legacy

Revert to pre-legacy: Crouch-Clipping, V-Sync Toggling, Resolution Toggling, and third-party programs become or continue to be impermissible in all runs.

(5) Go Further

Crouch-Clipping, V-Sync Toggling, Resolution Toggling continue to be permissible in non-legacy category runs. Additionally, third-party programs (e.g., Dxtory) may be used SOLELY to toggle FPS decreases for purposes of Crouch-Clipping or Air Running in non-legacy category runs. Third-party programs continue to be impermissible for any other use.

The foregoing list would be incomplete without this option. Compelling arguments can be made both against and in favor of use of a third-party program in a speedrun. The argument against is quite simple: use of a third-party program goes beyond the confines of the game.

The argument in favor is more complex, but worth exploring. Given the nature of our "skips," it is a source of tremendous frustration that we were not provided a developer console or simple in-game option to allow us to dynamically change FPS, which is a trivial task in a number of games (i.e. Half-Life and its progeny). For those games, runners can simply bind a key to cap their FPS for whatever manipulation or glitch is being performed. Absent such an option, we are stuck doing the "messy" solution of Resolution Toggling to achieve the same effect within the confines of the game.

With Dxtory or a comparable third-party program, it would obviate the need to set custom resolutions, would work the same on essentially every machine, and would "clean up" the clunky nature of Resolution Toggling while permitting us to continue to break the game completely.

It is not unprecedented for a speedrun community to allow use of third-party programs. Two popular speedrun communities do so specifically so that runners without necessary hardware can perform all the same tricks.

A certain skip in the Dishonored speedrun is extremely inconsistent without the use of a freescroll mouse. The Dishonored community specifically allows runners who do not have a freescroll mouse to use a macro/autohotkey script to perform the skip.

Similarly, several rail/edge boosts in the new Doom speedrun require a specific (high) FPS. The Doom community specifically allows runners to use a trainer which has the sole function of dropping draw/view distance to achieve sufficient FPS for these skips.

Ultimately, though, it is up to the runners of each community to decide what is and isn't allowed. Thoughts and comments welcomed.

In attempting to find a more consistent method for crouch-clipping the exit shutter in M11, I revisited a previous idea discussed in our analysis of the M17 "alien push clip" (see http://www.speedrun.com/ai/thread/6fqkt ). Specifically, I suggested that it was possible to artificially lower FPS without the use of any third party programs by setting up a custom game resolution in the engine configuration file, ENGINE_SETTINGS.XML, located in \steamapps\common\Alien Isolation\DATA.

It is now apparent that this is exceptionally useful in the context of crouch-clipping. By briefly switching to a high resolution, it is possible to dramatically lower the game's FPS, which trivializes many of the existing crouch-clips used in the Any% and All Missions runs.

The effect is similar to what certain runners have been able to achieve by "VSync Toggling" - with sufficient initial FPS (usually around 200), switching VSync on allows a small window within which certain crouch-clips are made possible (M10 Server Hub [Red Shutter], M11 Exit Shutter [Upstairs], M11 Exit Shutter [Downstairs]), or easier (e.g., M18 Elevator). It appears that the transition from a high FPS to a much lower one causes this effect.

However, unlike VSync Toggling, this new technique ("Resolution Toggling") has much lower requirements and is significantly more forgiving; it is possible to Resolution Toggle with half the initial FPS required by VSync (100), and the window of opportunity to crouch-clip is double or triple the duration. Consequently, Resolution Toggling will be possible for a much broader array of desktop and laptop hardware, including many machines that were unable to VSync Toggle.

Additionally, Resolution Toggling has the added benefit of opening doors (literally) to crouch-clips that were previously impossible even with VSync Toggling. For example, it is possible to skip M18's facehugger sequence entirely by crouch-clipping out of the locker in M18 (see and ), which should shorten the Any% route by almost 10 minutes.

There are also numerous new clips possible throughout the All Missions runs (i.e., M4 door to Hughes, M10 elevator to Gemini, M14 Nest Alpha Core, Minigames, Purge Sequence, et cetera). Many more will likely be discovered with additional testing and experience.

TL;DR - Dynamic switching to high resolution to temporarily limit game FPS and enable a whole new world of crouch-clipping. Should work on any machine (PC only, sorry consoles!). Any% and All Missions times will be dramatically reduced (again).

Here are a couple easy crouch clips that save a lot of time in the Safe Haven run:

G5:

B8:

This one is big.

Major time saves using this glitch/mechanic have been discovered and tested in numerous missions, including M2, M3, M6, M7, M10, M11, M12, M13, M14, M15, and M16. We'll be sharing these and any new glitches/routing here and on Discord as they are compiled.

Special thanks to PackSciences, who first hinted at this glitch (), Chimpaneez, who inspired a fresh look (), and of course everyone who has helped or will help explore this magic.

:D

A growing number of speedrunners and community members are relying on Discord for discussion about the game (and other things). Anyone interested may join at the link below.

https://discord.gg/0Sk7X8JLpV478kG2

It has now been several months since the PC AI community has had access to a load remover for LiveSplit. Based on tests (see my prior posts and spreadsheets), it appears to be working accurately and as intended. This is a great addition to the community because it levels the playing field among PC runners who have dramatically different hardware (and thus, significant differences in load times).

Until this point, the leaderboards have been sorted by Real Time. This was primarily motivated by the need to validate the accuracy of the load remover, and additionally to provide runners with ample opportunity to submit new personal bests with load times removed. Those objectives have largely been achieved, although not every runner has submitted a new time and several of them are no longer running the game.

It is now time to discuss how best to integrate and merge (if at all) existing runs into a leaderboard sorted by Game Time, rather than Real Time. As of now, we are in the minority of PC games that ostensibly continues to prioritize Real Time where (1) a functional load remover is available, and (2) load times vary dramatically based on hardware.

Part of the rationale behind this persistence has been the (completely valid) concern that the leaderboard will become non-sensical and messy if sorted by Game Time where certain runs only have Real Time values. Because of the way the website works, every run that does not have a Game Time is prioritized lower than those that do. In other words, a 2:48 Real Time run will appear to be ranked worse than a 2:59 Game Time run, which is obviously not correct.

Following are several options. For purposes of this discussion, "existing runs" refers ONLY to those runs that have not been (a) timed with the load remover, or (b) manually re-timed to remove loads.

1. We do nothing and continue to prioritize Real Time (by virtue of sorting by time with loads as the default), despite the availability of a functional load remover and our knowledge that load times vary dramatically based on hardware. This perpetuates "pay to win" - runners with better hardware will have lower load times and better overall times - and discourages runners who have anything less than the best hardware.

2. We time out loads for all existing runs. This is a tremendous amount of work but something I would be willing to do if runners would provide (a) unobstructed YouTube VODs (or equivalent) of their runs and (b) time(s) of any death(s) that occurred during those runs. "Unobstructed" is critically important - if the load icon is not visible (i.e. because of a face cam), it is nearly impossible to accurately determine load times.

3. We use the same values for Game Time and Real Time for existing runs timed (a) without the load remover, or (b) where the load icon was obstructed. (An example of this are my runs in Nightmare Any% and Nightmare Low%.) Essentially, we can prevent the website from prioritizing Real Time runs lower than (unequivocally slower) Game Time runs by simply giving those existing runs a Game Time. This is not technically accurate (as the Game Time would include loads), but it would avoid a non-sensical leaderboard. Additionally, it would not affect the current Top 5 runs, all of which have been either timed with the load remover, or manually had their loads removed. (As a FYI, this is the option most games have implemented when a load remover was introduced - see, e.g., http://www.speedrun.com/me )

4. (Variation of #3) We remove some fixed amount of time as "load time" from existing runs. Based on runs completed with the load remover, and runs manually re-timed to remove loads, it is clear that PC runners have at least 4 minutes of load times, not counting reloads due to deaths. Under this approach, a 2:48 Real Time run would get a 2:44 Game Time. Again, this is not technically accurate, as load times vary greatly by hardware, and this will necessarily be more beneficial to runners with closer to 4 minute load times than those with 6 or more minute load times.

5. We split the leaderboards into Real Time and Game Time. This will be duplicative and messy (in addition to requiring more work to maintain). Furthermore, the Real Time leaderboard would likely become obsolete.

Option 3 (or 4) is my strong preference. However, this is not a dictatorship that simply imposes draconian decisions. Comments welcomed.

Free time for 100% runners.

It's possible to clip the audio log and ID tag out of the cage with the maintenance jack, avoiding the need for 100% runners go through the vent. Enjoy.

Oops, I did it again. :^)

Enjoy.

crater was nice enough to send me this "major" out of bounds version of the infamous M12 tram trust glitch, which he figured out 6 months ago:

Dunno if it's useful (you'd probably need a save station or locker to pull yourself back in bounds), but it's pretty slick!

Here are two VODs of the Safe Haven "double skip" (B8 + B9). Perhaps there is a clue buried inside that will unlock the secret necessary for consistency. We think the mwheel use on the B7 terminal is critical, which is why the VODs include that portion of the testing. The second example goes to the end to show that this skip allows the DLC to be completed without ever touching B8/B9.

Example one:

Example two:

Don't think this is faster than the current any% yolo strat (with a really good hack, it might be close and sans risk to boot). It should be a great time save for low% and NSR runs. Enjoy.