Satisfactory Wiki:Style guide

This page is a guide to creating or editing mainspace pages at Satisfactory Wiki in accordance with the established article style. These guidelines are not set in stone, but they should generally be followed in order to maintain consistency across pages, unless there is a good reason to make an exception.

Language and units
Text should generally follow formatting and grammar as usual on wikis. Wikipedia's Manual of Style provides a detailed overview. However, it does not need to be followed as strictly here, since this is a video game wiki after all, not an encyclopedia. Styling that should be used is notably: The default game language is US English, therefore, the wiki should use US English as well. etc.
 * using proper grammar
 * using MediaWiki formatting in favor of plain HTML wherever possible
 * avoiding speaking to the reader, except for tips sections and tutorials
 * Color not Colour
 * Aluminum not Aluminium
 * Sulfur not Sulphur
 * Meter not Metre
 * Labeled not Labelled
 * Signaling not Signalling

The units page discusses units present on the wiki. Same applies to the formatting of numbers, discussed below.

For consistency, the plural of gas is spelled gases, not gasses.

Capitalization
All in-game entities with their name explicitly spelled out should follow the in-game case.
 * Reinforced Iron Plate
 * Supercomputer
 * AWESOME Sink
 * Resource Well
 * Head Lift

Other phrases which are not a specific name should use lowercase (inside sentences) or sentence case (beginning of sentences, article names).
 * Resource node

Page names
Pages describing a single subject should follow casing rules described above. Pages for groups of subjects generally use word case to mimic in-game casing, such as Conveyor Poles or Train Signals, even though it would be acceptable to not capitalize either in text.

Additionally, page names should avoid special characters, even if their use in the software is permissible (FICS⁕MAS < FICS*MAS < FICSMAS).

Experimental content
The wiki prefers content in the stable branch of the game over experimental, as discussed here. In a nutshell, experimental content never replaces early access content, but is rather presented alongside it and marked as experimental. History sections are exempt of this rule, as mentioned below.
 * If a feature is only available in the experimental branch (e.g. a building or mechanic), the page is marked as experimental content using.
 * If there was a change to a feature already in the stable branch, experimental only content is marked with.
 * Example: The Fluid Freight Car can carry 1600 m of fluid.
 * UI icons are not replaced with the experimental only version, nor are they reuploaded as a separate file.
 * If a recipe was changed in any way (ingredient, crafting duration, building etc.), it is stored as another separate recipe set to experimental and the name marked with.
 * If a feature was removed in experimental, it is marked by appending it with  (the   template is for completely removed content only), and the removal is mentioned in the History section.
 * Example: Biofuel is an item that can be crafted from Biomass.
 * Pages are not moved to stay in trend with new names of features.
 * Example: Patch 0.3.6 introduced Mk.2 Pipelines and simultaneously appended "Mk.1" to "Pipeline" to more clearly distinguish them. If both Pipelines were maintained on separate pages, this would mean that Mk.1 Pipelines would be on a page named "Pipeline" (consistent with Early Access), while Mk.2 Pipelines would be on a page named "Pipeline Mk.2".

Upcoming content
Upcoming content is content that has been officially teased and is expected to be introduced to the game in a future update.
 * In order to prevent many stub pages being created (as there is usually little or just not enough information about teased features), all upcoming content should be listed on the Future content page.
 * Certain exceptions can apply, which are situational (e.g. the Crab Boss is unusually notable, due to being teased since the E3 trailer).
 * Even if enough information for a feature is gathered, it should remain on the Future content page. Pages created despite this should be marked as upcoming content using.

Numbers

 * Spell out numbers if it is below 10 (zero to nine) and is mentioned as a single number in the context. Use numeric (Arabic) notation otherwise.
 * Where large numbers are mentioned, every 3 digits should be separated with a comma, such as 1,234,567,890. Spaces are not required.
 * Periods should be used as decimal separator, such as 0.5 etc.
 * Where superscript is to be used, prefer template over Unicode as the latter is smaller and thus more difficult to read. These templates is a shorthand to call
 * = 45 m
 * = 300
 * = 30 km
 * To represent a long decimal with specified decimal points, use . The full decimal can be viewed when mouse hover the number.

Control
Where specific control keys are to be executed, use the following template:

