Your support makes Blue Moon possible (Patreon)
tsukasa Request Thread Documentation
Version: 1.3.0This thread contains the full documentation for my (tsukasa's) request threads; it explains how the request threads are structured, why specific sources are chosen, how the versioning system works, and other miscellaneous details. Like the request threads, this documentation is also versioned and has its own respective changelog; the versioning system for this documentation works the same way as the request thread versioning.
Table of Contents
Structure
The structure of the request threads follows a pre-determined layout and is closely matched across all request threads; any structural differences across request threads will be minor and will occur only when tailoring the request thread to its purpose is prioritised over keeping a strict structural layout.Headings
The heading structuring across all request threads is as follows:- Heading 1: Title
- Heading 2: Section
- Heading 3: Subsection (sections within sections)
Tables
Tables within the request threads follow a big-endian format, with the most relevant/main part(s) being on the left of the table, and the least relevant/detailed part(s) being on the right of the table. Tables will deviate from this structure only if it is required due to context (e.g. Team A of characters in the left column, Team B of characters in the right column).Sections
The request threads are divided into sections. Each section contains information related to a specific component of the request thread.Notes
The Notes section contains a list of noteworthy details about the current request thread. Notes are per-request thread and may or may not be shared across multiple request threads.About
The About section contains information about me and what I'm looking for for the particular request thread you are viewing. Due to this section containing personal information and the type(s) of partner(s) I am looking for, it will likely remain the same across all request threads, unless there is a specific reason to change it.Plots
The Plots section contains information about the plots available in the request threads. The plots are laid out in per-fandom tables, with the plot title in the left column, the plot description in the middle column, and the available characters in the right column. The plot tables are contained within button spoilers, with 1 button spoiler per fandom.Plots are divided into 2 types:
- Original plots have a large amount of flexibility. Either an original character or fandom canon character can be used for both myself and partners; all fandom canon characters I am familiar with and like are located in the Fandoms and Characters section of the request thread.
- Fandom-based plots use pre-defined characters which are often contained within their respective fandoms. The characters in these plots cannot be changed, and must conform to their original canon personalities. All partners are required to play as a canon character; choice of canon characters is given when the plot is flexible enough to allow it. I will play as either a canon character or an original character. For more information on fandoms and characters included in these plots, refer to the Fandoms and Characters section of the request thread.
Characters
The Fandoms and Characters section contains information about the available characters and their respective fandoms which can be used in the Original plots located in the Plots section. Each fandom and character has an individual link which will take you to an external resource containing more information about the respective fandom or character.Kinks
The Kinks section contains information about my turn ons and turn offs. Both turn ons and turn offs are laid out in a table, with the left column containing my turn ons, and the right column containing my turn offs. Not all turn ons are required to be included in my plots, but no turn offs can be included. Anything not stated in either list can be discussed out-of-character.Copyright Notices
The Copyright Notices section is located at the bottom of the request threads and contains copyright information for each series/fandom included in my Plots section and Characters section. I care about providing proper copyright attribution to the copyright holders of these series/fandoms, for both legal and credit purposes, so each new series/fandom addition to my request thread will accompany its respective copyright attribution. All of my plots are considered fair use of copyright.Sources
Why Are Specific Sources Chosen?
Sources are chosen based on their merits and their ability to provide the required information related to a specific part of the request threads. My source of choice for fandoms and characters is Fandom, due to it being the location a large amount of fans go to both record and consume information about fandoms and characters; it is also highly likely to contain correct and detailed information not found elsewhere, such as Wikipedia, due to fans wanting accuracy in their respective fandoms' communities. In cases where there is either no Fandom community available, or there is a lack of information available, about a fandom and/or character, the closest alternative will be chosen (such as Project iM@S for The Idolmaster). For information outside of fandoms and characters, Wikipedia is my source of choice.Date and Time
All dates and times across all request threads are ISO 8601-compliant. The short-form formatYYYY-MM-DD is used for dates, and hh:mm:ss for times. The full expression may be used when necessary; YYYYMMDDThhmmssZ (UTC without offset), YYYYMMDDThhmmss+hhmm (with positive offset), or YYYYMMDDThhmmss-hhmm (with negative offset).Spacing
Hypertext Markup Language (HTML) should be styled via Cascading Style Sheets (CSS), not via HTML itself[1]; since BBCode is a non-standard markup language which parses to HTML, the same concept applies. Unfortunately, Blue Moon Roleplaying does not implement CSS control, thus forcing non-compliance with HTML when parsed from BBCode due to the requirement of using hard line breaks via the</br> element rather than the proper <p> and </p> elements; XenForo also breaks a lot of HTML and implements it in a non-standard fashion. For this reason, line breaks are not included in the BBCode and rely entirely on website CSS which cannot be controlled by the user; this may cause lack of spacing or too much spacing, as well as breaking accessibility for people using assistive technologies such as screen readers.Versioning
What is the Numbering Scheme?
The numbering scheme of the request threads is divided into 3 blocks (herein referred to as Block 1, Block 2, and Block 3, in left-to-right order); the version blocks are separated by periods. All request threads use Semantic Versioning. When a version number block is incremented, all blocks to the right of it are reset to 0. The legacy versioning scheme was most recently a similar numerical versioning scheme which lacked standardisation. Before numerical versioning, the versioning scheme used Calendar Versioning and was based on the date the request threads were updated; this versioning scheme had the disadvantage of lack of ability to update the request threads more than once per day, thus was replaced by a numerical versioning scheme.Block 1 contains the
MAJOR version; this number is incremented whenever a breaking change is made to the request threads, such as substantially changing the structure, or adding or removing sections.Block 2 contains the
MINOR version; this number is incremented whenever a non-breaking but substantial change is made to the request threads, such as adding or removing a plot from the Plots section, adding or removing a fandom or character from the Fandoms and Characters section, or adding or removing a note from the Notes section.Block 3 contains the
PATCH version; this number is incremented whenever an unsubstantial change has been made to the request threads, such as fixing a typo, changing sentence structure or wording, or fixing or optimising the BBCode.Why Are Numbers Skipped?
While a rare occurence, version numbers are sometimes skipped due to an internal version update occurring before the previous version was posted. All changes are planned in advance, and are bundled into a specific version number; if another change is made outside of this version number, a new version number is assigned to that new change or bundle of changes, thus rendering the previous version unnecessary to be posted since it has already been superseded.Changelog
The changelog is posted independently of the main post of the request threads and can typically be found as post #2 in each request thread. The changelog contains a list of changes made to the request threads since the previous version, along with the version numbers associated with those changes.
Last edited: