95 replies to this topic

[jaxjace]

Some people, just wanna watch the forum burn.

[old man odin]

Fen Tetsudo, on 03 December 2015 - 01:51 AM, said:

All that says is PGI will not take administrative action against players who create problematic edits (which would include exploits), instead they will simply remove the ability to make those edits. So its not saying that all edits are okay, its saying PGI will remove the ones they deem are not okay, as they become aware of them.

Okay buddy, if you want to draw the distinction between how PGI moderates and what's a breach of ToS go ahead. This is where I get off this crazy train though. There is zero difference to me between the two. A rule isn't really a rule if it's only purpose is to be quoted by forum lawyers.

[MechWarrior3671771]

"if you want to draw the distinction between how PGI moderates and what's a breach of ToS go ahead"

Huh? No reason to get snarky. I'm just explaining that your "proof" doesn't say what you claim it does.

[Tarogato]

I think we need to quit using the word "exploit" as nobody here can clearly agree on what it means. Instead, let's focus on a couple things that cover the same topic but aren't subject to this verbal wankery and rule lawyering:

A: are edits to the user.cfg allowed? (this is a resounding "yes" from PGI as far as I can tell)
B: are there any edits to the user.cfg that can provide an unreasonable advantage? (yes, we can tell because PGI has elected to remove some cvars. One even just yesterday.)
C: what edits can be considered to provide an unreasonable advantage? (this should be the main topic of debate, imo, and an ongoing process)
D: are members of the competitive community leveraging such edits against their opponents? (as far as I can tell, no. I have yet to see evidence of this. Twitch streams and competitive match recordings from player perspective are all available to us to peruse and use as evidence, but I have yet to see the production of any proof.)
E: is editing the user.cfg a punishable offense? (seems to be a resounding "no" so far from PGI)
F: should some cvars continue to be removed from the list? (of course - as bad eggs are found, they should be culled)
G: should the entire user.cfg be locked away from the player? (PGI hasn't said anything about this, but that's where the rest of my post comes in... )

Mechwarrior Buddah, on 01 December 2015 - 03:16 PM, said:

they should just lock user.cfg and be done with it imo

Fen Tetsudo, on 02 December 2015 - 10:20 AM, said:

<shrug> What was unreasonable was your crowd arguing that ANY edit to user.cfg was allowed and couldn't possibly be an exploit because the devs had locked down all remaining edits that were problematic.

We're back at square one again. Please tell me how the following settings are considered an exploit or provide an unreasonable advantage and should be not allowed or are sufficient grounds for locking the user.cfg away from players:

sys_MaxFPS = 30

Do you know what this does? Do you understand the "outrageous advantages" is bestows upon the user? It caps your framerate at 30. For a player like me who's framerate fluctuates widely between 30 and 70 throughout a match, it helps to have my framerate restricted so that I am not distracted by the sudden frame drops into the low 30's and it makes sub-30 drops much less noticeable. Also, many streamers and youtubers cap their framerates at 60 to avoid screen tearing in their recordings. Why should this option be taken away from us?

gp_default_cockpit_light = 1

This sets your cockpit lighting to "off" to reduce glare and distraction. In game, you have to press a key to do this at the start of every match, but with this little user.cfg tweak it is set automatically so you don't have to do it yourself. What is so bad about this?

r_DepthOfField = 0
This sets your depth of field (the blurriness in the distance) to "off". This is particularly useful is you don't like playing on Low settings just to get rid of the distance blur. You can now play on High without the ugly blur.

r_MultiGPU = 1

Enables multi-GPU support - expect much better framerate if you are using Crossfire/SLI. Set to 0 for optimum performance on a single GPU setup. It's possible that if the user.cfg were locked down, some people with high-performance rigs would be adversely affected and suffer a serious drop in frame.

e_particles_thread = 1

Ensures that particles rendering is threaded and is the optimum setting for multi-CPU rigs.

r_ColorGrading = 0

Disables color grading, which is basically a hue/saturation filter that is applied by post processing in the Very High settings. This can significantly help people get more acceptable framerate while running Very High settings.

[Bilbo]

GernMiester, on 02 December 2015 - 02:55 PM, said:

