Leaderboard

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

I do think that humanoids should have to be alive to be infected. If they die mid-gestation of the larva, the larva should stop growing and fail to burst. Requiring the hosts to be alive also gives the hosts the opportunity to fight back and make Xeno life much more difficult. It also gives non-frontline castes (drones/queen) something to do while sentinels/hunters fight. From my experience on CM, this can be very much a fun and interesting mechanic for both Xenos and hosts, although it's difficult to say how this would be received or play on Paradise. CM actually has answers to this solution. The way CM solves it is by having humanoid creatures inside of nests heal at a slow rate, so intense damage will still kill the host (thus, preventing burst) whereas light or medium damage is generally countered by the nest. Dealing stamina damage to a host through a chemical seems like a bad idea - if they have a large buildup of that chemical, they will have next to no chance for recourse once infected and/or nested (either that or the stamina damage will have to be nerfed into near non-existance). This basically never happens on Paradise (due to quick larva gestation time and long nest breakout time), but you can struggle out of nests as with every other binding/buckle situation. It may be better to reserve the chemical for simply minor heals, and be applied either by non-frontline castes (Drones/Queens) or by the nests themselves. Notably, CM also has a feature that allows larva during the final stage of growth to finish growing, even if the host dies. If it's not satisfactory to just simply have a heal, we can have a crack at implementing that too. Also, the answer right now is a focus on stamina damage. In general, Paradise has been moving away from hard stun mechanics and with the Xenomorph rework I very much intend to do the same as much as possible. I just reworked the tackle/disarm chance into dealing stamina damage, and have been tweaking the numbers and testing it. It deals stamina damage based off of how much armor the target is wearing, clamped with the minimum value being 10 (10 hits to floor) and the maximum being 30 (3 hits to floor). Subject to change in the near future. At the moment only chest armor is factored but it may be better to factor in all armor worn. Edit: Soon I'll be going into the neurotoxic spit code to rework it to deal stamina damage (and perhaps test a chemical that deals stamina damage over time).

Hello everyone, I'm finally back. Been through a lot IRL, first my SSD died and my PC was unusable for a few weeks.... then, the day I decided to get back to the rework, I was hospitalized due to a lung collapse. I'm fine now (It was quite a few months ago, so don't worry.) I've got more time on my hands now, so I'm picking back up the Xenomorph project here. I've wrapped up the final bit of the Xenomorph Rework Deisgn Doc, and I'm looking for more feedback/suggestions on it before posting it to the github. It's still a little incomplete, and I may be adding more to it as I continue updating my code. Please leave a comment on it and let me know what you think. The more feedback the better. Thanks! Edit: Commenting and suggestions should be enabled for the doc. https://docs.google.com/document/d/1Uzpluf2qixaJd1-IM6XPMV5n-pTgphvNGnZG71160jc/edit?usp=sharing