Anticept

Blades also need to be quenched or they will not have any hardness at all. After that, they need to be tempered, or crystalline matrix will have internal stressors, making them super brittle. If you just let it air cool, it will be like annealing it and will be a flimsy piece of metal. They would lose their edge the first time you tried to cut with them. Very makeshift indeed!

There's lots of way meta-knowledge could already be abused, but it's not as big of a problem as everyone says it is already; there's opportunities to become a sec borg, but in general it's not always meta'd.

That's what jobbans are for. Just as well, there doesn't need to be an incentive to drop alert levels if it's enforced at CC level. There's no justification to stay red a whole shift under this system. We could playtest this for a couple weeks and see how it plays out. Again: I repeat: THIS IS NOT A LICENSE TO KILL They must actively be impeding security. It's not "turn it into an excuse to manhunt". This is widespread, station ending danger. Not threat to a few individuals or command staff, but large scale, indiscriminate destruction. If this were implemented, I'm sure there would be more ahelps for a while, until people learn don't fuck with sec during a red alert. They SHOULDN'T BE FUCKING WITH SEC DURING A WIDESPREAD EMERGENCY PERIOD.

It's not to deal with traitors unless there's SIGNIFICANT damage or outright, blatant mass murder. Code red could also be called later in rounds on shadowlings, signifying when command has decided to go lethal on thralls. Edited that bit in. Abuse of code red could be met with warnings and further corrective action if it continues to be abused.