If its a function of the engine its been there the whole time.

I have used rglow chnages and fnd that it makes zero difference since I hit exactly where I am aiming anyway but my lasers now look like C R A P.

I know the variable has been there. I just wondered if a recent change might have affected the allowable range of it. I was referering to the wall hack tweak. I didn't see a problem with the rglow tweak anyway.

[Roadkill]

The "in good faith" line in the FAQ is no longer applicable because PGI has told us that there's no concern with modifying user.cfg. As I said before, the FAQ that Fen is quoting is 2 years old and no longer up-to-date. It's been directly superceded by a PGI representative.

Something isn't an exploit until you know that it wasn't intended. Since at one point edits to user.cfg were completely disabled, and then PGI added back in only the edits that they wanted to allow, it is safe to assume that all available edits in user.cfg are intended until we're told otherwise. Which means that editing user.cfg cannot be an exploit because as far as we know all available edits are intended.

PGI is of course free to examine edits that are brought to their attention and remove them if they decide that they are no longer appropriate, and it is possible that there will be a brief period prior to that edit's removal but after PGI tells us that a particular edit isn't intended where using a particular edit would be considered an exploit, but no such examples exist at this time.

Editing user.cfg is not an exploit until PGI tells us that it is.

[BigJim]

Just to see what people were talking about, I trued using the line that lets you see through walls the other day, just for one drop.
It was Crimson, and it was horrendous!

Couldn't see the meshes that make up the floor, or the walls of the cave, or the carpark, couldn't see where I was going because I could see in the distance, but any object around me would not render - no idea if I'm behind cover, or if my target is, if I'm walking into walls, or down a hole... damn...

If you could switch it on/off mid-game, I could see it being a massive advantage, but as-is, yeah it should probably be taken out for professionalisms' sake, but as an actual advantage for play, it's dubious, if not a downright hindrance to the player using it.

[Dimento Graven]

BigJim, on 03 December 2015 - 10:06 AM, said:

Just to see what people were talking about, I trued using the line that lets you see through walls the other day, just for one drop.
It was Crimson, and it was horrendous!

Couldn't see the meshes that make up the floor, or the walls of the cave, or the carpark, couldn't see where I was going because I could see in the distance, but any object around me would not render - no idea if I'm behind cover, or if my target is, if I'm walking into walls, or down a hole... damn...

If you could switch it on/off mid-game, I could see it being a massive advantage, but as-is, yeah it should probably be taken out for professionalisms' sake, but as an actual advantage for play, it's dubious, if not a downright hindrance to the player using it.

Not knowing anything about the particular cvar in question, but is it possible the value you set was range? So that if you set it at say... 100, anything 100 meters or closes was drawn, but beyond that it was off, allowing you to see through all the terrain objects?

If so, I could see what it was such a problem in competitive matches, you would still have up close navigability, but also be able to situate yourself to see the enemy where normally you wouldn't be able to.

[Ghogiel]

dario03, on 03 December 2015 - 12:51 AM, said:

Its the same command. Which is why I was saying they should just limit the input range. With that said though, even with that and/or the game settings turned up you can still have issues with invisible walls and pop in.

Try these uber leet hax e_viewdistmin = 4096

If you don't want holes in your buildings from the crappy LODs try e_lodmin=0 or 1. That should force CE to use LOD0 (the full res mesh) or LOD1 (the first LOD mesh) for all objects even mechs. (hopefully no RVNs at 1500m made of janky triangles with gaps everywhere.)

Dunno about terrain LOD though.

[Mechwarrior Buddah]

Tarogato, on 03 December 2015 - 08:16 AM, said:

I think we need to quit using the word "exploit" as nobody here can clearly agree on what it means. Instead, let's focus on a couple things that cover the same topic but aren't subject to this verbal wankery and rule lawyering:

