Status of "Cheat" Mods

[chrstgtr]

16 minutes ago, Atrik said:

But (obviously) it's nothing as good as just making every player mods visible in the game room.

No matter how many times you say this doesn’t make it right. 
 

Players should be allowed to chose who they play with and what advantages (mods) their opponents have access to. If you are cheating I (and others) don’t want to play with you. The end. If you openly cheat, I don’t want to play with you. If you secretly cheat, I don’t want to play with you.

@Dunedan’s proposal is aimed at letting players decide what mods their opponents have access to. Your insistence on weakening that just further suggests that you somehow believe your wants are more important than the desires of anyone you play with. It doesn’t work that way. Multiplayer games are meant for everyone’s enjoyment—not only yours. 

[guerringuerrin]

33 minutes ago, Atrik said:

If it's an option, it can be nice. But (obviously) it's nothing as good as just making every player mods visible in the game room.

This would be nice to incorporate, although it does not prevent encapsulating code within another mod

 

28 minutes ago, Atrik said:

 I think there never was a single threat about this mod saying something relatable beside "cheat cheat". Even when talking about introducing features, it's about preventing cheats, and the suggestions are totally biased toward preventing mods, not cheats.

This statement is a unfair, considering the lengthy arguments I've and others gave about this mod in the past, not appealing to simplifications like saying it's a cheat and that's it, but delving into the automations it carries out and whether those automations are fair or not in a competitive game and/or if they should be part of the vanilla game and why.

 

38 minutes ago, Atrik said:

Because we love so much to throw cheat every sentence to look very smart, the debate will hardly evolve around more useful matters.

In the same sense as the previous paragraph I would say that it is important for all of us to review how much willingness we have put into having a constructive debate on this matter...

[Gurken Khan]

41 minutes ago, Atrik said:

this feature would be to disallow (a) mod

If I understand it correctly there's a signed version and an unsigned; so it would disallow the secret use of one variant and not disallow the mod in general.

It's hard for me to believe you don't see the difference, and that you don't understand that people don't want to play against players who are secretly using scripts and whatnot.

[Dunedan]

40 minutes ago, Atrik said:

If it's an option, it can be nice. But (obviously) it's nothing as good as just making every player mods visible in the game room.

How would you ensure the names of the mods shown would be legit?

41 minutes ago, Atrik said:

Even if you consider adding some stuff like checksums I don't think  cheats wouldn't find their way through it, easily since it's an even an open source game. So again, this feature would be to disallow (a) mod, not prevent cheats.

It wouldn't prevent cheats, but would make them less trivial if you need to recompile the game to make them work, instead of dropping a bit of JavaScript in a directory.

1 hour ago, wowgetoffyourcellphone said:

I'd be throwing the ban hammer like Thor in Ragnarok if I had the power.

Please report players cheating by using mods or other means. Without reports there is little we can do.

[ShadowOfHassen]

You know, we could just put a kernel level anticheat... Maybe that'd help...

[Atrik]

30 minutes ago, chrstgtr said:

@Dunedan’s proposal is aimed at letting players decide what mods their opponents have access to. Your insistence on weakening that just further suggests that you somehow believe your wants are more important than the desires of anyone you play with. It doesn’t work that way. Multiplayer games are meant for everyone’s enjoyment—not only yours. 

I only wish for him to correct me but his proposal suggest a single checkbox "all or nothing" the disallow unsigned mod. So no my suggestions isn't weakening it, as host, and every player, can review each others mods.

16 minutes ago, guerringuerrin said:

55 minutes ago, Atrik said:

If it's an option, it can be nice. But (obviously) it's nothing as good as just making every player mods visible in the game room.

This would be nice to incorporate, although it does not prevent encapsulating code within another mod

Indeed it won't, but I didn't pretend it would. It would be just be better in my opinion for all player to be able to see each others mod rather then having a supposedly official enforcement option that would be hated, by maybe ~50% of players I play with regularly since AFAIK they use 1 or more unsigned mods.

9 minutes ago, Dunedan said:

Please report players cheating by using mods or other means. Without reports there is little we can do.

I would like to report myself for using progui, the most harmful cheat in 0ad, please show me the sanction you deem adapted to such infamy. Ban my account "Atrik_III"?

[Norse_Harold]

5 hours ago, Gurken Khan said:

All parties in the know = not cheating

Using it secretly = cheating

This is my opinion, as well.

 

7 hours ago, Dunedan said:

