Question 2

Alt focuses the title bar or something, like it does in a whole lot of other applications. You can watch this video. I mention what it does in there. Note that pause buffering came to be banned for speedruns so you should simply never press alt.

Question 3

Are you playing on controller? If you're talking about momentary grey/white screens on every respawn, those are caused by having a controller plugged in, and cause an RTA loss but not an IGT loss. Ziggy's runs have them, for example, but mine and cake's don't.

Otherwise if you're talking about pitch darkness that actually lasts several seconds, I'm afraid that is an anomaly that at least Cake and I also experience but don't understand. We think it's a side effect of Windows 10. It is indeed annoying. On the bright side, I don't think it affects IGT, but it will obviously mess with your splits a little bit. Hopefully it doesn't happen very frequently for you.

Hope this helps. Let me know if you have any other questions. You can also join the vi speedrun discord if you want some realtime discussion instead of forum replies. Pic below of the invite location on speedrun.com.

Question 1 (cont)

The line up we use is as follows:

1. Respawn at save and slide to the right, drop down.
2. Align yourself with the left side of the block to your right, as seen in my runs. You can do this while falling and it does save frames, but for now we are considering it psycho behaviour; it's much easier to press against the wall by doing the short hop you mentioned. Note that in my 34:15 IGT run I accidentally didn't align with the wall but still got it. In my 34:28 IGT run, I aligned and got it.
3. After aligning, release right so that you stay aligned with the wall, and fall to the ground.
4. Do a "neutral slide". This means sliding without any left or right input, so just down + action.
5. After starting the neutral slide, begin holding right.
6. The hard part: at some point after leaving the ledge, you must press and hold jump with good timing, then at some time later you must press flutter with good timing. These are not free, but they're not extremely precise. I would estimate you have about a 4 to 7 frame window @ 60 fps for either of them, but I haven't measured and I don't know that anyone has. The difficulty here comes from not having a background cue to time your inputs with; it's either muscle memory or you can try to estimate it based on the dust path left behind vi as she falls.

What will help you get the hang of Pixel Jump is going frame by frame on your successful and failed attempts, and try to identify a trend in the correct timing from that. At first you could do this with others' clips and it might help to mimic their cosmetics so the footage is directly comparable. On YouTube you can use , and . to move one frame in either direction, and use shift + , or . to slow/speed up the playback rate. Avidemux is also a useful tool to have for footage analysis, as it's extremely snappy for frame-by-frame stuff once you've got a video loaded, but you need to have the video stored locally so that's a pain for looking at others' clips. VLC can do it too but it's not as responsive; check VLC keybinds.

My description of the jump + flutter is... I jump before vi feels like she has started falling too fast, and I flutter while I still have a little bit of upward momentum at the end of the jump. I know that's vague but trying to figure out some kind of description like that for yourself to go off might help.

Welcome back.

Question 1

That's called Pixel Jump. I will say this upfront: this trick isn't the easiest and it doesn't save much time. There are much more important things to dedicate practice time and resets to. Consistency and being able to finish a lot of runs is so valuable in this run, and that's coming from the guy who was by far the least consistent player until 2023, always going for risky fast strats. You should probably just do the strat that Ziggy does (video link). Cake also demonstrates it in his full run guide which is a great resource (video link). Both parts are in the Guides section on this site, too.

Anyway, Pixel Jump might be pixel or subpixel perfect with several feasible starting positions spread apart, but we aren't certain how it works. You can get it without a line up but we believe it's based on at least one of three unreliable factors.

Here is my technical explanation. I'm not certain on these but they are pretty solid hypotheses based on how other platformers work. You can skip this if you don't care to know:

1. Horizontal subpixels due to vi's acceleration. When games accelerate objects they usually don't go with a simple acceleration like 1 pixel/frame^2, as this is too imprecise to achieve the exact gameplay the dev wants. Typically acceleration has a decimal point in it, meaning that every frame vi's horizontal position is likely having a decimal point rather than being an integer (whole number). For example, 352.38267539 or some other arbitrary decimal component, but rounded down to 352.00000000 for the sake of determining which pixel vi is standing on. Every frame this subpixel value changes by an amount her velocity and therefore acceleration dictate. On some frames, she will move an extra pixel due to an accumulation of this decimal component combined with rounding. This happens in IWBTG fangames too, if you're familiar. In those, The Kid moves at a consistent horizontal velocity of 3 pixels/frame with instant acceleration and deceleration, so this concept of subpixels only applies to his vertical position where jumps have acceleration and deceleration. It can result in gaining an extra pixel of peak jump height if you bunnyhop when you are at a certain vertical subpixel.
2. Retaining a variable amount of sliding velocity when you slide off a ledge. Sliding at some distances from a ledge retains a higher velocity for longer than sliding from other certain distances does.
3. A varying string of horizontal positions vi is present at throughout her movement due to a velocity above 1 pixel per frame (this is called a "hstring", short for horizontal string). If you're moving 3.5 pixels per frame while holding right, then you would exist on pixels 0, 3(.5), 7, 10(.5), 14... But look at all those positions that were impossible for you to be at! What if the jump is only possible had you existed at one of those skipped positions? It's possible that with some hstrings, the jump is impossible no matter what the player inputs. However, we don't have the resources or willpower to arduously test this.

What we do know is that having a consistent horizontal position for the start of the slide helps with the Pixel Jump. If you do not use a line up, this trick remains luck based for humans, as we cannot play around the above factors in realtime.

Sometimes you can get them first try but catching them in general is only just above 4% chance: https://docs.google.com/spreadsheets/d/1UO1Z8ia5qweHh6vnNRayWA_4A-uO7sdQfYGA8y8F4jo/edit#gid=0

Also, most of our runners are very active on the NieR: Automata speedrun discord, which you can find by going to http://discord.nierspeedrun.com or clicking the "Discord" link in the sidebar to the left of this writing.

I'm having the same issue.

It seems impossible to sort a board's times using a "mixed" method. That is, having loadless being the primary sorting method, but having RTA mixed in where appropriate.

For example, currently: Player A has 1:05 (loadless) and 1:10 (RTA). Player B has 1:07 (loadless) and 1:16 (RTA). Player C gets an insane 1:02 (RTA) and has their time placed further down the board than Players A and B. This doesn't make sense, because srdc explicitly tells you that "RTA cannot be quicker than loadless" if you try to submit a run with an RTA quicker than loadless. So, realistically, the Player C's 1:02 (RTA) HAS to be quicker than Player A's run, despite not having the loadless time to prove it.

Another problem is that Player D can get a 1:12 (RTA) and it'll again put it below every single run with any loadless time submitted. In this case, the board can't accurately predict where the loadless time would sit, but it would obviously have to be quicker than the RTA. Hence, the run should be placed by comparing its RTA to other runs' loadless times, instead of being automatically put below every single loadless run.

Also, when you initially set a board to use loadless and RTA, all the pre-existing runs will have their RTAs set as their loadless instead. I think this ties into the way defaults work in board ordering or something, but yeah, that's another issue.

Basically, it'd be super duper nice if we could sort by loadless without sorting by ONLY loadless. Therefore, it could be called "mixed" sorting.