A: are edits to the user.cfg allowed? (this is a resounding "yes" from PGI as far as I can tell)
B: are there any edits to the user.cfg that can provide an unreasonable advantage? (yes, we can tell because PGI has elected to remove some cvars. One even just yesterday.)
C: what edits can be considered to provide an unreasonable advantage? (this should be the main topic of debate, imo, and an ongoing process)
D: are members of the competitive community leveraging such edits against their opponents? (as far as I can tell, no. I have yet to see evidence of this. Twitch streams and competitive match recordings from player perspective are all available to us to peruse and use as evidence, but I have yet to see the production of any proof.)
E: is editing the user.cfg a punishable offense? (seems to be a resounding "no" so far from PGI)
F: should some cvars continue to be removed from the list? (of course - as bad eggs are found, they should be culled)
G: should the entire user.cfg be locked away from the player? (PGI hasn't said anything about this, but that's where the rest of my post comes in... )




We're back at square one again. Please tell me how the following settings are considered an exploit or provide an unreasonable advantage and should be not allowed or are sufficient grounds for locking the user.cfg away from players:

sys_MaxFPS = 30

Do you know what this does? Do you understand the "outrageous advantages" is bestows upon the user? It caps your framerate at 30. For a player like me who's framerate fluctuates widely between 30 and 70 throughout a match, it helps to have my framerate restricted so that I am not distracted by the sudden frame drops into the low 30's and it makes sub-30 drops much less noticeable. Also, many streamers and youtubers cap their framerates at 60 to avoid screen tearing in their recordings. Why should this option be taken away from us?

gp_default_cockpit_light = 1

This sets your cockpit lighting to "off" to reduce glare and distraction. In game, you have to press a key to do this at the start of every match, but with this little user.cfg tweak it is set automatically so you don't have to do it yourself. What is so bad about this?

r_DepthOfField = 0
This sets your depth of field (the blurriness in the distance) to "off". This is particularly useful is you don't like playing on Low settings just to get rid of the distance blur. You can now play on High without the ugly blur.

r_MultiGPU = 1

Enables multi-GPU support - expect much better framerate if you are using Crossfire/SLI. Set to 0 for optimum performance on a single GPU setup. It's possible that if the user.cfg were locked down, some people with high-performance rigs would be adversely affected and suffer a serious drop in frame.

e_particles_thread = 1

Ensures that particles rendering is threaded and is the optimum setting for multi-CPU rigs.

r_ColorGrading = 0

Disables color grading, which is basically a hue/saturation filter that is applied by post processing in the Very High settings. This can significantly help people get more acceptable framerate while running Very High settings.

Do you know every possible command that can be made in the cfg? Cause obviously the players do and the devs dont

and again... Im running this on a six year old rig, again, WITHOUT using the cfg. So if your rig cant handle this game, time to upgrade. Again, game security should trump this.

Edited by Mechwarrior Buddah, 03 December 2015 - 10:29 AM.

[Tarogato]

Mechwarrior Buddah, on 03 December 2015 - 10:28 AM, said:

Do you know every possible command that can be made in the cfg? Cause obviously the players do and the devs dont

and again... Im running this on a six year old rig, again, WITHOUT using the cfg. So if your rig cant handle this game, time to upgrade. Again, game security should trump this.

Yet you ignored the fact that all of the cvars I listed above can be used for optimisation on high-end rigs...

... try reading next time?

[Mechwarrior Buddah]

Tarogato, on 03 December 2015 - 10:35 AM, said:

Yet you ignored the fact that all of the cvars I listed above can be used for optimisation on high-end rigs...

... try reading next time?

yes, I ignored them because theyre largely worthless.

maybe say something not worth ignoring next time?

Edited by Mechwarrior Buddah, 03 December 2015 - 10:38 AM.

[MechWarrior3671771]

A: are edits to the user.cfg allowed? (this is a resounding "yes" from PGI as far as I can tell)

The FAQ says edits are allowed within limits: "it is acceptable to edit the user.cfg file under certain conditions.... . As long as you are editing the user.cfg file in good faith.... In summary, if a modification is giving some sort of benefit over other players, this is a violation of our Terms of Use". So not a resounding yes, but a yes within limits.


B: are there any edits to the user.cfg that can provide an unreasonable advantage? (yes, we can tell because PGI has elected to remove some cvars. One even just yesterday.)

Agreed.

C: what edits can be considered to provide an unreasonable advantage? (this should be the main topic of debate, imo, and an ongoing process)

