Special Containment Procedures Foundation
Area 27v2 Raid Regulations
Written by ThomasTrainiac and unix_system
1. Raid-Time Regulations
-
1.1 - Raid Minimums
It is a requirement, at the start of a raid, for there to be at least three combatives and three insurgents. The raid time will begin at the allotted time, but until that time the raid will not be considered in effect (if insurgents come 10 minutes late, then the raid will not be extended by 10 minutes under normal circumstance) -
1.11 - Mid-Raid cancellation
If for a long duration of time (over 8 minutes) there are fewer than three insurgents, or at any time there are fewer than three combatives, the raid will be officially on hold. If there are fewer than three combatives, then by default the raid time will be extended for the time elapsed without combatives in favour of the insurgents. This is not the case, regardless of combative count, if there are fewer than three insurgents. In the event that there is a major breach of any Euclid or Keter Class SCP, the raid will continue until Protocol AD is called, or the breach(es) are contained regardless of status. -
1.12 - Raid Times
All raids must be on either a 30 minute mark or an hour mark (i.e XX:30 or XX:00). Raids may only happen at most twice a day. If the raid party is found failing to follow this rule they will be suspended for raiding for up to 4 days. Site Director+ will decide the exact amount. -
1.2 - Protected Locations
To ensure fairness, the following locations are not to be entered by insurgents:- All combative armories
- Medical Department Spawn
- Cafeteria (during breaches)
- Breach Shelter (during breaches)
- Control Room
- CDC Control Room
- All airlocks are not to be camped in to wait for combatives
-
It is prohibited for insurgents and combatives to stand behind the S3 walls at all times, unless a breach is present and it’s absolutely necessary for ease recontainment.
-
It is prohibited for combatives to use riot shields during raid time at any point.
-
It is prohibited for insurgents to camp inside of department spawns in all circumstances, but they may enter spawns to retrieve a hostage that may be kept inside.
-
Insurgents entering this area may void the raid in accordance to raid voiding procedures. Camping outside of these areas will also result in consideration for raid voiding.
The following locations may not be entered by combatives (during raid time):- Tunnels
- All airlocks are not to be camped in - wait by the corner at the intersection at a minimum.
- Tunnel explosive points
- Camping sectors are strictly prohibited and all department guidelines that state to stay in a sector for recon, etc, are void.
-
1.3 - Raid Wins & Losses
Only The Following personnel are permitted to declare raid wins / losses- Members of the Department of External Affairs (as per departmental regulation)
- Level 4 Personnel and above (who are acting as raid spectators)
-
These are the only personnel who can decide who has won or lost a raid (however ultimate authority is granted to the Department of External Affairs). Other decisions are invalid. If four or more personnel and or insurgents believe the personnel in the Department of External Affairs that has decided raid win/lose and or negotiations is unfair, it may be debated.
The criteria for legitimate wins for CI are as follows:- A major breach of a Euclid or Keter humanoid SCP which leads to the initiation of warhead destruction (i.e. sustained for over 30 minutes)
- Uncontrollable spreading of an infectious SCP, causing widespread damage and the initiation of warhead destruction (i.e. over 50% of the site infected)
- In accordance with Hostage Negotiations
- A mobile Euclid or Keter SCP inside of insurgent spawn
- Around 70% of hostagable personel taken once
-
The criteria for a combative win (i.e. an insurgent loss) are that no major breaches occur and no hostages are taken and not retrieved (i.e. executed in accordance with Hostage Negotiations). If any of these do occur, at any point, contained or not contained, according to the database the raid will be marked as a draw.
In the rare event that there is widespread misconduct in regards to a parties’ actions during raid time, the following can (at the sole discretion of DEA & Site Directors+) be grounds for an auto win for a side:- Evidence that a combatant, either with the support or without the support of their comrades, was blatantly performing major exploits or glitches to assist a side with the raid is grounds for an auto-win for the opposing side.
- Evidence that any combatants entered a restricted area (see 1.2) is grounds for an auto-win for the opposing side. Camping restricted zones may also be considered at the discretion of the deciding authority.
- The disobedience of any part of Section 1.1 - Raid Minimums (including 1.11 - Mid-Raid cancellation)
- Result of hostage negotations.
-
1.4 - Use of Restricted Areas During Raid Time
Personnel may not hide in areas that are not accessible to insurgents. This includes spawns, and[REDACTED]
. Personnel may not enter these areas for longer than 5 minutes total during raid time. This does not apply to Intelligence or Combative Personnel.
2. Raid Hostage Guidelines
-
2.1 - Hostage Taking
Within SCPF, Any Foundation Personnel, Class-E, or Class-D may be taken hostage, except for combatives and insurgents. The Engineer and O6 of CI may be taken hostage. They may exempt themselves from hostage-taking but must ask the raid moderator to announce that they are exempt.
Within GOIs, any GOI member on-team may be taken hostage.
Only on duty intelligence personnel, and designated raid spectators will be exempt from hostage taking (to avoid a conflict of interest).
A maximum of 3 hostages may be taken by either side with at least 5 minutes in between. These hostages must be released or shot within 10 minutes if DEA / Raid Spectators do not express an interest in negotiation for the user -
2.2 - Hostage Tools
Hostages may have tools or other rights taken away by the hostage-taking parties. Breach of these rights will not lead to punishment by Site Rules. -
2.3 - Escaping as a Hostage
Hostages may not leave, glitch, reset, or use any other method to escape captivity. If a hostage has to leave momentarily (rejoining, rejoining due to detain glitch, no AFK leaving) or crashes, they may be teleported back immediately to where they left and would still be considered a hostage. -
2.4 - Punishment of Hostages for Foundation Law Violations
Hostages may not be held accountable for on-site rule violations if they were compelled to do so by the hostage-takers. This does not open the window for helping the enemy, which is still disallowed. If required, an Ethical Board may decide if an action was justified. -
2.5 - Terms of Negotiation Conduct
Once the terms of negotiations are agreed upon by both parties, they shall be followed by both parties otherwise the raid will be ended and raid time automatically suspended. Upon the conclusion of negotiations, any mutually agreed decision shall be honored by both parties.
3. On-Site Activity Rules
-
3.1 - Unintended behavior
Any sort of Glitching, exploiting or utilising bugs in the game for unintended purposes is strictly banned. The punishment will be based on the severity of the offence, however by default the punishment for any form of exploiting (running an exploit program specifically to target the group) will result in a databan. -
3.2 - Glitching includes, but is not limited to:
- Shift-Locking
- Using provided tools in unintended ways (i.e. detaining a colleague through a door / wall they wouldn’t normally be able to go through. if the the door in question i.e the atomics door by the helipad, are broken but you have the clearance, you may detain a colleague through)
- Exploiting issues with SCPs or products to gain unfair and unintended advantages
-
3.3 - Modified Clients
Modified Clients, such as those which give minor, non-obvious advantages via exploits (i.e. Aimbots, ESP, or Click to Teleport) are explicitly banned. These are classed and treated as exploits and will most likely result in a databan. A “PC check” may be requested to prove innocence. -
3.4 - Provision for Testing
The rules regarding glitching and exploiting apply to all, including the O5 Council, except the following subsets:- Site Directors
Site Directors are permitted to perform reasonable testing, with the permission of the Developer of that site. Using glitches for personal gain will lead to the revocation of this clause. - Any user who joins will have an implicit “do no harm” tester status (their use of exploits or glitches may be overlooked if it was done with the intent to demonstrate to development staff the issue and get it fixed)
- Site Directors
-
3.5 Clearances
Site Directors have the exclusive permission and ability to change the clearances required to enter certain sectors, not including[REDACTED]
. The clearances are as follows:
- Sector 1: L0+
- Sector 2: L1+
- Sector 3: L3+
- Sector 4: L5+
-
[REDACTED]
:[DATA EXPUNGED]
4. Admin Regulations
-
4.1 - Admin Ban Procedure
When a user is banned, the following steps should be followed:- Investigate - ensure that the user actually performed a bannable act, or that their actions qualify for a ban.
- Inspect - begin collecting evidence through logs and screenshots via view. If any witnesses, ask for their recording.
- Interrogate - if possible, talk to the user in-game to ask about it. If they leave, you may assume guilt. If they reply, take into account what they have to say into your judgement.
-
If you have proceeded through all these criteria, you may go through with the ban procedure. In regards to some common misconceptions:
- Just because a user has a G36C, or an AK-74u, this does not make them an exploiter. The same goes for them owning high-level cards. Although it is authorised for you to be suspicious of these users, unless they clearly have items they should not (SD armour,
[REDACTED]
), you should not immediately ban them without following the steps. - Users may no longer be banned for entering classified areas by legitimate means. This includes
[REDACTED]
, the Warhead Silo, et cetera. If these users simply slipped in past an authorized user, then they do not qualify for a ban. If however, you have sufficient belief that they have glitched or exploited into said areas, you may proceed with the action.
- Just because a user has a G36C, or an AK-74u, this does not make them an exploiter. The same goes for them owning high-level cards. Although it is authorised for you to be suspicious of these users, unless they clearly have items they should not (SD armour,
-
4.2 - Abuse, and consequences
Abuse is not, and never shall be, clearly defined past the use of admin where not deemed needed for an administrative or functional role. This means that, if it is required to continue gameplay on the site (noclipping to un-glitch an SCP, btoolsing to fix a broken door which is blocking access), viewing / tracking users for exclusively exploit-prevention purposes, or announcing key information via announce, or it is required as part of a divisional role (i.e. Intelligence) then it is permitted. If, on the other hand, it is used to create an unfair advantage, or it is used for the amusement and abusive activities of the user (such as using commands like track to find and kill CDs, or non-combatives giving themselves a G36C) then it is not permitted.
The sole discretion on the punishment for admin abuse is up to the Developer of the Site → Who can be overruled by the Head Developer → Who can both be overruled by the O5 Head & Administrator.
Punishments - There are three types of punishments, which involve the severity of the offence, and the history of the user.- Classification I: Minor - Temporary Removal of Admin - This involves small lapses in judgement, such as teleportation to assist in travel, abuse of PM, or occasional more serious offences (using immature commands such as kill, startergiving tools without need, giving CDs rifles, etc).
- Classification II: Moderate - Permanent Removal of Admin - This involves multiple classification I offences, or major breaches (abuse of the ;ban command to ban enemies unjustly)
Thomastrainiac
Head of CI development, “The Engineer” of CI
Unix_System
SCPF Developer