Difference between revisions of "Rigdio/Future"

From Rigged Wiki
Jump to navigation Jump to search
Line 324: Line 324:


Note how <code>shared</code> replaces <code>filename</code> for the brace horn of both players. This tells rigdio that, rather than looking for a file, it should check the files loaded by <code>shared</code> at the root level. The value of the <code>shared</code> key tells rigdio what key to look for; in this case, both players are looking for <code>brace</code>, which will direct them to a single shared instance of <code>shared-goalhorn.mp3</code>. If Player 1 scores a brace and then Player 2 does, Player 2's brace horn will pick up where Player 1's left off.
Note how <code>shared</code> replaces <code>filename</code> for the brace horn of both players. This tells rigdio that, rather than looking for a file, it should check the files loaded by <code>shared</code> at the root level. The value of the <code>shared</code> key tells rigdio what key to look for; in this case, both players are looking for <code>brace</code>, which will direct them to a single shared instance of <code>shared-goalhorn.mp3</code>. If Player 1 scores a brace and then Player 2 does, Player 2's brace horn will pick up where Player 1's left off.
YAML keys are order-independent, so <code>shared</code> does not need to be placed before <code>goal</code> in the file in order to use shared audio files.


== New Conditions and Instructions ==
== New Conditions and Instructions ==
The switch to YAML format allows for much more advanced metacondition features. Previously, the only metacondition was the <code>not</code> condition; rigdio v2.0 adds boolean logical conditions (<code>and</code> and <code>or</code>, each of which operates on a list of conditions), as well as an <code>if</code> condition, which can be used to check one condition and use the result of that condition to determine which other conditions to test for a final result. (Note that an <code>and</code> condition is unnecessary in usual operation, as this is the default behaviour of condition lists. However, inside other metaconditions, <code>and</code> is necessary to combine multiple conditions into one place.)
The switch to YAML format allows for much more advanced metacondition features. Previously, the only metacondition was the <code>not</code> condition; rigdio v2.0 adds boolean logical conditions (<code>and</code> and <code>or</code>, each of which operates on a list of conditions), as well as an <code>if</code> condition, which can be used to check one condition and use the result of that condition to determine which other conditions to test for a final result. (Note that an <code>and</code> condition is unnecessary in usual operation, as this is the default behaviour of condition lists. However, inside other metaconditions, <code>and</code> is necessary to combine multiple conditions into one place.)

Revision as of 21:24, 10 March 2018

rigdio is an automated soundboard designed to ease the burden on streamers during cup events, and increase the options available to managers. It is available for download here on github. This page is designed to help managers prepare for the upcoming v2.0 release of rigdio; for the deprecate v1.x version, see this page. See also the changes from v1.9 section of this page.

This page will be updated as v2.0 grows closer to release.

Audio Exports

rigdio functions by using so-called audio exports. An audio export contains all audio files used by a team in a cup: anthems, goalhorns, chants, and event clips, as well as a YAML file which tells rigdio how to process these songs.

Structure of the YAML File

YAML files consist of a hierarchical dictionary structure where keys are mapped to values. I strongly suggest reading the complete idiot's introduction to YAML, which explains the basic structure of the language. In addition to the basic YAML structures of strings, lists, and maps, there are some structures which are standardised for use with rigdio:

A song can be either a string or a map which contains

  • Either a filename or shared key, containing a string which indicates the location of the song.
  • Optionally, a conditions key, containing a list of conditions. A condition is a key-value pair which maps a condition type to a list of appropriate tokens.
  • Optionally, an instructions key, containing a list of instructions. An instruction is a key-value pair which maps a instruction type to a list of appropriate tokens.

If a song is represented as simply a string, it is treated as equivalent to the map case where filename has a value equal to the given string, and both conditions and instructions are empty. For example, both of these are valid songs:

Trombe - 404.mp3
conditions:
- goals: ['>=', 2]
instructions:
- start: 0:29
filename: Bracehorn - Hyaku Shiki.mp3

and the first song is equivalent to

conditions: null
instructions: null
filename: Trombe - 404.mp3

A clip is simply a song with a null or empty conditions key.

