Cheating in SupcomFA
-
I was hoping for some cheats. fake news -
I was hoping for some cheats. fake newsYea what a bait...ffs.
-
Most of you are missing the point of my initial query.
First we don't have any proper categorisation of what is cheating. There is too many grey areas. So to solve this a whitelist of integrated mods would be better than a blacklist. If i make a mod tomorrow that automates certain parts of the game is that cheating?
Secondly, most cheating goes completely undetected, and this is partially due to point 1, and partially due to a lack of accountability and transparency in gameplay.
So it would be nice to have a more definitive explanation and position, and assurance that if people work on anti-cheat implementations they will be integrated.
If i was to go give you a cheat i'd get banned, so idk why you're expecting me to bother cheating the game or supply people with cheating mods, when its not even something I'm interested in doing.
-
If the community was large, tournaments had a lot of money at stake, then the risk might be mitigated.
You have not given ANY evidence that cheating is wide spread and a problem. Give proper examples? Maybe come up with rulebook yourself?
-
Well personally I consider anything that inputs a command external of the player as cheating and anything that aggregates information in a way that the player would not otherwise have acces to is cheating as it gives a competitive advantage against a person who does not have the same mod installed.
-
I honestly have the same opinion. Take Target Priorities for example, where you can set target as the ACU so they don't target random pgens, engi etc. Gives you a huge advantage over someone that does not have that installed.
The way it was explained to me though... the targeting should be able to controlled by the player and just a downfall of how the game was designed originally.
-
@scytale you can do what you described without the mod though
-
I thought the target can change without right click? So targeting the acu for example, then right click to move, the target may change on it's own?
-
you can use the snipe mode, although target prioritizing the acu has been remove for a lot of land unit
-
@Psions said in Cheating in SupcomFA:
For example UI mods, would it be easier to simply ban UI mods and integrate those that are allowed on a case by case basis once approved and then add the adjustment of those on the options screen rather than the lobby screen?
No, no it wouldn't.
@Psions said in Cheating in SupcomFA:
Would it be worth to then separate in the vault a UI mod from a SIM mod. A UI mod could be anything that affects the user interface, while a SIM mod is anything that effects the simulation (E.G Auto eco management, hover bombing and all of that).
I already talked about this with some people when we were discussing the state of the mod vault. Considering the popularity of AI mods, Faction additions, etc. It would be cool to give the mod vault some proper sorting.
@Psions said in Cheating in SupcomFA:
But you're welcome to make personal attacks, instead of contributing to the discussion.
I'll take the offer.
You're dumb. Give the thread these before it's worth a "discussion"-
Evidence of cheating, feel free to link your thread from 2015. Don't think people havent realised how you keep avoiding this request. We know why you're doing it.
-
A consensus that UI mods are cheating, where there is definetly not one. You would need to bring your case to prove that they're of such an advantage to a player that it makes a tennable difference in a users play. We're just talking in this thread like it's a given that ui mods are cheats, which I don't think anyone else here actually believes?
-
-
The separation of UI and Sim layers for modding is a key feature of SupCom and one of the things that makes its UI so advanced. People should be free to use whatever UI mods they think will improve their experience or effectiveness, including coding their own private UI mods.
UI mods should be allowed and part of the game, and if some people are losing an advantage by not using them, then the problem is education, not UI mods.
And if some people know how about the existence of UI mods, but are unwilling or unable to use them effectively, then that's a player skill problem, not UI mods.
We can only decide that UI mods are a problem when their use is universal and we see that the entire game devolves into some unwanted state. That's the time when access to certain functions/data should be closed off to the UI layer, or certain UI mods banned, etc.
-
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.
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.
-
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).
-
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.
-
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.
