Cheating in SupcomFA

@AdmiralZeech

I don't have a problem with allowing UI mods. I think the easiest implementation of this would be to have UI mods disabled in ranked games.

That way you get best of both worlds

@biass
You provide no evidence as to why whitelisting UI mods is harder than blacklisting them.

"A consensus that uI MOds are cheating"

That is exactly what I'm trying to establish. Currently UI mods are a super grey area. I could make a UI mod tomorrow that would give me a competitive advantage and no one would have a clue it even exists.

There is currently 0 reviewability of this sort of behaviour, and its completely unclear where the line is drawn.

So the purpose of this thread is to see if we can establish that line.

i'm curious as to how you would make this whitelisting work though. Verification of the UUID ?

Discussion of implementation

You can do this in a variety of ways. I would need to go investigate more about the current implementation of some of the game featuers to give a more informed opinion about how this could be implemented.

From my current position and with the information I have. I would propose what I currently think would be a seamless implementation by adding an option for "ranked/unranked" and this option is selectable by host, and forces its application onto all clients in the lobby, this will disable the UI for UI mods and all currently selected mods are also disabled. Whitelisted UI mods are those integrated into the FA client already and any future mods that want to be integrated.

If your question is more about enforcing this to avoid people replacing integrated mods with their own cheated version, then I would need to look more into the implementation of the the integrated FA mods already. I suppose verification of the UUID might work, or have each UI mod on load send some data to the server, and verify its there, and if the data is not received by the server to disconnect the client, or raise a flag to moderators/admins that this is a potential cheater.

As a further comment to those who simply say "cheating doesn't exist" provide evidence. We do not currently have a definition of what is cheating.

Example of gamebreaking information modification:

If i make a mod tomorrow that automatically pings any t3 bombers as soon as they are in vision of a radar, even if the models are physically not loaded, that gives me a competitive advantage. In fact if I made this mod I bet it would be very popular to those who take this game too seriously. I'll call it the "Anti-Snipe" mod. It will ping the location of any beetles/mercy/T3 bomber/T3 solace detected within a certain radius of any ACU, and then send out a message into allied chat "WARNING SNIPE".

Obviously, this would drastically decrease the effectiveness of ACU snipes. It would actually ruin a complete part of FA gameplay.

Is it cheating? Well technically no not under the current definition as many other information mods are allowed and are not "cheating" per se.

Evidence:

As to evidence of cheaters? If i make a mod tomorrow that shows me the income of enemy or hell on the "mass" overlay incorporated other information about different units, this mod as of current is impossible to detect by observers or opponents and gives me an advantage. With such a basic observer function in FA and a huge amount of complexity when it comes to gameplay, it is very difficult to assess if people are cheating or not, unless they are overly blatant about it.

Why is cheating so problematic?

When a cheat becomes ubiquitous among certain users that have influence, they defend said cheat as a "normal function" of the game and deny competitive advantage. This leads to nothing getting done about it.

Auto-eco mods that auto pause engineers are no different from recoil macros in an FPS game.

Information mods can be no different that wall hacking (seeing location of all enemies) in an FPS game.

Essentially, there are number of users, many of whom are high rated and play in tournaments on a regular basis, who use these said cheats, and they find it offensive to tell them that they are cheating. Because they assume everyone uses the cheat they think it is morally okay.

@biass

On your question to do with evidence, please read above. It is physically not possible to detect non-blatant use of UI mods that are cheating. Which is why I favour a whitelist, as then it puts everyone on the same level playing field. The mods are integrated so that everyone has the same information and options.

On your second point, I would argue that any competitive advantage is cheating. If I install modification that allows me to select or configure or macro my units in a way my opponent does not have the same option of doing without installing that mod, then that mod is a cheat. The argument "install the mod" is facile. The same logic could be used to aimbotting and recoil macros in CS GO for example.

All players should have the same base starting point functionally wise in the game. If you have to install something which is external to the base game to be put on a level playing field then that modification is a cheat as it means one player has a competitive advantage over another. Mods are genuienly useful and provide QOL fixes can be implemented (as many already are) through a whitelist.

If the game is not-ranked then people can use whatever they like, so we're not squashing or restricting creative talent in the map and mod making process. This will also mean that UI mods have a testing environment before they are integrated.