It isn't? Undisplayed mods wouldn't work that way either, unless the player uses a recompiled version of 0ad, which is a much higher hurdle than just installing a mod.

I agree with this.

5 hours ago, Dunedan said:

I created an issue to add an option to only allow signed mods: https://gitea.wildfiregames.com/0ad/0ad/issues/7166

I don't think that this would solve the problem. WFG isn't signing mods frequently enough to satisfy the userbase, and probably never will. Many users choose to use unsigned mods, even in ranked games. I guess that your proposal is an attempt to minimize the effort for attempting to solve the problem. I think that it would not actually solve the problem, though.

I think that it would be better to put the effort in to adding a feature that shows all players the mods in use by all players in the match. It would also be useful to add a feature that allows the hoster to define two lists: a list of required mods, and a list of optional mods, and to enable a setting that blocks users from joining unless they have mods consistent with those lists. I think that this is the most that we can do to resolve this conflict short of using a kernel-level anti-cheat system.

Edited October 31 by Norse_Harold

[real_tabasco_sauce]

The option to allow or disallow unsigned mods on the host side seems like a good idea. It can allow more casual hosts that don't feel strongly about the use of this mod to let players use it, and allows hosts that want a level playing field to disallow this mod.

Secondly, the argument that "there are other cheats, therefore a cheat mod isn't bad" is not valid. From what I've seen from the gaming industry as a whole, anti-cheat is as much about making it harder to cheat vs. actually stopping cheating.

Lastly, just because this cheat mod improves the experience for a select few players, doesn't mean it's features should be added to the game as a means to level the playing field. We shouldn't completely rework the GUI and gameplay style of 0ad just because a select few players want high-level automation.

Edited October 31 by real_tabasco_sauce

[real_tabasco_sauce]

30 minutes ago, Norse_Harold said:

I think that it would be better to put the effort in to adding a feature that shows all players the mods in use by all players in the match. It would also be useful to add a feature that allows the hoster to define two lists: a list of required mods, and a list of optional mods, and to enable a setting that blocks users from joining unless they have mods consistent with those lists. I think that this is the most that we can do to resolve this conflict short of using a kernel-level anti-cheat system.

So this would be like the host is signing what mods can be used vs letting this be determined by what mods are signed by WFG. I suppose its good too, but it might not be user friendly. Should @Dunedan's idea constitute a 'competetive mode' with higher standards for fairness, I think it would be more intuitive. Its easier for hosts to simply select or deselect a button than to manage lists of mods, especially when they might not be aware of the mods players are using.

I think the default setting should be off tho.

Edited October 31 by real_tabasco_sauce

[BreakfastBurrito_007]

6 hours ago, Gurken Khan said:

Using it secretly = cheating

There is a grey area where the majority of people know about the mod in a given host, no one mentions it, and the mod user(s) ignore players when it gets brought up. The status quo is unfortunately that clean users need to ask mod users to stop instead of mod users asking if they can be allowed to use the mod. 

I'm not clued in to the signing/compatibility checks situation, but we need some setup where the onus is on the mod user to make sure everyone in the host is ok with the mod. The mod does not have to be banned to solve the issue of player discontentment like that of @RangerK.

There is absolutely an advantage of using progui's autotrainer compared to basic autoqueue, I'm tired of this fact being denied. It is good that autoqueue is unoptimized for the sake of the game, automatic features should always perform worse than direct player management. Quickstart and autotrainer both break this rule of thumb by providing automation that outpaces even the best 0ad players' direct management, all without even a thought. 

I think quite a few high level players aren't interested in disturbing cheaters unless they are beaten by it. Some of this is due to players being unaware of the amount of production building idle time they have when they play (more than you think). I think there are statistics that could be shown on the summary table that would reveal the magnitude of the progui advantage.

 