Not going down that rabbit hole, as people have demonstrated they can't even comprehend a basic FAQ or even comments in this thread without distorting misrepresenting what was said. Going over definitions of "unreasonable advantage" would take 30 pages each while people played word games to protect their pet advantages.

D: are members of the competitive community leveraging such edits against their opponents? (as far as I can tell, no. I have yet to see evidence of this. Twitch streams and competitive match recordings from player perspective are all available to us to peruse and use as evidence, but I have yet to see the production of any proof.)

Inconclusive and irrelevant. First, you would need streams from that player's cockpit to see what they see, and they could simply run their stream with problematic edits turned off, since they know they are streaming. Second, look at how much was involved just to detect a known hack (the wallhacking ban). What we do have are admissions from players that they would use an edit that removes screenshake, if it were available.

E: is editing the user.cfg a punishable offense? (seems to be a resounding "no" so far from PGI)

Agreed. Just don't assume that since PGI is declining to punish that there is nothing wrong there. There are several reasons why PGI would decline to take administrative action. Their decision to not do so should not be taken as proof its okay to create exploits using edits to user.cfg.

F: should some cvars continue to be removed from the list? (of course - as bad eggs are found, they should be culled)

Agreed.

G: should the entire user.cfg be locked away from the player? (PGI hasn't said anything about this, but that's where the
rest of my post comes in... )

I don't think so, but I don't have a strong opinion either way on this. If players continue to abuse the user.cfg in bad faith, then maybe it should be locked away.


"Please tell me how the following settings are considered an exploit or provide an unreasonable advantage and should be not allowed or are sufficient grounds for locking the user.cfg away from players"

Again, not going down that rabbit hole, as you guys have demonstrated some serious reading comprehension difficulties. And the recent removal of the wallhack edit is proof that certain edits to user.cfg can be considered exploits and will be removed.

----

Roadkill: "The "in good faith" line in the FAQ is no longer applicable because PGI has told us that there's no concern with modifying user.cfg. As I said before, the FAQ that Fen is quoting is 2 years old and no longer up-to-date. It's been directly superceded by a PGI representative."

It has not. The email you are referring to simply states that PGI won't bother with administrative action against players that may have edited user.cfg in bad faith, they will simply remove those edits instead.


"Something isn't an exploit until you know that it wasn't intended."

Not exactly. Its possible to use an exploit without knowing its an exploit.


"Since at one point edits to user.cfg were completely disabled, and then PGI added back in only the edits that they wanted to allow, it is safe to assume that all available edits in user.cfg are intended until we're told otherwise. Which means that editing user.cfg cannot be an exploit because as far as we know all available edits are intended."

The recent wallhack edit proves that to be wrong - it is possible to create exploits using edits to user.cfg. PGI did not add back in only the edits that they wanted to allow, else they wouldn't now be removing the wallhack, and the recent email wouldn't need to say that they will remove problematic edits in the future.


"Editing user.cfg is not an exploit until PGI tells us that it is."

No. The wallhack edit to the user.cfg was an exploit that PGI didn't even know existed until this week.

Instead of claiming "that which is not specifically forbidden is allowed", players should use their own judgment to make edits "in good faith" (there is that term again). If they find themselves in a gray area and are unsure, they can ask PGI about a specific edit or even post questions to the forums about it. Saying that its okay to use a possible exploit because PGI hasn't told you not to is a cop out.

Edited by Fen Tetsudo, 03 December 2015 - 11:01 AM.

[Roadkill]

Fen Tetsudo, on 03 December 2015 - 10:46 AM, said:

And the recent removal of the wallhack edit is proof that certain edits to user.cfg can be considered exploits and will be removed.

Wrong. What it proves is that PGI can change their minds and remove something that they'd previously allowed.

PGI removing something != that something is an exploit.

Something is not an exploit unless we know that it was unintended, because that is part of the definition of an exploit.

This is the problem you keep running into. You seem to think that players define exploits. We do not. PGI defines what is or is not an exploit.

PGI disabled all user.cfg edits. They then added back in limited functionality to editing user.cfg. The natural and in good faith interpretation of that action is that anything that can be edited in user.cfg is now allowed until such time as PGI tells us that it is not.

