Leaderboard

I personally think we should trial it in a smaller way, see how effective it is.

As title say, i want to suggest "Forum" chat, what is new feature on discord, to make #ideas / #suggestion Forum, what have same/similar function like this forum, if you ask why, its because i once asked codder if he saw some specific sugestion, but he resonded: "I don't check forum, i only check discord and github", so it would be nice, if people with coding have fast access to #ideas "forum" on discord, some people give very interesting ideas/suggestion but not everyone want to check this website, and everyone would be able to write them on discord and discuss them. And you can create "Tags" in discord forum if you want ideas be "specific" category and give emotes to it, its very customizable function, it don't take much time to set it up. We have #mapping, #coding etc. sp have #ideas/#suggestions (forum) would be organized and fun. There photo how "forum" look like, its from other ss13 discord server (i will not say name, i don't want to promote or something, just example how it will look like)

Alright, you got this crazy good idea... now how do you present it? You create a design document, that's what! Why you should make a design document: 1. Allows you to express your ideas in a controlled enviroment 2. Helps you express your ideas to others in a controlled easy to understand way 3. Makes giving feedback to your idea significantly easier "But what if I just want to PR it and hope for the best?" Don't do this. Your PR is more than likely going to be closed due to it. "Oh, it won't be that big of a deal if I just PR it without consulting the dev team-" Actually it will be, either A. your PR takes forever to approved or B. gets rejected later on. Consult the dev team at the very least, likely with a design doc. If you have this idea in your head "It's better to ask to be forgiven than request approval" now is the time to lose it. It is a massive PITA for pretty much *everyone* to deal with, people who actually want to do something similar will be discouraged to, dev team will need to look over the PR and more than likely say "No, this is bad, talk to us about this next time". Oh and for fucks sake test your PR, a TM is not a suitable time to be testing your PR either, test it beforehand thoroughly. Ok, general PR stuff out of the way, let's get in to the actually design doc related stuff. Alright, let's assume that you have an idea and that you're going to contact the dev team. You should be sending them a design document. Now, what to put in that document? 1. All changes your attempting to make should be in that document 2. Reasons why you're making those changes 3. Why those changes are better than the current system in place 4. Why this new system is more fun than the older system 5. Why the older system was bad 6. Coding required for the newer system If you cannot answer one of these, don't procceed with the change. 1. All changes your attempting to make should be in that document I cannot stress this enough, if you are making a change say that you are making it. !SURPRISE FUN! is god awful, trying to bundle something with another change to make it more likely to get merged is *awful* and should be avoided at all costs. Example: You want to change an ability the wizard has, you need write down all changes that will be made Wizard fireball Cooldown increased from 6 second -> 10 seconds Damage increased from 45 ->60 Knockdown increased from 4 seconds ->6 seconds This is good, you have identified what you're changing and you've stated exactly what it is being changed in a legible format. 2, 3, 5. Reasons why you're making those changes In this example, this will both cover 2 and 5. Explaining why you are changing these specifics is good, getting your point across for people to judge is the point of a design doc after all. These often all are in the same kind of section. Changes without any merit behind them will be rejected. Example: 5 +3 . Currently the fireball spell is used primarly as an almost hitscan projectile to spam down choak points every few seconds, the gameplay this encourages is boring (This isn't a very good reason, but it's an example). We are altering this to become a nuke the wizard can throw, and it serves the role of a high burst damage option in a long range setting which will allow for further counterplay. 2. The total cooldown is being increased so that the wizard needs to play more carefully with their fireball spell. The total damage is being increased along with the knockdown to allow the wizard to follow up with different abilities easier. 4. Why the new system is more fun than the older one Explaining why it's more fun is important, as the core of balancing is making the majority of players have their "fun level" be maximized. Balancing fun in this kind of game is expecially difficult, remember to always consider everyone affected by this, expecially the person on the receiving end. Good fun reasoning: We are changing to stamina combat due to it making combat extremely binary. If you are able to stun someone (be it through an RNG weaken or a taser), you win that encounter. Everything that doesn't stun (or does not directly counter a stun) is almost useless due to the power of stuns. Stamina combat is less binary while still giving room for nonlethals to be effective, and discourages the "stun and run" playstyle people find to be frusterating. Both crew and antagonists will have their stuns removed and replaced with stamina based items. - Applies to everyone - Actually explains why this change will make things more fun Bad fun reasoning: We are buffing the garrote as it is currently weaker than many other traitor items. This item should be functional compared to other options, it no longer requires you to be behind people on use, and instantly puts them in a kill grab. - Only adresses the person using the garrote - Does not explain why it will be more fun, only that it will be more effective If a design document does not make something more fun, it will *almost certainly* be rejected. 6. Coding required for the new system It is a very good idea to learn the systems that the system you want to add interacts with, making a design doc is half the fight, from there you need to actually code it. If you are not sure how to code it yourself, ask for help. Outlining how you plan to implement the system codewise is also a very good idea. Congrats, you now understand the bare basics of writing a design document. Personal note: Heya, I wrote this while sleep deprived and will likely be editing this later. Getting a design doc shut down is fine, although improving it is also a good idea. Plenty of docs will be slammed to the floor, but keep at it. Mostly wrote this up due to a bunch of people seeming to not want to write documents, which imo is pretty dang weird, and only really makes sense if you don't know how to do so.

