Created save files can now be used as long as they are identical to blank ones at the start.

This means a file that is not completed, is in Angel Island, has no Emeralds, has 3 lives and no continues.

S2 RTA minus everything except the IGT flooring

You can read the description for general comments but to summarise:

• Both the timer and animals have an influence, but both are relatively marginal.
• Animals have a lower influence than the IGT. I would estimate about half.
• Pauses have a huge impact depending on how much it's done.

With these results I would normally say switching to RTA is not worth it with the issues for emu that we've found. But considering it needs to be solved for S3K regardless, I would say RTA is worth it for tracking the pauses which are significant.

Pancakes recently recorded a video of Console and Fusion running the demo of Sonic 1 side by side. This illustrates pretty well how much at least loading times on emu can affect a run:

While RTA vs IGT is a discussion worth having for Sonic 1 and 2 still, it's already a fact for S3K and the new list of emulators must account the fact that loading levels among other things could add up to several seconds of advantage over the course of a full game run.

@chronoon I hear everything you say, but I just want to avoid a potential future situation where we do find a difference that does make an impact and need to remove it again. Perhaps the gain is worth the hassle though, so this is why I want community input on the topic.

At this time I'm in your camp that there is no discernable difference except for the fringe cases like Tails in CN which isn't exactly helpful to a run but I do wonder if someone for example double checked if there is a load time difference between New save and existing save.

@Zaxon96 I would like your opinion on what emulators should be allowed/not allowed. I believe there should be a definitive list of allowed verified emulators but unfortunately I'm not up to speed on what would constitute a good one.

@Zaxon96 we used to have issues on TSC where people would submit runs that were impossible to ascertain if they were legit or not because they were done on TAS emulators with nothing else to back them up. The reasons for not banning them were something similar to yours, they were the easiest way to record and cheaters gonna cheat anyway.

I agree with your opinion that following the rules should be simple, unintrusive and hard to misunderstand. But there is a balance where too few rules (or bad ones) makes the leaderboards lose legitimacy. If people are going to cheat I want to make it as hard as possible to increase the chances they make a detectable mistake, otherwise there's no way for verifiers to live up to their name.

I've spent all day today of my free time to try to verify a run which would have been much simpler if only for a few changes, and I still can't tell if it's good or not. So yes I agree the rules need a change and some things can probably be relaxed, while other things should be added.

Now my question for you is what would be acceptable and what would not?

-- Emulators -- Ben and leandrom,

Just to be clear the reason I'm worried about open source emulators is that it could be easy to make small edits, such as prompting text or removing text that we make rules around.

Changing code might sound like too much effort but searching for the text "Savestate Successful" and replacing it with a space is simple enough that any aspiring cheater could do it easily in an open source project.

I cannot see why there's a good reason to open the pandoras box of allowing emulators with native TAS capabilities regardless of other safeguards that are in place. It's just a plain bad idea if we're making a list of allowed emulators.

Perhaps there could be a compromise in that if you use an open source emulator or front-end you need to enable frame counter?

Also when it comes to RAM watch and edit I mostly want to limit options where someone could for example set the score counter so splicing is easy, but as you say there are external tools for that already. Good point.

-- Lakes idea -- I don't like that. Maybe we could allow some flexibility if a trusted runner did something with no impact like forgetting to enable the frame counter in a run if that becomes a rule. But a points system seems, no pun intended, pointless.

Most rules would apply to Sonic 1 as well. Please discuss here: https://www.speedrun.com/s3k/thread/w89y7/1#3n613

Most rules would apply to Sonic 2 as well. Please discuss here: https://www.speedrun.com/s3k/thread/w89y7/1#3n613

There has been talk recently of the rules being outdated. This thread will be used to discuss potential changes that have been suggested.

When replying, try to separate your arguments and preface it with the category so it’s easier to follow.

-- Emulators -- The current list of allowed emulators is outdated. Many runners nowadays use varying front-ends with differing cores that blurs the definition of what is actually allowed, originally the list was made for standalone emulators.

General requirements:

• Accurate enough emulation to not gain a real-time advantage over console.
• No input-replay functionality (TAS)
• RAM watch and edit not available
• Hard coded settings that make it harder to do video splices (e.g. no setting to turn off notifications on creating savestates)
• Not open source (?)
• Complete list should cover Windows, Mac and Linux OS.

-- Input viewers -- Runs on emulators are usually easier to use for cheating, so it stands to reason they should have more requirements when submitting. At the same time the rules must require reasonable low effort and be unintrusive on the runner. Requiring the use of external input viewers for emulator-runs seems to fit this definition well. I would like to hear any concerns with requiring https://gamepadviewer.com/ for emulator runs.

