Skip to content
Open in Editor

Style Guide for PvME

Introduction

This channel covers stylistic aspects that PvME guides tend to follow for consistency and ease of reading.

⬥ Try to stick to these guidelines when submitting writeups/improvements to guides.

These guidelines may not cover every situation, and will be updated as required. Feel free to raise concerns about any scenarios not covered for discussion.

‎ ‎ ‎ ‎• Please bring up any concerns that are not covered by these guidelines.

Some commonly used templates for ease of writing may be found in #Templates.

Note: If you ever require any assistance with styling, feel free to tag an editor!

Basic Guide Structure

This is the basic structure that PvME guides begin with. By using similar structures across all guides, it is easier for readers to find the section that pertains to information they are looking for, as sections will tend to remain in the same order (e.g. Presets will always be near the top of a guide, Table of Contents at the bottom).

There may naturally be some variation in guides for different bosses, but the basic layout will remain the same.

Basic Structure

Note: Each of the bold bullets is a major section in a guide, and contains sub-sections within it.

Introduction

‎ ‎ ‎ ‎• Brief overview of the boss.

Presets

‎ ‎ ‎ ‎• Examples of loadouts for killing the boss.

‎ ‎ ‎ ‎• See the section on Preset Layouts for information on this.

Mechanics

‎ ‎ ‎ ‎• Describe the mechanics that the boss uses across the encounter.

‎ ‎ ‎ ‎• You can skip this section for advanced/higher-level guides if required.

The Fight

‎ ‎ ‎ ‎• Explain the fight, and how to approach it.

‎ ‎ ‎ ‎• Structure it into multiple subsections if the fight involves multiple phases (e.g. Vorago, Araxxor, Telos, Tz-Kal-Zuk), etc.

Rotations

‎ ‎ ‎ ‎• This section is typically excluded because rotations are covered in a phase-by-phase manner in the previous section.

‎ ‎ ‎ ‎• It may have merit in some guides.

Example Kills

‎ ‎ ‎ ‎• Embedded links to any example kills for the reader's reference.

⬥ Follow this basic format and incorporate the other guidelines for embedding, rotations, etc. and you should be well on your way to having a stylised guide.

General Style Choices

These are some general rules to follow with regard to grammar, punctuation and other PvME-specific practices, applicable to all guides.

Language and Formatting

⬥ Prefer UK spelling and style.

‎ ‎ ‎ ‎• e.g. armour over armor.

⬥ Prefer the date format YYYY/MM/DD.

⬥ Ensure proper punctuation.

‎ ‎ ‎ ‎• Capitalise the first letter of every line.

‎ ‎ ‎ ‎• Section and subsection names have important words capitalised.

‎ ‎ ‎ ‎• Add periods at the end of complete sentences.

‎ ‎ ‎ ‎• Utilise the Oxford comma.

⬥ Text may be emphasised through the use of bold, italicised and underlined text.

‎ ‎ ‎ ‎• Bold text is typically reserved for main items from a list for discussion, or for emphasis of certain points.

‎ ‎ ‎ ‎• Italicised text is usually for small notes that accompany sections and is usually not preceded by a bullet.

⬥ When writing titles, do not capitalise the following:

‎ ‎ ‎ ‎• conjunctions e.g. but / and / or

‎ ‎ ‎ ‎• articles e.g. the / a / an

‎ ‎ ‎ ‎• prepositions e.g. to / on / for

PvME-Specific

⬥ When using emojis, the order is: word, then emoji - e.g. Spellbook Swap SBS

‎ ‎ ‎ ‎• The exception to this rule is in presets where obscure items go emoji, then word - e.g. conservationofenergy Conservation of Energy

⬥ Always surround emojis by one space on either side.

