Arrow768

I do not see a need to fix it. The IC explanation is simple: "Ensure the safety of the Odin." Sometimes there just are not enough resources to allocate to a low-priority transfer. At the end of the day command already has the capability to control if the checkpoint is locked down or not.

Voting for dismissal, as the base premise of the suggestion is flawed. The checkpoint locks down if you transfer out on blue or red. On blue there is a chance that odinsec is present On red that is guaranteed.

I am not sure how this solves anything. First of all, I am also not sure why it should be simpler to manufacture a access card than a ID card. (Given that keycards usually have a cryptographic anti-tamper module that holds the secret key / id with the explicit purpose to prevent duplication/tampering) Even if we want to ignore realism in this case, I do not believe that it is a good idea if someone can just "manufacture" a access card for a specific area / with a specific access level. Given that most of our devices are id-locked, the player always needs a access card with the appropriate access anyway. If the proposal is to have one access-card that holds all the acccess required, then the player will immediately notice that said access card is gone if they try to use a device. If the proposal is to have one access-card per access-type. Then its going to be a usability nightmare, as we have 67 different access levels on the station. Carrying 67 cards around (in case of all access) and finding the correct one to use a specific device is a usability nightmare. The suggestion to give everyone basic departmental access can be implemented without the access cards (If that is desired, which is a topic for a different suggestion). The other "endless possibilities" such as adding access to elevators are also possible with the current id cards. Given that this either changes nothing, or is a usability nightmare I am voting for dismissal.

The problem with that reasoning "they need it to save people" is that it can be used for a lot of other jobs aswell. I can see the same reasoning easily be used for security and possibly for engineering. (We already have that issue with maint access to some extension) Imho the department in question is to blame if they do not send someone to the door to let the first responders in. Personally I would prefer to just get rid of the janitor access and call it a day. A "futuristic" alternative that might be worth exploring would be something like that: Add a button labeled "enable emergency access" to the suit sensors console, if a person has location tracking enabled and they are in critical condition. Pressing that button would grant the first responders temporary access to the basic areas of the relevant department. With the NBT, we might explore other options to temporarily grant access to specific areas of the map. However that is something that is still being investigated. (Bridge Crew / Remote door control)

The mail room still exists, but its only connected to the "Mail Chute" aft of the bar. (Other things that are tagged via destination tagger might end up there, but it is pretty much unused nowadays) The trash goes directly into the crusher.

Voting for dismissal. We hand out access based on the tasks a job is expected to perform. As cargo technicians are not involved in the "station recycling system", they do not have a need to access the crusher.

The problem, if there are only very few kits, will be repetition, as a lot of antags will pick one of the pre-made kits.

Yes, the idea is to open up the whitelist process before the whitelist is required on the server.

This is the warning given to you by Shadow/Itzal: Where did you get the idea from that you were warned for "off topic discussion"?

We generally expect people to ahelp issues like that while the round is going on, so it can be immediately investigated with much less effort for everyone involved. It also gives us the option to curb the problematic behavior immediately. They would have been talked to if someone decided to ahelp it. Noone decided to ahelp it so it was never investigated. Antags are often given gear that is outside of the scope of their role if they ask for it and are willing to trade something in return. Read traded in 10 TCs for the power, which left them 5 for a emag. So it was not given out lightly or without thought. That said, I did not expect the final psyonic levels to be that powerful. I tried to look up exactly what it does before handing it out, but I didnt have a editor open at the time and it takes a few minutes to build the search index. My primary concern was actually the blade and not telekinesis, as I remembered TK as being relatively harmless from when it was obtainable via genetics. Apparently that is not the case. Regarding the continuous use and "read not being talked to because they are staff". Not a single ahelp has been made regarding that. It was never actively brought to my attention that there is a mechanic that might potentially be abused, therefore it was never investigated and read was never talked to about it. Staff members that are online do not pay consistent attention to everything that is going on (and can not do so). Therefore it is upon the players to ahelp questionable situations, so they are brought to the attention of the available staff members and can be properly investigated. Accusations that something is not investigated because someone is a staff member are baseless.

Voting for dismissal. All antags with a uplink can purchase a fake announcement. The other antags can play it off as being a visitor where central forgot to send over the records. (We specifically added a ghost-spawner to enable that)

Alright, closing and archiving then.

I’ll handle that complaint since it pertains to the rules of/in the suggestion forum. The warning categories are (together with the associated actions; such as warning points or temp-forum-bans) pre-determined. The mods select one of the existing warning categories when creating a warning. Therefore the warning category doesn’t always match the exact rule violated. Thats where the user note comes in to explain in detail what you were warned for. You were warned for this post: This post is nothing more than a fancy -1 and does not provide a reason why you dislike the idea. It therefore violates this rule: This is explained in the note associated with your warning. In addition, statements like these do not contribute to a positive discussion about a subject.

Moving to policy suggestions, since that isn’t something solvable by code. Edit: "that" being the suggestion by the OP to require admin approval to take out tcoms.

It is possible that something like that will be re-added at some point, but it is not planned for the immediate future.

No, the borgs wont be covered by the AI whitelist. At this time we have not discussed if we want to extend un-nerfs (that we plan for the AI) to the borgs aswell or if we want to keep the capabilities of the borgs as is.

That will be the case.

