control_freak variations in BYOND Discussion

Page: 1 2
ID:133259
 
Jan 3 2009, 9:16 pm (Edited on Jul 14 2009, 8:43 am)
Separate combine-able settings on control_freak for each of the following:

- User-defined macros may not be used.
- Only the world's skin or the default BYOND skin will be loaded, not a user-customized version.
- The Options & Messages window in Dream Seeker is inaccessible. It will only come up while first connecting to a remotely hosted world, or if a world takes a long time to load. The .options command will not make it appear.
- The menu items from Options & Messages are unavailable in Dream Seeker's system menu.
- The default F2 macro for the .screenshot command is turned off. The command is then only accessible through the skin you create.

It would also be nice to have the option to call the .commands on disabled features directly through code, like with .screenshot, but for .profile and such.

*accidentally deleted this post and had to rewrite it... there was a link on it to some other topic that is now lost forevarrrrr*
#1 Jan 4 2009, 5:34 am
Yeah. Having it use bit flags (similarly to the sight var) or even text strings in parameter-format instead of being boolean would do the job.
It'd also be nice if it could be modified dynamically at runtime, so you could only disable players' abilities for certain times (f.ex. for a certain activity). I can see at least one thing it disables though that probably wouldn't be possible to change at runtime, but it'd be nice if we could change the other limitations at runtime.
#2 Jan 4 2009, 11:50 am
That's all nice, but making us use default control set up will make laptop users have a hard time with games.
#3 Jan 4 2009, 12:50 pm
In response to Dpheonix7 (#2)
That kind of comment seems inappropriate on this topic given its context; this isn't a feature request for the feature you speak of (which is already in), but rather a request to control what is limited better; in effect it even helps counter the problem you've mentioned in a way. =P
#4 Jul 14 2009, 8:39 am
BUMP

Any word on this? Kaioken's suggested functionality should work nicely.
#5 Jul 14 2009, 9:01 am
In response to Falacy (#4)
It could also work if it was a list.
If certain values are in the list, k.
#6 Jul 14 2009, 11:22 am
In response to Falacy (#4)
Well, it's been planned for future versions for awhile. Or as we call it, it's on The List™.
#7 Sep 8 2009, 4:28 am
Bump. Any ETA on this? Seriously, is the delay on this feature because the initial control_freak is a hacky implementation or has this request been ignored/deferred solely because you guys didn't like to implement it in the first place.

I've just been in a BYOND game that has this turned on. Why? Because user-defined macros were interfering with the macros that the developer made.

It isn't the intention of this developer to disable everything, but he just wants the macros off so his custom macros don't interfere with whatever the user has set.

I don't see how difficult this change could be. The main programmer already expressed a dislike for this feature, and the name (control freak) already suggests all of upper management does too. I don't see the need to worry about backwards compatibility here; just make it a bunch of flags. Heck, combine a few things if you still don't like it, but I see no reason to defer this since it should be easy enough to change.

Heck, why not take this oppertunity to remove control_freak's ability to remove the Options & Messages window, or to prevent it from disabling its menu items? This feature was only requested anyway to prevent user-defined macros from being used or the skin to be changed.

Frankly if you ask me, only 3 flags should be necessary:
- Prevent user-defined macros from taking effect and disable the "Macros" command under "Client" in Options & Messages.
- Prevent the "Screenshot" command from working, and disable the ".screenshot" command.
- Prevent the skin from being modified.

All other features should be enabled by default and should not be influenced by the developer. The whole point of separating things like this is to give the developer freedom of choice, but a line has to be drawn. At the moment it's either one or the other; please give us some more control over these things.
#8 Sep 8 2009, 4:56 am
In response to Android Data (#7)
Android Data wrote:
I've just been in a BYOND game that has this turned on. Why? Because user-defined macros were interfering with the macros that the developer made.

That is a terrible reason.

"These macros will apply to all games if the corresponding keys are not in use."

With this knowledge in mind, the solution is tedious, yet rather simple. Make a macro set with every possible macro sent to a blank verb. Vioala! No user macros.
#9 Sep 8 2009, 5:03 am
In response to Hiro the Dragon King (#8)
Hiro the Dragon King wrote:
"These macros will apply to all games if the corresponding keys are not in use."
With this knowledge in mind, the solution is tedious, yet rather simple. Make a macro set with every possible macro sent to a blank verb. Vioala! No user macros.

Aside from that just being a ridiculous solution to begin with: http://www.byond.com/members/ BYONDHelp?command=view_tracker_issue&tracker_issue=537
#10 Sep 8 2009, 5:14 am
In response to Falacy (#9)
Falacy wrote:
Hiro the Dragon King wrote:
"These macros will apply to all games if the corresponding keys are not in use."
With this knowledge in mind, the solution is tedious, yet rather simple. Make a macro set with every possible macro sent to a blank verb. Vioala! No user macros.

Aside from that just being a ridiculous solution to begin with: http://www.byond.com/members/ BYONDHelp?command=view_tracker_issue&tracker_issue=537

Aside from that being ridiculous as well, I just tried it. Works for me. If I define a macro in game, it won't let me use the custom macro.

Edit: Is it more ridiculous a solution than locking people out of every option in your game?
#11 Sep 8 2009, 5:19 am
In response to Hiro the Dragon King (#10)
Hiro the Dragon King wrote:
Aside from that being ridiculous as well, I just tried it. Works for me. If I define a macro in game, it won't let me use the custom macro.

Yea, maybe they fixed it, though I never tested it before.

Edit: Is it more ridiculous a solution than locking people out of every option in your game?

Yes, considering most other things you'd want locked out as well. Do you know how many macros there are to block out? Let me know when you sit and tediously make 100+ blank macros in a template interface... though then again I'm not even sure if you can copy things from one interface to another.
#12 Sep 8 2009, 6:07 am
In response to Falacy (#11)
Falacy wrote:
Hiro the Dragon King wrote:
Aside from that being ridiculous as well, I just tried it. Works for me. If I define a macro in game, it won't let me use the custom macro.

Yea, maybe they fixed it, though I never tested it before.

Edit: Is it more ridiculous a solution than locking people out of every option in your game?

Yes, considering most other things you'd want locked out as well. Do you know how many macros there are to block out? Let me know when you sit and tediously make 100+ blank macros in a template interface... though then again

Some one should write it up and post it for others to use.

I'm not even sure if you can copy things from one interface to another.

That's what Notepad is for.
#13 Sep 8 2009, 6:45 am
In response to Hiro the Dragon King (#10)
Hiro the Dragon King wrote:
Edit: Is it more ridiculous a solution than locking people out of every option in your game?

Yes, it is, because frankly, I'm not going to spam the client with "... and now we're going to set the 'K' key to a blank macro ... and now we're going to set the 'L' key to a blank macro ..." and I can't be arsed to modify the template since that takes a lot of time as well. Furthermore, the guy said that his custom macros were leaking through despite setting his own macros (though I believe he did change them at runtime, which could have a difference in behavior?).

Note that even if I've done everything by the end, every time the client presses a button there'll be needless communication thanks to the blank verb. Hooray!

In any case the purpose of this post is not to whine about how stupid it is to lock people out of every option for the game, but to encourage Staff to give us the option to do things like this without locking people out of the game.
#14 Sep 8 2009, 7:16 am
In response to Android Data (#7)
Android Data wrote:
Bump. Any ETA on this? Seriously, is the delay on this feature because the initial control_freak is a hacky implementation or has this request been ignored/deferred solely because you guys didn't like to implement it in the first place.

I was actually just mentioning to Tom on Friday that one of the things I'd like to do at some point is get a list of the specific things users would want to lock out with control_freak so that can be expanded, since there have been several requests to do so. Most of the work is in mining the existing posts so I have an actual list of choices to work from. Most of the posts so far have been weak on specifics. Beyond that though, extending the var shouldn't be that hard at all.

Lummox JR
#15 Sep 8 2009, 7:37 am
In response to Lummox JR (#14)
Weak on specifics? The first 2 posts in this topic not only request the desired functionality, but suggest how its new implementation could be handled.
#16 Sep 8 2009, 7:44 am
In response to Falacy (#15)
Falacy wrote:
Weak on specifics? The first 2 posts in this topic not only request the desired functionality, but suggest how its new implementation could be handled.

Your first post in the thread is the only one I found with a list of possible things to cover. The second post, by Kaioken, has no specifics I can make out. But there have also been suggestions scattered abou in other threads, so it isn't just this one.

Lummox JR
#17 Sep 8 2009, 7:46 am
In response to Lummox JR (#16)
Lummox JR wrote:
Your first post in the thread is the only one I found with a list of possible things to cover. The second post, by Kaioken, has no specifics I can make out. But there have also been suggestions scattered abou in other threads, so it isn't just this one.

Kaioken suggested using Boolean like on the sight variable for each of the settings, or possibly a param string. He also mentioned having most of these settings mod-able at run-time.
And I had one of the other main threads linked from my original post, but as it says up there, I managed to lose that.
#18 Sep 8 2009, 7:49 am (Edited on Sep 8 2009, 8:07 am)
In response to Lummox JR (#14)
Lummox JR wrote:
Most of the work is in mining the existing posts so I have an actual list of choices to work from. Most of the posts so far have been weak on specifics. Beyond that though, extending the var shouldn't be that hard at all.

Flags:
- A flag to lock the skin. This makes the skin impossible to edit by the user, and possibly only stores it in the RAM so it can't even be read. (reason: preventing people from seeing which windows are in your skin. though if the skin sucks it can be annoying when it's on)
- A flag to prevent user-defined macros from taking effect in the game. The "Macros" command is blocked and any global macro definitions are ignored. Only game macros are accepted. (reason: some games use weird macros / lots of macros, some games want to it to help prevent cheating, consistency with the game manuals' list of defined macros) (+additional feature: retrieve a list of user-defined macros using winget?)
- A flag that hides the "Server" menu altogether.
- A flag that hides the "Reboot World" button in the Server menu (alternative: a winset instruction that allows you to define an in-game proc that Reboot World should instead re-route to. Reason: so the game can provide its own means for rebooting w/ countdowns and stuff while still allowing DreamDaemon to reboot instantly.)
- A flag to hide and prevent access to the .screenshot command (also hides the option in the menu).
- A flag to hide and prevent access Command button in the Client menu.
- A flag to prevent you from using the "View page source" command in browser elements. (Right now, you can only "Copy" or "Select all" when you right-click a browser element... I'd like to see the View page source command back so I can debug the browser locally.)

In addition to all of this, it would be nice if control_freak could be changed at runtime, at least in client/New() or at some stage before it. That way, users with administrative privileges could have a different control_freak than those without. (Developers can see the Server tab and View Page Source for example, normal players cannot.)

EDIT:
- A flag that determines if a joystick is required to play the game. If so, it activates joystick support on the client and activates special joystick macros (stick up, stick left, button 1-8, ...)
- A flag that says that joystick support is mandatory: those without a joystick cannot enter the game at all! (Unlike the flag above which simply says that joystick support should be enabled; a user can still reroute joystick stuff to their keyboard or mouse but some games may find this cheating)
- A flag that allows the host to determine public/private/invisible settings. If disabled, the host can only host the game in "public" mode (or perhaps whatever is set in world/visibility, provided this is altered to allow for 3 constants (PUBLIC,PRIVATE,INVISIBLE) rather than only true/false).
- A flag that allows the host to pick a port. If disabled, the host sees which port the game wants to run on (derived from world.recommended_port or world.desired_port) but cannot change the port. If the variable is set but the flag is not then it will recommend the port but not enforce it. (For RPG's that like to use dedicated servers with dedicated ports?)
- A flag that prevents hosting of the game at all. DreamDaemon refuses to host the file and under DreamSeeker the "Host..." option becomes unavailable. (For single-player games.)
- Prevent the progress bar or any notifications of (resource) downloads from appearing under Options & Messages. (Reason: I dunno. I found it in some post.)
- A flag that requires alpha transparency support. If it isn't available in hardware mode (some way of detecting this?) then switch to software mode automatically.

That's all I could find under BYOND Features.

EDIT #2:
Feature: Allowing hosts to make an "admin.txt" file is already possible, and by default this gives those listed access to the Reboot World & Profile World commands (where applicable).
Feature suggestion: Perhaps a control_freak parameters within admin.txt can set the control_freak variable for that particular key. Since this is all in the environment variables, BYOND can check it at a lower level than if it were soft-coded in client/New().

- A flag to prevent hosts from using the above method.
#19 Sep 8 2009, 8:15 am
In response to Falacy (#17)
Falacy wrote:
Kaioken suggested using Boolean like on the sight variable for each of the settings, or possibly a param string. He also mentioned having most of these settings mod-able at run-time.

Kaioken's post didn't actually have anything of use for me, because using bitflags was planned from the outset. There was never any question of how to extend the var, just of what the extensions should do.

Changing settings at runtime isn't something that has been planned for yet. I can't really see any reason such a feature would be helpful though.

Lummox JR
Page: 1 2