-- Livesplit -- Livesplit has autosplit functionality for a number of emulators nowadays and in the future it might be possible to run it on any console using image recognition. Moving forward it might make sense to require the .lss file generated. This could be implemented in a number of ways such as always being required for emulator runs, or it could be just required on your first few submissions until you reach a trusted status in the community. Please let me know if you think this is an awesome or terrible rule and how you would like to see it implemented if so.

-- Framecounter -- Depending on the emulators allowed, it could make sense to require a framecounter visible in the game window. However it might be controversial because while it would add some extra tools for moderators to verify by it looks bad and could be distracting. Again give me feedback on this suggestion.

Note: this is not the FPS value, it is the number of frames since boot.

-- Hard reset -- While it does have use as a tool for verifying runs, many new runners are using retroarch which currently doesn’t support this meaning you need to exit and reenter the program altogether. There are also a couple emulator runs that are currently verified but doesn’t follow this rule which would mean they would have to be discarded. Finally this rule doesn’t apply to console runners and to require it has been said to increase the risk of hardware damage for serious runners.

With other suggested changes, this might be an unnecessary requirement moving forward.

-- Save files -- Starting a run from a created file that has not completed Angel Island should have little impact on the run, however it has been recently shown that softresetting a save file does have some effects in a few cases. If it can be shown that there’s no speedrun benefit to starting from a created file, this rule can be relaxed a little bit.

-- Grandfathering -- All verified runs currently submitted would be grandfathered into the leaderboards and will be judged on those terms in case suspicion is raised about them in the future.

I will allow a couple weeks for responses so everyone gets to give their input. Please consider that discussion on e.g. discord might be missed so if you do please reply here afterwards. If there is a topic that seems controversial I might create a vote for that item.

Thank you for helping out the community!

Making your own inputviewer doesn't require serious dev skills though. And I haven't thought about it before but you can probably make it read from the same input file as the emulator with little effort. Is there a way to verify that the input viewer used is the one from the site?

Just thinking out loud here but as a C# novice I can think of a number of ways to circumvent the issues you guys think are solved with an input viewer if tas emulators are allowed.

Ah if it's a website like that it could be fine.

The main problem with allowing any emulator is that someone could record footage of an emulator then just put that into the window of a another emulator and lie about what they are using. It's much easier when verifying to have a standard set of emulators with known pecularities to check for.

It's also the reason I initially had the rule about recording the entire window, because all videos I had to check before was without documented emulator so double checking what emulator something was played on to see if they lied about using a TAS-enabled one became unreasonably difficult.

I wrote the rules initially so I think I should give my input on this.

If you do runs on emulator I do think you should be able to put in the extra effort to make the life of the verifier easier. There is simply too much variation in emulators so I think there should be a single or couple standard emulators and settings to do runs.

But the emulator scene has evolved a lot as well and I'm not up to the speed on it so if people agree on adding or removing one to the list I'm all for it.

Regarding outside programs with input view etc I do think that would be a good idea, but it has to be free and supplied here on this site, and also be supported on pc, mac and linux. Or have alternative versions that are equivalent.

OMG you're a genius!

As the title says, can a sub/category for a game be ported into its own game such that all runs are preserved?

If not, can I submit it as a request for a new feature or is there something in the backend that prevents it from being possible?

Thanks

Yea sorry I fixed this for the other games but I guess I forgot about this one

Unfortunately this doesn't seem possible without adding a subcategory that the filter defaults to. If that changed then yes it could be added without issues.

EDIT: Nevemind I solved it haha

I added a new variable for you Sonic runners when submitting runs. You now have to specify whether you're using Tails or not!

This also applies to the All Emeralds category.

You can sort by "any" and get the full list like usual, or sort it for the one you're interested in by using the filter tab.

Feel free to discuss what you think of this new change here.

Regards, TimpZ

I have added "Sonic or Tails" as a new category on trial. If after a few months it appears to be inactive it will be deleted again.

The Sonic or Tails/run changes a couple stages from the normal run as well as potentially being more beginner friendly (not counting CP1 haha). When I have time I'll post a video with a route to help people out with getting familiar with it.

I highly recommend using Tails for this category, if nothing else because he's really cute!

Feel free to discuss what you think of this new change.

Regards, TimpZ

Here is the most up to date public disassembly of the code that I know of: https://raw.githubusercontent.com/sonicretro/skdisasm/master/sonic3k.asm

If you need to learn how to read the code itself I recommend this site: http://mrjester.hapisan.com/04_MC68/

As far as I know the steam and xboxlive etc releases are just emulators with the original code running, the original PC release from the 90s has the most changes I believe. Here's a list of glitches on Sonic Retro that is mostly written by me years ago but be aware it's far from complete: http://info.sonicretro.org/Sonic_the_Hedgehog_3_%26_Knuckles_bug_list (also note that some of the things listed might not strictly be glitches by the proper definition)