A song list can be either a YAML list containing one or more songs, or simply a single song. For instance, both of the values of anthem shown below are valid song lists:

anthem: Chicks Dig Giant Robots.mp3
anthem:
- conditions:
  - opponent: m
  filename: u - m Anthem - Youen Naru Kizuna no Hibiki.mp3
- conditions:
  - opponent: x
  filename: u - x Anthem - Otome No Kimochi.mp3
- conditions:
  - opponent: k
  filename: u - k Anthem - Ooari Chihatan.mp3
- conditions:
  - opponent: a
  filename: u - a Anthem - Citrus.mp3
- conditions:
  - opponent: lit
  filename: u - lit Anthem - Pastel Pure Tranquilite.mp3
- u - u Anthem - Pastel Pure.mp3

The rigdio YAML file uses seven keys at the root level of the file: team, anthem, victory, goal, chant, event, and shared.

The team Key

This key is required!

This key should always be set to a single string value: the name of the team, without any slashes. For instance, in the M icon.png /m/ YML file, we have simply

team: m

The anthem Key

This key is required!

This key should contain a song list containing all songs which

The victory Key

This key takes the same values as anthem.

The goal Key

This key is required!

This key can be either a single song, a song list, or a map of player names to song lists. In the third case, it is required that a default key be included. In the two former cases, they will be treated as if they were in the third case, with all songs stored under the default key.

When a player goal is indicated, the player's name will be searched in the goal map; then, the first song in the found song list (or the default list if none is found) will be played. For instance, M icon.png /m/ has a goalhorn for each of its strikers, and a default goalhorn that changes based on their opponent: thus, their goal key contains a map with six keys. Each striker's name maps to only a single song, while default maps to a list of four songs.

goal:
  Alteisen Riese:
    conditions:
    - goals: ['>=', 2]
    filename: Bracehorn - Alteisen.mp3
  Gundam RX-78-2:
    conditions:
    - goals: ['>=', 2]
    filename: Bracehorn - Gundam.mp3
  Hyaku Shiki:
    conditions:
    - goals: ['>=', 2]
    instructions:
    - start: 0:29
    filename: Bracehorn - Hyaku Shiki.mp3
  Mazinger Z:
    conditions:
    - goals: ['>=', 2]
    filename: Bracehorn - Mazinger.mp3
  Shin Getter Robo:
    conditions:
    - goals: ['>=', 2]
    filename: Bracehorn - Getter.mp3
  default:
  - conditions: [opponent: co]
    filename: Trombe -co-.mp3
  - conditions: [opponent: d]
    filename: Trombe -d-.mp3
  - conditions: [opponent: wsg]
    filename: Trombe -wsg-.mp3
  - Trombe - 404.mp3

The chant Key

This key should contain a single song list containing all chant clips for the team. For now, chants still do not have the ability to use conditions.

The event Key

This key should contain a map with any of the following keys: sub, yellow, red, owngoal. In turn, each of these keys should contain a map of player names to lists of clips, which will be played at the appropriate event.

The shared Key

This key indicates songs to be made available through the new "Play By Reference" system. The value of this key should always be a map, where the keys are the names of the songs to be used within rigdio, and the values are songs. Note that if any conditions are attached to a shared song, both the conditions of the referencing entry and the shared song must be met in order to play it!

Examples

M icon.png /m/, Winter 2018:

team: m
anthem: Chicks Dig Giant Robots.mp3
victory: The Big O- Sure Promise.mp3

goal:
  Alteisen Riese:
    conditions:
    - goals: ['>=', 2]
    filename: Bracehorn - Alteisen.mp3
  Gundam RX-78-2:
    conditions:
    - goals: ['>=', 2]
    filename: Bracehorn - Gundam.mp3
  Hyaku Shiki:
    conditions:
    - goals: ['>=', 2]
    instructions:
    - start: 0:29
    filename: Bracehorn - Hyaku Shiki.mp3
  Mazinger Z:
    conditions:
    - goals: ['>=', 2]
    filename: Bracehorn - Mazinger.mp3
  Shin Getter Robo:
    conditions:
    - goals: ['>=', 2]
    filename: Bracehorn - Getter.mp3
  default:
  - conditions: [opponent: co]
    filename: Trombe -co-.mp3
  - conditions: [opponent: d]
    filename: Trombe -d-.mp3
  - conditions: [opponent: wsg]
    filename: Trombe -wsg-.mp3
  - Trombe - 404.mp3

