Arrow768

Moving to completed.

Atmos has recently been changed here: https://github.com/Aurorastation/Aurora.3/pull/5178

They are still in shock and denial

Implemented here: https://github.com/Aurorastation/Aurora.3/pull/5300 Lockers are already implemented.

Atmos has recently been changed again: https://github.com/Aurorastation/Aurora.3/pull/5178 Moving to the archive.

They were added for a few months as part of the rotating weapons and have been removed again. Might be added again in the future (or not since they are quite op).

Moving this to the archive as its already implemented and we received no response from the author.

No author response. Moved to the archive.

Implemented here: https://github.com/Aurorastation/Aurora.3/pull/5299

Implemented here: https://github.com/Aurorastation/Aurora.3/pull/5297

Mixed secret is gone. Into the bin it goes.

Has been implemented aswell

That has been completed quite a while ago.

Implemented here: https://github.com/Aurorastation/Aurora.3/pull/5265 Moving it to completed projects.

Has been implemented here: https://github.com/Aurorastation/Aurora.3/pull/5268 Moving to completed projects

I dont see an issue with maint drones as long as they don't actively interfere with the current actions of an antag. If you break cameras and a few minutes later the maint drone comes along and repairs them, then that's fine. If you are in the process of breaking cameras and the maint drone repairs them after you break them and uses tables and vents to avoid being destroyed, than that is active interference which should be punished.

A militia is definitely not something that you would want to have during standard operation and should be forbidden (it already is due to neglect of duty, trespassing, possession of contraband, assault, ...). During non-standard operation (i.e. shits fucked) there is enough wiggle-room to ignore certain existing regulations if it ensures the survival of the station. A official IC policy that determines if, when and how a "militia" can be formed would acknowledge that the station regularly faces threats that can wipe out the entire security department. Otherwise there would be no need for a official ic policy that regulates that. Therefore I am heavily opposed to the idea of a IC policy.

Implemented here: https://github.com/Aurorastation/Aurora.3/pull/5287

We generally dont use forum or external polls for controversial features. Therefore I created a server poll. It should show up in the Join menu, when you connect to the server.

Yes, thats a not a policy suggestion, but a dev suggestion. Lets move it.

The Dungeons have been removed from the PR this feedback topic is about (after community feedback) The PR contained only the framework which allows loading astroid dungeons in preset locations. PRs that have been merged can be seen on github as well as the git_log channel on discord. (In addition to the changelog) The framework which was contained in that PR has been tested sufficiently. (Again, it did not contain any dungeons, just the mechanic to load them) "Recently, a mining drone blew up a section of the station by shooting a fuel tank." - Amazing. A truly random event that noone coded. Be happy about it ,enjoy the RP caused by it and the ability to tell a truly unique story that happened on the station. This feature has been requested by and coded for the Lore Developer If you would have bothered to take a look at the PR, you would have seen that. This has been elaborated on sufficiently. I have no interest in repeating that discussion here. It´s sufficient to say, that this feature has been removed. Which has been nerfed two times (before you made that post; also logged in the changelog) This is the feedback topic for it. No community feedback regarding the speed has been provided. We do not check all channels on all discord servers for "community feedback on certain PRs." We have feedback topics. If feedback is not provided in the feedback topic, you can assume that we did not see it. Up until a day ago the PR wasnt even marked as review required -> So nobody reviewed it. All of those PRs that you mentioned as "problematic" have been changed in some way because of the community feedback or no community feedback has been provided.

Please remove the second autopsy room, it seems like feature-creep. (Dont listen to everything the department-mains tell you) As previously mentioned the second waiting rooms seems like a space-filler (its almost as large as the medical lobby) Imho the space can be better used with (parts of) the psych and the size severely reduced. (Also remove the food vending machines from it. There is a "refreshment post" right next to it.) An alternative would be to move the GPs office to the upper level and leave the psych on the main level. Which might be preferable as this would give anyone in medical another relatively secluded space to do shady things in. I can see the benefits of the medical breakroom, on the main level, but I believe a closer cooperation with service area would be beneficial.

