Arrow768

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.

Have you used a different byond account in the past ? Because the mentioned timeframe doesnt match what we have on record

There are more then enough sources for all these items: You can: Go and ask cargo Go and ask engineering Search Tool Storage Search Maint

In our case a Pneumothorax is caused by sudden pressure changes. If there is a sudden pressure change, there is a very good chance, that the lung will rupture and the air from the lung expands into the pleural cavity which will cause the lung to collapse. What should be done is making sure that a you do not get a pressure change from soft or graduate pressure changes (i.e. internals run out, forget to turn on internals when in a space suit, trying to breath out of a empty O2 bottle) Other than that the current implementation is fine.

[blurb that refers to a quote that has been twisted out of context] If you quote me, please quote me completely, correctly and do not twist the quote out of context. If you would have quoted me completely you would have noticed that I am opposed to the moving, because the motors required to drive a borg require substantially more energy than a emergency radio.

How about we just wait until we can actually playtest it before we start changing stuff around ? I do believe that our mappers are not complete morons and that they have put some thought into what they have done.

Simple Question: How can a machine work, if its only power source is depleted ? It cant. (Also dont say emergency power source because a radio only needs a few 100 mW of Power where as a Elektro Motor used to drive a industrial robot needs a few 100W of power) I prefer Jackboots solution, where a automatic message is sent on binary when there is a issue with the Borg (be it power, heavy damage, ...) It´s much like the emergency beacon a blackbox sends out thats used to find its location. I plan to add mechanics to triangulate transmissions with another project and triangulating a lost borg seems to be a nice usecase.