stats.wesnoth.org - cheaters, be gone!

[Feldegast]

Has anyone else noticed that many players, who upload to stats.wesnoth.org, do the "save and reload a turn" thing many times to finish scenarios? That completely fakes the statistics. You are cheating, if you reload a turn until you are happy with the inflicted/taken damage. I wish such uploads would be excluded.

[Max]

why? i doubt there would be much left if you omitted each scenario where someone "reloaded" a previous turn. it's pretty much part of the game for some people.

why not suggest to include this information and make it visible?

[Feldegast]

If stats.wesnoth.org shall be used to improve the scenario/campaign balancing, it is not helpful to collect data from cheaters who end a scenario with more gold and no lost units, because they retry turns until they get satisfactory random numbers. For "easy" difficulty it might not matter, but for "normal" or "hard" it does matter. A well-balanced Wesnoth campaign should be winnable without such foul tricks.

[Aethaeryn]

If stats.wesnoth.org shall be used to improve the scenario/campaign balancing, it is not helpful to collect data from cheaters who end a scenario with more gold and no lost units, because they retry turns until they get satisfactory random numbers. For "easy" difficulty it might not matter, but for "normal" or "hard" it does matter. A well-balanced Wesnoth campaign should be winnable without such foul tricks.

I kind of agree. If the only people who win are those who cheat the RNG, then the developers think the scenario's okay and they might not fix a nearly-unwinnable situation. Perhaps at least have an option to hide stats with scenarios with more than 3 reloads?

[turin]

Easier than filtering on whether or not they reload would be filtering on whether their luck was excessive in either direction. (I say this would be easier because I suspect there's no capability in Wesnoth to keep track of how many times a game had been loaded, and it would probably be a real pain.)

[Sapient]

actually, there is a way to detect with WML if someone has reloaded the game, but it's rather hackish. You have to assign a value to a variable with an invalid name, such as this

Code: Select all

 [set_variable]
  name="detect,has_reloaded"
  value="if_reloaded,yes"
 [/set_variable]

(at the beginning of the scenario)

then later....

Code: Select all

[if]
 [variable]
  name="has_reloaded"
  equals="yes"
 [/variable]
 [then]

# player has reloaded

 [/then]
[/if]

[tsr]

...

Heh, do you mind explaining why this works?

/tsr

[Max]

when someone uploads statistics - what files are used to collect this information?

analyzing a replay save game would "expose" cheaters. a szenario with 20 turns should include enough information to see if someone excessively used save/load. e.g. an overall "luck factor" of 1.2 (in contrast to an expectancy value of 1) would be a more than clear sign this happend.

and players that replayed a previous turn just to try out a new tactic would still have a "luck factor" that won't differ much from the expected value.

some of these statistics could even be listed at the end of a szenario (or the campaign).

[epameinondas]

is there any way to detect an rng cheater in a pvp match?

[Feldegast]

and players that replayed a previous turn just to try out a new tactic would still have a "luck factor" that won't differ much from the expected value.

Analyzing random numbers won't be sufficient, I think. Imagine you reload a turn to kill a single important enemy unit with a severely wounded horseman, and it works out fine after a few attempts, but at the end of the turn when it is the enemy's time to move, the many random numbers of your units' attacks in defense go towards the average again.

It's single moves that make the difference. To kill a leader in kamikaze fashion. And when it has worked, save, reload, and kill the next enemy unit in the same way.

On stats.wesnoth.org one can discover long yellow colored stair-case effects in the scenario summaries. It is obvious that the player quit and reloaded not only one turn, but many turns, to decide between "hit and miss" or "survive and be killed".

You end a scenario with not much gold (perhaps the minimum gold) and wonder how much gold other players have had. You visit the stats server to see that somebody ended with 500-600 only due to cheating.

Whether scenarios are playable should depend on whether you can win them from start turn to end turn. That means, green bars on stats.wesnoth.org.

[Max]

Analyzing random numbers won't be sufficient, I think. Imagine you reload a turn to kill a single important enemy unit with a severely wounded horseman, and it works out fine after a few attempts, but at the end of the turn when it is the enemy's time to move, the many random numbers of your units' attacks in defense go towards the average again.

It's single moves that make the difference. To kill a leader in kamikaze fashion. And when it has worked, save, reload, and kill the next enemy unit in the same way.

you're right. one could restrict load/save to important turns...

On stats.wesnoth.org one can discover long yellow colored stair-case effects in the scenario summaries. It is obvious that the player quit and reloaded not only one turn, but many turns, to decide between "hit and miss" or "survive and be killed".

You end a scenario with not much gold (perhaps the minimum gold) and wonder how much gold other players have had. You visit the stats server to see that somebody ended with 500-600 only due to cheating.

Whether scenarios are playable should depend on whether you can win them from start turn to end turn. That means, green bars on stats.wesnoth.org.

if someone has the setting that deletes older savegames once a replay save game is created - there won't be any yellow colored entries?
but i still don't understand how statistics are collected at all.

what does such an entry tell me:
Game ID Player Start turn Start gold Time taken Result End turn Num turns
222828 19471... 0 100 629 victory 12 32
4037 44854... 11 23 136 victory 12 32

first entry: you can't tell how often a player has save/loaded within this game?
second entry: why does it start with turn 11? that's because a player saved this game and loaded it?

if i never load a manually saved game - will it always be listed as start turn = 0? (if i stick to autocreated save games)?

[Feldegast]

Auto-saved and auto-deleted games are not considered at all. Saving games is no operation that submits statistics to the server.

Only every time you end a scenario (quit=yellow, defeat=red or victory=green), the differences to your start parameters (from the start turn) are sent to the server.

The time (in turns) you played until you quit results in a yellow bar. Every yellow bar means the player quit after playing at least one turn. At which turn a player re-entered the game by reloading a saved game becomes visible in the graphical stats. The yellow stair-case effects in the graphics are the result of things like ending a turn, receiving lots of damage and killed units by orcs, quitting the scenario, reloading the previous auto-save game, receiving less damage by orcs due to good luck, saving after those satisfactory results and continueing at that point.

Ever seen a couple of units that all missed twice or thrice especially when you expected them to eradicate an already wounded unit? That's normal game-play. You need to consider bad luck like that. And the enemy might kill one of your units because of that. If on the contrary you reload until you get satisfactory random numbers, that's cheating and makes it much easier to finish scenarios and campaigns. Think "horseman effect". You can overrun the enemy at daylight if you retry often enough until all your horsemen hit at least once.

[pauxlo]

...

Heh, do you mind explaining why this works?

/tsr

I didn't try it out, but I suppose the variable gets in the savefile
something like

Code: Select all

[variables]
    detect,has_reloaded=if_reloaded,yes
[/variables]

And this sets two variables, not one with illegal name.

I think this is a bug ... either [set_variable] should set two variables here (or do nothing at all, or give an error message), or the savefile should be able to store variables with such names.

[Feldegast]

A typical example. Everybody who knows the beginning of that campaign notices immediately why the player managed to end with a lot of gold compared with normal non-reload cheating game-play.

[turin]

Wait... so, if this is already possible, why exactly is any change needed?