FrancemprGG put a lot of time and effort retiming dozens of runs in the past days, he's a hero fyi
Please give the option of removing streams from showing up automatically on the frontpage of SRC. Right now the twitch/speedrun thing in particular is pretty much 24/7? (or close to) and effectively acts like an automatic video ad (and I mean let's be honest that's the goal isn't it). Using SRC to promote your own stream to this extent and force it down everybody's throats is heavy-handed and unacceptable in my opinion.
As you expect it's kind of common sense that the fraglimit or bot count (and other variables that affect bot behaviour) can't be changed but I guess it wouldn't hurt to add it to the rules yeah.
Basically cosmetic changes only.
~ Announcement ~
Starting from today, the ranking in the Q3 leaderboard will be decided based on times without loads. The times with loads will remain in their own column. Loads include the 'awaiting gamestate/connection' screens and the loading of the map assets, bots etc before the spawn. Note that the menuing required to go to the next map is not included in the loads and is still part of the final time.
~ What's the idea? ~
Recently, we started to notice that the loads' duration differ massively from one player to another. After some investigation, it turns out that beyond the CPU specs of the players, the OS actually has a massive impact. For whatever reason, Windows 7 has a ~25s advantage over Windows 10, due to the fact that Win 10 gets stuck on 'awaiting gamestate' screens. Windows 8 is somewhere in between.
On top of some computers being able to load the maps much faster, we all agreed (on Discord) that such an unfair factor mostly out of our control should be removed when comparing runs. After careful consideration, it was decided that an autosplitter with load removal (courtesy of liveth/pekafacer) will be used.
~ Autosplitter ~
If you want your runs to have a time without loads, please use the livesplit autosplitter script that you can find in the Resources section. So the competition and ranking are as fair as possible, we'd like for everyone to use that same tool to get their no load time. https://www.speedrun.com/tools/Q3A_ASLR_644it.rar
liveth explains in the following post how to set it up if you're unsure: https://www.speedrun.com/post/eenu7
~ What about old runs? ~
So that all the past top runs without a 'no load' time don't become obsolete/overshadowed, Ewil and I are going to retime them to some extent when we have a chance, and manually determine 'no load' times. We can't promise to retime the entire leaderboard obviously, and priority will be given to runs near the top.
~ Can I just submit times with loads? ~
Yes, using the autosplitter is not mandatory to be in the LB. Note that if you don't use it and don't have a time without loads, it will impact your ranking though as any run that used the AS will be marked as faster than yours. If you don't care, feel free to submit with loads if you prefer.
That being said, if you're going for a top time or consider going for one, please use it so we can compete on equal grounds and accurately have your run at the top if it should be there!
~ Bonus information/tech for loads ~
funny_ha_ha found out that the gamestate screen can be made much shorter, even on Windows 10, by kicking the bots at the end of the map before the pedestal.
This can be done by binding "kick allbots" to a key and using it after the last frag. Make sure to not use it before reaching the fraglimit though or you will be unable to complete the map.
Note that as the gamestate screen is already removed from times without loads, this tech has no impact whatsoever on those, and on the ranking. But if you're interested in also pushing your time with loads, give it a try!
Je vis à Kyoto justement donc c'est dommage qu'on n'ait pas échangé d'infos auparavant ! J'y suis depuis avril 2018.
Right now I'm living in Japan so grabbing a beer is gonna be difficult for me! Hope you enjoyed your stay in Taiwan, I actually went there in march for a few days (as it's close to Japan) and thought the landscape outside Taipei was really wild and unique.
Hey baruch!
I have to say that when I worked on the game back then, given that I spent little time on it, it felt like I did a pretty good job routing a lot of things from scratch (TAS can only be used to some extent) and that the run produced was even cleaner than expected. Soon after I did realize a couple of things I overlooked and some dumb small time losses here and there, but even then I was imagining the run could be brought to something like 5:53.
So the fact that it's now sitting below 5:51 is extremely impressive for me as well and all the small optimizations that were brought by you and Max (obviously Max in particular is bringing the game to the next level right now but I know you also helped the process a lot) were really remarkable and by far exceeded my expectations. From my experience and all the games I've seen, I think it's fair to say that Asterix at the moment would rank among the most optimized games with small communities. I know that a while ago I had some interest in coming back to this because I felt that a little more could be done with it, but as it is right now it's pretty much at the lowest priority it could be for me, not because I don't like the game (not saying I love it but it was more fun than I expected at first to grind it) but because I don't think that I would have much (if anything) to contribute, and the game was already done justice by other people.
Well I say that but apparently there's still some sizeable improvements, although your videos aren't working (if you could fix that, I was curious to see what it was like). Even so, that's just curiosity on my part and doesn't change the desire to watch from a distance, and I'm sure Max on the other hand will incorporate them if they are reliable!
As for you, I can only wish you good luck on your next endeavours!
@Dangerless Thank you, one of the two contacted me after you got in touch with them. In the end we settled it and so it should be fine to let it as is, as it was promised not to do unwanted changes to the LB without first discussing it with the players.
I see your run in this LB https://www.speedrun.com/Asterix_SNES so it should be fine as far as you're concerned?
Hello,
I'm SuperMod for the game Astérix (NES) and I'd basically like for the two other SuperMods to be removed. To begin with I'm not sure how they were added, I think maybe when the series was submitted? None of the two run the game but that's not the issue.
Long story short there's been multiple instances of a mod unilaterally deciding something completely dumb and unwanted by the community, and me having to clean up the entire mess afterwards. Last incident was him adding other different games to the same LB for whatever reason when it's always been dedicated to the NES one only, and adding one totally unrelated SNES run at the same time. I just had to remove that run, all the other versions, an extra column specifying the version etc. Last time I had to change the time for every run because he decided to add wrong milliseconds to all of them.
I have nothing against this person in particular and he seems quite dedicated to helping, but he doesn't know what he's doing with this game and he hasn't apparently heard about contacting players and mods before so.
There's very few submissions and I can basically handle them on my own, but I'll see if some of the players also want to be mod as they would be suited, and so it's not just me mod.
Yeah they're obviously different games and should be treated as such. This LB was always for the NES PAL one, and idk why but suddenly there's plenty of other versions available and a mod added a completely irrelevant run to the LB... I can imagine he's behind this so anyway I removed the run, all the extra versions, and I'm gonna try to settle the situation before another trainwreck happens.
Right now I'm inactive but I'll most likely do a few small things with speedrunning next year. I'm considering playing Asterix again at some point in fact (for like a week or two, don't have the time for long grinds like what i did with smb3).
Grats on your runs!
I forgot to mention something important in relation to framecounting: checking that the recording didn't have any frame dropped. OBS tells you if frames were dropped, but on top of that it's not too difficult to check after the fact if you didn't look or just don't know.
What you can do after you calculate the final time based on the number of frames (if you're not sure if frames were dropped i mean) is compare what you found with what the timer would be if you started and stopped perfectly the splits. For example if you see on your recording that you started your timer 3 frames late, and you stopped it 3 frames early, it means that the final time on your splits should be lower than what you calculated by 6 frames or 0.100s. Of course there's sometimes small rounding inaccuracies with the timer (which is why we framecount to begin with) so as long as it's within like a 1 or 2 frames margin it should be fine. If there's a big discrepancy though you know your recording is missing some frames.
I actually checked for your two 5:54s and both of them matched perfectly in that regard so no frame was dropped.
Alright so a bit late but here we go, here's a short album, followed by my explanations. The explanations might seem confusing at first but I'll summarize the idea & the method at the end. All the values I'm gonna give are for 60 fps but i'll talk about what should we do with 30 fps recordings after (in the future please use 60 if possible).
After pausing the emulator (screenshot i called frame -1), i buffered the A press, and frame advanced. So on frame 0 (i call it 0 because i like how the number of frames after that visualizes directly the duration but you can call it frame 1 if you prefer, it just has different implications) the input is registered, that frame 0 is the start of the run (and the one we should use when framecounting runs imo, there's no sense in measuring the time from a later cue because we should really time from the very first input on the title screen).
Consistently (I checked if it was always the same) the screen will be black after a duration of 3 frames (frame 3 in the screenshots). That frame is easy to find with vdub to time it precisely so we should use it.
A common confusion is which frames to include in the calculations, if we have to add one extra after doing a substraction etc. The short answer is that you use the frame of the final cue and the frame of when the first input is registered in your calculation and you do nothing else. Imagine the last frame as a barrier, as soon as you see it the run is done and anything beyond the barrier is not part of the run (so the point is you don't want to include the duration of that frame itself). In the screenshots I posted, the duration would be 4 frames and not 3 if we included the duration of the black frame itself, but it becomes black after a duration of 3 and not 4. Anyway that's a really convoluted way to explain (and I don't even know if it was needed) but basically just substract the two values you found in vdub.
As a reminder, we said that the last frame was "Bravo! Tu as retrouvé Obelix" or w/e it is in other languages.
--------> LET'S TAKE AN EXAMPLE
You just got a run and are retiming it in vdub (the video is recorded at 60 fps flat). The black screen after the start input happens on frame 56447 in vdub. The Bravo! screen happens on frame 78012.
56447 - 3 = 56444 , that's your "frame 0" or when your input to start the run was registered 78012 - 56444 = 21568 , that's your run duration in frames (at 60 fps flat) 21568 / 60 = 359.4666666... , run time in seconds (divided by 60 as it's the speed of the recording, obviously you divide by 30 if your video is at 30 fps)
Which gives us an official time of 5:59.466 (and not 467 as we round down times in speedrunning typically).
--------> WHAT ABOUT 30 FPS VIDEOS
Alright so that's a small pain (please do 60 if possible), particularly because the black screen cue is after 3 frames, which can't be divided by 2 to have a full number of frames.
Basically, from the black screen, you'll have to substract 2 frames to find your first one (you'll overshoot the start by an invisible half frame though (when i say half frame i mean at 30 fps)). If you substract only 1 frame you're gonna have a final time faster than it actually was. In theory we could substract 1.5 frame but we'll have a run duration in frames that won't be a round number, which is really silly. Timing should be based on the concrete footage available I think.
--> Quick example at 30 fps: Black frame at 21028 Bravo! at 31858
21028 - 2 = 21026 , frame 0 31858 - 21026 = 10832 , run duration (30 fps) 10832 / 30 = 361.0666666666...
Official run time: 6:01.066
In theory we could also at this point substract from that total 1 frame at 60 fps of duration knowing that we overshot the start by that (or for example do it before the division: (10832 x 2 - 1)/60 -> 6:01.050, which matches the difference of 0.01666.. or 1/60) . Although I'm personally usually more inclined to really stick to the number of frames of the video (and encourage people to use adequate fps), I'm not particularly against the idea either and it's definitely not unreasonable so I'll see what you think of it.
So yeah, quite a long and convoluted post but gimme your feedback about all that, what do you think?
Yeah I can definitely also have a look (and I'd like to) but if that's alright with you, can it wait this week-end? I'm quite busy until then but I promise to do it this week-end without fail (might even be able to on friday).
I'm 100% against approximate milliseconds personally. It's either accurate or we don't put them.
That being said it's not too late to framecount them as long as we define the start and the end properly and find out a consistent way. I assume you both still have local recordings so once a method is established, the framecount can be done in a breeze (if needed I'll do it myself if you don't have virtualdub and all but it's not hard to get). When the video is on Youtube, you can pretty much reach a close answer too by using the frame advance tool that Youtube has combined with the timer but that should be mostly used as a confirmation or a last resort and not the main method. Even if you don't have a local recording, downloading the video from twitch and using it as such should do the trick (btw i hope you recorded at 60 fps because that's the most accurate, but if you recorded at 30 it's not the end of the world).
Also we don't need to add milliseconds to every run, we can do it under a certain treshold like in LBs such as SMB1 (or 3 in two categories). For example right now, only the top 2 or top 3 would need milliseconds really, and then every new run that beats a run that already has milliseconds (or is within the same second) needs milliseconds itself as a rule, something like that?
For the end frame, simply using the first frame of the text saying you rescued Obelix or whatnot would be perfect imo as you said. Easy to locate and matches what we were aiming for when stopping the time basically.
The start frame is slightly trickier to locate usually, would need to be tested quickly in an emulator (by frame advancing and all from the start input) to see if the duration between start & gameplay is consistent (that's not necessarily the case). And see if we can find a clear visual cue that would help us locate the start input (the start input has no cue itself if i'm not mistaken but maybe the title screen disappears consistently like always the same number of frames after you press start). So for example if the title screen always disappears 5 frames after (number thrown randomly), we can first locate that disappearing frame, and then go back 5 frames to locate the start.
It sounds like a hassle at first but believe me, once a method is established and agreed upon, it's then done incredibly quickly when needed and is much more reliable & convenient than any alternative.
I noticed that due to the double 5:55, a mod went and added milliseconds to all the runs in the LB.
The problem is that all of them were incorrect because they were just based on what livesplit was saying (sometimes when the text screen was shown (i noticed that in the case of Baruch at least), sometimes just when the timer was stopped like for me or the newer 5:55. In the first case, it didn't take into account the gap at the start, and in the case of the 2 other runs I mentioned, it didn't take into account the gap both at the start and at the end.
In short, do not add milliseconds unless the run was framecounted (we need to figure out a clear start & end point for that in fact) or unless there's an autosplitter out there that we could use (that would be great but there isn't one right now).
It's true that the new 5:55 is slightly faster and the LB should reflect that, but adding wrong/quite off milliseconds is not the answer.
It's really hard to reply to you without a video/context or whatnot.
It's not emu and i don't know how emu handles resets but for example on console after some failed attempts I had to hard reset the console because a soft reset wouldn't dump values well enough and the WW could become impossible (happened to me before i realized).
Might have similar issues on emu, or other things in the stage having an impact, or something else entirely. If you have a video of the entire thing, please post it (here or on Discord) so we can try to help. Otherwise next time try to record your practice in case you have such concerns.
