Wasn't sure what to title this.

As most people who speedrun PC games seriously are aware, having to deal with ever-evolving hardware is the underlying problem with trying to do so, and that it feels more fair to compare runs based on their execution (their time 'without loads') than to compare runs based on their real time (their time 'with loads').

For my personal bests, I've always tried calculating out all of the frames I observed the game spent frozen in a 'read' or 'write' state - similar to how I think SDA verifiers performed their calculations when handling my runs in the past - to the best of my ability. I've always done this manually; I've never had an automatic means of doing this. And I've always wanted these leaderboards to have a column for this "excluding loads" time I'm describing, but didn't want to implement it until there was a way to do this automatically.

I don't expect to return to F.E.A.R. much anymore, so making an automatic process that would accurately detect every instance of when the game is not in player control (due to a read/write condition) and calculate that time out of the splits is not something that I will be trying to do, nor do I have prior experience in anyway.

I do want to stress that my intention was to have every instance of the described player non-control be involved in the calculation, rather than making a crude program that only recognizes between-stage loading screens. That means checkpoint saves, quicksave saves, save loads, et cetera. A program that only calculates out SOME of the loads and produces a time from that would just feel (more) arbitrary, in my opinion.

So to anyone that comes across this, I just wanted people to be aware that it's not my intention for these leaderboards to only have a "real time" column, but didn't want to incorporate an "excluding loads" column that only excluded a portion of the loads. I did consider making what I described a reality myself, but, well, never had enough of an interest compared to other affairs to devote time to it, let alone experience making such programs.

I don't have any expectation of this being made a reality, and I can't foresee there being enough runs (at least, anytime in the near future) for this issue to even matter on a significant level, but I figured this thread would be worth making for posterity's sake if nothing else. If anyone ever shows up that actually attempts to do this, you have my gratitude.

I saw you calculated my load times and everything when I submitted my runs recently (thanks for that btw). What you're saiying is that you'd like to have something better than just an auto-splitter for the game ? That's what we're using on F.E.A.R.

I would have liked to have such a thing on Perseus Mandate but since I'm not good at programming things, I can't design it. Hope someone does this in the future.

All I did for your run's real time is change, primarily, the start time for your run, because the way I time these runs is based on player control. Control is gained right after the first checkpoint save in the game (once you've landed after parachuting) and control is (mostly) lost when you're congratulated at the end. I think timing based on such control gain/loss is the most fair thing to do. Additionally, what a timer says is not gospel, since it could be inaccurate for any number of reasons - the main one being that the player simply didn't start it or stop it at the right time - so I personally always open the run up in a video viewer afterward and check the start and end frames to confirm the actual time.

Yes, I basically would want a more sophisticated means of automatically removing the moments of time that the game is not in player control. From what I can tell, such autosplitters only detect when the bar on the loading screen is moving from empty to full, which is only roughly half the time the game is spent outside of player control. It's not ideal and not what I consider a proper calculation of "in game time" or otherwise, but again, I have no idea how to have a program know how to calculate out every instance of lost control, and thus, have always done this process manually for my own runs, even despite the amount of time it consumes for me to do so.