Arrow768

From the forum rules: If you dont have any interest to actually remove security and just want to discuss it with the wider community, the suggestion forum is the wrong place. Therefore moving it to general

Voting for dismissal. The Odin is not, and was never designed to be used by players for a prolonged amount of time. In addition, there is no "punishment" for dying. You are able to respawn with a different character after 20 minutes of time. In addition, the Odin will not exists in its current form on the NBT, so any effort put into any development of it would be wasted at this time.

It is already possible with some effort. You can just order a dummy mob from cargo and put their id and a jumpsuit on it. Then that dummy-mob will register on the suit sensor console with the name from the ID card. There is also another method available, but I´ll leave that to you to figure out ICly Given that this is already possible, voting for dismissal.

I have to echo the concerns from Matt. Being a moderator, maintainer and developer is a pretty big commitment already. In addition you returned to Aurora less than 3 weeks ago. Given that short timeframe I can not support the application at this time.

Moving to policy suggestions as this pertains to a current ic policy.

It is established practice that we never found the need to write down specifically as it is very rare that someone tries to make a staff complaint over a staff complaint. Accounting for all possible eventualities in our rules would just cause needless bloat. As a closing note: This is a private server/community, so we have the capability to choose the people we want to have in our community. A decision has been made that we do not want you in our community for engaging in jokes about doxxing/swatting people and possibly the actual activity of doxxing/swatting people.

You can make a staff complaint to get a ban reviewed and you can make a staff complaint to get that decision reviewed. The option to make staff complaints ends there. (As otherwise one could try to make a staff complaint over every follow up decision that does not go in their favor) Therefore closing this topic without further action.

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.