Donator
What does this suggestion change/add/remove:
This suggestion seeks to increase the granularity of bind functionality. The only real situational adjustment for binds we have right now is that we can just blanket toggle them all on or off.Ideally, what would be nice if we could just specify in some way, a list of which jobs a particular bind could be active for; So when you press that bind's button, the bind first checks that the job you're on matches one in that job list (if the job list is not empty. if the job list is empty, then it ignores the check and triggers anyway) - If so, then it triggers the bind.
In my opinion, it would be nice to also have toggles for each bind in addition a blanket on-off for every bind. Although that would be less useful than the above and be potentially a little pointless/unnecessarily complicated.
Has something similar been suggested before? If so, why is your suggestion different?:
Only similar suggestion to this is an active suggestion from the past week by Geronimo, to prevent non-essential personnel from using panic button-type binds. This is something I had planned to suggest anyway, but is ultimately an alternative solution to the problem they are posing, as well as being aimed at other problems.Possible Positives of the suggestion (At least 2):
-
There's a few scenarios that this would apply - But I think most importantly I should bring up /me shows Site Admin/Affairs ID. As things are right now, only certain jobs are allowed to use this, those being ISD, Site Admin, Site Command, Ambassadors, the DoIA and more recently, the DoEA (and I think both deputies? I know at least the deputy DoEA can). Having the ability to only limit that to the specific jobs you have that can do that would prevent circumstances where it's accidentally used, i.e. You normally play a lot of any of the above jobs, but you flag on another for whatever reason and habit/muscle memory kicks in when ID checked - That or you just hit it by accident. Potential for less accidental powergaming, I guess??? But you get the general idea that it could be less accidental - Another notable circumstance could be binds for opposing GOIs, let's say you play both Foundation and CI. You kinda don't want to accidentally use any one faction-specific bind while on the other. I can't imagine what faction-specific bind you might have, the only thing that comes to kind is opening comms between CI and F. That's probably not something you want to accidentally hit as a Sr. Researcher.
-
Restricting a bind to only work for certain jobs means you could possibly have multiple things bound to the same button, all set to different jobs and it would only trigger whichever bind matches a job you're currently on. Which then means you can have what is basically a single, universal panic button that could be different for whatever job you're on.
-
Being able to set binds for specific jobs would allow for RP-specific binds, like for things like basic tech expert maintenance RP or medical RP.
Possible Negatives of the suggestion:
-
This could just be too hard to do or not even possible, I wouldn't blame you - This is asking for an overhaul to a very old UI element, with UX concerns. And like, how would we specify the jobs for each bind? String list (which has to be accurate enough to get a match for the bind to work)? Series of drop-downs (which would either just be limited/obtrusive)? And then we partial search what job we currently are, against that list. Like, the logic of how it should function is simple, but actually putting it into the UI system, in a way that would work might just not be doable.
-
Binds as they are already confuse a bunch of people, so adding this to it might make it worse - We do have community support for this, but... Yeah.
-
It's possible that not enough people would use this feature of binds to warrant its implementation.
- Binds list could get too big, unwieldy, hard to edit.
Based on the Positives & Negatives, why should this suggestion be accepted:
This would make binds more useful and make it harder to hit the wrong bind if you're not on the right job for whatever bind it is. There is also the concern of the upcoming Site Admin ID SWEP implementation making the point about Site Admin/Affairs ID binds moot; However, this has more uses than that and it can at least help with that, in the way that I wrote, until the SWEP's eventual implementation
Last edited:
Community Sup.
Group Moderator
Junior Developer
Programming Team
Trial Game Master
