Donator
It's time to cook.
What does this suggestion change/add/remove:
First off, I want to say that I don't intend for this to remove the current features of 914; My idea here is to facilitate increased RP as well as breach variety/options with the addition of a SCP-914 job slot for a player.SCP-914 As A Job
Add a new job for 914 under the SCPs tab. This would probably need to be a whitelisted job as what I have in mind would, while increasing the potential for RP and such that could come from interactions with 914, obviously comes with abuse concerns and such, that would need it to be reasonably gated off.The way 914 works right now, would be the same way that it works whenever no-one is on the 914 job, as well as all the time 914 is breached. Same mechanics. However, as 914 is a map prop (& entity? Assumedly, since it has behaviours that would require edits to it - I'd imagine just an extra flag that could be turned on and off via GLua? Depending on these states).
Someone flagging on the 914 job would kind of be like flagging on the 079 job - No model, probably a containment blocker around the 914 area to stop them from flying around and disrupting RP in the same way 079 could, etc. Same rules would also apply with being able to noclip around and such, as the movement would be identical.
Non-Breached Behaviour
Whenever someone puts something in 914 and tries to process it while someone is flagged on 914, the player playing 914 gets the choice of what to do with the item in the input booth, depending on what item it is (But importantly and specifically, not the setting; Let the player decide how the setting may or may not influence the outcome).This could range from the default behaviour to... Whatever's implemented/feasibly implementable, really. Maybe let them turn a prop into a different prop? Someone tries to disguise themselves on 1:1? Maybe 914 can have the choice of disguise; It could be one that's deliberately extremely unhelpful (...Also part of what I said before about abuse comes in, in terms of helpful things. If accepted, the implementation should be done with preventing abuse in mind) - Then the door opens after the choice is made and the change happens. And by virtue, the length of time 914 processes things would become variable.
This could be implemented via a SWEP w/ UI options, etc. There may need to be a blacklist of what is processable by 914 in this way.
Breach Behaviour
Obviously, I don't mean for the actual 914 machine itself to suddenly sprout legs and start running around the facility causing havoc - Using a combination of Fr3ze's workshop map, building, some PAC3 and a little camera trickery, I made a short concept video for what a 914 breach could look like (Well, the start, at least - And conveys the general idea of what I'm proposing).But in the case that either stops working or w/e - Here's a little rundown of what is covered:
- Obviously, it would have a containment box that shows its breach status and shows whether or not 914 is breached - Same as other breachable SCP's containment boxes, can hack it, etc. 914 would also be in the breach queue.
- When breached, either via the breach queue or being hacked out, 914 is triggered on the current setting.
- Once the doors are shut, SCP-914-A (provisional) will spawn in the output booth - This is the player on the 914 job. Additionally as mentioned before, 914 behaviour would revert to standard for the duration of the breach.
- Potential for either passive or hostile breach.
- 914-A's loadout could be all themed around mechanical/clockwork type stuff; Obviously it would get Keys, but also a melee option - In the video I showcase the idea of it just having a grandfather clock to whack people with? I admit the idea of a robotic clockwork-based SCP running around and whacking people with a grandfather clock is a little goofy, but it was the best I could reasonably come up with. Maybe like a metal pipe? Some kind of obscure gear that's long? I don't know.
I don't imagine that 914-A would have a ranged option if accepted, but if so, I think a revolver would suit it best. It has the most 'manual' feeling of any weapon and fits the mechanical/clockwork feeling very well.
In the meantime, you could probably reasonably do something along the lines of... Cheddar's 650 model? Unsure.
914-A would be able to break most doors, as well as some blast doors (Most importantly, the type of blast door that 914 is behind so that it can actually leave the CC into the facility).
I think it should have a slower-than-average movement speed, not as slow as 7722, but not as fast as maybe 912 or 049.
And 914-A would be terminable. I think it should have a moderate amount of health, but not too much - More than other terminable SCPs.
Has something similar been suggested before? If so, why is your suggestion different?:
It's not possible to search past suggestions for just '914' as it's too short for the search function. Most past 914 suggestions involve changing its behaviour and not actually having it be player-controlled in any capacity. This does overlap in that the way it works would be changed;For example there's this currently active suggestion from Flare about processing GOI keycards in 914. This could potentially be a way to facilitate doing something like that; Have what happens be entirely up to the player on the 914 job - Put a CL3 CI keycard in, get a bunch of bananas out of it. However, it's more likely that the possibility for improving GOI keycard clearance not be something available to Foundation, which I agree with. Hence my saying earlier about a blacklist about what the player on 914 can process, which could include GOI keycards. In that respect, this suggestion would be entirely counter to that one.
There is also my other suggestion about giving 860-2 breach behaviour. I state in that one that it's a testbed for this suggestion. I was satisfied enough with the community response to that, that I felt this to be viable.
Possible Positives of the suggestion (At least 2):
- Another breach option for players that want to breach as SCPs & players that want to hack out SCPs - This implementation would not require a new map area to be planned and modelled out, as it uses an existing one (However, it will still need mapping changes). This additionally adds another whitelisted SCP; Which NL have been saying they want to add more whitelisted SCPs.
- Vastly increased RP potential for 914 - On top of passive breach RP, the non-breach behaviour adds further depth to interactions to 914 without the need for a GM; It could also be used in conjunction with a GM for an otherwise enhanced event experience & roleplay immersion.
- Diluted breach pool - As I mention in my 860-2 suggestion, adding more easy-to-deal-with breaches to the potential pool of "what's breachable" means that breaches on average will end sooner; Which means getting back to RP. Server health go up.
-
It's strange, right? So, I know we have our own canon on CN, but - I happen to be an expert on 914 as it is on the wiki. I know that 914 isn't a sentient/sapient entity, but the way it acts, it's kinda basically an analogue artificial intelligence. If you've ever read through some of the funny experiment logs, you get this impression that even though you know, as part of its description, that it's not any kind of biological intelligence - It has the qualities of some intelligence being behind what happens with the output. This non-breach facilitation would decently recreate that to good effect.
As for the breach behaviour and having something just randomly come out of 914. Yeah. That does happen. There's tests where 914 activates seemingly by itself where it's like "Input: Nothing, Output: Something" - With the implication that the origin is extradimensional or similar. It would really help hit home the "non-standard space-time" categorisation of 914. - Nerfs 073
Neutral points of the suggestion:
- Alterations to the D-Class & 914 Raid Loops - Obviously discounting abuse of this which should be disallowed and prevented where reasonably possible (in that D-Class & GOIs could have someone flag on 914 to get whatever disguise/effects they want as quickly as possible), D-Class & GOIs have less of a guarantee to get useful disguises, as the results of raids would be entirely up to the whims of whoever is flagged on 914. This could be seen as a negative from a D-Class & GOI point of view and a nerf - But ultimately speaking, this is kind of a sidegrade; it can offer more potential, interesting results rather than things going as expected.
Possible Negatives of the suggestion:
- Abuse/Minging - As much as I say it shouldn't happen, that doesn't stop it from potentially happening - That being that people can have 914 flag on and get targeted results. Ideally you want like in the whitelist app to make it clear that this should not be used this way, punish people that do abuse it with warnings and WL removal, etc. Keep people that would misuse it off the WL. But this doesn't guarantee it isn't abused, as well as that being abuse being difficult to determine; It requires a certain level of trust of the people that get WL'd for it. That being said, a WL should apparently be sufficient, given that staff see no problem with whitelisting 22415, which have abilities that can be used to significantly minge/grief RP/breach situations; However this is a somewhat faulty comparison as it's more easy to determine when that has been abused, compared to 914. It's also just another thing for staff to tend to.
- Significant Dev Time - This is asking a lot. Even though I said it doesn't need a new map - It still needs mapping changes to make the necessary alterations to 914; It needs a model for 914-A (or whatever it ends up being called), it needs implementations for the 914 job, it needs balancing. Obviously this isn't going to happen overnight or within the next few months. This is going to be a long-term project. It's also possible that because of the way 914 works, that this is not possible - Or at least that the time & effort to do so doesn't reasonably warrant the implementation overall.
Based on the Positives & Negatives, why should this suggestion be accepted:
This is something I've been heavily ideating for past 4 months or so. I almost didn't suggest this and had it sit my backlog for the foreseeable future as it has all the hallmarks of a new SCP suggestion, but I think this is reasonable enough to warrant long-term consideration, if at all possible. I firmly believe that once implemented, the potential benefits to both RP and breach variety outweigh the downsides. 914 flag on.I do also appreciate that not every SCP at all, let alone in LCZ ,has to be a breaching SCP - But I think there's considerable merit for these changes and it's not just mindless breaching. In addition to any breach benefits, the breaching aspect could be considered incentive for people to be on the job and interact via the non-breaching mechanics, creating RP. Both sides of this work in harmony with each other.
FAQ
Last edited:
Senior Moderator
SCP-RP Staff
Event Team
Trial Game Master
Group Moderator