History
This section of the page should list changes to the article topic based on game patches. It should generally follow the official changelog, but sometimes there are undocumented changes introduced in updates. In those cases, the information should be based on in-game testing.
 * Entries are listed retroactively: The most recent change is at the top and the oldest at the bottom.
 * Entries start with the patch that is always linked.
 * If there was only one change in a patch, the entry is on one line.
 * If there were multiple, all notes for that patch are indented, and the first line only has the patch.
 * If it has zero entries,  is used to mark it as missing. If it has some entries but is either outdated or there are uncertainities,   is used to mark it as such.
 * Only include changes that directly affected the page topic, not changes that were only related. For example:
 * Assembler's building cost is changed and no longer requires Modular Frames – this is mentioned in the Assembler's history, but NOT in the Modular Frame history, as Modular Frames didn't change themselves, only its usage did.
 * Aluminum production was rebalanced – this is mentioned in the history of Alumina Solution, Aluminum Scrap, Aluminum Ingot etc., but NOT in the Bauxite history, the raw ore still behaves the same itself.
 * If it has been introduced as brand new, the entry should say just "Introduced". If it was implemented from being previously unobtainable (unreleased), it should say that it "has been made officially available".
 * If it never has changed, there should be only one point saying "No changes".
 * Unlike the rest of the wiki, entries prefer experimental over stable. Therefore, if something changes in experimental before it goes to stable, only the experimental change is mentioned.
 * This is because something can change in experimental and then be reverted back, which would result it not being mentioned at all.
 * Reformat entries to sound relevant.
 * For example, Patch 0.4.0.4 patch notes include the following change:
 * Certain buildings can now be rotated 45 degrees when placing instead of only 90 degrees: Jump Pad, U-Jelly Landing Pad, Street Light, Personal Storage Container, Light Control Panel, Power Switch, M.A.M., AWESOME Shop, Craft Bench, Equipment Workshop.
 * Such change would be formatted as "X can now be rotated 45 degrees when placing instead of only 90 degrees", NOT "Certain buildings can now be rotated 45 degrees when placing instead of only 90 degrees: X".
 * If there are changes that are not mentioned in any patch notes, or the exact patch in which the change occured is not known:
 * Use "Unknown Patch before/after (link to patch)" or "Unknown Patch between (link to patch) and (link to patch)" for when it was added into the game.
 * Alternatively, "Unknown Update X patch" can be used (where a certain update refers to any patch during the development of that update).
 * Include references if possible.

Examples of good history sections: Geothermal Generator, Cable, Electric Locomotive

Images
Images should follow these general guidelines:
 * All images:
 * Categorize and apply the license on all images on upload.
 * Use simple, short, recognizable filenames. "Raw Quartz node in a cave.jpg" is a far better filename than "Picture of a quartz node I found in a cave full of spiders while exploring rocky desert.jpg".
 * For user-made in-game screenshots:
 * Crop image whenever possible. Cropping should be aimed to minimize file size.
 * When UI is the subject, avoid blending the UI with bright background, which can be best avoided by viewing against a black background.
 * If taking a screenshot of a subject, ensure there is nothing intrusive in the way. If UI is not relevant in the screenshot, use Photo Mode to hide the UI. Holster / de-equip any equipment, which usually takes up screen space.
 * Unless transparency is necessary, use JPG, aiming for filesizes of about 300 kB or less. WebP is another alternative which allows for transparency. The resolution of the screenshot can be usually reduced as well.
 * PNGs can be compressed using tools online, which can reduce their size by 30-70% without any visual loss of quality.
 * For user-made infographics or similar non-screenshot images:
 * Just as with in-game screenshots, avoid intrusive elements in the image and aim for the smallest filesize.
 * Screenshots of third-party tools using assets from Satisfactory use.
 * For UI icons extracted from the game:
 * Use the highest resolution available (as there are usually two or three resolutions of the same UI icon).
 * Do not alter the images in any shape or form.

Game character
Where the player-controlled character is mentioned, Pioneer should be used. Where gender is referred, use She.

Formatting

 * When forcing a line break, use  tag.
 * A double return creates a similar effect but with different spacing.
 * Transitioning from paragraph and number bullets or point bullets automatically create line break.
 * One empty line between 2nd tier headings. No empty line is required between 3rd tier headings.
 * Some module or template automatically includes line break. Be sure to preview the edits before deciding whether additional line breaks are required.
 * When a non-line breaking space is required, use  tag.
 * This will force the line break to be happen before (or sometimes after) the words joined by the non-breaking space.

