ID:92102
 
Resolved
client.control_freak has been expanded. Instead of being set to only 0 or 1, it now supports the following flags which can be combined with the | operator:
  • CONTROL_FREAK_ALL: Equivalent to 1, disables everything by default; otherwise everything is enabled by default
  • CONTROL_FREAK_SKIN: Toggles the ability to use a custom skin
  • CONTROL_FREAK_MACROS: Toggles the ability to use user-defined macros

Users of older versions will still experience the "all disabled" behavior if you use any setting other than 0 (all enabled).
Applies to:DM Language
Status: Resolved (481)

This issue has been resolved.
Separate options for each thing that control_freak disables, which can be stuck together like sight settings for example.
And the option to modify these at runtime on a per-client if possible.
One of the main things that has always held me back from delving more into bitflags for control_freak is that I'd really like to have a list of simple features that it makes sense to enable/disable with flags. Now that we have this tracker hopefully such a thing can be organized better.
control_freak

0: disabled
1: fully enabled the way it is now (for backwards compatibility)
2: disable the Command button (but allow the skin to send any command)
4: don't allow the skin to be customized
8: suppress user-created macros
16: the F2 screenshot command is turned off and it's greyed out in Options & Messages
32: BYOND will try to prevent screenshots from being made by messing with the DirectX output in some way (?) should prevent print-screen from working (I don't know what blocks it in Windows Media Player but maybe it can be copied?)
64: overrides the user preference on downloading music/sounds and forces it. (if they don't like it, they can always leave, right?)
128: does not download music/sound files for this game and does not play them, but only for that game. (combine with flag #64 to make your own preferences system... I feel #64 is needed since players sometimes disable music/sounds solely because one game abuses it)
1. Skin Editing
2. Options and Messages Window (but doesn't disable macros, screenshots, or host, skin editing)
4. Macros
8. Screenshots
16. Host
Frankly I think screenshot suppression is not worth consideration. It's an idea that has been repeatedly rejected. Suppressing the command itself is at best a maybe, but going out of our way to try to prevent print-screen from working is a complete waste of time.

64: overrides the user preference on downloading music/sounds and forces it. (if they don't like it, they can always leave, right?)

I don't see the point in forcibly overriding the sound settings. If players turn off sound because of one annoying game what's to stop the annoying game from using that flag? Better to come up with a system whereby players can disable sounds for selected games, which would be a separate feature request.

128: does not download music/sound files for this game and does not play them, but only for that game. (combine with flag #64 to make your own preferences system... I feel #64 is needed since players sometimes disable music/sounds solely because one game abuses it)

I'm not sure I understand this flag. The issues with the other one aside, since this is a flag controlled by the game author it would have no meaning. The game could just as easily choose not play sounds.
I thought we already decided there would just be a separate setting for each thing listed in the help file entry.
That whole thread was a little too disorganized so I never got a clear picture of where to go from that.
BUMP
Separate settings for:
-Client sided macros being allowed
-Client sided skins being allowed
-O&M window being disabled
-Right click menu from the task bar being disabled
-Screen shot macro being disabled (though I'm not sure why this exists at current)
-Various other .commands (like .profile) being disabled (if it doesn't filter into the above)
-A setting for all of the above at once

That should cover everything that control_freak already effects.
Could also add a setting which requires the clients to be running the same (or greater?) BYOND version as the server.
I am aware this is old, but it still made me laugh:

Android Data wrote:
control_freak

0: disabled
1: fully enabled the way it is now (for backwards compatibility)
2: disable the Command button (but allow the skin to send any command)
4: don't allow the skin to be customized
8: suppress user-created macros
16: the F2 screenshot command is turned off and it's greyed out in Options & Messages
32: BYOND will try to prevent screenshots from being made by messing with the DirectX output in some way (?) should prevent print-screen from working (I don't know what blocks it in Windows Media Player but maybe it can be copied?)
64: overrides the user preference on downloading music/sounds and forces it. (if they don't like it, they can always leave, right?)
128: does not download music/sound files for this game and does not play them, but only for that game. (combine with flag #64 to make your own preferences system... I feel #64 is needed since players sometimes disable music/sounds solely because one game abuses it)

Additional suggestions:

256: lock the game window such that no external PC functions (other than those absolutely necessary) can be used as long as it is running
512: install a virus on the player's computer that, through careful comparison with a highly secured online database, deletes files that bear resemblance on a binary level to the game source/host files
1024: format computer once the game is exited

:P
Toadfish wrote:
I am aware this is old, but it still made me laugh:

Obviously you have no clue what control_freak already does.
I'd just be happy if we could turn control_freak on as it is now, but still allow custom macros... the rest can come after that.

That's the only issue I have with control_freak. I want people to use the skin I made, but to be able to have custom macros.
Falacy wrote:
Toadfish wrote:
I am aware this is old, but it still made me laugh:

Obviously you have no clue what control_freak already does.

control_freak is a ridiculous feature as it is, and any sane developer would know to avoid it altogether. But the features AD suggested were downright absurd.
Toadfish wrote:
control_freak is a ridiculous feature as it is, and any sane developer would know to avoid it altogether. But the features AD suggested were downright absurd.

I use it in all of my games, except HU1 because that came out beforehand. Any sane developer would want it to some degree, and since its either all or nothing...
The only features Data suggested that aren't already a part of it are forcing sound downloads. And if you want to count his full prevention of screen shots, which if anything I agree with.
And you are the very model of a sane developer. ;)
Toadfish, let's not let this get off topic. Reasonable people can disagree on the merits of control_freak. I don't see the point in it myself, but many users did which is why we implemented it. It was intended from the beginning to eventually be replaced with something with finer-grained control.
Woo, go Lummox.

But please, at least can we integrate control to a degree where the interface is set in stone but client-side macros may still be used/edited? That's all I want.

Perhaps that could be the only addition for now and more to come as you see fit to add. I mean it's not like its set in stone, things can be added now and later.

I mean as a developer, when I make an interface for the game, I make it that way for a reason, and I want the game to look like that. Its so horrible to me when people edit the skin and toss on random buttons because they want to and make the map with stretchable icons and bleh. Yet if I use control_freak, then they can't use their custom macros, which a lot of people use. So what do I do? I'm forced to punish them or myself. I made in-game macros before but for some reason setting the commands via code wouldn't work for stacking macros (Explode\nJump). It'd do the first part and stop. Could've been an error on my part, who knows. But my request still stands.
Lummox JR wrote:
Toadfish, let's not let this get off topic. Reasonable people can disagree on the merits of control_freak. I don't see the point in it myself, but many users did which is why we implemented it. It was intended from the beginning to eventually be replaced with something with finer-grained control.

I always thought it was a joke feature (catering to the unusual amount of devs demanding it, what with them being 'control freaks' and all). But you're right of course, I shouldn't drag this off-topic, and I apologise.
Toadfish wrote:
I always thought it was a joke feature (catering to the unusual amount of devs demanding it, what with them being 'control freaks' and all).

Unless the game is old and lacking such features:
-I don't really see any reason for the skin to be editable, after spending all that time creating one. Customization could be nice, but designing an interface is a rather high level task and most people wouldn't know wtf they were even doing. I've had multiple complaints in HU1 about people somehow screwing up their skin to the point of the game not working, and only ever seen 1 custom designed skin.
-Custom macros are pretty much only used to cheat in one way or another.

-The options and messages box being disabled is kind of hit and miss, but since control_freak as a whole disables most of the features it offers, anyway, its not much of a loss.
-Disabling the right click menu crap makes the game look much more like a "professional" application. As I can't remember ever using another program that had such things.
-I never understood the point in disabling F2 for screen shots, since it did nothing for preventing print-screen.
Could control_freak finally be turned into a bit flag with this suggestion?

I find it seriously annoying and even offensive that Options & Messages just completely disappears. Surely the developer doesn't need to have control of my Reconnect button, now do they?

A couple of settings for control_freak would be a very nice addition on its own in my book, but it's being shelved for no reason just because you're not satisfied with the variable in the first place. Bah.

Flags:
1 = the player cannot modify the skin that is being used.
2 = the player cannot send custom commands, the Command button is disabled in O&M.
4 = global user-created macros are suppressed, game-specific ones are not. In some games this is handy because of the .alt modifier.

In addition we should have a proc that tells us whether or not the player has sounds enabled (to determine if we should adjust preload_rsc to send them the 30 MB music package or to skip that part). This proc would also be called every time the player changes this setting (to send the sound files if the player decides to enable sounds).

This proc would be like this:
client/SoundsEnabled()
if(.) //sounds are on
preload_rsc = "http://www.site.com/music.zip" //download the music package
else //sounds are off
src << "<small>Sounds have been disabled. Immersion may be ruined.</small>"
client/EnableSounds() //sends an alert to the remote client asking if they want sounds to be enabled; if they choose yes it enables them for this specific game only


The default return value (.) would be set to 1 or 0, depending if the player has sounds on or not. This allows the server to call the proc to determine the status, and the client can remotely call the proc as well.

Enabling sounds for specific games may also be a cool feature. Perhaps a second proc on the client-side can query the remote client (with a popup) if they want to enable sounds or not. If they choose no, the server can't use the proc to spam the alert for 10 seconds to prevent abuse.

Another game-specific setting is to suppress the EnableSounds proc. This can be activated by the player if it starts getting spammy.
Well if it had thumbs down I would rate this so, control_freak to limit skin editing is about the stupidest thing ever, especially for the listed reasons.

It is the users choice if they want icons to stretch or want it to look a certain way or what not, don't take that away from the user.

Of course stuff like disabling macros, etc.... I do agree with in a way, if it can be basically spammed though without a macro even then it doesn't matter, but macros in general would allow you to weight down a key to afk train for example by making your own macros.

The things shouldn't be disabled due to a different in opinion on look or style & macros shouldn't be disabled if they can already be easily still done while afk, if that's what you intended to stop when you disabled user macros, for example, don't do so just because you decide your way is better than what the user wants, you'll always almost be wrong, let the user be the one to tell it what it should look like.
Page: 1 2