Denied Mechanical Prevention of Breaking FearRP While Cuffed.

[Emilia Foddg]

What does this suggestion change/add/remove:​

Implement a 323 SWEP-style system for attempting to mechanically enforce cuffed FearRP: The idea being that instead of where the 323 SWEP fills a meter that causes slowness and visual effects in affected players, this meter would instead disable the ability to break out of cuffs all the time it's filled past a certain threshold (The threshold in this case being past 0%, but you could experiment with something like 1% to give certain RP situations some wiggle room? Although that'd need a rule change and is likely not viable due to minges).

This meter would fill when the cuffed player is having a gun pointed at them in close-range (Testing & experimentation would need to be done to find the appropriate range at which this should happen - For example, take the hallway leading to the elevator to Floor 3, just from the door to the double lift doors; If you put someone in cuffs at one end and someone with a gun at the other, is that range reasonable? I actually can't parse this mentally for the life of me - I know you definitely shouldn't be able to do it from distances like across the other side of Lobby, from Garage doors to Main Gate or just from great distances along the map on Surface in general; But some situations get funky. It's ultimately up to Content and I'd imagine a reasonable distance for this can be easily determined). More players holding the cuffed player under gunpoint would ideally fill the meter faster.

The meter would then drain at a steady rate when the cuffed player is not having a gun pointed at them.

The meter should not fill under the following circumstances (Non-exhaustive):

• The cuffed player is an SCP - SCP cuffs are a slightly separate implementation anyway? Since it's a different SWEP under which the cuffs are not breakable without assistance. Not only that, but SCPs are immune to FearRP anyway - So there is no need to have something that could be exploited to potentially keep SCPs bound in situations where they should otherwise be able to escape (i.e. Another SCP shows up to try and free a cuffed SCP; This invariably results in guns being pointed around and having that apply to the cuffed SCP in this case not only doesn't make sense, but is also exploitable in an undesirable way).
  
  
• There should be a flag available to the Event Team to apply to any given player, with this flag active, the meter should not fill, for event purposes - I personally can't come up with an eventuality for it other than "The cuffed thing is an SCP or reality bender or w/e", there's probably a few event scenarios where you'd need someone to break out of cuffs while under gunpoint, that may need to apply to jobs over than the Event Role (It could even be as a result of something conferred to someone on a normal job role, as part of an event scenario).
  
  
• EDIT: The only person pointing a gun at you is actively trying to break you out.