Moved it to projects, since there´s a PR for it. I believe that the damage amplification of the force gloves should be reduced or removed. We have recently removed / changed weapons in a way to remove their ability to instantly end a players round. It is only logical to continue this here. (If you do something like that, it has to be done across the board and not only selectively where it suits the antags)

The idea is interesting, but recently there have been movements to remove/rework weapons that insta-stun. This would readd such weapons again. To elaborate a bit more: The Tornado Gun would need to be changed to not be a insta-stun weapon (or the no-insta-stun policy would need to be re-visited) -> Possibly changed to just push the people in its path back. The Glacier Gun could be changed to require multiple hits on the target to freeze them (each hit attempts to lower their body temperature and when a sufficiently low point is reached they will be completely frozen) The Dust Devil seems fine as suggested. The Meteor Sling will need some tweaks -> I could see it trigger the meteor random event, with a longer warning time. The Lightning Rifle sounds interesting aswell.

As a note before I start: I use lubricant and grease interchangeably for this post. Regarding Lubrication/Greasing: Lubrication is not only needed "where friction is used to generate power" (And friction is never used to generate power. Friction is a byproduct of two moving parts being in contact. Which generates heat, which needs lubrication to reduce the friction to avoid issues caused by the friction. You generally try to avoid friction as its a unwanted by product that reduces the efficiency of the overall machinery. Tires are a notable exception.) Most machines nowadays are lubricated in one way or another. Examples where lubrication is needed includes everything from: (Water)-Turbines to Engines, hydrodynamic fluid bearing, industrial robots, milling machines and even doors. All those things have huge differences in their requirements for lubrication/greasing. Some of those things require a complicated system that ensure a continuous flow of lubricant others just need to be lubricated once in a while (or when they start to squeek, like doors). I see a few issues with both suggestions (making IPCs require coolant/lubrication) Let´s start with the coolant: The issue with the coolant is, that you do not need to replace it regularly. Most of the time, you just need to top it off every few months. Someone mentioned the idea of the coolant being a chemical compound, that reacts with heat and then needs to be replaced after it has reacted. That has a few issues aswell: * There is no reason to use a special compound, if these tricks arnt needed for welding machines and combustion engines. * It wouldnt make sense to have a special chemical compound that expires with heat and needs to be replaced regularly as that would incur a cost that can be easily avoided. Onto the lubricant: While the lubricant needs to be replaced / topped off from time to time it is still not a very regular thing. The lubricant doesnt loose its lubrication ability in a matter of hours or days, but a matter of weeks and months. Personally I would do the following: Add a combined form of lubrication and coolant to IPCs. Lets just call it "space-lube" for the rest of the suggestion (The name can be changed easily enough) Each Robot (IPC/Borg) has a internal space-lube level (and temperature for IPCs) -> The higher the current space-lube amount, the higher the heat capacity. The space-lube level degrades /very slowly/ during normal operation down to a minimal level (In fact so slow that they might even last a shift without replacement if they dont go run around) If the robot is at or below the minimal level, they movement speed is slowed down as a safety precaution (and IPCs are unable to sprint) The space-lube level can be replenished at the standard recharges up to a "normal" level. The roboticist can top up the space-lube level up to a "maximum" level If a IPC operates in a environment without air, the temperature of the space-lube increases If a IPC operates in a environment with air, the temperature of the space-lube decreases The amount of coolant and the cooling rate (as long as the powercell lasts) can be increased by hooking up a external coolant tank / cooling unit (the temperature of the IPC and the external coolant equalize over time and not instantly to avoid powergaming) (And its probaply a good idea to pick a name that does not include lubricant or lubrication.) I believe the idea outlined above adds a interesting mechanics to robots IPCs and borgs and can contribute to some player initiated RP as it is out of sight during the normal operation and does not impede the flow of the round too much. (for both IPCs and borgs). Ofc it goes without saying that the thirst mechanic needs to be adapted to the species. (For example Unathi would have a much lower need for hydration than Humans or Skrell. Who will need to regularly moisturise themselfs with a special hand-moisturiser to avoid drying up and getting organ damage)