Hey all, I wanted to bring some background on some changes coming to how framecounting works based on our current standards. I'll keep this brief because it's alot to sort through and the mod team is still working on it in the background.

In a nutshell, recordings are at a variable frame rate, so any start point frame that has some of the DP bar filled will have milliseconds added to the final time based on the distance from the correct starting point to compensate for the dropped frames. Keep reading for the more detailed explanation.

The Standard

As a reminder, for PRTS Runs and similar, we use the following standard for determining the start and end points for runs that use auto deploy.

• Start point reference
• End point reference, unless DP is capped, then the first frame when the opaque Mission Success screen appears becomes the end point.

So one of the major issues we have been having involves the start point.

The Problem

Modern video recordings are being recorded at a variable frame rate even if it says its at a static frame rate. Top that off with how the hardware, whether phone, emulator, or type of computer rig, will further add to that variability. There have been times when framecounted runs were showing signs of the recording skipping over the standard start point. This is causing issues where the start point is later resulting in a shorter final time compared to a better hardware recording that was able to accurately capture the correct frame.

As a result, systems that performed poorer than others or were running their game/auto deploys at 30 FPS are at an advantage.

Invalid Standard Example

This is frame #1507 for a WB-7 run from the WB speedrun contest. This is the reference frame before the start point for the run, so we start the timer on the next frame.

The next frame, which is frame #1508, should show the small amount of the white DP bar appear. However, in this frame, the bar is already ~7% filled, which should not be considered valid.

Valid Standard Example

This is frame #593 in a different recording for WB-7. This is also the reference frame before the standard start point.

Unlike the previous example, in frame #594, the DP bar is not already partially filled.

It's difficult to see, but it's a very subtle white line at the beginning of the DP bar. It's easier to see when moving through the video frame by frame. This example does follow the standard correctly.

If you haven't noticed, the two recordings are from the same individual, but the recordings were made at different times.

The Solution

Our goal is simple: make speedrunning Arknights as easy and sensible as we feasible can. The mod team works hard to ensure that any runner of any skill level using any hardware can, at the very least, participate in the leaderboards. This also boils down to keeping the settings as varied as possible, such as being allowed to play the game at your choice of 30 FPS or 60 FPS. You can read more about our Accessibility clause in the New Category Guidelines forum post.

To achieve keeping the game as accessible as possible, we will be adjusting runs that do not follow the standard start point for framecounting by adding milliseconds to the final time based on distance from the beginning of the DP bar in the reference frame. This will be done using a formula that is still in the works (I'll edit this news post and announce it in Discord once it's complete). All this work will be done in the background by the mods.

Where does this apply? Only top ranked runs for high profile contests or speedrunner request are subjected to framecounting. Otherwise, the mod team will use the YouTube Frame Counter. Because of the daunting task of it, the mod team will not retroactively recount any run before September 7th, 2023, unless explicitly requested by the runner.