In the interest of preventing them from trying to game the system (And tbh, they shouldn't be trying to break cuffs while under FearRP anyway) this meter should not be visible to the cuffed player.

EDIT 2: Another option here is to only apply this to D-Class, especially considering upcoming changes to first-time players on the server - For reasons outlined in positive point #2.

EDIT 3: The above may also potentially serve as a nerf to D-Class gameplay in some respects, which itself is a double-edged consideration with both good and bad points to it.

EDIT 4: If deemed necessary in light of the further discussion on this topic had in this thread, this mechanic wouldn't have to necessarily outright disable breaking out of cuffs - It could just make it more difficult to do so. This could provide reasonable leeway to edge cases while improving enforcement of FearRP.

Has something similar been suggested before? If so, why is your suggestion different?:
A presently active suggestion from Wulfric asks for stricter FearRP enforcement via a rules change. Under the initial mistaken impression that it was a content suggestion, I replied to that in confusion at the lack of an actual, tangible prevention method, suggesting the changes outlined in this suggestion.

In particular, a lot of their issues don't really make sense and/or won't be solved by what they propose. For instance:

for example when arresting/kidnapping some people they will try to break out of cuffs the instant you turn away to open a door or such, this is really stupid as them turning away for a split second isn't much of a reason for them to no longer be under fearRP especially since if they turn back around they could very easily kill them before they break out.

I don't see how their suggested rule changes will prevent behaviours like this that, under the current rules, already breaks FearRP and would be punished as such in a sit. Their proposed changes just seem to make things more complicated for both staff and players alike.

Obviously this suggestion is different, because it attempts to resolve the problem by preventing it via game mechanics and not ruleplay.

Possible Positives of the suggestion (At least 2):​

• Less annoyance & tedium when arresting/kidnapping players.
  
  
• (Hopefully) More strongly instils the idea to newer players that you shouldn't try to break out of cuffs while under FearRP -
  Spoiler: Further Elaboration

  Yes, new players should be properly learning the way the server works and such; But in this case... Generally people's eyes tend to glaze over at long , important walls of text that yes, you should generally be reading all of if you want to be properly engaging with it, such as any of my suggestions or the server rules - And on top of that, if you give players the option to do something, they'll certainly do it unusually just because they can. You could argue that anyone with that mentality would probably find themselves in trouble in a different way, but that's not really a valid excuse to not clamp down on something that players aren't even allowed to do in the first place. Additionally, in the majority of cases where D-Class break FearRP, it's not really taken to a sit, the D-Class is just immediately killed. Which I understand favours the RP more (As you don't want to constantly be interrupting everything by calling sits just to be like "Yeah, you broke FearRP, don't do that, here's a warning" every few minutes), but in doing so, carries the inherent risk of that player mistakenly learning early on that "It's ok to break FearRP" (Because there was ultimately no consequence for doing so) and potentially carrying that mentality into later roles/positions where retaining that erroneous mentality would be both detrimental to them and the RP they get involved in.
  

  [...] the onus is on the player to make sure that they're properly informed [...] My reasoning here is more to do with trying to properly integrate new players into the server environment, generally speaking, when you join a server like this for the first time, you're checking it out and wanting it to sufficiently draw you in before you start dedicating any of your time and/or money to it; Think about this from the perspective of a new player: You've found a server that potentially interests you, so you join it and your literal first expectation is to read a big block of rules (which yes, is shorter than it used to be), note here that I'm not trying to justify not reading the rules or otherwise provide a reasonable excuse to break them, I personally think that being wilfully ignorant of the rules is not particularly acceptable when you break them (But I can understand not being able to recall every single one at all times, although that itself should not be a free pass to get away with something really bad).
  
  Essentially what I'm trying to say is that they'll not read the rules anyway, which isn't something that should be encouraged or facilitated, but rather mitigated - So therefore it's in the interest of maintaining healthy server growth and population to try and... I guess spoonfeed to new players a little? I feel like that's the wrong way to put it, but I hope you can understand what I mean. It's not like we don't already have these kind of... Guard rails? Training wheels? For D-class already, such as preventing them from using certain things in their inventory; And even though both that and what this suggestion asks share a commonality in terms of "This makes sense for it to be a thing for them not to be able to do," we do end up back at the whole issue of disruptiveness.

  
  
• If the game is enforcing cuffed FearRP in staff's stead, then less sits would need to be called in relation and staff can be freed up for other purposes.
  
  
  • This also means that cuffed FearRP is more enforceable during lower population hours where there may not be as many staff members on to handle a sit - Granted, anyone who tries to 'game' the time of day to abuse lack of staff presence to do things like break FearRP I imagine will still get punished anyways (And probably even more severely for deliberately trying to avoid punishment), but generally if there's a reasonable, feasible way to crack down on this and ensure potential rulebreakers feel less emboldened, there's no real reason not to take it.

Possible Negatives of the suggestion:​

• Potential issues with the mechanic being overly obstructive where it shouldn't be, in ways detrimental to RP - Yeah, this is going to have teething problems unless the majority of use cases are thoroughly tested before adding it to the server proper; This is not an overnight implementation.
  
  
• The development effort that it would take to implement this properly would not be worth it, what we have presently is fine - I can understand this reasoning. This would require (potentially extensive?) changes to cuffs and probably also VGuns? This is not a small or simple implementation by any means and I can get that it might seem overengineered and needless levels of effort for a problem that's... Kind of already solved? I'm just putting forward that we may be able to solve it better. But I can see how this might be unnecessarily reinventing the wheel.
  
  
• Massive risks of bugs which would be massively detrimental to RP - An example that comes to mind is the system not letting people break out when they should otherwise be allowed, which could be exploited to unfairly benefit kidnap RP.
  
  
• Potential abuse of the Event flag - Honestly, the GM team are usually good with handling these kinds of things, but the possibility is not zero. It could be that this functionality is something restricted to specific GM/Staff ranks and its use is requested where appropriate. That would reasonably limit this potential.
  
  
• Overreliance on this functionality.

