SpaceSkeletonVEVO

Reducing part creation time should be a function of improved protolathe/circuit imprinter parts, if it isn't already. I think that given the existence of a queue system multiple parts per click are unnecessary and would clog the interface. Maybe add the queue list in a frame to the side instead of having it in a separate screen entirely? The exosuit fabricator gets that done nicely.

It's not necessary to change the default hat. Just give the HoS a variety of hats, mechanically the same, just with different sprites. A bit like how the HoP has a variety of possible uniforms in a locker in his office.

I'm sorry, but the construction cyborg module is currently absolute garbage. The only thing it has going for itself is the RCD, which is already of limited use because of heavy power cell drain. It doesn't have a light replacer, it does not have all the tools, it doesn't even have a plasteel synthesizer (which engineering borgs do!). I haven't seen a single cyborg go construction, with the exception of myself, just to see if it changed at all after baymerge. Apparently, on Bay it doesn't even exist. It might as well not exist here, and should not be used as an example. The duties of a custodial cyborg and engineering cyborg overlap about as much as the work of a janitor and station engineer do. Janitors are expected to be able to do minor repairs, but you won't see one operating the SM; likewise an engineer running around with a bottle of space cleaner can sometimes happen but he won't be stomping around in a mech spraying polytrinic acid to cleanse the station of unbelievers mopping the halls or making sure disposals is flushed every so often. I'd be all for giving the custodial module some tools to be able to accomplish this balance. However, balancing modules by removing features isn't the direction we should be heading in as a server.

You can use the multitool to find the alarm wire and then cut all wires but this wire. If memory serves, the wires are the same across all station cameras.

Cyborgs already have to deal with these Cam issues, it's not that big of a deal, the AI/Security rarely catch them in the act. That said, maybe tie them to Security EVA Gear instead of basic Security Gear. Mining Hardsuits already have built-in cameras, it's really not farfetched or game changing, just makes it easier to track down the lost Crewmembers/Equipment if things come to worst. Keep in mind that synthetics can shut off the camera component at will and it will rarely, if ever, be questioned. If we are dealing with a "HoS demands all the officers to have cameras on at all times" situation, then you are clearly not getting away with having it pinned to your uniform but turned off. If we move the idea to EVA gear, then there is no reason to have the camera restricted to Security gear only, since they're not the only ones who can get lost in space or attacked by carp or subject to anything else that would warrant a rescue. I am personally opposed to the idea as it appears to provide nothing but opportunities for bad play. Even if we ignore the very real possibility of forcing officers to wear them at all times (in breach of code green privacy regulations), come Blue or Red officers will find their already limited autonomy completely stripped in favor of HoS micromanagement. I imagine that will be helpful to the station come Merc - rounds of which are pretty common nowadays, I'll admit - but what other antagonist warrants that sort of commitment?

Hello all. Searching the forums I found no thread about improving the paperwork system. I find that with the introduction of baycode consoles, and more specifically the printer, the current system is due for upgrading. The changes proposed aim to make life easier for paperwork-heavy jobs such as Internal Affairs and the Head of Personnel among others whilst also providing avenues for beautification of station paperwork. I have decided that instead of making a great amount of different threads for relatively tiny changes, I would make a bigger thread relating to a single subject. While it goes against what the reminder on top the page is telling me, adhering to one-thread-per-suggestion would result in the whole first page filled with paperwork suggestions. I understand that the latter would be more unwelcome. Disclaimer: my current understanding of the underlying paperwork code is based off of these .dm files. The Aurora codebase does not appear to be different in any way. 1. Colors Black text on white paper is the paperwork staple. This is all well until you need to add large tables, make highlights in the text, or ensure that the front page of your 40-page fax to Central Command looks just right. Consider the following example: Other than tables, non-standard text colors would provide an unique aspect to every document. Firing someone? Why not use bold red letters to drive the point home? The possibilities are endless. How this would be achieved: For fonts: t = replacetext(t, "\[fcolor=$foo\]", "<font color=\"$f00\">") For tables: In paper.dm inside /proc/pencode2html(t); t = replacetext(t, "\[tcolor=$foo\]", "<table bgcolor=$foo border=1 cellspacing=0 cellpadding=3 style='border: 1px solid black;'>") t = replacetext(t, "\[trow=$foo\]", "<tr bgcolor=$foo>") t = replacetext(t, "\[tcell=$foo\]", "<tc bgcolor=$foo>") where $foo is a six-digit hex code. For paper itself: While colored paper does not appear to have enough RP potential to warrant introduction, the idea remains the same. [bgcolor=$foo] to . 2. Multiple fonts Currently, our clerks are only able to use Verdana, with Times New Roman being used for signatures. Considering BYOND is played on a Windows environment, it would be safe to add additional options, such as Georgia, Tahoma or Courier. How this would be achieved: t = replacetext(t, "\[font=$foo\]", "<font face=\"$f00\">") where $foo would be one of the font names. 2a. Teletype A special example of an additional font would be the tag, meaning Lucida Console in monospace. To the best of my knowledge, this is what printouts from the Cargo Bay already use. There is no reason not to extend it to any other printer on the station. How this would be achieved: Supported natively by BYOND under the tag. Replace [] to <> in the paper text and you're ready to go. 3. Abbreviations A long, technical text could be made easier to read by the end user if it could be shortened. This shortening could potentially be afforded by abbreviations - but as the matter stands now, any abbreviation could cause OOC confusion even though the character themselves wouldn't be justified in not understanding it due to supposed IC knowledge. The abbreviation tag would provide clarification and smoothen out roleplay. How this would be achieved: Supported natively by BYOND under the tag. Replace [] to <> in the paper text and you're ready to go. 4. Paperwork library We have a large library for all sorts of books. Why not for paperwork? Even today, most templates of papers are provided by the relevant authorities for you to print out, fill out and deliver for their consideration. With this feature, HTML experts could put a wealth of templates in the pre-existent library database for all sorts of characters to use, no knowledge of the code required. How this would be achieved: Allow access to library database (functionality as per library computer, minus printing books - single pages only) to station consoles. Introduce "paperwork" category for potential uploads. 4a. Digital checkout Instead of paperwork being presented in the current form of checking out a book and having it printed for you, the file containing the code could be downloaded to your console's hard drive for potential editing before printing (or easier volume printing). This would make editing of existing templates to suit current needs easier - why reinvent the wheel when you just need to change a few words to turn a material request form into a material delivery manifest? Whilst I recognize that the current system's limitations are in place for server security - making singularities out of paper was a bad time for all - I understand that the proposed tags would not open any new attack vectors. I welcome others to add their paperwork improvement suggestions to this thread and thank the developers for their consideration of my suggestions in advance. Any suggestions given will be added to the OP for clarity.