Arrow768

I dont really like the idea that officers can walk into the secure armory at code red. Other than that, I think it might be quite interesting

I am inclined to dismiss this suggestion as we dont have any objectives for our antags and therefore we dont have any "Major" or "Minor" crew or antag win conditions

Will be changed in a upcoming update

Will be added in a upcoming update

Will be removed in a upcoming update

BYOND Key: Arrow768 Character Names: SINA-129, Paul Jonson, Alexander Adler, Foxtrott Species you are applying to play: Snek What color do you plan on making your first alien character (Dionaea & IPCs exempt): Light Green Have you read our lore section's page on this species?: Yes I read that page on the wiki Snek's name: Ssling Sarr Snek's role: HoSsss What does your snek man do: Brig people. Make sure brigged people never leave the brig. Ssstrangle criminals with the tail

I quite like the new voting restrictions.

I´d rather not hard limit it, but scale up the cost with increasing turret numbers.

There have been quite a few suggestions in the past about fleshing out the economy a bit more and we might look into that some day after the new map. But I dont like the idea that all chars of the same ckey share the same bank account.

The issue of SEC Coordination with command if there is no HoS / Captain can be solved easily. Just promoted a trusted officer to interim HoS Or get the HoS spare headset Or give the Hos spare headset to a trusted officer. And no other head of staff has access to anohter departments channel. So why should the HoP ?

The reason why its not available on sec records is, that CCIA wanted the ongoing actions to be only available to heads of staff via the employment records consoles. If that has changed, this can be implemented.

The ruling has been provided. Archiving the Suggestion.

I just noticed a problem with the suggestion of removing the blobs ability to suck in people diagonally Essentially, this could be exploited by people to attack the blob manually without the risk of getting sucked in, by just standing diagonal to it. Also the suck-in mechanic is there to remind people that its a bad idea to attack the blob with manual tools. Just use ranged weapons. There are quite a few available. It seems that there is a 40% chance, that the blob sucks in a mob within a certain range and a 60% chance that it attacks you. What could be done to solve the issue of people getting sucked in diagonally is reduce the chance of that happening when it is in process and limiting it to the "main" directions. Additionally, to prevent people from exploiting this by attacking the blob diagonally a chance is added in attackby to suck people in if they attack the blob with non-ranged weapons.

Yup, 3 would definitely be a additional blob subtype. (But I would keep the same color, so it cant be meta´d to easily)

I have some ideas how to generate CPU Points without APCs. We have have quite a few modular computers on the station. It should be quite possible to allow the AI to spawn a process on their that generates CPU Points for the AI (amount depending on the other programs that are running, the processor, ...) And then there is stuff in another project I am working on that could allow something simmilar

I feel a reminder of the "1 suggestion per topic" rule is in order here. The suggestion is to buff beepsky not to remove him.

Just saying: Actively Blocking Radio Transmissions from a certain person doesnt make sense for a client side device. Other than that it sounds interesting.

Problem with removing walls and doors is, that blobs only spawn in maint. So you end up with a blob covering a maint tunnel. It´s incredibly easy to take it down then ocne you locate the main core. Just line up a few emitters right outside of the maint tunnel and the blobs gone. I believe that environment kills are completely fine. If someone goes to fight the blob unprepared and they die, you cant really blame the blob. Everyone knows that´s a space station. Everyone knows that if there is a blob breaches can happen. If they insist on fighting the blob without a spacesuit and there´s a breach, it sucks for them. Regarding the fuel tanks With the new map, this wont be a real issue anymore. Even if they explode, they wont breach to space, since there is not space below the floor, but rock and therefore the room wont be vented. Regarding the maximum size Afaik there is no size limit at the moment. Only the number of sub cores is limited. (And through that a max size is established; So you can already get a long slim blob, if it spawns in the right place) But there are also some interesting suggestions: Remove some of the adjacent blob tiles if the sub core goes down Make the blob prefer open spaces compared to walls when a new blob tile spawns (i.e. give open spaces a higher chance of being picked) Maybe add a tweaked version of the blob that doesnt take down walls and doors to add more variety to it