Based on the Positives & Negatives, why should this suggestion be accepted:​

I don't particularly feel much for this idea, I'm just mostly mad that the other suggestion is a rule suggestion, so I decided to make a better one that tries to actually solve the problem they had.

Now if I had a penny for every time someone tried to solve an issue with ruleplay when there are perfectly reasonable ways to solve them with content changes...

 

[Skinner]

Can you please elaborate further on this?

...Because from my perspective, it's not clear here whether you share any of the concerns I outline about the functionality of this and ways in which it could potentially interfere with normal server play (Or if it'd just be too hard to implement), or if you just want to break FearRP. Maybe it looks that way to just me, I don't know. But I genuinely don't get this mass -Support.

Also,
-Support
I want to break FearRP.

A mechanical method of displaying FearRP is not the method to countering it... It sounds too harsh and could very easily be exploited just from the mere title of this change

 

[Emilia Foddg]

A mechanical method of displaying FearRP is not the method to countering it... It sounds too harsh and could very easily be exploited

See my argument to Sceptre on this.

just from the mere title of this change

Judging books by covers, are we?

 

[Bananolas]

-Support
I dont think this is needed because staff most times can solve this issue and second seems like a over complicated solution to something small.

 

[Skinner]

See my argument to Sceptre on this.

Judging books by covers, are we?

If game mechanics aren't the solution, ruleplay isn't the solution and neither is properly informing the playerbase (all which in themselves are something of monumental, if not impossible tasks to accomplish sufficiently), then that leaves nothing else. That covers every conceivable direction from which this can be approached. No solution to this that does not fall under any of those three umbrellas can be ideated, nor implemented.

I don't see reason to argue with this, there is no current need for FearRP to undergo any sort of change as it is handled correctly by 90% of the playerbase. A mechanical method of restraining people from breaking out with fear neutralises the standpoint of "roleplay" in FearRP and turns it into a method of captive which people can abuse if they simply get their hands on you with elastics - it just doesn't sound right at all, and the title is here to be judged like this suggestion, which I've taken time to read.

Why would staff need such a thing too? It's very obvious that yes, staff handle sits very often about this recurring issue, but it's part of their voluntary work; and their demise falls to handling players whom can't read the rules, or make the mistake of not understanding what FearRP/NVL is. If you begin introducing an automated, forceful system node to a roleplay action that was previously used by the playerbase with little to no issues; instead of teaching players HOW to roleplay out FearRP and how to keep someone calm and composed so as to not have them break out - it will only cause more issues in my opinion.

A reminder that we are on a public server, and not 2026 Site-9; so roleplay expectations for things like FearRP cannot be perfect from all players. If you wanna do something right about FearRP, call a sit on those who broke the rule infront of you, it takes an AOD 3 minutes to deal with a fearrp sit. The simple solution is to not change anything, but keep the staff team informed to deal with FearRP rather than try and take an easy way out.

Then again, CT will probably deny this; and take field notes for the future on this problem, so it's safe to say you looking out gives them a piece of mind about this "common" issue which does require a fix yes but not necessarily an urgent one at the present time.

 

[Emilia Foddg]

staff most times can solve this issue and second seems like a over complicated solution to something small.

I don't see reason to argue with this, there is no current need for FearRP to undergo any sort of change as it is handled correctly by 90% of the playerbase. A mechanical method of restraining people from breaking out with fear neutralises the standpoint of "roleplay" in FearRP and turns it into a method of captive which people can abuse if they simply get their hands on you with elastics - it just doesn't sound right at all,
[...]
It's very obvious that yes, staff handle sits very often about this recurring issue, but it's part of their voluntary work; and their demise falls to handling players whom can't read the rules, or make the mistake of not understanding what FearRP/NVL is.
[...]
it will only cause more issues in my opinion.

I can agree with this - I do state in the OP that I recognise the level of unnecessariness with the premise and I acknowledge the level of frivolity involved, although this makes me curious about the specific scenario(s) that would make someone want to produce a rules suggestion on the matter. When considering these things, I feel like the relative miniscule scale of this issue makes it difficult to reconcile grievances with potential resolutions, as solutions like rule suggestions or what I've presented here definitely feel overkill -