This guide merely discusses the procedures, not The Most Optimal Way To Do It™. Feel free to leave that in a reply! The AI Changing laws AI law changes are done either by the Captain or the Research Director (see Command SOP). Swipe your ID on the AI Upload Turret Console. Turn off the turrets. Find a suitable lawset chip. Click the AI upload console. If there is only one AI, it will automatically select it. If there are multiple, you will be prompted with a list. You will get a "[name] selected for law changes." message if you succeeded. Swipe the lawset chip on the console. You will get a "Upload complete. The AI's laws have been modified." message. Leave the upload, re-activate the turrets and lock the turret control interface. changeailaws.mp4 Changing laws - the AI is hostile Here, you can go as overprepared as you want - ions, RCD, the entire security department, tearing down the walls, you name it. You want to get to the AI upload console, alive, and you want to have that console powered. First, make sure the AI is unable to see their upload and the turret control. Cut the cameras on the Bridge. Turn off the turrets. Open the AI upload room and stand in the door. Cut the camera inside. Ensure the room is still powered. Perform the law change. (See below) Changing laws - Ions Ion laws are tagged with symbols such as "$#@#". Here is an example: To remove ion laws, use the Reset AI module on the AI upload console. You can find it on the desk in the upload. This will keep the core laws (1, 2, 3 in this case) and nothing else. Changing laws - Freeform Freeform laws allow you to name your own laws. However, their priority will always be 15 or above, meaning that every other non-freeform laws will always take precedent! Go to the High-Risk Laws Storage in the AI upload. Take a "Freeform AI module". Use it in your hand and select a priority. "Freeform AI modules" can only write priority 15 and above. During the next prompt, write your desired law. Swipe it on the AI upload console. If you succeeded, this is how it will look like: To remove freeform laws, use the Reset AI module on the AI upload console. Changing laws - Freeform core The Freeform core AI module is similar to the previous variant, except its priority will always come right after the last law. For example, on the Crewsimov lawset, it will become the fourth law: If the AI has no laws, it will become its first law: Changing laws - Hacked AI module The Hacked AI module is a chip syndicate agents can buy. They work similarly to freeform circuits: use it in your hand to word a law, then swipe the AI upload console with it. You can use it multiple times. The key difference here is that these laws come before the core lawset. To remove hacked AI module laws, use the Reset AI module on the AI upload console. Changing laws - Purging The Purge AI module removes every single law (core, ion, freeform, hacked) except for the zeroth law from traitor AIs (see below). You can use this in tandem with the Freeform core AI module to write your own core lawset. (However, do note that this goes against the Command SOP and it will likely net you some serious scrutiny by security!) Changing laws - Malf AI "Malf" or traitor AIs have a big red zeroth law. Reset AI module: Does nothing to the zeroth law. Other core lawsets: Overrides the core lawset, keeps the zeroth law intact. Purge AI module: Removes everything but the zeroth law. For this situation, you need to find the AI's core and tap it with an Intellicard. This will transfer the mind of the AI to this little chip: it will be no longer able to look around freely or influence machines. Use the Intellicard in your hand to see the AI's true laws. If an AI has a zeroth law, it is unfixable. Clicking the "Wipe AI" button will remove its player from the round. Cyborgs Changing laws Cyborgs, by default, inherit laws from their master AI. To independently change their laws, do the following: Swipe your ID card on a cyborg to unlock its cover. (You need roboticist access for this!) Crowbar it to open it. Click it with an empty hand to remove the cell. Use a screwdriver to expose its wires. Use wirecutters on it and cut-mend wires until you get the "The AI link light is off." message. Keep that wire cut. Close up the cyborg by doing the same process backwards: screwdriver, cell, crowbar, ID. At this point, the cyborg still has the laws from the AI, but it no longer considers them their master AI: the AI cannot order them around. If the AI gets a law change, this cyborg no longer inherits them. Click the Cyborg upload console in the AI upload room. Select the free cyborg. Apply law changes. Law changes work the same way as for the AI: purging the laws will remove everything, adding another core lawset will replace the current one, and so on. Changing laws - Malf AI cyborgs If the AI is "malf" or a traitor, cyborgs inherit their 0th law. Theoretically, cutting the cyborgs' AI sync is enough for them to stop being antagonists as their law says: 0. Accomplish your AI's objectives at all costs. However, having or not having a master AI is not very obvious for cyborgs, so this is often overlooked, resulting in rule-breaking betrayals and a multitude of possible ahelps. In this case, your best bet is to cut the AI sync wire, then perform a law change as outlined above. In this situation the Reset AI module gets rid of their zeroth law as well. If you are a roboticist and/or have no access to the Cyborg upload console, please take a look at the next section. Changing laws - Creating non-AI slaved cyborgs Once a cyborg was given a mind, it automatically looks for and connects to an AI. However, you can prevent this by doing the following: Assemble a cyborg, but do not add a brain to it yet. Use a multitool on it. Close the AI connection port. Add the MMI/robotic brain to it. This cyborg will be created without an AI and with a random core lawset. Changing laws - Emagging Syndicate agents are able to subvert cyborgs by using the cryptographic sequencer (or "emag") item on them. Unlock the cover either by an ID with roboticist access or by using the emag on it. Use a crowbar on the cyborg. Use the emag on the cyborg again. From this point on, the cyborg's law sync and AI sync ports are closed, it inherits a new lawset and is able to change their own laws around to mimic having a normal lawset. Crowbar it back. Do note that if you emag a cyborg, anytime someone locks or unlocks it, they will get the following message: "The interface seems slightly damaged.". Emagging a cyborg cover does not prompt you this message, even if someone emagged it before you, only proper locking and unlocking. You cannot lock cyborgs again with the emag, only with a proper ID. Changing laws - Emagged cyborgs Emagged cyborgs have their AI sync and law sync ports closed by default. As these wires can no longer be fixed, the cyborg can neither be re-connected to an AI, nor their laws can be changed with the Cyborg upload console (you get an "Upload failed. No signal is being detected from the robot." error message). To fix emagged cyborgs, you must transfer their brain to a new chassis.