There's little point between blue and red, since most of the time it's next to impossible to actually enforce half the SOP items on the list. I would like to propose a change to alert procedure. Green: Same as it is now Blue: Essentially, is the red alert that we have now. For threats or suspected threats to the station. Red: Martial law. Screwing with security forces allows them to respond with any force warranted, including outright lethal if needed. They can brig indefinitely as well until the alert level is lowered. This is for station-wide emergencies, such as: widescale bombings (welder bombs don't count, nor do single bombs), blob, nuclear emergency, wizards, large scale violent riots, final stages of shadowlings. The key here is that actively impeding security or response forces itself creates more danger. Don't fuck with them. That doesn't mean security can just go around killing people at will. They must be actively impeding. But it does significantly remove barriers on security forces. Since it takes two swipes to use, it helps curb crazy captains anyways. Isn't crazy proof, but working around getting two head authorizations should result in CC crackdowns. The rest of the alerts stay the same, with gamma getting the same treatment as red with the extra equipment.

I've argued that the disabler cooldown could use some tweak. Even without rapid cooldown, it still can fire a lot of shots constantly. I feel that's a better fix.

Vampires, to me, have a potential to them. However, much of that is, as alffd said, is in roleplay. However, paradise is effectively, play to win. I can't enjoy building up roleplay with an antag without someone showing up trying to valid them. This is what has me enjoying baystation so much when I'm not feeling up to playing on Paradise. Antag knowledge is restricted, and greentext doesn't exist, so they have much more freedom to interact with the crew in their own creative ways. Most antags on baystation are not automatic valids just because they happen to exist. I've had rounds on baystation where I've been on the edge of my seat because the antags were building a great fucking plot. While I would love to see some of this adapted to paradise, the fact is, until the drive to play to win is changed, I don't think good roleplay will ever be appreciated.

This is now official! Remember: THIS PROCESS IS ENTIRELY OPTIONAL It is RECOMMENDED for large code changes, but still optional.

It's "representative", not represenative. The first and foremost importance of being a professional is spelling your own title correctly!

Doop, buzwarn (sp?), and bizwarn are others.

It's still quirky (VERY quirky) and can get annoying from time to time, but very good. It's a voxel based construction game. Video is worth a thousand words. This is probably one of the best videos to showcase.

@tzo I still vehemently disagree with your belief that genetics should be science. They do fit a duality, which is probably how we got here in the first place, but the end result, as well as some of the important mechanics, are medical. Same with virology; t's a research type of job (RNG heavy but none the less), but it is ultimately still medical. Further, they often need to deal with radiation and mutation treatments; something that is a better fit for medical access for the refrigerator, than using scichem. If not made as part of medical, then honestly, I think that we should stop interpreting the fact that the geneticists answer to two heads as a "requires both of their approvals," and instead state simply that they have two bosses, both with full and INDEPENDENT rights.

Edited a bit more. But yeah, you get the point.

I edited it a bit.

My personal thoughts on SOP: First, there should be tiers of SOP. The first tier isn't really SOP, but instead job specific regulations. These regulations are portions which MUST be followed, or punishable by demotion/brig time. These are items with VERY serious implications if not followed. Production of combat mechs, for example, which are not turned into the armory, creating dual+ engines in engineering, or use of contraband. These would be things that require the relevant head of staff's/captain's WRITTEN APPROVAL to make an exception for, if it were even allowed by regulations period. They would get their own crime and punishments written right there in the regulations (brig time, demotion, community service would be examples), and make an entry in space law that mandatory regulations may have their own penalties. NOTE: Mandatory regulations would essentially be like space law. These are only a few things which, if not followed, present a MAJOR hazard to the station and crew. Mandatory regulations should be kept to a reasonable minimum and and only be written for extreme cases. The reason these aren't thrown in with the rest of space law, is it could result in a huge amount of space law bloat. It would be better to put these in with job specific information while sec continues to be concerned with general criminal activity. Then, there's SOP which is *recommended*. Engineering backup power generation methods, for example, are *recommended*. Example: solars and turbine are backup when the engine is running ('backup' could be anything the CE decides, like if it's a solars only station and turbine is brought online). However, I do not believe these should be enforceable, UNLESS events occur in which demonstrated incompetence occur (meaning, after the fact). For example, I don't bother with solars and turbines when I have an engine running. They actually make it more difficult for me to respond to power grid problems of way the grid works. I end up having to take extra steps to detect where the failure is as a result, instead of just following the discharging APCs along the station's grid backbone. I don't stop any engineers that volunteer, but I never do them myself as I can reroute power pretty damn fast and I don't like it when captains tell me to do them and don't listen to my reasoning when I recommend against it. Then there's actually optional SOP. This SOP is standardized suggestions for organizing departments. A head can ask their subordinate to reference it, instead of typing out a big long list of what they want done. But, the department could choose to deviate too. Delegating tasks to the medical front desk, for example, for minor injuries, while major ones are sent back to more specialized doctors, would be an example of optional SOP. The head of staff needs to be trusted to do the work too. Captain should not be micromanaging. I admit, the captain can still get involved, but it's *recommended* that they follow the proper channels (note that *recommended!*). Also, we need to change the SOP books that are in game. They need to reference the wiki. I think science robotics has some books that are a little out of date. Finally, fucks sake we need to address paperwork. People are inventing giant long forms which are becoming an increasing pain in the ass just because they can. That needs to stop. I'd like standardized paperwork forms and that's it. P.S. we really should put in space law WHY the punishments are so lenient in some cases. It really should explain that it's not meant to take an antag out of the round if they slip up on something minor. It's written around the idea of making it punishing for their mistake, but not round ending.

I do see the merit in this, but also the annoyance. What about a 300 degree view to sort of simulate how people normally look around, but not crane their neck to look behind them? You can see all around except directly behind you. Someone could sneak up and attack people from behind, but the blind spot would not be annoyingly large.

... why not come up with more unique things for the cyborgs then? Yes, they are kind of out of place, but I'm still not convinced tossing them out would be the answer. Software viruses for example. Damage areas too. Not quite in the same matter as the other player entities, but something mechwarriorish. Targetting arms can destroy their weaponry. Targetting legs disables and even stops them from moving. Targetting their chest could damage their power systems. Head for sensors and communications. Stuff like that. Easy to destroy a subsystem (IPC like), but would take some doing to completely destroy it (enough chest damage and you can just pull out the posibrain). They would still retain their vulnerabilities to EMP and flash.

