[quote=Alayan]2FA is a big inconvenience and I'd really prefer to avoid it[/quote]

Can you elaborate on why it is a big inconvenience? Entering a 6 digit code every 30 days, or when logging in on a new device isn't exactly a big ask for a security measure that will almost completely eliminate this issue from occurring again.

Over here: https://www.speedrun.com/s3c

To be honest, the category you're after already basically exists, without any ambiguities of what the rules will entail: https://www.speedrun.com/s3k/Death_Egg_2 Time to get level select isn't included, but I don't think there's much interest in that side of things anyway, the rest is just down to how fast you complete Death Egg 2 (where in that category the actual level is required).

This feels very arbitrary, and 10:35 sounds very long if I'm understanding the point of the run. Start a run, enable level select, get to MH1, enable debug, reset enter doomsday 2 with debug, defeat bosses.

is about 2:50 using normal S3K timing (start from the save select screen to fade out) and has plenty of mistakes to it, that could make it shorter. Using Sonic from the get-go would add about 20s due to the AI cutscene, but under 3 minutes would be easy.

And the run doesn't really show anything of interest, to be honest. Getting to the vine and pulley has very little in the way of speed tech, and the boss is just cheesed because debug mode gives you access to instant hyper sonic, except for the last phase for some reason. And having to avoid pressing buttons that affect things due to Debug mode.

@desa3579 Technically I have for multiple games and emulators: https://github.com/SonicSpeedrunning/SEGAMasterSplitter This uses the "load removal" part of the autosplitter to remove Time Bonuses from a few Sonic games (mostly S3K and it's variations, and S1 SMS). It might not be a good example to work off though due to its nature of supporting both multiple emulators and games at the same time, so is very complex (but for me makes adding either a game or adding/updating an emulator easy).

[quote=PresJPolk] "For your own safety" -> "We'd rather lock out legitimate users because we've given up." [/quote]

What legitimate users would be locked out? with TOTP (Google Authenticator, etc), if someone is on mobile then they have apps available on mobile for TOTP, if they're on a desktop they can use their mobile device, or there are desktop applications like WinAuth for Windows, or browser extensions that can be used to provider the TOTP codes. This is less secure for an individual if their actual computer gets compromised, but that isn't the case here. So would go a long way to prevent the same thing from happening in future.

Yes better backups and partitioning of data would help with the recovery and localise only those boards affected, but as the old adage goes, prevention is better than the cure.

As it's an endless runner without a defined completion it's unlikely to be added. Generally, games in the Sonic series will only be added if there is enough interest and runs of the game to warrant a board.

All runs required video evidence I'm afraid, and won't be accepted to the leaderboard without.

My thoughts on IGT vs RTA-TB are very simple.

If you want a fair comparison across all versions of the game then IGT is fair play.

However, speedrunning is about going fast, and completing the game skillfully in the fastest (legitimate) way possible. Many other games use one platform over another due to lag or load times. Some run on different languages because it saves time over the course of the run. I think we can agree on for these games that straight RTA rewards going slower on certain levels, which we don't want. So RTA-TB is the best representation of skillfully going fast.

Given that with the testing that was done the Steam release in the majority of games tested was the fastest, and that the Steam release is legitimate and widely available. It comes down to choice - want to run on the fastest? Run the steam release, want to play on Genesis/Gamecube/Retroarch? accept that it's not the fastest version to get the very best time.

The research is here: https://docs.google.com/document/d/1NFh3eRnRK1lT_X142esNWcS43mtYPAZ6QqIjYLGMwhc/edit

If anyone wants any clarification on any points or has any suggestions for further tests that will provide more info in Sonic games, then let me know. We already did a test between everdrive and real cart, and the difference was within the margin of error (1 frame over about 6 minutes).

If it's all done in game without cheats etc then it would be good for the glitch run as it would skip 5 levels, and could be routed in depending on what's necessary etc.

