Leaderboard

So in its current state, the Emag is a fuckin nightmare for Sec, Engineering, command, as well as anyone who owns the door that gets emaged. And its infinite use with no cooldown between uses. What i propose (kindly suggested by one Hal 9000) is that we add some type of cooldown to it. It could be -Small amount of charges but it recharges over time (maybe one to four charges at a time?) -may charges but it doesnt recharge -maybe add a recharger function to it, it has a few charges but you physically need to recharge the Emag in a weapon recharger All of these with some type of cooldown timer added to it, would make the user have to actually think about where and when would be a good time to use their emag instead of running around emaging every door that happens to be in their way. Making it less hell for engineering to fix doors because now they dont have to worry about the 13 other doors emaged while they where fixing the first one. Helping Sec because it would slow down the intruder as well as make it harder to just casually stroll into places ,such as evedence, with the funny all access card.

Name: Advanced Medical Hypospray (AMH) Desc: AMH is medium sized tool what can fit into satchel, tool can be aquired at RnD with 2 upgrades and can't store chemicals without upgrades: AMH Standard Chemicals - Installing this upgrade will consume all 100% capicity for AMH, it will have standard set of 3 chemicals used very often to treat patients: Charcoal, Saline-Glucose and Epinephrine. AMH Selective Chemicals - Installing this upgrade will consume 30% capicity for AMH, it will allow player to choose before installing with chemical (one type) can be stored in AMH (like menu choice where you have written all chemicals), of course this upgrade will need higher RnD research and mineral cost. Notes: - After installing AMH upgrades, player can change chemicals by clicking on AMH (similar how medic cyborgs choose chemicals to inject). - Players need fill AMH with chemicals they choosed. - Upgrades can be removed from AMH with crowbar (similar to PKA). Where Idea come from: I got this idea after playing few times as medic, and i really liked that hypospray can inject any chemicals quickly, but i like to hold 30units of each key fluid (glucose, ephi and charcoal) in 3 different hyposprays, so i tough one time: "What if there was hypospray what can contain 3 different chemicals in one spray" so i make reskin of basic medical hypospray, and want to ask to make it reality. Edit: I read all 3 comments (at time of editing it) and i thank you for showing me that i explained this wrong way, so i now will try explain it a little better and change upgrades from capicity suggestion to different. You can write comments if you think i still need change it more. Filling chemicals animation: -> -> ->

Something I've been planning for a little while now, a new set of syndicate bundles as well as rebalancing the existing ones. These haven't really been touched since 2020 and I felt changing them up a bit would encourage people to take a gamble on buying them more. You can find a full design document I've made for this here - https://docs.google.com/document/d/1ub1OMjx0yxr45YOqrBeWZycONnJRNbYPaBrM0Vezz-k/edit?usp=sharing The below is a summary of some of the information in the documents, though I would still recommend reading it for the full changelist. What's been changed at a glance? 7 reworked or modified bundles (Spy, Hacker, Bond, Thief, Bio-chip, Darklord, Professional) 3 new bundles (Agent 13, Infiltrator, Operative) 1 unchanged bundle (Payday) 1 removed bundle (Sabotage) Why change the existing ones? Mainly to change things up a bit since as mentioned prior, they haven't been really been touched since 2020 and the last new bundle added was back in 2019. Since then a lot of the things some bundles were balanced around (Sec borgs, instant stuns etc.) have been removed and more recently a fair number of syndie items had price reworks as well. Additionally, there were always certain bundles which I felt really needed a complete rework or removal, owing to them being very situational or not a long of fun for the traitor who received them (Hacker and Sabotage, specifically). Why remove Syndicate Encryption keys from most bundles? They were originally added to encourage multiple traitors who bought the bundles to team up with their specialized kits. Since codeword highlighting is now a thing it's easier and more common for traitors to use them instead, as well as some people not liking the encryption keys due to sec being able to use them if taken from a traitor. They're still in bundles where they fit the theme but no longer a freebie in every one, which frees up some TC in bundles for other more fitting items to take their place. If you have any feedback, criticism or further questions not covered above or in the design document, please post em below!

Thanks for the input, all of these problems should get delt with :>

I am on the edge about this idea, because I genuinely despise doctors hogging multiple hyposprays/handheld defibs. They were intended to be QoL items in the first place (no need to use epipens then litter with the empty injector), not something to bypass pill timers/patch requirements with. I believe cyborgs have a hypospray with multiple chemicals in it because they are physically unable to use pill bottles/patch boxes or administer pills/patches. Doctors are capable of all of this, and I don't see a situation where one absolutely needs to inject something instantly that is not epi or salbutamol (to keep the patient alive). I am not sure if people are not aware of these pill/patch containers and thus not using them or if chemistry has not enough active players for multihypos becoming the standard. The idea itself is good, cyborgs already have it and it is useful, but I don't think it'd be healthy for the game. People gotta slow down a bit.

this honestly should be a thing, especally when the blob renders the station unsurvivable via normal means and over 100% irrecoverable, I remember one cult round where a blob grew so massive it not only lagged the server it also somehow managed to outgrow a team of 6 DS including myself as one member and an SOO shooting it at once and it just speedrun style nyroom at our nuke and destroyed it despite taking direct hits, so the admins that round had to just, force instant-explode the station. also if the station hasn't even got any areas left safe from the blob, what's the point in even keeping the round going anyway, while DS can be fun, I think blobs should have a failsafe. maybe to make it a bit more fun, have a team of DS autospawn and have to arm and defend the nuke before X time where the blob just consumes the station TG-style. but yeah, easier said than coded...

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.

Absolutely. My biggest mistake with new tcomms was making it so easy to repair. I did at one point consider making the machine only able to operate in cold temperatures, but felt that may be too extreme. However, now the issue has been raised like this, I may consider it.