for example when arresting/kidnapping some people they will try to break out of cuffs the instant you turn away to open a door or such, this is really stupid as them turning away for a split second isn't much of a reason for them to no longer be under fearRP especially since if they turn back around they could very easily kill them before they break out.

But at the same time, if I envision the circumstance in which this takes place, if I were a GenSec escorting a test and the offender is a D-Class (who could potentially be new to the server), I definitely feel that "sit feels overly frivolous/time-wasting for all involved" deal.

If you wanna do something right about FearRP, call a sit on those who broke the rule infront of you, it takes an AOD 3 minutes to deal with a fearrp sit.

And I imagine for most GenSec players in the circumstance I give above (especially on the newer side - Which itself is its own concern if new players that aren't properly learning about FearRP in the way I've been saying then move onto GenSec and potentially apply any misconceptions there), as I've said, they'll just... Not take it to a sit. Which I acknowledge is pretty irresponsible of them in terms of things like proper FearRP enforcement and of course, feeding into the cycle that I describe here - But also is just... Like, it's petty. You know? Like yes, it's the right thing to do, but you can understand what I mean here, right? Imagine just hopping on GenSec and then obsequiously, pedantically and hall-monitoringly calling a sit for every single time a D-Class breaks FearRP when you have them cuffed.

Overall with this, I personally don't know how to reconcile this issue and as a result I think the point you make here is neither right nor wrong - It's conditional and I think there's greater nuance to this that I am trying to elaborate on, which you are collapsing - Not incorrectly, as this is pretty specific and again, petty to a not-insiginificant extent.

A mechanical method of restraining people from breaking out with fear neutralises the standpoint of "roleplay" in FearRP and turns it into a method of captive which people can abuse if they simply get their hands on you with elastics - it just doesn't sound right at all, and the title is here to be judged like this suggestion, which I've taken time to read.
[...]
an automated, forceful system node to a roleplay action
[...]
HOW to roleplay out FearRP
[...]
roleplay expectations for things like FearRP [..]

This line of argumentation made me realise something.
FearRP is not roleplay.
Why do I say this?

1.04 FearRP - FearRP stands for "Fear Roleplay". This is simulating being afraid for your life and the lives of others in a situation that would realistically require it in the real world for an average person in your job. Actions you take must reflect this, where possible.

Spoiler: Examples of FearRP

• When you are unarmed and at gunpoint, no matter the number of aggressors.
• If you are armed but are being surrounded and are at a disadvantage by aggressors.
• If you are stripped, handcuffed, or restrained, FearRP still applies, no matter the number of aggressors.
• Purposefully expose yourself to virulent SCPs (008, 049, 409) unless ordered to at gunpoint by CI, Foundation, or the GOC (within the server rules)

1.04(a) FearRP Exceptions - Orange Suits and reality benders may not be FearRP'ed, unless they are under restraints.

Follow my train of thought here:
The normal idea of roleplay carries the general connotations that a given situation will go one way or another, the flow of which is determined by how the players act out the present situation, based on what kind of character they're playing at the time. There are two major things which define the roleplay - The nuances of the character being played and their then-current role in the scenario. Even though you can argue that there is leeway in how you can say, 'resist' in the kinds of controlled scenario where FearRP applies, FearRP is the explicit rule that in these applicable situations, you must be fearful for your life (and/or the lives of others), which is something we apply as a rule, even in situations where it may not make sense.

Consider the following (IMO, decently feasible) RP scenario (that would remain the same after the change proposed by this suggestion):

1. GenSec tries to extract a D-Class from D-Block as requested by a Researcher for a test.
   
   
2. D-Class goes through the airlock and is held under gunpoint by GenSec - Said D-Class, as a hardened criminal who has done some fucked up things, loudly states that they don't give a shit whether they live or die and just wants [the GenSec] to die, violently resists despite being under gunpoint.
   
   
3. Dies.

