Denied SCP Bodyblocking Prevention Changes

[Zen]

What does this suggestion change/add/remove:

• SCPs should always collide with each other for their full model and hitbox, and it shouldn't be possible for anyone to (accidentally or purposefully) hide inside another SCP. This mainly applies to 682, where human-sized SCPs can easily hide inside of it and be unable to be hit while breaching it.
• The containment borders that prevent an SCP from leaving when not breached should leave a big enough gap that humans can get in past the SCP in the cell, and they physically cannot be in the doorway enough to bodyblock them. E.g. the HCZ non-spec cells allow the SCPs to go a little bit out of their cell door - this should be effectively inverted, and there should be a gap inside of their cell door that they cannot enter, so that containment units can get in to attack the breacher SCP without the contained SCP possibly blocking it.

Has something similar been suggested before? If so, why is your suggestion different?:Not that I can find. It's already against the rules, but these changes would make it physically impossible in certain (common) ways.

Possible Positives of the suggestion (At least 2):

It would reduce SCP bodyblocking incidents a lot.
It would improve realism (not allowing SCPs clipping into each other).
It would reduce staff workload dealing with bodyblocking sits, which can be complicated as they usually require video evidence.

Possible Negatives of the suggestion:
SCPs can't come too close to the door, reducing their active space when contained.

Dev/configuration work required.

Based on the Positives & Negatives, why should this suggestion be accepted:
It would remove the possibility of a recently very common issue that can lead to fail breaches (which heavily affect RP).

 

[Giudon]

-Support
On the suggestion, you stated "SCPs should always collide with each other for their full model and hitbox"
then on the positives, you stated "It would reduce SCP bodyblocking incidents a lot."

682's hitbox has been decreased because of how janky he was. do you really expect that they'll increase it?

 

[Zen]

For that specific one, I mean SCPs should always collide with each other, not necessarily with all other players. The collision jank with 682 shouldn't really be an issue between SCPs, or at least not as much as it has been with it and the environment and it and humans dragging it while cuffed.

 

[Playdoughzombie]

-Support
Cope, you have grenades for a reason, you also have a chatbox you can use to type "@there is an scp bodyblocking" also over half of the scos in non spec are terminable, terminable scps are allowed to block doors, so once again COPE.

 

[Zen]

The changes to containment blockers can be case-by-case if necessary. 082 is immortal, so definitely shouldn't be able to be in the doorway when contained, and TGs often bodyblock the door and then shoot at us when we inevitably hit them at all, so probably also shouldn't be able to be in the doorway. 9000 honestly not really an issue.

Grenades are also not a useful tactic in this kind of situation, as they have limited damage and range, and also don't do anything to prevent the breach from continuing. It's also against the rules in the first place, so we should never need to use in-character solutions for it.

Breaches like this are also very time critical and often don't get a moderator response quick enough before the SCP is already breached, which heavily affects RP.

I'm not entirely sure why you're being toxic about a simple change like this that only enforces existing server rules.

 

[Bill Nye The Guy]

pretty sure it's a source limitation that prevents playermodels from irregular shapes

 

[Painter]

+support

Only about the containment blocker thinking, having 082 sit in his doorway and kill anyone that enters with someone like 8837 breaches him goes hard, and don’t tell me “grenades” cause 2 handgrenades that do 70 damage to a SCP directly under their feet is gonna kill em.

 

[TripTrap]

Suggestion Denied

---

Hi @Zen,

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

After taking your suggestion into account, we came to the conclusion that this is not something that we can really fix, we also decided that this comes as a limitation to the source engine.

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