it would actually be super helpful if you could link the broken community posts in question I’d love to take a look to see if I could help reformat it with the current system (with your permission, of course) and/or take notes on the specific missing formatting features.

@Meta Sure here is one example, https://www.speedrun.com/yi/forums/q8mf0

Ok @Meta feedback #1, after reading your entire post you could have just responded to

"Are we just effectively limited to the buttons in the reply box?" with a 'yes', instead of that monstrosity

Feedback #2, I'm very unhappy with you (the site) removing formatting support for tags (and not providing a replacement) that my community has been using for 6+ years. We had the functionality for 5+ years, now it's gone. No reason provided.

Who are the admins of the site rn do we even know? I'm not being facetious

Do staff read these boards? Or someone point me to a formatting guide? I can wait. Not waiting forever tho

I don't mind formatting standards changing, but literally what are they now? I can't find anything current on the site or the forums. Are we just effectively limited to the buttons in the reply box? If so, this seems like a serious regression, there's no way we had better functionality 7 years ago.

What's going on with formatting? I carefully formatted posts for my community and most of it is broken now. Every formatting guide on the side is outdated, every major post I've made in the past has broken tags everywhere. We can't center text anymore? Are we using markdown? Point me to documentation or a resource please.

That's not acceptable, literally just check if the user is logged in. It's one line of code.

added SwitchVC, as far as I understand its the same emulator as WiiUVC

[quote]My run has been rejected on the grounds of a rule stemming from this discussion, yet made before any moderator was able to demonstrate that one would be a better player with the setting turned on. They have still been unable to prove so.[/quote]A possible advantage has already been demonstrated, and explained to you in detail, multiple times. I very clearly laid out the logic and you haven't engaged with any of it. The only thing you brought up was a critique of the methodology, which I subsequently addressed and showed it did not meaningfully impact the findings.

[quote]Even after one moderator has given their playtest results and siding towards my claim, the evidence him and I have presented has been disregarded, essentially being told my numbers are wrong and my hardware is faulty.[/quote]Nobody has said your numbers are 'wrong.' Your hardware setup could introduce additional lag, this is true. As I've said though, it's ultimately irrelevant.

[quote]All of this being orchestrated by a single top level moderator who refuses to acknowledge new information or even actively investigate speedrun related matters.[/quote]I have explained multiple times that 'new information' doesn't impact this decision. Go back and read the logic that was very clearly laid out for you.

[quote]Behaviour like this is unfair, unethical and detrimental to the integrity of discussions when they are forced to be one sided and even when other moderator input is ignored. Why is this tolerated? Where are the other users who have allegedly voted in favor of the ban, and who audits the audit?[/quote]Nothing unfair or unethical has happened and further accusations of these or similar things will get you nowhere. Also, you voluntarily left the discord where these things are discussed. Those in favor of the proposal: shado, crispy, thurler, me, gill, forte, icterus, suus. Those against: none.

[quote]God forbid you actually test it. One step at a time. You can feel the lag[/quote] Feelings are not sufficient to override empirical data. You don't seem to understand this.

Here is the simple version: It has been shown that runahead can result in an advantage over console. If an emulator or emulator feature can result in an advantage over console, it is not allowed. Therefore, runahead is not allowed.

If you can engage with any of the reasoning I've laid out that's perfectly fine. Any additional 'just open the emulator' or 'unfair and unethical behavior' posts are going to be deleted.

[quote]Any inputs pressed midway through a frames, so like 8 milliseconds, would be polled on the next available frame and shown the next after that. a "half frame" cannot exist. its just not a thing. It should be counted, in frames, from 0 and up[/quote]I disagree but I'll adjust the data as you suggested. After rounding up all the decimals for each trial and averaging: Retroarch: 31 4 frames, 8 5 frames. 164 / 39 = 4.2 frames Console: 3 3 frames, 31 4 frames, 5 5 frames. 158 / 39 = 4.05 frames

After truncating decimals for each trial and averaging: Retroarch: 18 3 frames, 21 4 frames. 138 / 39 = 3.54 frames Console: 3 2 frames, 31 3 frames, 5 4 frames. 119 / 39 = 3.05 frames

Applying runahead 1 would result in less input delay for retroarch regardless of if you round up, truncate, or preserve decimals.

[quote]What can be made of this?[/quote]It is possible something in your setup is introducing more input delay.

I probably would test this myself for curiosity sake, but I don't have a 120fps+ camera.

Alright so you haven't disagreed with the any of the reasoning I laid out.

While more data is always nice to have, additional tests are very unlikely to be relevant. The only way they may become relevant is if someone raises a meaningful methodological flaw or another issue with the input delay test that has been linked.

to evaluate any possible advantage, nope

As far as I know, people in the community have played the game using retroarch with and without runahead.

Because a real world test with YI has already been done, I've linked it twice.

nope

I have deductively in the past couple posts, I can lay it out more clearly:

1. Retroarch can have, on average, less than half of a frame more input delay than console (premise 1) source

2. Runahead = 1 would reduce input delay by 1 frame (premise 2)

3. Therefore, Retroarch with runahead = 1 can have, on average, more than half of a frame less input delay than console (conclusion)

4. Emulators or emulator features that can result in an advantage over console, during a speedrun, are not allowed (axiom)

5. Retroarch with runahead = 1 can have, on average, more than half of a frame less input delay than console (premise)

6. Therefore, Retroarch with runahead = 1 can result in an advantage over console, and is not allowed (conclusion)

It has been demonstrated that, on average, there can be less than half a frame difference of input delay between retroarch and console. Retroarch having less than half a frame more input delay than console. Runahead 1 should lower the input delay by about a frame, resulting in less input delay than console.

After lengthy discussion, we have decided that runahead is banned as it can convey an advantage over console, as seen here. Note that frame delay is set to '6' in this situation, so higher values could lower the average input delay difference between emu and console as shown previously.

The main rules posts has been updated to reflect the leaderboard discussions

(Snes9x - Current) is not allowed as it is version 1.60. Any builds later than 1.56.2 are not allowed, as the snes9x devs made Super FX 2 emulation changes that result in 1.57 and all releases past that having less lag frames than console. If the snes9x devs make any changes to the Super FX 2 emulation in future releases, we will recount lag/loading frames and update, if necessary, to allow a newer version. Until there is any update, runs using (Snes9x - Current) in retroarch will not be accepted. There is a link to a compiled snes9x 1.56.2 core in the OP that you can use for retroarch. Alternatively, you can compile a core from the source code of any accepted snes9x version and use that.