The new patch for an in-built timer solves the question. It provides an IGT equivalent to RTA without loading times.
There may yet still be some small bugs if doing weird things (testing would be appreciated), but it should mostly work.
Old full run times (only PB) for 0.9.3 should be converted to RTA-without-loading times. That's not a very pleasant task, but that would be the best thing, I think, there aren't that much runs.
Frame-counting the loading screens for the published runs seems the way to go, yeah. Use the overlaid timer in the video, and count the time at the last loading frame - the time at the first loading frame as the loading time for that loading screen (that rounds it down somewhat, but that's better than rounding it up) ; and do this for all loading screens. Any frame-precise video-editor easy to use should do the work, though I can't tell you what exactly should be used.
Hopefully converting a single run shouldn't take more than one hour. There are 7 runs in total to convert in 0.9.3.
Btw, @Alistair_Findlay any% run should be replaced. After all, his expert% run is also an any%, and it has a much better time.
Also rules should mention that the time is counted in RTA-without-loading-time and point out the patch. That's ok to convert a few older runs I think, but that wouldn't be ok to have to convert new ones, so submitting a run not timed with the in-game patch timer = losing the loading time for future 0.9.3 runs.
Overlaid = put on a layer over something. Basically the timers who aren't part of the game but who are put over it in the video by the runner, like the one from LiveSplit. From what I can tell, all the runs use one of those.
I'm going to obsolete all my old full-game runs and re-run them with the timer patch. Re running might take longer but it will be more fun than counting frames lol. Anyway, it will be good to replace muley mcmuleface with kawaiikiki haha.
Good idea, sounds indeed more fun to rerun rather than to frame-count.
I may try to obsolete my own expert% run, would reduce the work to do.
@UbuntuJackson : The loading times are somewhere betwen 30-90s in the runs, I think that if your overall error isn't over 1-2s that's fine. I don't know what editor to recommend to you, I know I have already used a frame-precise editor at least once but I couldn't tell you.
You aren't absolutely forced to use the overlaid timer, you can also just substract the time of the first loading frame in the video editor to the one of the last loading frame to get the loading time. I suggested looking at the overlaid timer because it might be more convenient, that's not an obligation.
But maybe wait before doing a conversion, if we beat our times well enough with the timer patch so that it's better than the old times without loading time, then the conversion is unnecessary. You maybe could try to beat your own any%.
The timer patch doesn't work for 0.8.1% anyway. I was speaking about a 0.9.3 any%.
For framecounting, see for example : https://www.vlchelp.com/frame-stepping/ Or : https://www.mltframework.org/docs/melt/
Yes, you do the sum of the loading times (rounded down as explained above) across the whole video. This gives you a total time spent in loading, which you note and remove from your RTA total time.
Just do as precise as you can for each loading sequence The error will be around one video frame, so over the course of the run this will be one or two seconds, probably.
You don't have to count the number of frames, you just note the time at the first loading frame, go frame-by-frame until you reach the last (VLC might not be good for this because it can't go backwards). Then you note the time at the last frame of loading and calculate the difference to get the loading time. That's what I meant by "rounding down" : if you take the time at the first frame of non-loading rather than the last of loading, you might calculate a loading time higher than it really was. By the way, the in-built timer will also count one loading frame, so this is better for consistency between the two.