chant: null

event:
  sub:
    Alteisen Riese: "sub/Alt.mp3"
    Big O: "sub/Big O.mp3"
    Big Zam: "sub/Big Zam.mp3"
    Genesic GaoGaiGar: "sub/GaoGaiGar.mp3"
    Shin Getter Robo: "sub/Getter.mp3"
    Gunbuster: "sub/Gunbuster.mp3"
    Iron Giant: "sub/Iron Giant.mp3"
    Kamen Rider 1: "sub/Kamen Rider #1.mp3"
    King Gainer: "sub/King Gainer.mp3"
    Mazinger Z: "sub/Mazinger Z.mp3"
    Megas XLR: "sub/Megas XLR.mp3"
    Metal Gear REX: "sub/Metal Gear REX.mp3"
    Nineball Seraph: "sub/Nineball Seraph.mp3"
    Protoman: "sub/Protoman.mp3"
    Scopedog: "sub/Scopedog.mp3"
    Tekkaman Blade: "sub/Tekkaman Blade.mp3"
    Yamato: "sub/Yamato.mp3"
    RX-78-2 Gundam: "sub/Gundam.mp3"

  yellow:
    Big Zam: "yellow/Big Zam.mp3"
    Shin Getter Robo: "yellow/Getter.mp3"
    Hyaku Shiki: "yellow/Hyaku Shiki.mp3"
    Iron Giant: "yellow/Iron Giant.mp3"
    Kamen Rider 1: "yellow/Kamen Rider #1.mp3"
    Mazinger Z: "yellow/Mazinger Z.mp3"
    Metal Gear REX: "yellow/Metal Gear REX.mp3"
    Scopedog: "yellow/Scopedog.mp3"
    Megas XLR: "yellow/Megas XLR.mp3"
    Big O: "yellow/Big O.mp3"

  red:
    Big Zam: "red/Big Zam.mp3"
    Shin Getter Robo: "red/Getter.mp3"
    Gundam RX-78-2: "red/Gundam.mp3"
    Hyaku Shiki: "red/Hyaku Shiki.mp3"
    Iron Giant: "red/Iron Giant.mp3"
    Kamen Rider 1: "red/Kamen Rider #1.mp3"
    King Gainer: "red/King Gainer.mp3"
    Mazinger Z: "red/Mazinger Z.mp3"
    Metal Gear REX: "red/Metal Gear REX.mp3"
    Scopedog: "red/Scopedog.mp3"
    Ideon: "red/Ideon.mp3"
    Megas XLR: "red/Megas XLR.mp3"

shared: null

U icon.png /u/, Winter 2018:

anthem:
- conditions:
  - opponent: m
  filename: u - m Anthem - Youen Naru Kizuna no Hibiki.mp3
- conditions:
  - opponent: x
  filename: u - x Anthem - Otome No Kimochi.mp3
- conditions:
  - opponent: k
  filename: u - k Anthem - Ooari Chihatan.mp3
- conditions:
  - opponent: a
  filename: u - a Anthem - Citrus.mp3
- conditions:
  - opponent: lit
  filename: u - lit Anthem - Pastel Pure Tranquilite.mp3