This is a scenario that in this situation, with the given characters and roles being played, would make sense to be a thing that happens. D-Class, generally speaking, are not all nice people. They're death row inmates. Of course you're going to get one like this every now and then. It wouldn't make sense for all of them to be like this and it'd be unfair to just only randomly let some people do it and not others (on the same job, obviously there's exceptions like TB and GM events), which is not only why we have restrictions on riots, but also ultimately... Why this breaks FearRP, despite it being, in the way that I have presented it here, a reasonable series of events within normal roleplay context, outside of these concerns.

Even as Jonas said:

the entire reason you are under fear rp is because you are in fear for your life. if you get shot without any explanation like in an interrogation, you reasonably would assume that you are dead if you dont break out and dead if you do might aswell try and escape. I know for a fact If I was shot for no reason and wasnt dead id try and break out better to try and escape no?

Now that I think about this aspect, even though yes, in the situation, you are actively being attacked and dying - Even if it makes sense now that in being fearful for your life, you resist with the explicit purpose of trying to not die, by trying to break out while bound, while unarmed and under gunpoint, I think it would be ruled that you are breaking FearRP in this circumstance. Even though it makes complete sense in that situation.

Maybe this seems overly rules-lawyery at that point, but... I think we're operating under a major misconception about what exactly FearRP is, in the way that we've defined it. This might be overly philosophical (when am I not?) but when I boil it down, I think of roleplay as what the scenario is, how it's driven and where it can go. I think of ruleplay as what restricts the scenario and what isn't allowed. In this sense, I think FearRP is more ruleplay than it is roleplay.

That's not necessarily a bad thing - And neither is ruleplay in general honestly, FailRP is a good, explicit example of beneficial ruleplay, the chief distinction being that there are considerably less contexts that potentially justify something that could be FailRP - And there are a significant amount of mechanical restrictions already in place that prevent things that would be FailRP were they not prevented (For example, even though this isn't the primary purpose of containment blockers, they prevent a situation where a a researcher could just randomly let 457 out). The problem people have with ruleplay is when it creates restrictions that don't really make sense, which... Also seems to be the primary gripe about this, the chief distinction being that this is forced, rather than something imposed via a sit and a staff decision.

A reminder that we are on a public server, and not 2026 Site-9; so roleplay expectations for things like FearRP cannot be perfect from all players.

I agree that we shouldn't have unnecessarily high standards, but I also don't think this is a reasonable excuse to have low standards either. I do also agree that we can't have high roleplay expectations from all players either, which is why I proposed the alternative idea of applying this only to D-Class so that new players can at least properly learn how FearRP applies in the appropriate, applicable situations - And hopefully improve the way in which new players learn how the server works? While also mitigating the vicious cycle I raised earlier.

The simple solution is to not change anything, but keep the staff team informed to deal with FearRP rather than try and take an easy way out.

Not changing anything is the simple solution - But... That applies to everything, doesn't it? I mean, this isn't really equivalent to "Not needed" because even though that and "Not needed" conveys the same premise, sometimes it is just better to not make a change than to do so in the first place (The whole thirdperson debacle comes to mind, but to my recollection that wasn't meant to go out anyway and was deployed by accident - In fact now that I think, there are a lot of parallels to draw between this and the no thirdperson during codes problem), although I guess that may also be the intent of "Not needed" too, now that I think about it (IMO this is never really clear when it's used), but I won't deny that that's potentially the case here, but I respectfully disagree that when it comes to this issue not changing anything is preferable to changing anything - I think that if there is merit to either this idea or something that this could inspire, then it's worth exploring if any benefits are greater than their deficits and are worth the development effort.

Then again, CT will probably deny this; and take field notes for the future on this problem, so it's safe to say you looking out gives them a piece of mind about this "common" issue which does require a fix yes but not necessarily an urgent one at the present time.

I agree.

 

[Tay]

Suggestion Denied​

---

Hi @Emilia Foddg,

Thanks for taking the time to make a server suggestion.
The Content Team has chosen to deny your suggestion due to the following reasons.

We believe this suggestion isn't needed as it could interfere with RP due to its restrictiveness, and the development effort required would be better spent elsewhere, especially due to the high risk of bugs and/or breakages.


Your suggestion will now be locked and marked as denied.​