Your whole implementation idea cannot be achieved from lua code and changing the core engine in this regard is out of the question for FAF regardless how many times some people claim it is.

Avoiding blacklisting and whitelisting the simple way: I just fake my sim mod to run as a whitelisted mod.
More advanced: I just remove/disable all the ui-mod checks in my local lua code.

Nobody will ever be able to see what is happening on a player computer. He has free reign to modify everything, even the exe, as long as it doesn't affect the simulation.

It's basically the same thing as wallhacks in FPS games. You would need external anti-cheat tools to ensure that the game is running unmodified files, but we also know that none of these anti-cheat tools work reliably (+ cause other issues) and we will certainly not introduce one.

"Nerds have a really complicated relationship with change: Change is awesome when WE'RE the ones doing it. As soon as change is coming from outside of us it becomes untrustworthy and it threatens what we think of is the familiar."
– Benno Rice

Yeah, well first you could spend few minutes figuring out how it works, before suggesting "solutions"
Then I highly encourage you to made those mods you were talking about. And see for yourself whats possible and what's not.

@Brutus5000 So how do you integrate UI mods already into FAF?

The whitelisting option works the same way. The other section itself is just editing a basic map options (Which has already been done) and the lobby implementation itself and options there (Which has already been done).

You can do what you like on the client computer through the lobby since afaik the lobby is not FA.

Also if you read my full post I already considered end users replacing files. Which is why I suggested the whitelist mod sends confirmation messages to the server, and if one of them fail it either flags to moderators, or ends the user session by kicking them from FAF. However, you'd rather implement it.

@speed2 said in Cheating in SupcomFA:

bout. And see for yourself whats possible and what's not.

I'm not going to waste my time on something that as it stands will never be implemented. First we need a consensus on what cheating is, then agreement on what possible implementations there might be. Then I would be happy to help.

I highly doubt you go out of your way to code functions/implementations that you know are unlikely to ever get put into the game.

If ui mods get integrated into FAF they become part of the fa game repo. At this point it's no longer a ui mod, but part of the regular ui.