Theoretically it's possible, if the game thinks it's on level 6 at the end of level 1, the next level that the game would load would be level 7 (the one with the 2nd janken match). On the same path though, if it thinks it's on level 16 at the end of level 1 then you get taken to the last level of the game, and from a selection of higher levels you seem to get a crash or so.

I'm sceptical though, so will wait to see what you can dig up. :)

S1 Demo playlist on many platforms: https://www.youtube.com/playlist?list=PLZxm5GLYbrJfntOEN-FP2NX7O1CE5Zrh8

It gets really complicated, however from casual viewing:

• Model 2 appears to be the same as Model 1
• Fusion is quite a bit faster than console.
• Retroarch is somewhere in between the two.
• Higan is fastest and Exodus are somewhere between Fusion and Retroarch
• Bizhawk is slightly faster than Retroarch (which is odd a they both use the same core).
• BlastEm! appears to be on par with the Genesis, even with the console gaining a slight advantage over it as well.

I've started creating a spreadsheet of the timings from the S1 demos, which has the key bits filled in currently (Console, Fusion and Retroarch).

Based on these readings - but need to do demos from S2 & S3K as well to get a proper gauge, I would suggest multiplying the time in Fusion by 1.00441, and in RetroArch by 1.0027

I don't know if the special stage in S1 uses a different video mode, but all emulators appear to be quicker than console (except for BlastEm!). If we take the Special Stage demo out of the equation and those multiplications into account, we get very similar times to console. Again ,need the other data to make sure. We also need to take note that the refresh the console uses does not translate 100% into 60 fps video - hence why there are two different times for SY.

https://docs.google.com/spreadsheets/d/1vuKFn9RqW8Hi8Bn71Q-c2Q-cNyfgmyregZVGNk74pKg/edit?usp=sharing

The calculation isn't meant to be perfect but hopefully bring the times more in line with console. :)

@VariousVarieties you could always use the autosplitter for Sonic 2 (just press the Activate Button in the Livesplit splits editor,and you should be good to go).

I believe https://forum.speeddemosarchive.com/post/a_new_keyboardmouse_visualizer_create_your_own_layouts.html is what a number of people use to display keyboard inputs on OBS.

So I was poking around at Fusion and Regen, and found out that Regen has Input Replay functionality, along with slowdown and frame advance etc, so it can be used for TASing runs. e.g. I did a recording of a (poor) Angel Island, and then played it back from the recording, with the input display (just for "look no hands!" dramatic effect).

So seems like it shouldn't be allowed? and possibly retroactively void runs using it as they probably can't be trusted?

How about wording it. "Run must start from Angel Island, but not from a slot that has cleared the game". You can't go back to AI from an uncleared file anyway, so an incomplete file from HC onwards is invalid anyway.

I would imagine the only difference we find in future, is the same as the CN2 ceiling, where a potential trick is discovered that only works from an empty file, but given that CN2 seems to be fine from an AI incomplete file, I think it's unlikely we will find other differences that are major to the run.

Hi @timpz,

Using http://emulation.gametechwiki.com/index.php/Sega_Genesis_emulators as a reference.