⬥ Every channel should have its channel topic with the correct title (e.g. channel for "aod" would have "Nex: Angel of Death" as it's topic).

⬥ Where possible, the first message of a guide should be an image that best represents the guide.

⬥ If crediting a user for contributing them to a guide, give them a shoutout in #contributors.

‎ ‎ ‎ ‎• To tag a user @user ‎use the following syntax: <@userid> ‎with the correct userid.

‎ ‎ ‎ ‎• You can find a Discord User ID by right-clicking a person's name and selecting 'Copy ID'.

‎ ‎ ‎ ‎• You will need Developer Mode enabled for this: Discord Settings > Advanced > Developer Mode (ON)

⬥ Prefer to avoid plain links in the text if possible.

‎ ‎ ‎ ‎• Where feasible without loss of readability and good appearance, use embeds to contain specific links.

⬥ Do not end a line with a blank space (no trailing whitespace on a line).

Formatting Notes

⬥ Only use notes to emphasise important information.

⬥ Format notes like this: *Note: text describing main point.*.

‎ ‎ ‎ ‎• Notes should be italicised, and not preceded by a bullet.

‎ ‎ ‎ ‎• Language and formatting rules still apply, notice text ‎is not capitalised.

⬥ If needing to include more than one note for the same section, then format it like this:

‎ ‎ ‎ ‎• In this instance each note should be preceded by a bullet.

*Notes:
⬥ Text describing main point of note 1.
⬥ Text describing main point of note 2.*

Sections and Subsections

Guides are broken down into sections to separate different parts of the guide, with subsections used for further breakdowns within a section.

Formatting Sections

⬥ Format sections like this: ## __Sections__.

⬥ Format subsections like this: ### Subsection.

⬥ Every section title should be followed by a .tag:word ‎command in the next line after the section title.

‎ ‎ ‎ ‎• This is used to create links to sections in the Table of Contents.

Every section should have a subsection.

‎ ‎ ‎ ‎• If you can't think of a good Subsection title, you can say General x for y.

‎ ‎ ‎ ‎• Words in subsections should follow the same capitalisation guidelines as Sections.

⬥ Each subsection should be a new Discord message.

‎ ‎ ‎ ‎• This is done by placing a line with just one period character (.) before it (see below).

⬥ Content within sections/subsections should be in the form of bulleted lists with nesting for more granularity.

‎ ‎ ‎ ‎• See the Lists section below for more.

⬥ See the following image for an example.

⬥ The above image shows a part of a guide written following the guidelines, shown as it would appear within a properly formatted file:

‎ ‎ ‎ ‎• Proper Section heading heading (lines 11, 22).

‎ ‎ ‎ ‎• Proper Subsection headings (lines 16, 24).

‎ ‎ ‎ ‎• Valid .tag:word ‎tag command (line 12).

‎ ‎ ‎ ‎• New message indicator period . ‎character (line 23).

‎ ‎ ‎ ‎• Blank lines prior to section/subsection messages (lines 10, 21).

‎ ‎ ‎ ‎• Italicised note on line 20, and emphasised bold point on line 18.

‎ ‎ ‎ ‎• Properly used bulleted points within the subsection.

‎ ‎ ‎ ‎• Emoji used with one blank space between it and the preceding word (lines 17, 22).

Formatting Lists

Lists are the primary informational structure within a subsection.

Bulleted Lists

⬥ All bullet points contain 1 space between the bullet and the first word.

⬥ Format main points with the ‎bullet with no indentation.

‎ ‎ ‎ ‎• Format all subpoints using the ‎bullet indented by 4 spaces.

‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎⬩ Format sub-subpoints using the ‎bullet indented by 8 spaces.

Alphanumerical Lists

1) Format main points like this: appropriate # followed by a closing parenthesis ‎with no indentation.

‎ ‎ ‎ ‎a) Format subpoints like this: appropriate letter followed by a closing parenthesis ‎indented by 4 spaces.

‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎⬩ Format sub-subpoints like this: ‎indented by 8 spaces.

‎ ‎ ‎ ‎b) Bold and underline lists if they ever act as titles.

⬥ Main point
    • Subpoint describing main point
        ⬩ Sub-subpoint describing subpoint in further detail

1) Main point
    a) Subpoint describing main point
        ⬩ Sub-subpoint describing subpoint in further detail

⬥ The above example shows examples of formatted lists within a file.

Use subpoints and sub-subpoints as required to avoid illegible walls of text. Ideally, keep text as concise as it can be without losing meaning or readability.

Embedded Content

Embedded content here refers to two kinds of messages.

⬥ The first is embedding media content (images/gifs/videos/etc.) directly into the body of a guide to be able to view it and click on it whilst scrolling through the guide. To do this, the .img:<url> ‎command can be used.