[Stan`]

37 minutes ago, Norse_Harold said:

I think that it would be better to put the effort in to adding a feature that shows all players the mods in use by all players in the match. It would also be useful to add a feature that allows the hoster to define two lists: a list of required mods, and a list of optional mods, and to enable a setting that blocks users from joining unless they have mods consistent with those lists. I think that this is the most that we can do to resolve this conflict short of using a kernel-level anti-cheat system.

I'm not sure you have access to user mods right now (I suppose guest have access to the host's mods though).

My issue with just listing mods is you are basically just listing names. So I can make an autociv named mod with the progui features and it will go under the radar.

The good thing with Dunedan's approach is that one can rely on zip signatures which are harder to craft. With mod names, you mod can be a zip, a list of files in a folder, with or without mod.json and it's gonna be pretty hard to compare them between users. And if you can't compare them, you're just in a slightly better place than right now, but you have almost no extra guarantee.

Agreed on the signing times @Itms and I can take a while. And as mentioned on the autociv thread, not all mods are eligible.

8 minutes ago, BreakfastBurrito_007 said:

There is absolutely an advantage of using progui's autotrainer compared to basic autoqueue, I'm tired of this fact being denied. It is good that autoqueue is unoptimized for the sake of the game, automatic features should always perform worse than direct player management. Quickstart and autotrainer both break this rule of thumb by providing automation that outpaces even the best 0ad players' direct management, all without even a thought. 

I'd be against porting all of them to the main game, but I think some features in autociv are great, like the hotkeys. Our hotkey situation is bare, to say the least.

[BreakfastBurrito_007]

10 minutes ago, Stan` said:

I'd be against porting all of them to the main game, but I think some features in autociv are great, like the hotkeys. Our hotkey situation is bare, to say the least.

Yea those things I talked about as far as I know are just in progui (quickstart and autotrainer), which is what the calamity is about. The autociv hotkeys still require the player to execute every action. 

I think for adding things from autociv we probably want to focus on things that provide a useful quality of life enhancement but also avoiding anything that accomplishes multiple tasks in one action (macros).

Edited October 31 by BreakfastBurrito_007

[ffm2]

8 hours ago, Gurken Khan said:

8 hours ago, guerringuerrin said:

We can argue whether this is cheating or not

All parties in the know = not cheating

Using it secretly = cheating

Is it that complicated?

The current state of the multiplayer lobby just shows that this is not the case. Players just download proGui through mod.io and just use it. Even Atrik just assumes everyone knows by now that he is using it. One day Chrstgtr tells him he should not do it in his games, next game he does it again.

When I or RangerK return to this game after a break and join a 4vs4 game no ProGUI user tell them that he automates unit commands and unit production beyond human capabilities. Instead some even tell it is just a GUI.

4 hours ago, Dunedan said:

6 hours ago, wowgetoffyourcellphone said:

I'd be throwing the ban hammer like Thor in Ragnarok if I had the power.

Please report players cheating by using mods or other means. Without reports there is little we can do.

If some official sign were there, like a mod ban Atrik for a day or at least say that
-proGUI's autotrainer
-proGUI's quickstart
is considered officially as a cheat in regular use (not announced).

But we have this situation where the proGUI users just use it like great mods like autociv and feldmap. And then users tell in lengthy discussions about how it is ok and not a cheat.

Can we have a adult jumping in saying:
-The autotrainer of vanilla is intended to work that way (turning of if there's no res., don't automate adjusted batches), for this alpha
-Don't give units commands via makros / mods etc.

If you like the vertical panel or what that's ok for me. Maybe split it up in 3 mods and have one of them signed or accepted by the community.

One can automate everything away, but then it is a different game. Afaik DotA focused their game to play just playing the hero of Warcraft 3. That's ok. But you can't automate things away and play with the others that still do another part of the game in a way they never can reach you.

People will still cheat, but we can end this "is considered by some" discussion. Even if the advantage were small or however it is downplayed. Or start a poll before or something.

[Gurken Khan]

3 hours ago, BreakfastBurrito_007 said:

There is a grey area where the majority of people know about the mod in a given host, no one mentions it, and the mod user(s) ignore players when it gets brought up

10 hours ago, Gurken Khan said:

Using it secretly = cheating

 

[BreakfastBurrito_007]

17 minutes ago, Gurken Khan said:

 

I guess you see it as a black and white issue. I promise you its not, most players disapprove of cheating with progui but don't work together to exclude it from games, that still makes it cheating. It only takes one person to offend but it takes the near unanimous and timely agreement of multiple players to actually stop it. Most players don't want to "disturb the peace" to argue that a player should should be disallowed from using cheats, which starts heated arguments and delays the game. Instead the conversation online should be about whether to allow it when someone asks to use it.

[AInur]

Most of the cheats that you discuss exist in the form of a mod. Here is a potential solution: the clients synchronize all mod files from the host during the gamesetup process, regardless of whether the client has the same mods or not. All clients and the host will expose their mods folder to each other for synchronization over network, while players are chatting or waiting for the game to start. The advantages of my solution are:

1. All cheat edits of signed legitimate mods will be overwritten instantly.

2. Players don't need to restart the game or go through the hassle to download mods in order to join a particular host.

3. Less likely for OOS errors.

[Norse_Harold]

12 hours ago, Stan` said:

The good thing with Dunedan's approach is that one can rely on zip signatures which are harder to craft.

Of course this is a good idea. This idea can be applied to the idea that I have described, as well. Hashes can be sent over the network and compared with the host's hashes of required and optional mods.

I think that we should be brainstorming for all good ideas for solving the problem as completely as possible, listing how much time it would take to implement each idea, then letting the user base decide where they want to draw the line on what time investment, and perhaps bug bounty investment, is worth it compared to the expected value of the proposed feature.

Proposal 1: Add a feature where hosts can require that only signed mods are used by clients. This list is enforced by mod.io zip hashes. GUI requirements: one additional checkbox in gamesetup.

Proposal 2: Add a feature where all users in a match are shown all mods in use by all other users in the match. GUI requirements: make the names of users in the match clickable in order to see the mods that they are using, including versions and possibly hashes of mod content. Alternatively, add a new GUI page that shows the mods in use by each user.

Proposal 3: Add a feature where hosts can define two lists of mods allowed to be used by clients of games that they host: required mods and optional mods. These lists are enforced by hashes of the mod content compared between hoster's content and client's content. As a convenience to hosters, if they want to skip downloading optional mods that happen to be available via mod.io, zip hashes from mod.io can be used. GUI requirements: new GUI page for defining mod allowed mod lists.

How much development time, in man-hours, do you think it would realistically take to implement each proposal?

The user base should also be aware that Proposal 1 is an immediate compromise and would not, as completely as possible, solve the problem. I think that the combination of proposals 2 and 3 would as completely as possible, while staying open source, solve the problem. Maybe there's even more that we could do, but I haven't thought of it. What other technical solution ideas are available?

Separate topic: what process or software do you advise for WYSIWYG editing of GUI pages for 0ad?

Edited November 1 by Norse_Harold

[Norse_Harold]

7 hours ago, AInur said:

1. All cheat edits of signed legitimate mods will be overwritten instantly.

All signed legitimate mods will be overwritten with hacked malware edited mods instantly.

Fixed it for you.

Automatically sending mods from hosters to other users is a recipe for disaster. Instead, I advise comparing SHA512 or similar hashes of the mod content between users.

Edited November 1 by Norse_Harold

[ffm2]

2 hours ago, Norse_Harold said:

Proposal 1: Add a feature where hosts can require that only signed mods are used by clients. This list is enforced by mod.io zip hashes. GUI requirements: one additional checkbox in gamesetup.

16 hours ago, nani said:

the new rules for mod.io uploads don't allow mods with the compatibility flag off and that change the simulation folder (even if they preserve gameplay simulation untouched).

It seems mod.io also handle mods more restrictive because of abuse. This rule would be a problem as I see it atm. New rules can also come any day.

 

2 hours ago, Norse_Harold said:

Proposal 2: Add a feature where all users in a match are shown all mods in use by all other users in the match. GUI requirements: make the names of users in the match clickable in order to see the mods that they are using, including versions and possibly hashes of mod content. Alternatively, add a new GUI page that shows the mods in use by each user.

This is not a exclusive option and I think a good change. Players could also be made aware of mods they don't know and check them out because of the popularity. Also in the team set up one could put one proGUI user in each team to balance it.

 

2 hours ago, Norse_Harold said:

Proposal 3: Add a feature where hosts can define two lists of mods allowed to be used by clients of games that they host: required mods and optional mods. These lists are enforced by hashes of the mod content compared between hoster's content and client's content. As a convenience to hosters, if they want to skip downloading optional mods that happen to be available via mod.io, zip hashes from mod.io can be used. GUI requirements: new GUI page for defining mod allowed mod lists.

Some mods are big and if the host does not use them he should not download them. This seems a good additional approach to #2. I would add to this some appearing option for the host "ffm tries to enter your game with ffm_4k. Description: 'This mod increases the font by 2 sizes. Better suited for high res displays.' Add the key XX to your keyring?" And if the host gets tired of this mod he can remove this key.

 

This would of course not prevent cheating and be a hurdle for new modders but necessary as proGUI users show no awareness at all that it is cheating. It's verbosely described in proGUI, the day after and here by RangerK yet again. If a proGUI user then enforces these features another way, at least they are made aware that they cheat.

Edited November 1 by ffm2

[AInur]

4 hours ago, Norse_Harold said:

All signed legitimate mods will be overwritten with hacked malware edited mods instantly.

Norse Harold and ffm2 raise valid concerns. I now have a safer and more convenient plan than the hashes:

1. The host exposes the list of mods (must be registered, signed mods) that they are using to the clients.
2. The client sees the list and automatically downloads the specified mods from the trusted mod.io repository.
3. The newly downloaded mods will overwrite the contents of their mod folder and automatically activate themselves.
4. Then they can join the game and will not need to re-download and reboot.

 

Many new players are not able to download and activate the mods correctly themselves. Players who take vacations may come back with an outdated version of the same mod and OOS desync the whole game. Meanwhile, it is inconvenient for players to keep switching between community mods and public, then re-activate Mainland-Twilight or Feldmap; many players loose their slots or crash in this process. This is why I insist on refreshing the mod files automatically during the gamesetup page. I hope you can understand my perspective.

If the host is using unsigned mods, then the clients will not be able to find the list in mod.io and the host will not be joinable.

If the host edits mods without committing to mod.io as new versions, there might be an OOS issue. To combat this, we can use Norse Harold's suggestion of hashes to guarantee that everyone is running on identical source code. I hope you find my suggestions helpful.

[Stan`]