- u - u Anthem - Pastel Pure.mp3
chant:
- u - Chant - Magia.mp3
- u - Chant - Akkariiiin.mp3
- u - Chant - Garasu no Hanazono.mp3
- u - Chant - Onee-samaaaa.mp3
- u - Chant - Symphogay 2.mp3
- u - Chant - Symphogay 1.mp3
goal:
  :^):
  - conditions:
    - opponent: vr
    - not:
      - first: null
    filename: u - vr Akka - Yuru Yuri Daijiken 8bit.mp3
  - conditions:
    - not:
      - first: null
    filename: u - u Akka - Akkariiin Mesorogiwi.mp3
  '>>>,Gay':
  - conditions:
    - opponent: vr
    - not:
      - first: null
    filename: u - vr Nanofate - Eternal Blaze 8bit.mp3
  - conditions:
    - opponent: m
    - not:
      - first: null
    filename: u - m Nanofate - Romancers' Neo.mp3
  - conditions:
    - not:
      - first: null
    filename: u - u Nanofate - Secret Ambition.mp3
  default:
  - conditions:
    - opponent: m
    filename: u - m GH - Waikyou Shenshou Jing.mp3
  - conditions:
    - opponent: k
    filename: u - k GH - Crazy Psycho Lesbian.mp3
  - conditions:
    - opponent: x
    filename: u - x GH - Kesaran Pasaran.mp3
  - conditions:
    - opponent: a
    filename: u - a GH - Garasu no Hanazono.mp3
  - conditions:
    - opponent: vr
    filename: u - vr GH - Agony 8bit.mp3
  - u - u GH - Agony.mp3
team: u
victory:
- conditions:
  - opponent: m
  filename: u - m VA - Utsukushi Kereba Sore De Ii.mp3.mp3
- conditions:
  - opponent: k
  filename: u - k VA - More One Night.mp3
- conditions:
  - opponent: x
  filename: u - x VA - Shirojo.mp3
- conditions:
  - opponent: a
  filename: u - a VA - Butterly Effector.mp3
- conditions:
  - opponent: pol
  filename: u - pol VA - The Other Side of the Wall.mp3
- u - u VA - Super Ultra Hyper Miracle Romantic.mp3

Changes From v1.9

YAML Instruction Files

The .4ccm file format is deprecated. .4ccm was created as a minimalist format for simple lists of songs and conditions; as more features have been added, the limits of the .4ccm structure began to show. While the release version of rigdio v2.0 will still be able to load .4ccm files, they are not guaranteed to function properly on anything introduced after v1.9. Support for the .4ccm format will be ended no later than the 2018 4chan Autumn Babby Cup and possibly as early as the 2018 4chan Spring Babby Cup.

rigdio now uses the YAML data serialisation language as the means of handling export instructions. YAML files are much larger than their .4ccm counterparts, but they will allow for much simpler handling of advanced features.

Fewer Reserved Names+Characters

Unlike .4ccm files, YAML files are hierarchical; under the new format, you can have players named "goal" or "anthem" or whatever if you want to. The only exception is "default".

There are no reserved characters; however, player names containing > or # will need to be "quoted".

"Play By Reference"

One of the major limitations of rigdio v1.x was that each instance of an audio file was associated specifically with a given line; even if two players nominally played the same song, it would start from the beginning both times. To remedy this, the shared: key in the root acts as a registry of files, and can be referred to in other places. As an example, consider the following YAML snippet:

shared:
  brace: "shared-goalhorn.mp3"
goal:
  Player 1:
  - filename: p1 hat trick.mp3
    goals: [">=",3]
  - shared: brace
    goals: ["=",2]
  Player 2:
  - filename: p2 hat trick.mp3
    goals: [">=",3]
  - shared: brace
    goals: ["=",2]
  default: myteam-gh.mp3

Note how shared replaces filename for the brace horn of both players. This tells rigdio that, rather than looking for a file, it should check the files loaded by shared at the root level. The value of the shared key tells rigdio what key to look for; in this case, both players are looking for brace, which will direct them to a single shared instance of shared-goalhorn.mp3. If Player 1 scores a brace and then Player 2 does, Player 2's brace horn will pick up where Player 1's left off.

YAML keys are order-independent, so shared does not need to be placed before goal in the file in order to use shared audio files.

New Conditions and Instructions

The switch to YAML format allows for much more advanced metacondition features. Previously, the only metacondition was the not condition; rigdio v2.0 adds boolean logical conditions (and and or, each of which operates on a list of conditions), as well as an if condition, which can be used to check one condition and use the result of that condition to determine which other conditions to test for a final result. (Note that an and condition is unnecessary in usual operation, as this is the default behaviour of condition lists. However, inside other metaconditions, and is necessary to combine multiple conditions into one place.)