PGI has not done that. Ergo, editing user.cfg is not an exploit.

Quote

Its possible to use an exploit without knowing its an exploit.

This is true, but only if PGI has said that something is an exploit.

In this case PGI has not said that anything is an exploit, so they are not exploits.

Quote

The recent wallhack edit proves that to be wrong - it is possible to create exploits using edits to user.cfg. PGI did not add back in only the edits that they wanted to allow, else they wouldn't now be removing the wallhack, and the recent email wouldn't need to say that they will remove problematic edits in the future.

Again, wrong.

It is only possible for an edit to user.cfg to be a exploit if PGI tells us to stop using it. If they simply remove it, it's never an exploit. It just a tuning change or whatever else you want to call it.

Again, it's your terminology that is wrong, not your intent. An exploit requires that you use something that is known to be unintended (whether you personally know it or not). Due to the chain of changes to editing user.cfg, that requires an explicit declaration from PGI. The recent wallhack edit is just an example of an edit that, after further consideration, they've decided to no longer allow.

They could have made it an exploit by saying "stop using this edit until we can patch it out," but they didn't. They just removed it.

[Tarogato]

Roadkill, on 03 December 2015 - 12:00 PM, said:

Wrong. What it proves is that PGI can change their minds and remove something that they'd previously allowed.

PGI removing something != that something is an exploit.

Something is not an exploit unless we know that it was unintended, because that is part of the definition of an exploit.

This is the problem you keep running into. You seem to think that players define exploits. We do not. PGI defines what is or is not an exploit.

PGI disabled all user.cfg edits. They then added back in limited functionality to editing user.cfg. The natural and in good faith interpretation of that action is that anything that can be edited in user.cfg is now allowed until such time as PGI tells us that it is not.

PGI has not done that. Ergo, editing user.cfg is not an exploit.


This is true, but only if PGI has said that something is an exploit.

In this case PGI has not said that anything is an exploit, so they are not exploits.


Again, wrong.

It is only possible for an edit to user.cfg to be a exploit if PGI tells us to stop using it. If they simply remove it, it's never an exploit. It just a tuning change or whatever else you want to call it.

Again, it's your terminology that is wrong, not your intent. An exploit requires that you use something that is known to be unintended (whether you personally know it or not). Due to the chain of changes to editing user.cfg, that requires an explicit declaration from PGI. The recent wallhack edit is just an example of an edit that, after further consideration, they've decided to no longer allow.

They could have made it an exploit by saying "stop using this edit until we can patch it out," but they didn't. They just removed it.

Again, we're failing to define exploit, so we shouldn't be using the word, and as such I would highly suggest people quit arguing over it.

You can exploit the weakness of the IS XL by taking out its side torso. You can exploit the weakness of a Wolverine and lob off its right arm. You can exploit the weakness of a DWF by getting behind it in your Locust. You can exploit invisible walls by tricking the enemy to waste an alpha into one and then poking out and shooting around it. You can exploit the hitboxes of a UAV to fire an artillery strike without line of sight. You can exploit the low graphics settings to be able to see through some walls due to low quality LoD models. You can exploit the high graphics settings by not being fooled into wasting alphas into invisible walls on low quality LoD models. You can exploit the brightness and gamma settings to increase your visibility on dark maps. You can exploit a user.cfg variable that can set building render distance to basically "never."

You can call anything an exploit if you want to. So what does it matter and why are you bickering about it? Find something more important to argue about. Like whether certain things should be allowed or not.

[Dagorlad13]

Mechwarrior Buddah, on 03 December 2015 - 10:28 AM, said:

Do you know every possible command that can be made in the cfg? Cause obviously the players do and the devs dont

and again... Im running this on a six year old rig, again, WITHOUT using the cfg. So if your rig cant handle this game, time to upgrade. Again, game security should trump this.

You can look up all of the Cryengine console commands on GOOGLE. PGI can turn most of these commands into options in the MWO options menu and lock any commands out that they don't want by making the user.cfg file inaccessible.

Edited by IronClaws, 07 December 2015 - 12:15 AM.