Leaderboard

Good point! I didn't really consider hackmd.io. It's not something I've really used before, but I'll check it out and edit my above post with a hackmd link whenever I set it up. I never really cared about google doc doxxing (oh no, my real name, there's only a few thousand other people with it or so haha), but I can see why some ppl might not want to use it. The default speed for non-hunter Xenos is actually the exact same as the normal human walking speed, so all that really needs to be changed (if at all) would be a small increase in speed on weeds (or reduction in speed for humans on weed). I definitely do want to encourage Xenos to weed as much of the map as they can as 1. it's a good indicator for people as to what areas are not vulnerable to Xeno attack and 2. it adds a new and hopefully interesting dynamic to the gameplay. It's an interesting idea to have hunters lose the speed buff when interacting with things... however, it seems complicated to implement. It's definitely food for thought, but hunters could also be balanced by just simply reducing speed (and increasing health if necessary). I'd say the general goal for the caste would be a, well, lone hunter who can pick off single targets. Hunters have a leap ability (practically never used on Para because it's unneeded) that gives them the ability to floor any single target if they can land their leap. Combine it with the hunter being able to stealth, and you've got a great ambush caste even without a ridiculous speed buff. Mechs are another story, though. I've not really thought of using something like resin to slow them down. Mechs are already (generally) slow and Xenos are criminally ineffective at actually damaging them currently. Stacking an effect on mechs is an interesting idea, although with my inexperience in coding I will definitely need help to implement something like that. I've had suggestions to have an acid effect which degrades mech armor the more it is applied as well. I'm leaning more on the side of enabling more damage to be done to mechs as Xenos are already universally faster than the majority of mechs. Traps and doors are a great idea however. I would honestly really like to make it so that mechs cannot pass through xenomorph doors even if they are open, as well as having traps that either ensnare or damage mechs. I'm leaning a little more on the ensnare side for traps, as a big burst of damage from something unseen may be frustrating on the receiving end, but it would definitely need testing. At the moment, I'm looking at making larger, limited castes that act as a Xeno equivalent to a mech, being tankier and dealing more damage towards mechs to give Xenos a reasonable counter to them. It would be both relatively easy to implement and could provide a good solution to mechs without much hassle, although balancing them in a manner which makes them fun to play and fun to fight might be tricky. As it stands, my general plan for acid is to have a weaker acid that can melt smaller or weaker objects over time and a stronger acid which is capable of melting through walls and things. The plan is to make pretty much everything take a long time to melt. Ideally, it would vary based off of the size of the object, but current acid code is an absolute mess and to be honest, it needs to be completely reworked. I'd also like acid to simply not be applicable to items or objects it cannot melt, such as applying weak acid to walls/reinforced walls and such. Adding a weak regen that's buffed when on weeds is definitely on the table. It would prevent a lone Xeno from running completely dry and being helpless if it somehow got cut off from the hive (maybe it's the last one left). While it might be lore-accurate, I don't think it would be very fun for the leftover Xeno(s) after the hive is gone. To be honest, while I appreciate the excitement it will be a while before anything here gets fleshed out. I've considered recruiting a team to work on this as it's quite complicated and I am new(ish) to coding for Byond, but I don't really know how well that's typically received on Paradise or if anyone is willing to contribute.

I'm so happy to see this coming back again! I've been playing a lot of TGMC lately so I'd be really excited to see beno gameplay get the attention it deserves on paradise. If I may, you might want to try putting your design doc up on hackmd.io. It respects GitHub markdown (even summary tabs and stuff) and can be commented on with threads and stuff, so it might make it easier to review/go through especially for people who don't want to doxx themselves on google docs I might as well spitball some things here, I'd put them on the doc but I don't have a good anonymous google account. I can definitely move them over if this goes onto hackmd or something. For a counter to mechs/robots, I feel like we're looking at some creatures that what they lack in damage output make up for in CC. Perhaps it could make sense to adopt the concept of xenos firing non-destructive sticky resin to gum up mechs, slowing them down or slowing down their weapon fire-rate? Crew could possibly burn it off with a welder, lasgun, or flamethrower, a mech won't be able to really solo a hive without literal fire support from (possibly vulnerable) humans. Something like sticky resin traps, too, or perhaps door-like structures that xenos and humanoids can crawl through, would provide some interesting environmental gameplay in the tight confines of the station. I really like the idea of giving xenos a speed buff on weeds but making non-hunter xenos as slow as humans off of them, if not a bit slower. Xenos are supposed to be agile, but this gives them a mobility reason to weed everywhere they can. On the topic of speed, hunters could perhaps get a speed boost out of combat, but lose that boost after interacting with something (like dealing damage or trying to drag someone off). I agree that one of the biggest gripes people have with benos is getting stunned and superspeed dragged through the halls back to the nest, and it might be nice to see something addressing that. Regarding acid, I personally think it makes sense to keep wall-melting acid expensive. Xenos have all of these great movement tools at their disposal and so maybe it would make sense to force them to use them rather than busting down any obstacle in their way. Maybe keep it slow to finally destroy walls, but consistent (only needs one application)? Lastly, I think there should be some sort of passive, weed-free plasma regen, though it should be very weak to encourage weeding. The regen speed would need to be slow, and perhaps its amount could be capped per xeno to only allow for a base ability. If it's under consideration at all, I feel like it's a necessity that drones be able to at least regen enough plasma to plant weeds. I really like what you've got cooked up so far otherwise! Can't wait to see what comes out of it, and I'll definitely be keeping an eye on it

Greetings everyone! As some of you've noticed (at least I hope you've noticed) that I haven't written a monthly wiki update in 3 months. This is for a few reasons: I'm busy with college; I've been focusing more on interacting with the community through events and adminning; It is not healthy to lead development on a wiki and not takes breaks. Now that I've said that, I have been working on plans for this year and even past that in terms of where we can improve our wiki. Our wiki in its current state is far from perfect. While our content is up to date and our templates look pretty, there are still some basic principles and structures our wiki is missing. Normally I like to do a changelog but that is not the purpose of my forum post today. This is a brain dump of a lot of thinking I've done. It's not perfect. However, I want to provide direction for our contributors because what "wiki-development" is becomes a bit muddy after everything has been brought up-to-date with the codebase. What are the issues we need to tackle? As I’ve pointed out, our content is far from lacking, it’s almost completely up to date with the codebase excluding location based information. I will start with the larger (in scope/size) and the most important issues first and then work my way down from there. I know our wiki has made a lot of progress but I'm going to tear apart and criticize our wiki to the fullest extent possible. Please bear with me. Wiki Navigation Problem: This is the issue I view most in need of attention. What is wiki navigation you may ask? When someone opens our wiki, they see our main page with the cutsie splash and plethora of navigational divs outlining the many sections of our wiki our reader can explore. If you find the right link you can jump into a breakdown of our role pages, antags, guides, lore, and a bit more. We do a solid job linking most pages in our main page and it’s child pages. However, It’s just simply not enough. I should be able to take a brand new player who has never seen the wiki, tell them to find info on a specific topic, and expect them to find that exact page/info without external assistance. In addition, a player with some experience should be able to navigate from an end-node page (see tree chart structures) to another end-node page in a completely different category in only a few (3-5) page jumps. Solution: Portal pages with proper intersectional navigation with links to all relevant articles that would fit under the portal’s category. Category tree: every page has a minimum of one static category and a max of 3 static categories. Of those categories there should be a page type(guide, SOP, location, job, etc), if needed-> department (supply, service, etc), and misc categories (out of rotation, archived, etc). Not this does not include variable maintenance categories. Smart naming, use of anchors, and redirects to allow complete and full use of the search bar. File names need to have uniform naming, any reasonable search term needs to redirect, and any specific item on a table should have an anchor associated with it. Commentary: Why is this the most important you may ask? Well, what is any of our work worth if a player cannot find it. Article Quality and Structure Problem: How we write each article can be wildly different. Currently if one was to take a gander at the Guide to Engineering, Exosuit Fabricator, and the Guide to Genetics articles they would find that the prose and style of them is wildly different. How the information is structured and presented, how other articles are linked, how much humor is used, how sentences are bolded and italicized, the objectivity of the article, how templates are used, how the article introduces itself, and how friendly it is to new players varies to such an extreme degree between articles that it would be hard to say that most of our articles follow similar standards at all. As it stands, trying to read through articles one after another can be nauseating. When a reader goes into an article expecting like-structure from another similar article only to encounter a totally new style/prose their brain is immediately boggled and at a disadvantage for learning. In addition, when we don’t set these uniform standards for our articles, basic important knowledge is not included and much transitionary/body/meaty information is left out. Solution: This falls mostly on me to push. We need to establish a proper multipage Manual of Style and Guide to editing the wiki portal. This extends to everything: Templates, Files, Articles, Categories, and much more other nuanced things. Commentary: By establishing standards in a document, teaching our contributors proper technique, syntax, and style is much easier and it would allow our writers to attain a higher ability in wiki editing much quicker. Wiki Contributor Team The Problem: At the beginning of 2021, the wiki contributor team was dead outside of 2-3 people that periodically updated the wiki. Since then, it has been rebuilt into a group of roughly 6-8 people (although losing steam this year again) that regularly update the wiki to varying degrees. Some people are better at grammar, some are versed in images, and some people are good at styling. It’s a good balance but we can always get more contributors. I want to address two issues in this category: our atmosphere and contributor training. First, our atmosphere. I was ignorant of this when we were first developing as a community but we’ve adopted (and since have gotten better at avoiding) some bad behaviors. When someone comes to our channel with a wiki-issue/error we cannot just say “go fix it then.” This is the same as telling someone “when you code it” (WYCI) and then providing no guidance as how to code it. Our goal as wiki contributors when interacting with the community is always first and foremost to be receptive in ways to improve our wiki and second to enable outsiders to join our community and learn how to edit our wiki. I will never be negatively critical of anyone's work and neither should anyone else. Going forward I will absolutely not tolerate hostility. That is not to say you cannot criticize others' work or point out errors, but there are ways to constructively do this. The Solution Call out bad behavior. If someone leaves out important information or is clearly missing something, your first action should be to ask more questions and politely provide clarification where needed. If someone is being an unabashed dick, @ me immediately and I’ll sort them out. Files The Problem: An inherited issue from years of bad file organization has been biting us in the ass. Mediawiki has an awful search algorithm. If someone named an image of Xeno Meat Bread something like “xenobread” or god forbid “xbread” you will never and I mean never find it through the search engine. You have to type the exact name. This is why we have duplicate images and why when we write new articles we cannot find relevant images that already exist on the wiki. In addition, the quality of our files varies. While we have nailed down the standard 64x64px we haven’t nailed down what state the item needs to be in, if it should be a gif it has multiple states, and the frames/sec for those gifs. Solution: As part of the Manual of Style we need to develop guidelines for files on our wiki. A.K.A what size is ok, what quality, gif or png, naming scheme, etc. Once the guidelines have been ALL WRITTEN DOWN we should be going through all of files and standardizing them as much as possible The Plan for 2022 Alright I’ve had enough fun nitpicking our wiki, here’s how we can make it the best in the SS13 Community. Finish Every Portal Page What is a portal page? It is where EVERY job, location, guide, misc article for a specific topic is linked. This is important because if I'm looking for information about a feature but I only have a general idea/don't know the name of the feature it will be very difficult to locate it. Instead if I know it's related to a specific department I can begin looking in its portal. Not to mention this will allow us to identify holes in wiki where information/articles are missing. Each portal page has a uniform structure to it, it should be simple enough to set up. Every department portal page should list the roles, guides, and locations of the category it’s designed for. For other misc portals like the new player, wiki contrib, troubleshooting, and github contrib portals there will be a slightly different structure (with the same design however). Here are all the portals that need to be finished/made: General Service Supply Medical Security Engineering Research Command Antagonist Legal Special Role Wiki Contributor Github Contributor Technical Troubleshooting New Player Game Mechanics Lore Development of a Manual of Style We need to develop a fully fledged manual of style. The following pages will need to be created and written for it: Typography - Italics, Bold, Strikethrough, font size, underscores, colors Layout (By Page Type): Introductory Paragraph Body Paragraph Heading Naming Splitting articles up by sections When, where, and how to use images Where and what templates to use What Information to Include Templates Wikicode Standards <noinclude> documentation Styling Standards Files Images Gifs Naming Scheme Prose Objectivity/Bias Guiding vs. Telling Humor Writing Perspective (1st, 3rd, etc) Paragraph Structure Content Quality and Quantity of Information Readability Flow of Information Over/under-use of Interlinking Article Size and Scope Accessibility Categories/Category Trees Portal Pages Disambiguation Pages File Standardization While non-admin contributors cannot delete pages, what they can do is mark them for deletion as well as move them. By moving a file they “rename” it. Just make sure to go through each page where that file is referenced and fix it. Capitalization of Files Spacing of Words (A.k.a SecurityOfficer (wrong) vs. Security Officer) Naming of Files (Xeno Meat Bread instead of Xbread) Gif Speed must almost always be 1 frame/second. However guns should be 2 frames per second, actual DMI gifs should be their native speed, and misc gifs like changelings should be whatever works best. Going through pages one-by-one Once a manual of style is developed, every single page on the wiki needs to be gone over with a fine-comb. This is by-far the heaviest lifting objective. This is something that would have to be done gradually over time. This is not my priority and is something that is very very long-term. Current Rating of articles on a C, B, A and Good Article scale Go portal by portal and fill in any missing gaps + rework articles Development of the Following Pages I’m just going to list the pages that need to be created or completely rewritten (or the rest of the content filled out) Command Pages Guide to Leadership Guide to Problem Solving ??? Service Guide to Cleaning Github Completely Rewrite Guide to Spriting Completely Rewrite Guide to Mapping Completely Rewrite Guide to Coding Write Guide to TGUI Guide to Setting up the Code Environment Guide to Making a PR Technical process Idea to PR process Understanding how to write a good PR When to not make a PR Guide to Bug Fixing and PR Testing All the Manual of Style pages (Listed in another area) Misc Theta Station Researcher Heads Up Displays Starter guide to admin tools Mechs Guide to Regex