ID:132502
 
When 'control_freak' is used, players cannot see Options & Messages. This also means they can't get to the tick boxes to download sounds (for example).

Is there anyway to set this option without Options & Messages? It's caused a bit of frustration with players having sounds off and trying to re-enable it. They have to open another game (without skin restrictions) before they can change the option.

Am I missing something obvious?
BYOND Client > File > Preferences > Games tab
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.
In response to Android Data (#2)
It's nice for single player games, especially those that may be distributed outside of BYOND. Such options would likely confuse non-BYOND users.
In response to Android Data (#2)
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.
In response to Devourer Of Souls (#4)
Devourer Of Souls wrote:
I don't really think control_freak deserves as much negative attention as goto. It's a perfectly valid and useful feature, [...]

While this is potentially debatable, you start going undeniably downhill from here.

and personally saves me a lot of worry about potential exploits or bug abuse from players.

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.
All control_freak = 1 does is make some of the client program's features inaccessible. People can still mess with your server by other means - not to mention there are ways they can forcibly re-enable the disabled features (the client program, Dream Seeker, is running on their computer and hence is under their control).

Unless the game is designed for skin customization, or for custom macros, why would you ever want your players changing it?

First of all, 'the game' is separate from the 'interface'... and your backend shouldn't be designed to conform to your interface, but the other way around.
Second, again, this feature doesn't entirely prevent everyone from using macros or customized skins or their likeness, or using equivalent external means.
Your backend is what you should concentrate on making secure. Making the interface part secure is, in comparison, a mere bonus.
Above, you can also swap "backend" with "server" and "interface" with "client".

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.

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.
Like the resource archive (.rsc), the interface file (.dmf) of the world is stored locally in BYOND's user folder.

Note that you can solve this problem by not including the interface elements related to your secret in the interface file -- you can create those at runtime, instead.
In response to Kaioken (#5)
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.
In response to Kaioken (#5)
Kaioken wrote:
All control_freak = 1 does is make some of the client program's features inaccessible. People can still mess with your server by other means - not to mention there are ways they can forcibly re-enable the disabled features (the client program, Dream Seeker, is running on their computer and hence is under their control).

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.

I personally don't think control_freak is all that useful. 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 response to DarkCampainger (#1)
Thankyou.
In response to Devourer Of Souls (#6)
Devourer Of Souls wrote:
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.

Hence I corrected you, as this shows incomplete or otherwise flawed understanding. It doesn't prevent exploits because they don't come a player modifying their skin, they come from bugs in your program's code which need to be fixed rather than partly worked-around.

When did I say they weren't?

When did I say you said they weren't? ;) I was conveying a concept to you.
Besides, my reply there was rather clearly not centered on exactly what you said, but on the general matter discussed throughout all of my post.

Perhaps you could tell me where it is, exactly?

Resources of games you've played are stored in your cache\byond.rsc file.
In response to Mobius Evalon (#7)
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.
In response to Kaioken (#9)
Kaioken wrote:
Hence I corrected you, as this shows incomplete or otherwise flawed understanding. It doesn't prevent exploits because they don't come a player modifying their skin, they come from bugs in your program's code which need to be fixed rather than partly worked-around.

I don't think I'm the one misunderstanding, because I'm talking about exploits that come directly from the client modifying their skin. control_freak does prevent some form of exploit with interfaces much more simply than without it. 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.

The buttons are in part of an interface window, like so:


I made the distance rather minimal so the image would be forum friendly in size, but you can imagine those two buttons a little further away in 'reality'. It would take a little bit of time for someone to do this normally, but if a player were to modify their skin like so...


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.

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.

When did I say you said they weren't? ;) I was conveying a concept to you.

Well, you pretty much implied that I did, based on how you were putting quotation marks around words.
In response to Devourer Of Souls (#11)
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.
In response to Android Data (#2)
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.
In response to Devourer Of Souls (#11)
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.
In response to Android Data (#14)
The only problem I see with someone trying to use Autohotkey for macros, is the fact that they probably have no clue as to the name of the verb that needs to be parsed in order to carry out a specific command. Without that info, being able to edit or use macro's is kind of useless at best.

In my opinion, trying to kill user creativity is dumb. Look at Blizzard and what they've done with WoW. They let players upload their own interfaces, edit macro's, set up mini programs in game to aid the client, and more. None of that hurts actual gameplay, so why bother protecting against it. These type of player edits make the game interface and experience more dynamic, and more acclimated to the users needs and wants. If a player feels "Comfortable" playing your game, they're likely to play it for longer.
In response to Kaioken (#5)
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.
In response to Hiro the Dragon King (#16)
I agree with that.
A custom interface is as much coding as it is design.
In response to Falacy (#13)
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.