The TAS capable ones in that list are BizHawk, Gens, and MAME. Then reducing the Active List you have: Megado (no builds of this as far as I'm aware, so not worth worrying about currently). Genesis Plus GX, which has Retroarch, BizHawk and OpenEmu as front ends. OpenEmu is mac only so not sure if it has TASing abilities. PicoDrive - prefers performance over accuracy, again is a core for Retroarch, should be discouraged, don't think it provides any RTA benefit, so possibly doesn't need to be outright banned. BlastEm, Exodus and higan - all 3 strive for accuracy, nothing wrong with using them, no TAS abillities (Exodus has a RAM viewer/editor). None have a frame counter either.

Essentially, for no-TAS, show frame counter, we are left with Retroarch only, but you can decide what to do with framecounter-less ones.

@timpz,

Compiling an emulator can be quite a hefty task, so sometimes just removing some text isn't always that simple - of course doable though.

The frame counter is fine with me, it seems like it's pretty common in other communities and it's set-and-forget in most emulators. Seems some (like the one leandrom90 linked to) allow for showing it before and after the run as well. It also seems like my previous ideas about TAS emulators also showing that it's recording is also used elsewhere too. (The frame counter in TAS emulators show a different frame display when playing back as it's normally currentframe/totalframes rather than just the count, and also if the TAS emulator was shown to be recording, it's harder to fake then.

I also agree with leandrom90, no-one should be implicitly "trusted" for runs. This has been shown multiple times in other communities where even mods have posted WR cheated runs, that have been caught out at a later date. Forgetting to turn on the frame counter (as an example) from a long time runner would be a pretty weak excuse, as they would be well aware of the rule in place anyway.

Also agree that some rules can do more harm than good, with the issues I had with Retroarch not always working, and reluctance to use Fusion or Regen, it would have ruled me out from running the game.

Cakes - the input viewer is just a browser window that uses the HTML5 "Gamepad" specification, so just changes the style of the buttons when pressed etc. It would mean needing quite a toaster of a PC for it to degrade the performance enough to have an effect on someone already using the emu and OBS. :D

Some comments from me:

-- Emulators -- Accurate enough emulation to not gain a real-time advantage over console. ?

No input-replay functionality (TAS) ? - I feel like other rules make this moot (other games allow these emulators as well - such as the DKC series). But I don't really feel strongly enough about it to argue against it either. what about if say retroarch gets Input Playback though? I would prefer it if we were able to cater for emulator agnosticy with basic requirements.

RAM watch and edit not available ? - Whilst the intention is good here, from working on the autosplitter, it is a moot point as there are tools out there to view and edit the ram in game etc (possibly with a lot more documentation and tutorials than the ones built in to emulators). Whilst there are cases where RAM editing would potentially be useful to cheat, I think for the most part they would be obvious. And the non-obvious ones would be hard to detect, but again, excluding emus for it is rather moot.

Hard coded settings that make it harder to do video splices (e.g. no setting to turn off notifications on creating savestates) ? - This can be turned off in retroarch. However, I think frame counter display solves this for the most part.

Not open source (?) ? - RIP Retroarch then. This also narrows the emulator list significantly to a select few - certainly none I would consider using for runs currently. Not sure if any of the non-open source ones support frame counter display.

Complete list should cover Windows, Mac and Linux OS. ?

-- Input viewers -- Fine by me. Doesn't support keyboards though, which may/may not be a bad thing.

-- Livesplit -- This is fine by me, however, I think it's mostly a Windows only program, and the autosplitter may not work on Mac or Linux. So maybe some flexibility required here.

-- Framecounter -- I think the way me and zaxon have it set up is fine and unobtrusive in retroarch... sits in the bottom left corner with some transparancy, with a small but readable font, and sits nicely under the lives counter. is the settings I use (and zaxon has very similar ones).

-- Hard reset -- I think ditch it, it could potentially open the door for 3rd party input replay as the hard reset is generally a static point. If it's to be used for the "console on" timer objects, then it needs to apply to console too. Technically I would say a soft reset shouldn't be necessary for a requirement either, but if it is, should also apply to console too.

-- Save files -- I think this is fine, its only really AI->CN that are potentially affected as we re-use the save file after that. My autosplitter rewrite also caters for Angel Island resets to handle this case. I need to built some trust in starting from an AI save though, as things like the Ceiling in CN2 were certainly an issue. :D Don't think it really makes a difference to a run being valid or not though.

So the conversation picked up on discord a couple of days ago and then earlier in Zaxon's stream.

Some key points that have been raised:

• Genesis Plus GX allows Retroarch, however, by the same rule this also allows BizHawk (which also has a hard reset feature).
• Restarting/Resetting in Retroarch is a soft reset, rather than a hard reset.
• A hard reset in Retroarch requires reloading the rom, however, this is how it looks which looks open to splicing.
• It was suggested that using a display capture and cropping, however, I believe having complex capturing requirements was why the rule was relaxed in https://www.speedrun.com/s3k/thread/18plf
• A 3rd party input display could potentially be written to read an input file along with an emulator and could potentially "sync" them up so it looks legit.
• A number of reasons for a hard reset exist for real hardware too (clearing level select etc), however, for real hardware this comes with wear and tear.
• Hard resetting for emulator is mostly to prevent input playback. However, this strategy doesn't prevent splicing of a hard reset video and a video of a run using an emulator.
• Hardcore mode for retroarch was suggested, however, there comes an issue with when this should be displayed... before every run would be silly, but possibly at the end would be better - but again... splicing.
• Any rule created in attempt to prevent cheating has the potential to be worked around with enough determination.
• haty12345's latest knux run has also shown that a run can follow all the rules and still be further scrutinized to establish how legitimate a run is.

We could ban emulator outright, this is unlikely to happen, it would reduce the runner base, also BlastEm! and (to some extent) Exodus could pass off as being run on legit hardware when not. So is pointless trying to take a sledgehammer approach.

I think the rule set needs to still make things fairly simple for the legit emulator players, and making it easier on the mods for verifying, and help cater with past and future runs.

The Hard Reset rule is nowadays pretty weak to prevent cheating, video editing could be done to either add it in, or just splice it together with a tas'd run. If it's game related (e.g. for Level Select reset, or potential memory manipulation before the run etc), then it should be required for console as well (which it won't be). Also a hard reset for retroarch imo creates an easier avenue for a splicing point.

In addition to what I mentioned originally, I think we can have some more generic rules to cover a lot of scenarios present and future.

• Reset rules (whatever decided) should apply to both console and emulator
• Any emulator can be chosen.
• Declare the emulator in the submission, and have something during the run that visibly shows it is that emulator (Retroarch XMB or the yellow reset text), or window decoration is fine as well.
• 3rd party input display is recommended (e.g. gamepadviewer.com ).
• Using the autosplitter is recommended
• Special Rules for Emulators with input recording/playback (TAS-like emulators). --Either --- Input Playback & Recording is visibly shown to be disabled (this makes it flexible for Retroarch getting this in future, and Hardcore mode is used). However, flexibility needs to account for when to show it (start of every run would be a pain, so maybe at the end) --OR --- The following items need to be shown/used: ---- That the emulator is visibly recording the input (Gens has the red dot in the bottom right, and bizhawk has one in the status bar), and the input file is provided with the submission. ---- The frame counter. ---- The in-emu input display (in addition to requiring the 3rd party input display). ---- The autosplitter needs to be used (and it needs to support the emulator in question)

The combination of these things are "set and forget", with the exception of setting up the recording of inputs. If the emulator is recording inputs then logically it cannot be playing them back. The frame counter makes splicing very hard, and the input displays will need to match up with the 3rd party one.

The point about the autosplitter is it is very hard to manually replicate the functionality, i.e.where it pauses the timer and where it splits. Obviously it can split for a complete TAS runs, but would mean to create a cheated video with all the above would be some serious hard work to achieve.

These suggestions also cater for all submitted runs so far, as I don't think any emulated run either doesn't have something distinct about it, or the window is captured.

Other things that can be recommended to make run verification easier: hand/crotch cam, and streaming the runs. Neither of these should be a hard requirement, but obviously the more things runners do to legitimize their runs makes them easier to verify (or easier to spot inconsistencies).

I would say using the built in emulator input display should be discouraged, as ones like Gens and Bizhawk show the inputs from a playback file.. so harder to verify as legitimate.

RetroArch's is mostly an overlay for phones etc, and could be used, however, using something like the gamepadviewer.com site is separate from the emulator, so is a lot harder to fake with recorded inputs. I believe there are probably others out there, e.g. I think flying_fox uses a different one for her youtube videos, as I've yet to find a genesis skin for gamepadviewer (not that I looked for very long).

^ Thanks Lake :D