Look. To make it real simple. The crew played smart and rolled up a force to be reckoned with. Shadowlings also have sonic screech. It's a pretty powerful ability. Fire one of those off and escape is easy, even with a large mob. I KNOW sec borgs are powerful because of that disabler. The rest not so much without upgrades. The only part that I think needs adjustments is the disabler. Outright deleting secbogs is an *extreme* measure. I'm much more in favor of doing small changes at a time.

Which is why I say, the biggest issue is their disabler spam. The rest you can usually get away from unless you really fuck up. As for security: HoP can open a sec slot every minute.

They aren't omniscient. Just get out of sight! That said, a mob of secborgs... just shadowwalk or whatever to the other side of them to the areas they already cleared?

It's piss easy to stop a secborg. Just flash it. A mob of them I can see being a problem, but so would a mob of lethal armed security. That said, people need to practice running more often too. That includes flashing a secborg and just getting the hell out. People don't need to try and kill everything they run across... sometimes it's better to just disarm/disable and RUN. One part I am in agreement with: greatly increasing the heating on the disabler. Even without rapid disabler cooldown, it's still pretty spammy.

Also shadey is right. Typically the only thing people really care about is being killed. Theft is almost treated like a chore for sec to investigate. Rarely does RP itself make things interesting without the threat of death.

Shadey, I'm talking about antags that don't replace the existing ones. Completely new slots. And they would indeed be a low priority. If both are turned on, the standard antags would roll first.

They wouldn't replace the existing antags. They would be roleplay centric antags that are less about syndicate, and more about interesting story potential. It's something that needs a lot of thought and planning, but it's not meant to be the same greentext stuff.

