Hashbrown1806: yeah, but with the difference that you cheated into the rollercoaster being underage/too short. Meaning you broke the rules, and you might be banned from visiting that amusement park.

Trying to enter while underage and getting rejected in the door is something totally different from going in while underage

The rule are clear that its permitted: "A few non-Caffeine mods are also allowed For 1.14+: SpeedRunIGT, noPeaceful, and extra-options."

So yes you can use it for version 1.14+

What I have understand, timing mods however doesn't inflict the timing of the game, ergo moderators will still go by the "official" timer even if you use a timer mod. Timer mod is just for your own pleasure.

I think he should not be unbanned regardless of if he can show ID or not. He broke the rules by entering underage, then he have broke the rule. That the rule do no longer apply to him anymore because he is in age doesn't change anything.

Its the same if you submit a run with a prohibited mod, get banned, and then the prohibited mod is moved to allowed list. That doesn't change the fact that you broke a rule, even if doing the same thing TODAY is permitted, which wouldnt score a unban.

Or to take another example: If you smoke cannabis today, and then tomorrow cannabis become permitted to use, doesn't mean any fines or punishments is dropped, because you still broke a law during the time the law was in effect.

By the way, running a pre-recorded set of inputs that will result in the same game play, is literally a TAS.

Thats why I said it needed to be accompanied by a stream or video where the input device is visible in frame. The idea of the pre-recorded set of inputs were just to be able to verify it on the verifier end.

It was this youtube video, that made me suggest this idea, to close that loophole.

And this video: Because this time it was detected, just only because Dream did up the drop values by such an amount it was just plain obvious that he couldn't be that lucky.

Imagine if Dream would just tamper with the RNG a little bit. Just enough to beat leadership, but not too much to raise suspicion or being caught in careful analysis. Then he would get away with it.

Thats why im trying to come up with a solution. Im thinking of other solutions, like recording RNG values (that then can be replayed by a verifier or moderator during a verification run) or something similiar. But then the cheater could just modify the RNG generator to create the "desired values" instead of editing drop rates.

Kind of difficult problem/nut to crack. Thats why I started this discussion to come up with good ideas and collaborate with the speedrunning community to find a "antidote" to this cheating method.

If you read this page about Doom: https://dsdarchive.com/rules you propably understand how im trying to apply the same "verification" method to any game where cheating is achievable by tampering with luck or RNGs.

Its mainly this I am out after: "The authenticity of a run, in terms of compatibility with the original game, can be easily determined. If a user made edits to the game logic, their demo file would desync when another player tries to play it back." "demo file" = input sheet.

I agree on the fact that influencing/modding the game would be counterproductive in that case. Thats why the mod itself must be made such, so from the player's point of view, the game is effectively unmodified. Bascially, the drop rates and luck in game doesn't change.

And of course, I suggest it being a official "speedrun mod" so it would get accepted by the speedrunning community.

Its kind of hard, but you propably understand how im thinking... In the same way FPS counters and timers and other verification helpers/mods are added to the game to ensure the run hasn't been cheated - which technically - are mods - but are used to aid in verifying the run is legit, in the same way I propose some verfication for RNGs aswell, as RNGs are almost impossible to verify they are unmodified unless you have a large sample data or access to the RNG itself.

In Doom/Doom2 for example, the RNG is based entirely on input, same with Super Mario 64. This makes it very easy for anyone to verify these runs using a input sheet, as provided the exact same inputs, will result in the exact same gameplay. And thats what makes such games so nice in speedrunning, because nobody needs to suspect modified game as the run can be easily be re-run on a known unmodified copy of the game. (There other cheating methods however, but just the problem with modifyed game is eliminated).

Do the community have any other ideas on how this method of cheating could be eliminated?

Walgrey: I agree about its not currently flawed, but the reason Dream got caught was because he overdid it. Imagine he didn't overdo it, but just upped it enough to be able to beat the leadership, but not enough to raise suspicion.

Thats why I propose a method where it will be 100% clear cut if the run was cheated or not. With my proposed method, it would be enough to just up it with 1 point, and it would be caught IF the RNG would land on that modified point.