Tagging a page

 * When a new page is being created, always add  template at the first line. When the page contains all the information and in-game mechanics of that particular object, the stub tag can then be removed.
 * When page is outdated, add.
 * Other page tags:

Other

 * Every page should be categorized except for buildings, which are automatically categorized as 'Buildings' as long as the infobox on the page has 'craftedIn = Build Gun' and has a defined subcategory, as in build menu.
 * Whilst the Discord role is a capitalised singular term "COFFEESTAINER", the mixed-case usage appears on the Coffee Stain website as "Coffee Stainer".

= Item page format =

This is a brief description of the item that either mentions how it is obtained or used. is used, and is placed before this mean section, but after any notices there may be on the page (such as,   or  ).

Unlocking
If unlocked via M.A.M. research,  is used.

If unlocked via the AWESOME Shop,  is used.

Resource acquisition
For a raw resource,  is used.

Crafting
If craftable, recipes are entered using  and rendered using. If multiple items are present on the same page, use ...

Alternate recipes analysis
Use the following template: The following shows different ways to produce 1 'The item' / second, or 60 / min: 'Insert gallery of production graphs here, comparing different alternate recipes path with 60 item/min' 'Insert a table of raw ore consumption, energy, space and building count here'
 * Refer to Iron Plate for template

Space Elevator
Only for Space Elevator parts, mentions that it is used to complete deliveries in the following format:

Part Name is used to complete deliveries in the Space Elevator.

Research
If used in any M.A.M. research chain,  is used.

Equipment
If equipment, its usage should briefly be explained here, better here than in the mean section.

If used as ammo for any tool or weapon, this should be mentioned here.

Crafting
is always used, as when it cannot be crafted into anything, the template will say so.

AWESOME Sink
is always used, as when it cannot be sunk, the template will say so. When there are multiple items in the same page, use.

Tips
If there are any tips to be mentioned, they shall be listed here.

Trivia
If there is any trivia, it shall be listed here.

Current issues
If there is any bugs, glitch or their work-around, it shall be listed here. Besides that, make sure to report such bugs to https://questions.satisfactorygame.com/.

Gallery
If the page has any specific images to be displayed, it shall be here in its own gallery section.
 * For files enclosed by the  tag, the leading text   may be omitted, although any subsequent visual edits may automatically add them back.

History
History follows general guidelines as mentioned above.

Recipes
If the building is used for any recipes, they are listed here using.

Overclocking
If the building is a powered consumer or generator, information about overclocking is listed here using.

Types
If the page is a merged page, this section has a table outlining the key differences between the individual types of structures.

Construction
This section outlines information about how the building is built, which is usually used for non-interactible logistics structures, or building where how they are built is important for their functionality. Otherwise, it is excluded completely.

Usage
This section elaborates on the usage of the building. Can be excluded for buildings used solely for crafting recipes.

Remaining sections
Tips, Trivia, Current issues, Gallery, History, References and See also sections are identical to the item page format.

= Patch notes format = The lead section of patch notes is always created using the  template. See its documentation for details.

If there was a hotfix released that didn't increment the version number but changed the build number, it should be mentioned in the mean section. If there was an additional note added to the patch notes, it should be in its own section named Hotfix that is placed before the intro. See Patch 0.3 for an example.

Major updates have their logo at the very top of the page and key art at the bottom. Additionally, it is noted whether a patch is the "first" of a major update or if it "brings its features to the stable branch". See Patch 0.4.1.0 for an example.

Occasionally, a series of patches is released on experimental only, with the latest of the series being pushed onto the stable branch with the same build and version, but patch notes listing all changes of the series. To distinguish these, the earlier experimental release gets  added to its title. See Patch 0.2.1.17 (Experimental) and Patch 0.2.1.17 for an example.

Intro
The intro text that precedes the actual patch notes.

Patch note sections
Each patch note section has its own header, which is not in all caps (as formatted by default) and uses sentence case instead. Quality of Life is an exception, as the L gets capitalized.

Note that patch notes from Discord have preformatted bullet points (•), those should be replaced with normal lists:

• Change 1 • Change 2

Correct formatting:
 * Change 1
 * Change 2

The page should have  at the bottom. Categorization is done automatically by the Patch template.