24 minutes ago, AInur said:

Many new players are not able to download and activate the mods correctly themselves. Players who take vacations may come back with an outdated version of the same mod and OOS desync the whole game.

Well unless the mod is being disguised as a mod that doesn't require compatibility checks it will never happen. Unless of course people don't update versions in the mod.json but then you have broken mods and one cannot do much about it.

5 hours ago, Norse_Harold said:

Separate topic: what process or software do you advise for WYSIWYG editing of GUI pages for 0ad?

Any text editor. @Vantha @trompetin17 might have different approaches. You should use the hotloading feature as much as possible to get the fastest feedback. Two screens might help (or windowed mode)

5 hours ago, Norse_Harold said:

How much development time, in man-hours, do you think it would realistically take to implement each proposal?

For 1 maybe a few days + review time. For 2) more likely a week or so. More depending on how you compute the hashes. If unpacked mods are in scope one needs to define how exactly do you compute the mods' hash.

For 3) maybe the same time or more than 2). You also have to accept mod.io's terms to download anything from them and you still have to implement whatever is missing to force clients to broadcast their mods to you.

For all the proposals you need c++ changes and js changes. Finding a dev that can do both (correctly) might be tricky.

 

Another thing: "Cheat mods" could be on mod.io (minus the issue of signing taking time) with compat checks on. This way everyone has the same (guaranteed by the signature)