Preface So you want to contribute to the Paradise SS13 project? Awesome! There’s a couple ways you can go about this. You could just simply throw up a pull request on https://github.com/ParadiseSS13/Paradise and wait to see what happens to it. This is great for simple changes and bugfixes. If it gets turned down, then you haven’t spent much time on it. However, If your intention is to contribute something that you are spending a lot of time on, then STOP for a moment. Remember that staff are under no obligation to accept your contribution. We don’t want to see you spend a lot of time developing your idea, then have it shot down because it doesn’t fit what Paradise is trying to accomplish. We don’t want you to burn out because your code got rejected. That’s why there’s an OPTIONAL process you can use before you start laying the first lines of code, called the Proposal & Review process. In essence, this is more than just a 'suggestion'. A proposal is an idea you've taken beyond just the idea stage, you've organized it, considered its implications, and given it a lot more thought. It's become a PLAN. A proposal lets the staff and you about your idea a bit. If they like your idea, then you are far less likely to waste large amounts of time developing, as you’ve already got your foot in the door. You might even get help from various people to implement it! Writing a proposal really gives you a chance to think about and organize your idea. Often, an idea that sounds good in our head is under idealized circumstances, and once you really start considering implications, those circumstances can often fall apart. You really need to give some maturation time to a major idea, and a proposal is one way of doing it. Remember. Writing a proposal is OPTIONAL, but HIGHLY RECOMMENDED for more than bugfixes and simple changes. Ultimately, it’s your own time that is wasted, but that’s still valuable time to you, and to the project. Time that you spend on an idea that isn’t well received, is time that could have been spent on something that IS well received. This is the recommended way to go about writing a proposal. Each step assumes the previous one was successful. Draft a proposal. Encourage feedback during the drafting process from your trusted peers. Create a few small, simple examples if you can, like with sprites. Don't do drafts openly. This is your DRAFT. It’s not even close to ready, and throwing it out in the open at the start of an idea is bad. You’re going to end up with people throwing wild ideas at you, and by the time you are done, it’s not even going to resemble what you might have had in mind. Design by Committee often doesn't work. You're having dozens, maybe hundreds of players scrutinizing the shit out of it with little actual vested interest. You're going to rally a bunch of support for something that might not honestly even be possible due to technical limitations. If it gets shot down, you're going to cause a bunch of rabble rabble. Just don't do drafts openly unless you are TRYING to start a shitstorm, and don't be surprised if you get shut down because of it. This almost never ends well. Refine your draft into a proposal for review by staff. I would even suggest having at least a partial development plan done if you expect to have any points scored with the maintainers. Listen to their feedback, refine your proposal, or shrug and be thankful you didn't waste a whole bunch of coding time. You need a WELL DEVELOPED proposal. You are being GIVEN their limited time, so make full use of it. Submitting an amateur proposal isn't going to reflect well on you or your idea, and you shouldn't be surprised if it gets shitcanned because it looks like it would have been better done submitted in crayon. Examples are included later in what constitutes a good proposal. READ THEM! You want the first section to clearly address what it is you are adding or changing, and YOUR reasoning for doing so. Don’t leave it up to staff to try and guess why you are making this change. This seemingly innocuous part of a good proposal is actually quite important! Include a development plan. Can development of your idea be broken down into small, testable chunks? If so, DO IT! You WILL save yourself a LOT of heartache. Make sure the staff see your development plans too! When you try to make really large changes that take a lot of time to finish, you’re going to end up with merge conflict problems. Breaking things down into small bits avoids a lot of this, and also makes it easier to hunt down bugs. This also makes things much easier for people to contribute development time to your idea as well. Now for the hardest part. Submitting the proposal for PUBLIC consumption. You need to convince the playerbase that your idea is a good one, while still staying within your vision and what the admins and maintainers approved. The staff should monitoring and participating as well. Someone might make a really damn good point that causes you to do a big change, and you WANT staff to be part of it, because again, they are the ones that ultimately decide if it’s go/no go. Take the feedback you get, and further refine your proposal. By this point, the design is largely already done, so much of the discussion will revolve around refining the idea, rather than getting a ton of random suggestions. That’s another reason why you don’t publish your work in progress draft openly! Begin development! You're starting the longest part of this road! But the light at the end of the tunnel is within sight! Submit each chunk for review and testing, if possible, as PRs on github. Your idea, or portions thereof, could still get scrapped. Don't write off the possibility. Technical limitations can be encountered while implementing your idea, causing the whole thing to become infeasible. Or there’s a shift in philosophy and now your idea no longer fits the paradigm. That’s why you are encouraged to break it down! Tips for writing a good proposal: First and foremost. The less people have to assume, the better. It’s your idea. You need to convey it. If you leave gaps for other people to fill, they WILL fill it, and quite possibly with details that you didn’t make or intend. So that said, spend some serious time thinking through your proposal. For relatively small changes, this will still go relatively fast. For major overhauls, it’s strongly recommended you spend some serious time on writing up a good, solid proposal. You’ve already convinced yourself it’s a good idea, but now you have to convince others. Organization, spelling, and grammar You want to know the biggest thing between a good and a bad proposal? Presentation. If it’s well organized and doesn’t look like a 3 year old wrote it, people will spend more time reading it. That’s what you want, right? Imagine you are the hiring manager for a company, and you got a hundred applications. Chances are, you won’t even get past the first section of a resume if it is just a bunch of random things put on it that doesn’t flow. That’s the fastest way to get it sent to a recycling facility, and the applicant back applying for more jobs. On the other hand, even if the content is only okay but it LOOKS great, you, as the hiring manager will likely still spend the time skimming the first page! That’s just human nature. Fight it at your own risk. Remember. You are GIVEN staff’s limited time to look at your idea. Make it count. If you are crap at writing, find someone who believes in your idea who can help. Hopefully the way this document is written can give you some ideas on how to organize your proposal, because it was designed to do exactly that! If you follow the chapter “Recommended elements to include in your proposal,” it’s basically an outline! Recommended elements to include in your proposal: A Super Quick Summary What Your Proposal is for Keep it short and sweet. Details come later. What, at a glance, are you trying to do? Are you trying to add a sepia display filter for vintage feeling screenshots? Are you trying to add an item that allows double-jumping? Are you trying to add enumeration support to the code? These are already examples to show what I mean by a super quick summary. This could even be your headline! The important thing is to keep it a one or two line lead-in for your proposal. Your Reasoning and Justification. That is, your OWN reasoning and justifications. Don’t insert words into other people’s mouths. It’s a great way to start off on the wrong foot. You can still include links and sources to back up your claims (including links to other’s opinions), just don’t speak for anyone without their permission. Stick to what they’ve said if you are going to include them in your proposal. Examples: Bad: I’ve been talking to everyone, and we’ve all agreed that this part of the game sucks, and it’s about time that got changed. Who is everyone? That’s a pretty broad term to use. What “sucks” and why? This isn’t a helpful justification for your proposal. Good: I’ve been talking to everyone, and we’ve all agreed this part of the game is frustrating to play. The enemies are overpowered, there’s not enough engagement, and I find myself struggling to continue. A lot better. Still not defining who “everyone” is, and is probably inserting words into their mouths, but now we have something to go on. We can address specific elements and understand WHY you think this part of the game sucks, which is the biggest point you need to make. Best: I’ve been talking to playtesters John, Mark, and Tom about this part of the game. I find this section of the game frustrating to play, and they agree with me. The enemies are overpowered, there’s not enough engagement with some of the gameplay elements and are tedious at best, and I find myself struggling to continue because I have to restart several times from bugs. This is a GREAT way to state your reasoning. We have names of people and what they do, which carries a lot of weight. It just makes it sound so much more… important! It actually sounds like something that REALLY DOES need to be addressed now, and you even gave us the elements that specifically motivated you to make the proposal! Details of Elements that you plan to add, change, or remove. This is the meat and potatoes, and THE SINGLE MOST IMPORTANT PART. It’s pretty self explanatory what exactly this element of your proposal is trying to accomplish, so let’s focus on HOW you can make the most impact with this section. First, details please! Don’t leave things open for assumption! This is especially bad when someone doesn’t agree with your idea; they will be inserting their own assumptions with a negative spin, which means now you have to fight on their turf before you can argue on your own merits. That isn’t easy. That said, you need to carefully think through your idea. Abandon your preconceptions! If you have to make an assumption, so will someone else! Avoid using uncertainties excessively. “Maybe”, “Could”, “Might”, etc. are uncertainties. You’re the one making the proposal, be confident in your idea. You can propose alternatives or ask for feedback, but be assertive! Focus on the information people need to know, and keep the superfluous information minimal. Generally, it’s superfluous if you can take that information out or move it around, and it is making no impact on the point you are trying to make. Examples: Bad: I’m going to change the enemies so they are easier. They won’t die quickly enough! It’s a hard fight and I can’t seem to win! There will be more things to do, maybe some crafting, and an extra gun or two. This is amateurish. Don’t submit such dribble. This is what you say during a discussion, but it doesn’t belong in a proposal. A proposal is a formal piece of writing. Plus, there’s redundant crap that doesn’t need to be in there. Good: I’m going to change the enemies so they are easier. There will be some basic ammo crafting recipes to offset the ammo shortage, and two extra gun drops in a secret room behind the painting that will give more flexibility to the player to approach the upcoming fight. I am hesitant to call this “good”, but it does provide enough info to get an idea of what direction you are taking things. Best: I’m going to reduce the enemy health by 25%. There’s a hitpoint imbalance that I am addressing, which stems from the fact that I run out of ammo during the fight before I am able to find more. I also will add a simple crafting recipe to allow players to create more ammo from the scrap lying about, approximately three bolts for each piece of scrap, so that they don’t have to rely solely on finding ammo drops. That will add about 30 more bolts total in the level from crafting. Finally, as a bonus for exploring, there is a painting in the foyer that will have a corner torn and partially reveal something behind it. It will be a hidden room with two specialized weapons, one for sniping, and one for up close and personal brawling. Each will have advantages at different times in the fight, but these won’t be required to win. This is a BEAUTIFUL piece of work. We know exactly what you plan to do, and why. We have lots of information regarding your idea, leaving little to be assumed. Plus, there’s little superfluous information, helping to keep the reader focused. Concept Art Concept art does a fantastic job of helping illustrate how you think your idea will look when implemented. Concept art is something that isn’t applicable for most things, but does a hell of a job of improving the quality of your proposal for things where it is applicable, IF DONE RIGHT. Stick to showcasing the main elements of your idea. Concept art is basically a REQUIREMENT if you intend to change… you guessed it, ART ASSETS! Describing art in words is extremely tiring, both for reader and writer. If you intend to change a bunch of sprites, for example, include a couple of mock ups. UI elements also benefit greatly from concept art, because it’s difficult to visualize complex elements. UI concept art doesn’t have to be a visualization of the final product though, just stick to approximations. You don’t have to make concept art as good as your final product, as long as it gets the point across. There really aren’t many tips that can be given here about what concept art should consist of, that’s something you have to decide how much is enough. Ultimately, the more time you spend on concept art, the bigger the impact it will make! Example: Consider the following proposal change element to a UI: I want to change the configuration settings from just input boxes, to sliders and input boxes. When you get past three quarters of the scroll, it will accelerate greatly. The first three quarters will go from 0 to 10, the last will scale from 10 to 100. Example: See what that does? Even in this simple example, it says SO MUCH when you make a piece of concept art! It didn’t even need to be something crazy professional; it still makes the point perfectly! Development Plan This is the part that appeals to the coders. It’s also the section that will greatly vary from idea to idea, and may not even be needed in some cases. Mainly, you want a development plan for BIG ideas. Things that do major additions and/or overhauls and require significant investment in time. The biggest benefit to a development plan, is the ability to break a big idea down into small, digestible chunks. Generally, huge additions aren’t terribly difficult to implement, but huge CHANGES are. They are worlds apart. If you can break down your change into phases, this is much more likely to get through the approval process as things can be done in small steps, and to observe the effects as each step is done. As a side note, the other useful and important thing about breaking things down into smaller chunks, is it makes it far less of a pain to eyeball your code. Short, small changes are much easier to digest and review. Big changes taking a dozen pages are a pain. Anything larger than that, and good luck getting ANYONE to dredge through that anytime soon. You’ll have to decide how you want to lay out your development plan, and this can vary a lot too. Just keep it organized and intuitive to follow. The more detail you place into it, the better, as you can also use it as a sort of roadmap when you sit down to code your idea. As an example, if our idea is to change weapons from hitscan to projectile based, that will probably take a lot of work. Think about all the time that has to be invested in something like that. Now, what if I told you the game engine you are using doesn’t support projectile weapons, so it’s something you have to spend time on as well? It gets daunting. Yet, if you break it down enough, it becomes manageable. Like so: Phase I, Implement projectile physics in the engine This phase will assess the feasibility of moving to projectile based weaponry physics. Select an appropriate physics library for use in the game based on expected operating parameters such as projectile speed, rate of fire, and complexity of firing solutions. Create test cases to measure performance Test multiplayer compatibility Compile results for review Phase II, Refine and alter library to our specific circumstances. Take data from Phase I, to make alterations with the following in mind: Changes to networking code to optimize projectile prediction on clients Alterations to the library as needed to better fit operating parameters. This will be further defined as development progresses. Determine what properties each weapon needs to have and test. Evaluate edge cases for re-design or stripping from the game Phase III, Convert weaponry Polish implementation of weapon properties and functions regarding use of new projectile physics. Test and re-balance weaponry as necessary. Ship it! Laying out a development plan like that shows you are also considering the technical aspects of implementing your idea. Complex ideas really should have a development plan! Closing Thoughts Ultimately, how you format and write your proposal is up to you. As mentioned, this is an optional process. You could take everything suggested in here, throw it out the window, and do everything from the ground up your own way. Just remember though, that the people reviewing your proposal will have certain expectations, so you really need to hit a homerun if you decide to deviate. Or, if you chose to forgo it altogether, that’s up to you. This is a suggested way for you to work with staff and the community to get a feel for your idea, to help you save time in the long run! Good luck!