NEVER in my days have I ever seen a game run at 700+ FPS! Where in the galaxy did this guy get his computer from?! What extraterrestrial beings did he raid?! The most my computer is able to run at is 60! I'm diffidently making a TAS for this. Thank you for finding the video!

Alright, I just went back through and fixed a few of the mentioned errors, found and fixed a couple that were unmentioned, enhanced the readability a bit, and added a few explanations for things that were only briefly described. Hopefully this helps the paper out a bit.

• The main issue that I have with the use of the exponential identity is that involving it like that introduces it without context, proof, or the BEHAVIOURAL SIGNIFICANCE of X relative to how the identity was derived. When I was initially making the pdf, I actually did consider writing the exponential identity very similar to how you mentioned, but after some thought, I decided it would be too much of a jump when comparing to part two and the rest of the pdf.
• In the final part of the analysis, it can be seen in the function of average speed that it has a consistently negative derivative (applied to the boundaries permitted by game stamina and time). Therefore, the maximum value may be located near 0. This was actually mentioned near the end, but very briefly. But I should absolutely make this more clear.
• I should have specified, but the exponentials in the FINAL equation will approach 1, not 0. Sorry about that.
• The use of the differentials where you are suggesting was actually intentional. Variables like dx and dy were actually initially used as variables describing a number that approaches zero. I often times take heavy advantage of this ancient notation (mostly out of laziness, because I don't wanna have to use latex to write a limit). When I was talking about using the greek delta, I was referring to my use of it on page 5.
• Defining both f and g as continuous, although considered, was scrapped because I deemed that it really didn't matter that much. The mathematical ideas in the document were derived considering their applications to the math at hand. Some information had to be excluded for simplicity's sake if such information could already be intuitively inferred. Although it is a good idea if I'm being really tedious, it's not needed in this scenario; the general functions included within the pdf may all be considered continuous (except for a few obvious ones, like the recursion functions).
• Yeah that one is a bit of a silly mistake, and I'll probably fix those kinds of errors as it wouldn't decrease the overall comprehensibility.

Btw, I don't consider any criticism as too critical unless it's rude. As far as I can tell, you have been polite and EXTREMELY helpful for me! Not only am I glad that somebody read through the math I wrote out, but I'm also very glad that somebody actually gave me feedback to improve the document. I cannot thank you enough.

I greatly appreciate your feedback! I'll start by addressing your issues with reading it:

• (On Point One) I can understand your difficulty with reading through the context segment; it's very jumpy. To fix this, I will probably move the discussion of the CurveValue function down to the bottom. Also, I forgot to alphabetically reorder my equations, so I will be fixing that issue.
• (On Point Two) To me personally, proving everything is vital specifically due to the target audience; my reasoning for this is mentioned on the pdf. Also, I VERY MUCH appreciate your idea on a faster derivation of exponential identity. However, the idea is insufficient for proving the equation mentioned in the pdf, as the equation excludes the behavior of numbers in the numerator within the parentheses.
• (On Point Three) A lot of the math in between had to be excluded to reduce the size of the paper. I decided that the pdf was already kind of long, so I didn't want to add to much obnoxious math.
• (On Point Four) The pdf had initially intended to be posted on the forum in raw text, so when that failed, I had to copy the data into a place where I could print a pdf resulting in the loss of italicization. I attempted to go back in and fix this error, but I guess I missed a few. I greatly appreciate you pointing this out. I will be fixing this.

As for your points with calculation concerns:

• (On Point One) While writing the pdf, I was already aware that the equation I was deriving did not represent the average speed for all distances. However, it DOES represent the average speed for large distances and high fps (which is the focus of the pdf). This is because when the FPS and the distance increase the squeeze theorem can be taken into account. But you do graze against a really interesting point; what about all distances? This is one of the many things I decided to exclude from the analysis because this problem became extremely complicated. On my second part of the analysis, the pdf is already extremely long and features Lagrangian Inversion, the Lambert W function, advanced hyperbolic trigonometry, etc. But for the purpose and requirements of this pdf, you will not be able to achieve a greater average speed with a larger stamina interval; it basically just wastes too much time which can be seen with the derived equation for overall average speed.
• (On Point Two) The error you hypothesized will not occur at all. With our assumptions considered, the value of all referenced exponentials will approach one; all of their exponents are negative. It may also be observed that all values of these exponentials will still approach one even while accounting for their framerates using Equation E, because their values will be less than 1. But I do very much appreciate you pointing this out; it is something I should have probably explained further.

Finally, those pesky little mistakes:

• (On Point One) My unintroduced use of x comes from my initial modeling of the function, where I used x to represent frames elapsed rather than time. I accidentally left this in, so I will be fixing it.
• (On Point Two) I accidentally left this in by mistake because when I was previously modeling the function I was using speed independent values. As I was remodeling these functions for easier comprehension, I forgot to replace that value. Thank you for pointing this one out; I was wondering if I got them all.
• (On Point Three) My use of df is due to desmos absolutely not cooperating with me while I was trying to insert the delta symbol, so I decided to use d instead. I'm probably not going to be fixing this one as it really doesn't matter too much.
• (On Point Four) This one is already handled by use of the word "near", as it implies that these values cannot be determined at the point a. Also, the functions do not need to be handled more vaguely, as the assumption that f and g are continuous works as well.
• (On Point Five) I chose not to label every expression as "Expression [Symbol]"; I deemed that if I were to then it may add a layer of confusion and more convolution to the actual point of the pdf.

I was only aware of Gate Warping being used in conjunction with the scp-1499 dimension in version 1.3.3. If that isn't what you are referring to, then I would really like to see a video. I've always assumed that the Gate Warping trick, ESPECIALLY FOR GATE A, was very difficult to humanly accomplish. Also, I really want to see footage of the guy running through the pocket dimensions using his high end computer; that just seems hilarious.

Yeah, I'm aware of the 120 fps rule, but the potential that it has when making a TAS is extremely great, because as far as I know, that's sort of pseudo-fair game for a more absolute and general TAS, as long as you're not straight up cheating. To be fair, I probably should have more heavily suggested that my significance ratings on these bugs is likely biased towards TASing. Also, I have accidentally warped out of bounds at Gate B and magically ended up at the exit area, but what I find interesting is that it actually works for a multitude of areas. For example, when I was playing with my friend in multiplayer I was just sitting in the void near some pocket dimension structures. My friend asked me to teleport him to me, but when I did he magically spawned into the actual pocket dimension, and the bozo died after 106 spawned in to rapture him.

Throughout my short intervals of messing around with this game, I have seen several very interesting behaviors, bugs, and oversights within. My intentions here are to share as many of these interesting phenomenon as I can think of (that are worth sharing). I will be rating each of them on a confidence percentage (how confident I am that they are possible), a significance level from 1 to 10 (combination of potential impact and significance to the average player or a TAS), and a ridiculousness level (just how insane the idea is). Keep in mind that some of the mentioned ideas are merely speculative and will require further research into if they may work.

Arbitrary Code Execution (Confidence: 90%, Significance: 9, Ridiculousness: 8.5):

If you play the game a lot, you may notice that it sometimes generates a message box reading: "Memory Access Violation". For those who do not know, this message is usually generated when the game tries to access a region of its memory that cannot be read/written or does not have the read/write flag set. Now, there comes some heavy significance to this for one major reason: the game stores its executable code in a readable, writable, and executable region of memory, which is not usually done partly BECAUSE of things like arbitrary code execution and security exploits. If a reliable method of generating an access violation due to attempting to write to foreign memory can be found, as well as a way to reproduce such error consistently, then understanding how the error works may make it possible to generate code and run a jump instruction directly to said code. If arbitrary code execution is possible, then that would mean nothing is off the table in terms of possibilities: teleporting to endings, spawning in items and entities, even running console commands without using the console. The only issue with this is that I'm 99% certain that if ACE is discovered, then it's unfortunately going to be TAS only (because ACE in games is usually hard as hell).

Extreme FPS Bug (Confidence: 100%, Significance: 9, Ridiculousness: 10):

Because the game has a lower limit on its FPS Factor variable (which for anybody who has developed any kind of game, it basically functions like the game's DeltaTime variable), anybody running the game on an extremely high refresh rate might notice something very odd; their game will run faster. And no, I don't mean run faster as in like FPS faster, I mean everything will literally go faster. This happens because the game on each frame multiplies any object velocities (or really anything affected by its own speed) by how many frames have elapsed, adding said value to their respective object position. However, when the game's running on more than 350 FPS then the value will be capped at a minimum, meaning that each frame of the game will increase positions without adjusting for the higher refresh rates, thus making the game run faster. A general formula for the speed of the game may be computed as fps/350 when the framerate is 350 or more. This can allow EXTREMELY QUICK TIMES to be achieved... but since SCP Containment Breach has spaghetti code you would probably need to steal a NASA computer to actually see effective results of this oversight. (NOTE: I may make a TAS demonstrating this oversight in the future.)

Gate Warping (Confidence: 100%, Significance: 9, Ridiculousness: 5):

I have already made a TAS for this, but this glitch basically works by traveling to a specific area of the game that when saved and reloaded in will cause the game to transport you to a certain place. This can be done in basically any externally prepared region of the game: Pocket Dimension, Gate A, Gate B, SCP-860 Forest, etc. For the case of teleporting to Gate B, this can be done by travelling over to the Gate B exit area in the entrance zone, using SLHA to reach a certain height, walking to a certain spot above the room, and finally saving and reloading. The ease of this glitch usually depends on how many times you need to SLHA.

There are more, but I just decided to point out a list of the top 3 that I found most interesting. Also note that these glitches and bugs are either very unfair or nearly impossible to achieve.

I tried to post this here earlier but the content was continuously rejected and nothing was really working. I should have guessed that I wasn't going to be able to submit a colossal paper here in raw text (exaggeration, it's actually not that big), so I decided to upload it to a discord message, copy the link, and send it that way. I'm hoping this works otherwise I'm gonna look real stupid.

Anyways, here's the link to the PDF file!

Sorry for the awkward work-around.

Also, If I'm violating any rules by submitting a link like this here, then please let me know or, alternatively, take the post down if you have the power to do so.

Sorry, In my tired state I accidently wrote "reverse engineering", and that's not actually what I meant. I meant reversal of the random number generating function. Also, I already have a formula for the function written in number theory functions, now I just need to make a reversal for the function (-- whenever I get around to it; I'm pretty lazy sometimes).