And as I stated before adding anti-cheat measures into lua code (which is what you would need to do to send confirmation messages to the server) can also be removed (e.g. as a cheater I would always send an empty list so that officially I wouldn't be using ui mods at all).

"Nerds have a really complicated relationship with change: Change is awesome when WE'RE the ones doing it. As soon as change is coming from outside of us it becomes untrustworthy and it threatens what we think of is the familiar."
– Benno Rice

Each post just confirms even more that you have no idea what you're talking about.

And unlike you, I actually know the game code in and out. I know what's possible and what's not and I've spend quite some time experimenting with it. Even fixed several real exploits.

@Brutus5000

That is how I thought it worked, and that is why I suggested it would be a seemless integration.

You're missing the point of my suggestion. If the server does not receive the notificaiton, that is when it flags. The only way to circumvent this is for the cheater to replicate the exact same encrypted message, which would require editing the FAF client itself and then modifying an integrated mod to incorporate they're cheated code. That is significantly harder and more effort for them to do than simply load up a local UI Mod.

@speed2 said in Cheating in SupcomFA:

Each post just confirms even more that you have no idea what you're talking about.

And unlike you, I actually know the game code in and out. I know what's possible and what's not and I've spend quite some time experimenting with it. Even fixed several real exploits.

Speed as it stands you're not actually contributing anything to this discussion, and as Brutus pointed out already my expectations of how the client works are correct.

If you actually wanted people to help you develop stuff then you instead of being condescending to everyone who makes a suggestion or who offers there help, maybe be more constructive or don't post at all. As it stands all you are doing is venting on another member of the community.

I've modded a much more limited engine than Supcom has and all limitations have workarounds. If you wanted to be constructive then point out the problems that would be faced with the implementation, and then alternatives can be thought out.

And I, like you, look for the easiest solution, because it means less work instead of more. And there is nothing more frustrating than spending 10 hours on something and completing only to subsequently learn that it could be done in 1 hour.

So the only thing we currently need to figure out is how to block out UI mods from loading and how to verify the integrity of the integrated mods. I've made a suggestion for both, you're welcome to explain why these are not possible.

This post is deleted!

Nevermind that:

  1. Most UI mods aren't cheating but are to enable enhancements to visual display or selection, which may be a very personal choice.
  2. A blanket ban with whitelist would create a lot more work for developers to check all submitted ui mods.
  3. Will alienate a lot of players who aren't cheating.
  4. Will discourage modding which is one of the points of interest to some players and has helped to give faf its longevity.
  5. Is completely unenforceable anyway.

If there is a particular ui mod which is causing you sleepless nights you should probably discuss that.

Automatic eco management style mods have always been the big bone of contention but funny how most top players don't seem to use them.

@Reckless_Charger said in Cheating in SupcomFA:

Nevermind that:

  1. Most UI mods aren't cheating but are to enable enhancements to visual display or selection, which may be a very personal choice.
  2. A blanket ban with whitelist would create a lot more work for developers to check all submitted ui mods.
  3. Will alienate a lot of players who aren't cheating.
  4. Will discourage modding which is one of the points of interest to some players and has helped to give faf its longevity.
  5. Is completely unenforceable anyway.

If there is a particular ui mod which is causing you sleepless nights you should probably discuss that.

Automatic eco management style mods have always been the big bone of contention but funny how most top players don't seem to use them.

  1. Well we need a consensus on what cheating actually is.
  2. A blanket ban answers your enforceability question and its only for ranked games. There would be some work involved, but that would be no different from the current process, where "essentials" have previously been integrated.
  3. How are we defining cheating? Macros are well known in all other game type to be considered cheats. In fact if you take any UI mod currently in FAF and mde an equivalent for StarCraft2 and used it in a tournament, i bet they would be disqualified.
  4. I don't see this happening. In fact, there is more incentive, because rather than you being the only one using it, there is a chance for it to be directly integrated into the game. That is a direct incentive.
  5. See 2

But yes, the biggest problem we're facing it was is considered cheating. I could give myself innumerable small advantages, through UI mods and then inflate my rank and no one would have a clue. Which makes the whole FAF competitive gameplay a farce.

And if you say small advantages mean nothing. That is exactly how Hannible became a historical legend. He gave himself many small advantages on the battlefield and this led to victory and conquest across most of the civilised world.

This is just thread #6783865 about restricting UI mods. Well you just can't. You have a set of engine functions available that we can't change and the whole UI is built on top of that. How its built can be different on each computer and you will never have a way of telling if it is modified or not.

@speed2 Can you customise the interface that FAF lobby loads? Or detect when a UI mod is selected?

I guess one implementation since we have a blacklist, is to blacklist all UUID apart from a specific set of them.

Now the only question is UUID verification.

You can customize it but it always have to load the base game files. If you ban everything, you can always alter the base game files. At this point UI modding is prolly killed. But then you can try to verify if the base game files werent modified, but you can always go around it one way or another. And its a lot of work for no real gain.

You can implement any UI mod directly into the base game files and no one would know, so any checks of UID of the mods is not a valid option.

It takes 2 second to change mods UID to fit the one from the whitelist. And you will never tell it was modified

Speed; doesn’t nx2 files get changed whenever the game detechs, a difference between them and the host files? Or you mean base base game files?

I’m a shitty 1k Global. Any balance or gameplay suggestions should be understood or taken as such.

Project Head and current Owner/Manager of SCTA Project

Client, not the game, but then you can build your own client version that wont care. Right now, just changing the files to read only does the job.

You keep giving the same argument that they'll just replace an implemented UI mod with their modified mod, and then change over the UUID. My suggestion is that the client detects when a game is loaded and calls for a access token that is then generated by the integrated mods. When a game is issued as ranked, UI mods themselves are locked out from loading or being selected.

You can do exactly the same thing for the client, when they first log into the server to avoided non-authorised clients. Sure they can still go and hack the client, but at this point cheating is very difficult, and the community is to small for any sort of wide spread support the production of cheating mods that take that sort of effort.

As it stands anyone with basic knowledge of LUA can right now make a cheated UI mod and implement it with 0 restrictions. What I'm suggesting is not a "full proof" way. Its an "idiot proof" way. Basically it locks out idiots from being able to cheat the game.

You wouldn't even need an overly complex encryption key and you can base it fully on in game values, such as user ID. Parse the user name of the individual and then push it through an encryption module to generate a key that is then collected or sent to the server. As the server also has the user ID available it can do the same and match the code.

The qualm about work required is irrelevant. I'd be happy to contribute so long as I know it'd get implemented into the client.