And its not a "mod to do all that" - but rather a mod, either a general purpose that works with any game, or a mod that works with specific games - that just modifies the seeding to the RNG so its dependant on game input instead of game state or system state. Thus forcing the RNG to depend on inputs, and thus allowing a run to be perfectly replicated by anyone that wants to verify the run is legit.

The reason I asked, is because UserSettings.json takes precendente over InputUserMappings.xml, meaning if a keybind is specified in both, the UserSettings.json is whatever the game uses.

UserSettings.json is also whats written when you set keybinds inside the options menu (game interface).

HOWEVER - there is some unpermitted binds, that the game refuses to allow (which will respond "Keybind failed" if you are trying to bind them). One example is arrow-up to walk forwards. To be able to use a unpermitted bind, BOTH files must be editied manually, else the game will just overwrite them with the default bind.

Another way, is to delete the file completely, and let the game rewrite the file. Some of keybindings then is inherited from InputUserMappings.xml but not all.

Thats why I suggest that UserSettings.json should be permitted to edit. Since the file is automatically edited when using the game interface to edit settings anyways.

There is no sensitive settings inside UserSettings.json that could cause a unfair advantage what I know, but if that is concern, any editing could be restricted to "Keybinds only, defined as any value that starts on IK_"

ckellyedits: Note the last sentence in my original post: "NOTE: This idea post applies to ANY moddable game (or even unmoddable ones if the system-RNG approach is used), where RNG is a great factor in speedrunning - not just Minecraft that caused this concern/idea/feedback."

Thus, this is not something that is isolated to just Minecraft where this type of cheating happened (by Dream), but in any game where the time of speedrun relies heavily on RNG, where there is risk of tampering with the RNG to get better times.

Its just easier to talk in regards with Minecraft, since there is a specific cheating case there (call it Dream case) that can be used as an example on how this idea/system can be used to prevent or detect that type of cheating. The problem itself, applies to any game that uses a RNG where the result of the RNG affects the gameplay such so tampering with the RNG can give you better times.

Timmiluvs: I just outlined that in my post, how that is verified.

The moderator, takes the input sheet (which is then a file containing all the inputs, given in specific time) and "runs" the input sheet (basically runs a "TAS" kind of), on THEIR computer, with the same modification running.

If the run completes - then the run was played on a unmodified version of the game with the "SDC mod" applied. If the game was modified in a way that would affect the run in question - then the input sheet wouldn't complete on the unmodified game with the "SDC mod" applied, basically it would be desynced. For example, if Dream would modify their game to increase the drop rate of ender pearl. IF SDC mod were not used The run would ofcourse not complete either on moderator's verification run, since the game would be using their RNG and not the SDC-modded one, and thus the run would desync when anything random happens in-game.

Then in the moderators "verification run", then the game would obviously drop whatever is supposed to drop if the game weren't modified (lets say a flask of healing potion) and then the whole run would desync when the runner is "trying to combine a flask of healing potion with blaze powder" which wouldn't work.

Same would applied if the SDC mod in itself would be modified. Because the moderators would ofcourse run the input sheet with the unmodified original SDC mod. Then even a small nudge in the drop rate, would still invalidate the run because the run wouldn't complete on the moderator's computer. The rest of the verification is just to verify that the input sheet matches the stream in question - so the runner hasn't spliced or TASed the run.

No amount of coding ever, would be able to fool the moderator's verification run, that is done on their hardware, their software and the original SDC mod.

So the idea is that the modification in question, should make it possible to "re-run" a game play, on the moderator's side.

This problem doesn't exist when it comes to other modifications than RNG, because then its clearly visible in the stream or run, that something doesn't play out as expected - for example, gun recoil might be smaller than expected without reason for it to be so (like a addon item that player purchased in-game that reduces recoil).

With RNG however, its practically impossible to prove that it has been modified, unless when it has been modified in such large amounts that it becomes obvious.

Thats why I endorse a method, where the RNG is made predictable based on input events, thus a run can be "re-played" on the moderator's side, as a verification method.

Note also, it doesn't just apply to moderators. ANYONE with access to the stream and the input sheet file, could verify the run, by running the game + the SDC mod, and then applying the input sheet file. So even if someone doubts the moderators decision to accept the run, they could verify it themselves and be outproven by technology that the run was fair and legit.