I just did some tests with blob and found that it is not too difficult to put a blob down. The tests have been performed in the following environment: Only use tools that are available on the station Only one engineer Attack after blob is fully grown Power is provided by a fractal energy reactor. The attack plan is basically as follows: Locate the main core Find a location where you can line up the emitters Make sure the location is out of the reach of the blob Setup power in this location Setup 3 emitters lined up on the main core and tiles besides it Wait and maybe throw in a few flashbangs Within a few minutes the main core will be destroyed and the whole blob will collapse I did a few of these tests and without doing anything else than properly setting up the emitters the blob core went down in 7-10 minutes after turning on the emitters. It took around two minutes for all the emitters to get to the blob core. Then it was just waiting for the central emitter to down the blob core. If security were to shoot at the blob core at the same time (when they have a free line of fire to it), this time could be decreased significantly Yes it is correct, that there is a lot of damage potential, but the blob is rare and it can be easily put down even by a single engineer. Most of the machinery we have can be replaced (with a bit of effort) and there are suggestions to make the rest replaceable too. (Which will be looked into) Also with the new map, breaches are not as likely as they used to be. Currently I do not feel there is much needed besides people learning that they need to work together to attack the blob (the main core). In the last blob round I witnessed I saw the following: Engineering arrived there with 2 emitters and a flamethrower. Engineering has been informed where to exactly setup the emitters to line up the main core Engineering setup the emitters in some other way, attacking the sub cores Meanwhile the guy with the flamethrower started to attack the blob without any coordination Then security arrived with the flashbangs Obviously they started throwing them in. The more the better They downed the guy with the flamethrower who got sucked into the blob Meanwhile a security officer attacked the blob through maint from another direction (with a smg) He nearly made it through the main core before he ran out of ammo After some time, a single engineer relocated one of the emitters and lined it up properly with the main core After that it was just waiting for the emitter to do its work Major damage can easily be prevented if: If people actually work together instead of trying "to be the hero that kills the blob on his own" Departments coordinate properly Emitters are lined up with the main core Time the attack correctly (Wait for the emitters to get close to the blob core. Then throw everything you have at it)

So to sum it up: The problem is, that it is way too easy to setup a hidden upload terminal anywhere on the station or the astroid. A scientist can easily print out the required boards and place a upload anywhere they want. The following has been proposed to resolve this issue and is worth looking into: Upload consoles need to be "activated" by two heads of staff before they can be used. Non-Standard and high risk modules need to be "authenticated" by two heads of staff before they can be used Bypassing the activation / authentication can be done with a emag DNA / Finger Print based auth Other abilities to subvert the AI if there is a reasonable amount of effort required to do so Being able to backtrace uplod console (Integrate it into the IT logging infrastructure maybe ?) The following has been suggested, but is not feasible imho: Requiring the HoS or the Captain to auth a upload console Making the protection bypassable with a multitool (No, the multitool is not a hacking device capable of bypassing software restrictions; Its a hardware manipulation tool) Restricting the upload z-level (With the new map, all z-levels should be able to hold any console. With the current map its a bit different, but since we get a new map soon, its not worth looking into that)

I´ll look into as part of another project I am working on

Deemed unsuitable by two developers. Open for more than a week. Not approved by one developer. Binned.

Now that the thread has been cleaned up lets summarize it´s current state: I already posted a statement about this in post #21 Popping a lung due to a sudden pressure change is fine (Yes, even if its instant) Popping a lung due to running out of air is not (You should suffocate instead, until you bother to turn off "breathing from the tank") I am interested in any other cases where popped lungs might happen and where that might be inappropriate. I do not want to see any personal attacks again or any posts that derail the thread. The thread is now unlocked

Due to the huge amount of suggestions in the suggestion board we have cleaned it up and implemented the following procedure for all open suggestions: All suggestions will be looked at regularly and can be dismissed if two developers vote for dismissal, it has been in the suggestions forum for a week and no developer has approved the suggestion. Titles of suggestions will be edited to reflect their status: "[1 Dismissal]" indicates that the thread has received one vote of dismissal. "[2; Bin {INSERT DATE HERE}]" indicates that the thread has recieved two votes of dismissal, but the safety period of one week as outlined above has not yet expired. The date will mark when the thread will be binned. This allows for other developers to voice their disapproval. These tags are solely for the benefit of maintainers - do not edit them yourselves. All current suggestions will be talked about at a developer meeting and dismissed if no developer is assigned to it. The Suggestions and Ideas Sub-Forum also comes with changed rules: One Suggestion per Topic Make sure your suggestion has not been suggested before. (Search the Suggestions Sub-Forum) Do not title the topic in all capitals. Do not respond to idea's with gif's, +1/-1 provide reasons on why you like an idea or not. Do not derail the topic Read the whole topic before you post in it. (Yes, that means all of it) The usual forum rules still apply here. Developers will delete all posts that violate any of these rules or are not contributing to the discussion in a suggestion. The reasoning behind a suggestion should be elaborated upon in the initial post to a reasonable extent.

This thread is closed until I get around to clean it up.