EternalDuelistSoul wrote:

Is there anyway to set this option without Options & Messages?

Yes: don't use control_freak.

Am I missing something obvious?

The only reason I can think of why you would enable it is because you don't want your players using macros (easily bypassed with many, MANY freeware macro programs out there) or you don't want players modifying/viewing the skin which is lame because nobody will ever want to access the skin unless you suck at designing one, in which case you might want to appreciate some help.

So yes, you are missing something obvious: don't use control_freak as it does more harm than good.

I should actually start selling t-shirts with the text "say no to control_freaks" along with some banner ads against the bloody thing. I hate it ever since Tom and Lummox JR decided that it should be added just to shut some people up, and that the best way to add it would be to make it an all-or-nothing approach.

I've only ever used it once, and that was in my Hostserver application. I wasn't concerned with people wanting to steal the skin nor was I concerned with macros; I only did it because it fell into the range of a BYOND utility rather than a BYOND game so I felt it could be useful to distinguish things.

I don't really think control_freak deserves as much negative attention as goto. It's a perfectly valid and useful feature, and personally saves me a lot of worry about potential exploits or bug abuse from players. Unless the game is designed for skin customization, or for custom macros, why would you ever want your players changing it? Especially problematic if you have a game feature which is a secret, for example, which utilizes a skin element in some fashion, and that secret is found unintentionally by someone sniffing through your skin file.

Kaioken wrote:

client/control_freak = 1 doesn't automagically prevent those. Thinking you don't have to worry about exploits and bugs because you have it enforced is basically using a silly excuse to do less work. You're only giving yourself a false pretense of security.

I'm well aware that control_freak isn't a magical exploit preventer or fixer. You don't need to assume so much. What I meant was that it prevents exploits or bugs that could come from the client modifying his skin, which could very well happen, depending on the game in question.

First of all, 'the game' is separate from the 'interface'...

When did I say they weren't? If the game is not designed for interface customization, there's almost no reason a player should have that option. That's all I was saying.

This problem is especially unassisted by control_freak. In this regard, it only attempts to prevent players from loading a customized skin file. It doesn't even attempt to prevent anyone from viewing your skin file. Anyone can still view it, without obstruction.

I poked around in my local BYOND folders (cache, Skins, Keyinfo, pretty much all of them) for a skin file to a game that was not hosted on my local machine, not downloadable, and had control_freak enabled. I could not find it. I'm not denying that it's there, somewhere, but I couldn't find it. Perhaps you could tell me where it is, exactly? I'm a little curious now.

Thankyou.

Mobius Evalon wrote:

Most of the playerbase has neither the determination nor the skill to do any of that. For the most part, simply disabling a button or removing the most obvious means is sufficient to convince them it can't be done.

That kind of thinking is too naive. In the first place, you shouldn't assume using an exploit is going to be as complex or time-consuming as you think. There could easily be cases when it can be done with a simple memory edit or using a simple specialized tool or program (e.g. Windows Enabler).
Then, something else you're overlooking is that even if doing X is complex and requires certain deep knowledge, once a single person does it and writes and publishes an automated tool and/or a tutorial, virtually any fool can do it.
This phenomenon and its results are observed very often in many fields.
"Most people don't have the skill to do that."
As if every person who uses a cracked version of an application, uses an exploit tool to fool or crash a program/server, even writes a game or extracts a file from an RSC archive (ahem) - etc - actually has the skill to do the same action unassisted (or "from scratch", if you will).

[...] Fear of macro abuse et al should be handled by the code and not simply rely on label A not being found by casual skin editing.

In other words, you agree with me.

The example you described does not really fall under the definition of "exploit or bug abuse". An example that fits it better is a player editing a skin file to make available an 'admin control panel' window which is hidden and has its elements disabled by default, then using it to control the game. The problem here is that the program doesn't actually validate the admin status of the user of the control panel (it just counts on that if the user can use it, he's an admin, as the panel is only made available to admins by the program). Instead of fixing this problem by adding admin validation checks to the source code, you can somewhat mask it by disallowing editing your skin file. But the same exploit still remains and can still be exploited in equivalent or different ways, so your game's security is still god-awful.

Of course, in the scenario you've presented, there are a number of scenarios where a player could cheat as effectively (or more) even if you attempt to disallow using an edited skin. For example, a macro program could be utilized to automatically "click" the buttons in rapid manner, regardless of position. These aren't unheard of and don't really require notable skill or knowledge to use, either.

Devourer Of Souls wrote:

Just off the top of my head, let's say I have a rather simple game, where the goal is to press two buttons in succession a certain number of times, faster than all of the other players.

I don't need to modify the skin in order to cheat. All I need to do is download Autohotkey and write a macro that clicks on the buttons for me, making me much faster than anyone who would edit the skin.

The design is flawed here; not the ability to modify the skin. The whole issue could be avoided if you'd place a delay on the pressing of the next button. Or if you time the fastest response humanely possible and punish those that don't fall in that range.

Well, they could do it a lot faster than they 'should' be able to now. And the ways to check to see if someone is cheating in this fashion are limited. First, you can check to see if the buttons are located at the x/y coordinates that they're supposed to. But doing so wouldn't prevent this method of cheating entirely, because it's as simple as resizing button 1 to be huge, so that the top and bottom edges of button 1 and 2 are almost touching.

You could create the window dynamically, which prevents the entire issue from occurring. Players can't alter the skin while it's already loaded, and you still don't need to enable control_freak.

So, then you would have to check the size of the buttons... or you would have to create the buttons at runtime. While there's nothing wrong with that, I find it a large amount of work compared to setting control_freak to 1.

Security by obscurity is not a good way to design your game. If all else fails I may still be able to send raw commands with packets, I can still get access to your resource file if I break the encryption and as I said I can still cheat with your buttons by using a macro tool like Autohotkey, which you nor control_freak have any control of.

If it were up to me control_freak would be removed. The concept of the feature is nice, but it turns out I do rely on those features being available sometimes. Truth be told I have no problems not being able to modify the skin if the skin is designed properly but I do have a big problem losing Options & Messages.

My suggestion therefore is the same complaint I had back when skins were first introduced: just remove the "edit skin" option from Options & Messages, but leave every other functionality intact. We don't need the ability to modify the skin of a game unless the author of said game is such a dunce that the skin sucks badly.

The only persons that should be making use of the edit skin feature are the developers producing the game, in which case a control_freak option only makes sense if it only blocks the ability to modify the skin and not everything else.

And hands off my user-defined macros; I like them and I should be the one making the decision if I want to disable my global macros for a game; not some 16-year-old quack that thinks it's going to somehow be safer.

Kaioken wrote: "... and your backend shouldn't be designed to conform to your interface, but the other way around."

I've heard this argument quite a bit. It's tiresome and just as much a cop out as the statements you're rebutting. Ultimate Jigsaw was designed so that they work in tandem. A custom interface wouldn't work unless the creator of the interface had intimate knowledge of the source.

Falacy wrote: "Parts of control_freak should absolutely be enabled in almost any release. However, various other parts of it are a completely worthless hindrance. And since control_freak is all or nothing (even though they've been claiming since it was first released that it would become more flexible) it pretty much screws itself over."

You may want to check out this fallacy, Falacy.