The reason a mod is required, is to make it possible to "re-run" a full gameplay - inclusive any random events, as-is the runner played it. Just recording the inputs to a input sheet isn't enough, since when moderators replay the input sheet, the original unmodified RNG would ofcoruse fire differently, desyncing the run.

Thats why the RNG must be modified in such a way it does NOT give any advantage to the player or runner - from his perspective it would be to run the original unmodified game - but in such a way that a run can be "replayed" anywhere to prove its fair and legitimate.

The file common\Cyberpunk 2077\r6\config\InputUserMappings.xml is permitted to modify according to the rules, but the file AppData\Local\CD Projekt Red\Cyberpunk 2077\UserSettings.json isn't specified.

However, the file AppData\Local\CD Projekt Red\Cyberpunk 2077\UserSettings.json isn't in any of the game directories, and could be considered be a user file and not game file.

So, is AppData\Local\CD Projekt Red\Cyberpunk 2077\UserSettings.json permitted to modify or not?

The usage is similiar to InputUserMappings.xml so it could be suitable to include it as permittable to modify, in the rules.

I have a suggestion, to make it more detectable, and clear, when someone cheats a game, by altering the RNG to increase the luck.

Best to "solve" such problems in the future, would be to have some "speedrunning mod" or similiar (that SDC could officially create) that players must insert in their game, that alters the RNG seed to depend on movement, game time, the world seed or other form of input, but still give the same percentual drop rates. In this way, you can require that the speedrunner submits his input sheet, and then the exact gameplay can be replicated on the moderator's side. Comparing this with a live stream where the keyboard or controller is visible in the frame, would with 100% conslusion either tell if they are cheater or not, without having to analyze RNG drop rates.

This mod could either be a EXE that either modifies system RNG to act predictable based on inputs, which then would need to be "initialized" (maybe by pressing a key sequence that is specified in rules after game is started - making this key sequence visible in input sheet - and thus the speedrun would play successfully even on the moderator's computer regardless of how other things look). The advantage of this, is that the mod-EXE would work for any game that uses system RNG to calculate drop rates, but the disadvantage is that some games uses their own RNG that is not system dependent, and thus would require separate code in the EXE in question. OR it could be a game-specific mod, that is unique to each game that must be created by the moderators, but that gives more workload.

Because, then, an unmodified game, with the speedrunning mod, with the same world seed, should, given the speedrunners input sheet, give a completion of the game in the time claimed. If not (ergo, the speedrun becomes "desynced" just because the RNG drop rates does not match), then the original game has been modified. And in the same way, if the input sheet doesn't match the claimed stream (with the keyboard or controller visible), then the input sheet has been TAS'ed to give unfair advantage.

There is a kind of problem with analyzing RNG rates, and that is that its possible to say its impossible to win on the lottery = you cheated when you won on Jackpot with that 8 digit number matching your ticket. and thus forfeiting your monetary win. So its kind of difficult to prove that a random number generator was tampered with, unless you get to analyze the exact RNG - thats why official lotteries have their RNGs analyzed and then sealed with a tamper evident sticker. So nobody can claim the generator was cheated if the number of lottery tickets that won, is lower than the "expectation".

In the case with Dream's rum, its more clear-cut, but imagine if Dream would just up' their drop rates with a little bit, causing the rates to not be "impossible" or "unobtainable".

Thats why I suggest that a "speedrunning mod" should be used to submit speedrunning samples, which is then a official SDC mod that MUST be used when submitting speedruns.

This could then apply to all games were a RNG affects the run in such way that it would affect speedrunning.

Note that the mod itself doesn't need to be in any way "verified running" or "verified unmodified" - because when the speedrunner submits the input sheet and stream - the moderators just set up a identical setup on their side, meaning the run can be verified. If anything is modified or cheated with - the run will not complete successfully on the moderator's side.

And in this way, the actual run, can be replicated with 100% accuracy on anyone verifying the speedrun, giving more credibility even if something unlucky happens.

NOTE: This idea post applies to ANY moddable game (or even unmoddable ones if the system-RNG approach is used), where RNG is a great factor in speedrunning - not just Minecraft that caused this concern/idea/feedback.