[RangerK]

MOVES PER SECOND - Reacting to @ffm2 's comment on page 1 of this thread.

Wouldn't it be cool if after a game, you got see a chart of people's commands per second?  That would offer interesting insight not only into skill, but it also might reveal automation.

You could publish both peak and average commands per second.

Maybe there are some other statics that would put a spotlight on automation - like barracks idle time, resource use efficiency.

It seems that making more information public is technically easier than preventing certain behaviors.

Also - some unit-idle-time statistics at the very start to reveal start scripts?

[Stan`]

7 minutes ago, RangerK said:

MOVES PER SECOND - Reacting to @ffm2 's comment on page 1 of this thread.

Wouldn't it be cool if after a game, you got see a chart of people's commands per second?  That would offer interesting insight not only into skill, but it also might reveal automation.

You could publish both peak and average commands per second.

Maybe there are some other statics that would put a spotlight on automation - like barracks idle time, resource use efficiency.

It seems that making more information public is technically easier than preventing certain behaviors.

Also - some unit-idle-time statistics at the very start to reveal start scripts?

You can see some stats like that on https://replay-pallas.wildfiregames.ovh/

Maybe with the help of @Dizaka we could add such graphs.

[ffm2]

Also on the topic of idle time of barracks (or any building). I was just watching the video shared by @real_tabasco_sauce on proGUI, the day after (which indeed is very much on point of this topic). There is a overlay that has a nice counter that runs when buildings are idle.

Edited November 1 by ffm2

[BreakfastBurrito_007]

Progui is already very easy to detect from an observer's point of view and also from replays, even without these statistics. The main value is in determining the impact the cheats have on the gameplay, which is very important for increasing awareness. In the case of a more subtle cheat like a macro that could arise in the future, an actions per minute statistic could help detect those cheats early on.

I think the same statistics that could help reveal cheats would also be very helpful for players to try to improve their skills. They could look through the cumulative idle time plots to see where their first big increases happen.