If anybody finds any significant oversights or errors with the TAS, please let me know.

Okay, I just finished the TAS:

(Sorry for the odd screen resolution, my PC bad.)

My next project concerning this game will probably be one of the following:

Efficient reverse engineering of the Blitz random number generator using number theory calculus

or

Mathematical analysis of the CurveValue function (I know, it sounds extremely boring)

QUICK UPDATE:

First off, I rebuilt my TAS tool for this game, so I will attempt to finish a TAS concerning the 1.3.11 wrong warp glitch by tomorrow and post the video here. I am 90%-95% percent confident that I can complete the aforementioned goal.

As for the rest, after planning a route for the TAS, I determined that my estimate of 30s is a bit of an overexaggeration. I am sorry for the disappointment, but the time is more likely around 1m 30s for Gate A and possibly at best around 1m for Gate B (BTW, that Gate B one was a complete guess; I have absolutely no idea if it's right, it could just end up like my 30s Gate A estimate -- wrong).

TWO MORE THINGS!

The TAS will be played at a non-standard fps. In other words, it will not be played at 120 fps.

Finally, if I forget to include an explanation as to how the TAS works in the description, somebody please chastise me for it so I can go back in and fix it.

Recently (actually about 2 years ago), when I was decompiling the code and mechanisms of the game using reverse engineering for the creation a TAS, I came across a potential glitch that allowed for an LRT of around 30 seconds or less. Exasperatingly, however, this glitch requires a special form of incremental save-pause-closing to reach a height of about 5000 units (if I recall correctly). From this height, the player can travel to a specific position (as the floor will be solid), save, reload, and appear at either Gate A or Gate B instantaneously. This glitch has what I believe to be the same cause as the 1.3.3 wrong warp glitch (I didn't actually fully look into that, so I could be wrong). Another interesting thing of note is that this glitch doesn't even require the player to have ANY items whatsoever; you could literally just spawn in, go up to a height of 5000 units or so (again, not so sure about the height, as I still don't remember), run over to a certain position, save, reload, and boom, essentially game beaten.

IMPORTANT THINGS TO NOTE:

The time estimate of 30s is an estimate assuming that you're playing the game VERY WELL!

A more probabilistic estimate may be given at around 1m.

This glitch does not require ANY interaction with ANY of the sequence bits (computer, virus gas, remote door controls, etc.)

In the future, I may make a TAS to show the exact mechanisms of the glitch.