Veesus

Everyone else remembers these things being able to 2 shot being a bad thing right? Or is that just me -Support

Any competent branch head would just tell you the reasoning behind their changes if you asked, no need to make it mandatory. -support

The doors would not be any more glitchy with a lower delay. They're base source engine entities and are one of the most stable entities on the server. I've implemented this change in LUA and it works fine in multiplayer. The delay that's currently on them is basically an arbitrary number chosen by the map developer, and isn't linked to the opening and closing time in really any way.

TL;DR, make doors more responsive by removing the delay after a door finishes opening/closing Background: Anyone who has played on SCP RP for any length of time is familiar with the classic level 0 sliding door permeating the site. Those who have played a little longer would be familiar with how god damn slow they operate. These doors will sit idle for around 2 seconds after finishing their closing or opening animation, eating precious seconds of finite human life every time. This makes doors clunky and not that fun to interact with, which is a problem, as a good portion of SCP RP gameplay is opening and closing doors. This unfortunate quality of doors is not one with much intent behind it, but a simple consequence of the reset time on the button, which is set with no regard for the actual time the door takes to open and close (reset time is typically a flat 3 seconds, while doors only take 1.5 to cycle their animation) Suggestion: My suggestion to remedy the problem laid above is simple: Make doors more responsive. This would be achieved by setting the base reset time on buttons to be equal to their associated doors animation time. Any additional delay would be added as a flat time on top of this, although an additional delay is not necessary. This could be achieved through code without the need for any changes to the map. Consequences and Concerns: As previously mentioned, a large portion of SCP RP gameplay is opening and closing doors, therefore, any change to their opening and closing mechanics will have a large effect on SCP RP gameplay as a whole. Making doors more responsive would be an overall positive effect on gameplay, however there are some potential drawbacks that need to be addressed. The delay on door opening and closing has a tactical purpose in the current server meta. Closing doors on pursuers is an essential strategy for escaping situations for almost every job on the server. The delay provides the escapee an additional second or two before their pursuer can continue, which can make the difference between life and death. Removing the delay would remove this additional time, effectively buffing jobs with a mostly pursuer playstyle (security, SCP's) and nerfing escapee classes (D-Class). This change would also do the opposite. Escapee classes would be able to close doors on their pursuers faster, since the close delay would be removed, gaining the time they lost. Overall these two effects would balance out, changing the meta without majorly changing the balance. Leveled doors pose another issue. Being able to close a leveled door faster on a class that can't open it (like an SCP) would give a drastic disadvantage to whoever the door is being closed on, since they'd have to break it down or hack it, while with the delay they would have additional time to squeeze through the door before it can be closed. This new balance might not be satisfying for a lot of players, and there are compromises that could be made: Restricting the lower delay to code blue This would allow for faster movement through the site during code blues while keeping the normal pursuit mechanics during other codes Limit the lower delay to non leveled doors This would make sure that SCP's and hacking classes don't get given as big of a disadvantage in door based pursuits, while still providing a lot of the benefits of this proposed delay change Conclusion: Doors in this server are a huge part of gameplay, and yet they are the most neglected. They're clunky and unresponsive, and something needs to be done about it. if you have any questions, comments, concerns, or additional ideas, please leave them down below.

How did they drive a forklift from the surface with those tiny doors

+support shit gets stuck way too often

+support, weak as hell

Why can't SCPs breach doors that aren't their cc outside breaching hours? Seems unnecessarily restrictive.

Can't he already kill indiscriminately with a good enough reason? That's the only time you need to kill anyway. Also isn't this a job for only like 10 people anyway? -support

There isn't really any risk reward, you can just switch to another weapon or dodge while you reload, which isn't big enough of a risk for an instakill

+support Double barrel has been op on every dark rp server I've ever played on lol

It would not be difficult to code. Source engine has a team system in place already, and if for some reason that doesn't work, you have the PlayerShouldTakeDamage hook which can also be used for this purpose.

You know, this might be an unorthodox solution, but it wouldn't be difficult to program something that increases/decreases his max health/max regen based on the amount of MTF currently flagged up. You might need some way to check if players are AFK but that's not too difficult, really.

We can just write a bLogs module for tranqs +Support for logging tranqs

The point of this wouldn't be to completely remove metagaming, it would be to prevent unavoidable metagaming. When you encounter a disguised 8286 you have no choice but to know that they are an 8286 based on their job name, which you have no choice not to look at. This WILL influence your decision making, no matter how much anyone insists otherwise. It's basically subconscious bias. You've basically been forced into metagaming. 8286's disguise isn't meant to hold up much past a passing glance. But atm it doesn't even hold up against a passing glance, since the job name is part of the information you see in a passing glance.

Why does anyone think you'd need additional models? You can just bonemerge an 035 mask model whenever you want. That's how hats and cosmetics work in the source engine and it would work the same in gmod. As for idea that there would be a lot of coding involved this is simply untrue. It's trivial to take a list of a players weapons and give them to another player. +Support I think this would streamline 035 quite a bit and make it more fun to play, even if a little less mechanically interesting.

Huge -support a 2 inch thick door isn't really going to help you against an SCP that can corrode or teleport through walls. The ability to trap people in the elevator is just a part of the SCP's tool kit for capturing people. Calling this unfair is like calling closing doors on people chasing you unfair. It's just a strategy to help you achieve your goal. If you trap yourself in a locked room with an SCP you deserve to be punished, and that's just a risk MTF need to accept. In short, its not unfair at all.

It does not have to cause a lot of lag. It can be implemented the same as any other SWEP, with a small clientside only check that disables NoDraw on players when the thermals are activated. It would cause about as much lag as the keys swep. Not to mention it doesn't even have to be a SWEP, but could simply be a keybind that MTF can use, which is even less lag than a keys swep.

+SUPPORT People are seeing this as an issue of d4 being op or not while that's completely irrelevant. DBlock is the responsibility of nu7 and gensec, and E11 shouldn't be allowed to tread on that responsibility without permission, regardless of how redacted they are.

Also, on the topic of mechanically based solutions: a way to counterbalance the removal of thermals would be to implement something similar to how team fortress 2s cloak works. When the cloaker bumps into a player or gets damaged they would become partially visible for a fraction of a second. This would make it easier to secure a kill on cloakers even without thermals, once you do manage to pin them down.

+/- support I think teamspeak covers pretty well any possible use case this could be used for. I'd support this if and only if the radios could be looted/stolen from people via fearrp or something and allow branches without access to comms to get access to comms. Like a dclass would be able to steal a radio from researched and become able to read site comms

The cooldown would be about equal to the max time the thermals could be on. So pretty restrictive.

Huge +support Also, even though nobody asked, it would only be about 5 lines of code to actually programmatically enforce this for both armor kits and medkits, so people can't cheat the timer

+/- support I personally support an actual implementation of thermals as a game mechanic instead of outright removal. Like a button that can be bound to turn on thermals, which reveals cloaked players only to the person with thermals on. To balance this people with thermals on would gain some kind of slight debuff like a lower movement speed, and the thermals would have some kind of time limit of about a minute per activation and a slight cooldown after deactivation to prevent spamming. In return for these limitations, you would no longer need a reason to flip them on. This would lead to a much more tactical and calculated use for thermals, with mtf needing to coordinate with each other on when to turn on thermals. And before you say it, this is not very difficult to implement, relatively speaking.