⬥ The second is Discord embeds, which are self-contained message structures that are primarily used to tightly group together chunks of related info, usually accompanied by links to external resources (like spreadsheets, video clips, large screenshots, etc). Use these when appropriate.

‎ ‎ ‎ ‎• e.g. every !command ‎in PvME Discord is a Discord embed message.

In-line Embedded Media Content

⬥ The preferred hosting platforms are YouTube for videos, and Imgur for screenshots and short gifs/clips. Streamable is absolutely forbidden.

⬥ Images and video embeds should be their own message, avoid direct links to images in guides as far as possible.

‎ ‎ ‎ ‎• Example: the highlighted section below shows an embedded image.

⬥ If plain website links are used, then they should be formatted similar: **Link text** - <https://...>

‎ ‎ ‎ ‎• Surround open links with <> ‎brackets prevent embeds from appearing.

‎ ‎ ‎ ‎• Example: RuneScape Wiki - https://runescape.wiki/

⬥ If masked links are used, then they should be formatted like so: [Link Text](<https://...>)

‎ ‎ ‎ ‎• Example: Runescape Wiki

Gear Presets

Gear presets are used at the start of guides to concisely inform users of all items required to effectively tackle the content, including equipment, inventory setups, relics and notes on important items.

Styling Explanation

⬥ The basic preset layout is as follows.

→ Preset embed (contains sample image and breakdown with notes)
→ Relic Setup

Preset/breakdown link should be generated using Preset Generator (link in #Preset Generator).

Preset breakdowns should be sufficiently detailed as to be useful to the reader.

‎ ‎ ‎ ‎• See the one in the example preset below for an example.

Keep presets consistent:

‎ ‎ ‎ ‎• Rune pouches should match pouch colours in #armour-and-weapons.

‎ ‎ ‎ ‎• EoF emojis (when possible) should match colours in #eof-specs.

‎ ‎ ‎ ‎• Weapon switches be chosen to match their perked equivalents in #perks.

Avoid using dyed gear in presets.

Avoid using unreasonably expensive gear in presets.

‎ ‎ ‎ ‎• For example, avoid spiked boots, Elite Sirenic, etc. Use your best judgement.

⬥ Combining all of these, we can put together an example preset like the following:

Presets and Relics

Preset Suggestions
first_style_name preset first_style_emoji ⬥ second_style_name preset second_style_emoji

Writing Rotations

It is important that rotations are written in a consistent manner throughout PvME to ensure readability and accuracy. Here are some rules to follow when writing rotations for guides.

Rotation/Ability Formatting

Use the full code for PvME emojis from https://pvme.io/pvme-settings/#emojis to add emojis to a guide.

‎ ‎ ‎ ‎• For example, use <:bloodbarrage:537338981747261446> ‎instead of :bloodbarrage:

Use + to combine extra non-ability actions that occur on the same tick.

‎ ‎ ‎ ‎• This includes GCD surges/bladed dives, apot, vuln bombs, non-mage auto attacks, target cycle, etc.

‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎⬩ Example: deci + vulnbomb → (5taa) + cleave

‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎⬩ Example: deci + accel + surge + bdsurge

Use → to separate groups of actions that occur on the same tick.

‎ ‎ ‎ ‎• Example: bloodbarrage deto dbreathwmimpactbloodbarrage asphyx

Denote non-ability actions in parentheses (this does not include adrenaline potions or sigils).

‎‎ ‎ ‎ ‎• Detonate duration

‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎⬩ sonicwavedeto (3t) → bloodbarrage deto dbreath.

‎‎ ‎ ‎ ‎• Target cycle

‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎⬩ deto (3t) → (tc) + bloodbarrage deto dbreath.

‎‎ ‎ ‎ ‎• Channeling for unconventional durations

‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎⬩ bloodbarrage asphyx (3 hit) → dbreath.

‎‎ ‎ ‎ ‎• Explicitly specifying weapon

‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎⬩ (DW) bloodbarrage corruptblast → (2H) bloodbarrage dbreath.

‎‎ ‎ ‎ ‎• 5 tick auto attacks

‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎⬩ deci → (5taa) + cleave

‎‎ ‎ ‎ ‎• Waiting in rotations

‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎⬩ devo → (wait 2t) + surgesunshine

⬥ If the next action is delayed, specify the ticks starting from the cast of the previous action.

‎ ‎ ‎ ‎• For example, the last example above casts Surge surge 2 ticks after devo - i.e. one tick before the global cooldown ends.

⬥ Stalled abilities will be denoted as s<ability>, and releasing stalled abilities will be denoted as r<ability> + <next ability>.

‎ ‎ ‎ ‎• Example: ssonicwave → rsonicwave + dbreath

⬥ Auto attacks are implied when using defensives (defensives imply 2H auto, freedom implies oh/2H auto).

⬥ Include adrenaline potions and sigils where they are used.

Special attacks should be denoted with both the weapon and the corresponding attack emoji in order:

‎ ‎ ‎ ‎• From the physical weapon: sgb spec

‎ ‎ ‎ ‎• From an EoF: sgb eofspec

‎ ‎ ‎ ‎• If special attacks are used off-style, it is unnecessary to specify prayer flicks.

Commands and Formatting Syntax

This section contains general syntax for formatting text in guides, some helpful commands in GitHub syntax, and PvME Bot instructions in case automatic channel updates fail.

Formatting Syntax

**Bold text** ‎- this creates Bold text

*Italicised Text* ‎- this creates Italicised text

__Underlined text__ ‎- this creates Underlined text

‎`Code block text` ‎ ‎- this creates Code block text

## __Major Section__ ‎- this creates a

Major section

### Subsection ‎- this creates a

Subsection

Note: multiple formatting syntax may be combined together.

Discord Commands (to be used in #unknown-channel)

The following commands are used for instructing the bot to perform certain actions, which may be required at times.

pvme$txtpost (attach a .txt file here)

‎ ‎ ‎ ‎• Posts the text file in Discord.

‎ ‎ ‎ ‎• Useful for proofreading to make sure it doesn't fail any automated style checks.

pvme$txtsync post CHANNEL_NAME

‎ ‎ ‎ ‎• Purge/reposts the channel with the copy of the file the bot currently has downloaded.

pvme$txtsync link CHANNEL_NAME CATEGORY/FILENAME.txt

‎ ‎ ‎ ‎• Tells PvME Bot to link CHANNEL_NAME ‎to the contents of CATEGORY/FILENAME.txt

pvme$txtsync txtpost pull/PULL_REQUEST_#/head CATEGORY_NAME/CHANNEL_NAME.txt

‎ ‎ ‎ ‎• Posts that pull request with most recent edits/commits to the channel it is linked to.

‎ ‎ ‎ ‎• Example: pvme$txtsync txtpost pull/381/head mid-tier-pvm/dragonkin-laboratory.txt

pvme$commands add COMMANDNAME txtsync commands/COMMANDFILENAME.txt

‎ ‎ ‎ ‎• Adds a command accessible with !COMMANDNAME ‎based on contents of file COMMANDFILENAME.txt.

pvme$commands add ALIASNAME alias COMMANDNAME

‎ ‎ ‎ ‎• Adds an alias as an alternate command to view .

pvme$commands delete COMMAND_NAME

‎ ‎ ‎ ‎• Deletes a command (can be a source command, or an alias).

Table of Contents (formatting)

The Table of Contents (ToC) is present in every guide, and used for quick navigation. It is important that this is accurate, to ensure users are directed to the correct information within guides, especially as guides get longer in length.

ToC Formatting

⬥ ToC is a Discord embed, and should be in at the end of every guide in a section called "Table of Contents".

⬥ The ToC should be pinned in the channel.

‎ ‎ ‎ ‎• To do this just add a new line with the command .pin:delete ‎after the message.

⬥ The Basic ToC structure has section names along with links to those sections, for each section of the guide. See the code example below.

{
  "embed": {
    "title": "__Table of Contents__",
    "description": "*To edit this guide, visit <id:customize> and select Entry Editor*",
    "color": 39423,
    "fields": [
      {
        "name": "__Section 1__",
        "value": "[Link]($linkmsg_tagword1$)",
        "inline": true
      },
      {
        "name": "__Section 2__",
        "value": "[Link]($linkmsg_tagword2$)",
        "inline": true
      }
    ]
  }
}
..embed:json
..pin:delete