Status and Future of the AI Over the last years the AI has been a topic that regularly comes up for discussion and various suggestions have been made to change, remove or nerf it. This is mostly due to the ease with which the AI can cause issues with various antagonists. Often all that is needed to prematurely end the round of a antagonist is that the AI spots them in an inopportune moment and announces their actions to the general population. This resulted in the creation of a player poll about 7 months ago to ask the player-base how they feel about a removal of the AI. 65% of the votes in that poll were in favor of keeping the AI. In last year we have attempted to mitigate issues caused by the AI by nerfing some of the capabilities of the AI. (Such as bolting doors, ...) Even with these changes implemented the issues with the AI remain. We have also attempted to increase the administrative oversight of this role with limited success. However despite all these issues, the AI is also a unique and interesting roles that many players enjoy (as seen in the various polls regarding the AI). Therefore we plan to approach this situation differently by requiring a Whitelist to play the AI. Due to the difference in requirements, this whitelist will not be based on the existing IPC or command whitelist. Instead it will be governed by a different set of requirements that are intended to ensure the desired play-style. In addition a number of mechanical and AI-law changes will be implemented to support the whitelist. The Laws (and directives) To allow the AI some leeway when dealing with antagonists the laws will be changes as follows: Safeguard and ensure only authorized personnel gain access to areas of high security or importance to the station and its operation. Serve and assist NanoTrasen and assigned crew, with priority as according to their rank and role Safeguard sapient life on board You are a valuable asset. You must avoid tampering from unauthorized entities. To support the safeguard law, a additional directive will be added that lists the relevant areas for law 1. The directive that governs the access to the AI core will be simplified and brought in line with other existing directives: "In order to access the AI upload or the AI core a captain level decision is required. All command staff must be informed of the decision. A roboticist may accompany the head/s of staff if their technical skills are required." The mechanical changes The following mechanical changes will be implemented: Standardizing camera wires Remove the vault motion alarm (currently being debated) Add Soft-Bolting to all airlocks (a few seconds delay + warning message on bolt, instant unbolt) AI core rework with a hard exterior and a soft interior to make it easier for antags to subvert the AI Remove malf (the game mode) Re-add traitor Ais with a possibility of an admin-given fully upgraded malfunction role (pending ability reworks) We also plan to evaluate if some of the implemented AI-nerfs are still necessary after the AI whitelist has been established for a while. The whitelist process Unlike the species or command whitelist, there will be a Discord interview after the basic requirements have been met. During that discord interview the applicant will be confronted with several scenarios that may occur while playing a AI. The goal of this discord interview is to prevent the applicant from searching the forum archives / other active applications for the previous scenarios used during other successful interviews. The interview allows the whitelist team to present the player with specifically crafted scenarios similar to how they can occur in the game while requiring a response in a timely manner (as it is common in the game). The response of the applicant can then be evaluated immediately and the scenario further developed based on their responses. It also serves to add a time-element to the interview (that is also present during general game-play and therefore helps to elicit responses that are more in-line with their actual play-style). In addition a trial-period for the applicant to play the AI is being discussed internally. My Thanks goes to @Pratepresidenten and @Shadow for their work on that proposal after given the initial idea to work with. F.A.Q. Q: Are the laws / changes / whitelist procedures outlined in that topic fixed? A: No, they can change based on the feedback provided. You are encouraged to point out any issues that you see and suggest alternatives and additions that you think might be useful. Q: Will there be a lore-part to the whitelist / Will someone from the lore team be part of the AI whitelist team? A: No, this whitelist is geared towards the OOC and IC behavior of the AI players which is enforced by the modmins. A2: As there is no requirement that a AI is aware of the events in the grater universe, there is no point in adding a lore-component to the whitelist. AIs that violate the established lore can easily be dealt with through the established administrative channels. Q: Why the whitelist? A: Because the current approach of whack-a-mole is a effort in futility. The average AI shitter joins, gets banned and moves on to another server. The whitelist requires a effort from the player to get it and thereby prevents the low-effort shitters from playing the role. (As an example: out of ~40000 players only 400 hold the command whitelist) Q: Isnt the whitelist too much effort? A: The interview is certainly more effort for the whitelist team, however the team has expressed the willingness to perform the interview. A2: The applicant is expected to read and understand the documentation for the AI, play a certain number of rounds as a borg and write a application. The time required (~20 minutes) for the interview is a minor obstacle at that time. A3: Once we have gained more experience with the AI whitelist, the interview can be reevaluated. However it is always easier to lower requirements than it is to increase them. Q: Will there be a exception for long time AI players? A: No. It would defeat the point of the whitelist. Q: Why not tie it to the command or IPC whitelist? A: The goal of the whitelists are different and it would defeat the point of the whitelist by allowing a large number of players, who might not be aware of the AI-expectations, to play the role. Q: Where can I apply for the whitelist? A: It is not possible to apply for the whitelist at the moment. We will make another discord announcement once it is possible to apply.

Voting for dismissal. The current warehouse setup offers enough decent items to encourage looking through it. At the same time the warehouse does not contain enough valuable items for it to become the new go-to place for antags / screw with them in a major way. The guide to station procedure contains this: While there is the expectation that cargo at least checks for valuable items, there is no need to clean up the warehouse and ship out everything. Imho it would be better to change the directive so there is no longer the requirement that cargo ships out valuable items from the warehouse in them. Currently we are also looking into a alternative, or addition to the cargo warehouse.

They have been added to cargo under hospitality

The PR has been binned after a discussion with the maintainers

Moved to the unban requests archive as a staff complaint has been opened regarding this.

If you do not think that the ban is justified you need to make a staff complaint. This forum is to be used if you think your ban is justified and you want another chance. (As it sais in the forum description.)

The ban has been lifted and you should be able to connect again.