|The logo competition for the 2021 4chan Winter Cup is now taking submissions.|
|The deadline is January 15th, 23:59 UTC. Logos will be placed in this gallery like has been done previously to facilitate discussion. This will be followed by a week long polling period to determine which logo will be used. Please make sure you submit both a qualifier version and a normal version. Please send all submissions to Potatotron. You must supply a high-res PNG file and the original multi-layer source file.|
|Cloverleaf logo: .png .svg||
|Cloverball logo: .ai .png .svg|
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.
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.
You can convert a v1.9 .4ccm to a v2.0 .yml file by using this tool. (Due to limitations with how v1.9 was implemented, it must be placed in a folder with your rigdio.exe to do this; it requires some rigdio dependencies.)
Lazy Rigger's Export
The following sample export shows a team with a single anthem, victory anthem, and goalhorn.
team: yourteam anthem: youranthem.mp3 victory: yourvictoryanthem.mp3 goal: yourgoalhorn.mp3
To add chants to your export, we add a
chants: section somewhere in the file:
chants: - chant1.mp3 - chant2.mp3 - chant3.mp3
- before the file names indicates that the chants are a list. Chants do not currently support instructions or conditions, so simply listing filenames will suffice. The order of chants does not matter.
Adding Event Clips
Much like chants, events have their own section:
event:. However, rather than just listing filenames, we need to indicate what type of event they are. Thus, to have
redcard.mp3 play when a player is given a red card, we add
event: red: redcard.mp3
Likewise, we can use
owngoal instead of
red to respond to subs, yellow cards, and owngoals.
Goalhorns and event clips support player-specific audio: only playing when a given player scores (or triggers the event). In the case of goalhorns, having player-specific audio will create a button in the GUI for the streamer; event clips are played automatically from SENPAI. To add player-specific audio, move all existing values in that category (in this case, simply
yourgoalhorn.mp3) to a subkey named
team: yourteam anthem: youranthem.mp3 victory: yourvictoryanthem.mp3 goal: default: yourgoalhorn.mp3
Then, add a separate key named after that player, and give it the player's goalhorn.
team: yourteam anthem: youranthem.mp3 victory: yourvictoryanthem.mp3 goal: Your Gold: goldhorn.mp3 default: yourgoalhorn.mp3
The order of keys within a map does not matter.
If you want a song to play only when specific conditions are met, or apply instructions to change how it is played, it's necessary to expand the simple
key: filename format into a full song structure.
For instance, suppose we want the striker horn for Your Gold to only play on a hat trick. We take
goal: Your Gold: goldhorn.mp3
goldhorn.mp3 in a list
goal: Your Gold: - goldhorn.mp3
Now, we need to expand
goldhorn.mp3 into the song structure, which is a map containing three keys: either
shared to indicate what to play, and then
instructions to explain when and how to play it. First, since we're loading this song from file, we indicate that clearly with a
goal: Your Gold: - filename: goldhorn.mp3 conditions: null instructions: null
Note that there is no dash before the
instructions lines; this indicates they are in the same list entry as the
filename line. To make this play on a brace, we need to add an element to a list in
goal: Your Gold: - filename: goldhorn.mp3 conditions: - goals: [">=",2] instructions: null
Conditions and instructions both take lists of maps from a key to a list of values ("tokens"), which tell rigdio what the condition is and what it needs to do. In this case, we make a
goals condition with tokens
">=",2: this says we will play this song if and only if Your Gold scores their second or later goal.
In v1.x, conditions and instructions were treated the same way by the file format. This is no longer viable due to changes in how the internals handle things, so it's now good to know the difference.
- Conditions change when the audio is played. The archetypal condition is
goals, which plays the file for a certain goal threshold.
- Instructions change how the audio is played. The archetypal instruction is
start, which determines where in the file to begin playback.
To add an instruction to a song, you do much as you would with conditions, but in the
instructions list instead. Continuing from the previous section, if we want to start
goldhorn.mp3 thirty seconds into the song, we use
goal: Your Gold: - filename: goldhorn.mp3 conditions: - goals: [">=",2] instructions: - start: 0:30
Sharing A Song Between Players
If multiple players might play the same song under different conditions, but we don't want to load two instances of the song (thus starting from the beginning both times), we need to load the song into shared space. Suppose you have two players, YourLeftMid and YourRightMid, and you want to play
wingers.mp3 whenever either of them scores. Naively, we could write
goal: YourLeftMid: wingers.mp3 YourRightMid: wingers.mp3
but this would cause the file to be loaded twice, and not play from where it left off if one of them scores after the other. To get the song to resume properly, we use
goal: YourLeftMid: shared: wingers YourRightMid: shared: wingers shared: wingers: wingers.mp3
This will load
wingers.mp3 into shared space with the name
shared: inside YourLeftMid and YourRightMid replaces
filename: and tells rigdio to search shared space instead of the audio folder.
Conditions and instructions can be added to shared songs as normal, but be warned that a shared song will only play if its attached conditions and any conditions on the player using it are all met!
goals: [operator, number]takes two tokens: an operator (>, <, >=, <=, ==, !=) and a number, and will return true when the number of goals scored by the player (including the current goal in cases of a goalhorn) satisfies the condition.
team goals: [operator, number]works like goals, but checks the total number of goals scored by the team rather than just by a specific player.
lead: [operator, number]works like goals, but checks the goal difference (this team minus opposing team) rather than goals by a specific player.
opponent: [string, string, ...]takes one or more tokens, and will return true if any of them match the opposing team name.
match: [string, string, ...]takes one or more tokens, which can be any of: "Group", "RO16", "Quarterfinal", "Semifinal", "Final", "Third-Place", "Boss", "Consolation", or "Knockout" (where "Knockout" covers a combination of "RO16", "Quarterfinal", "Semifinal", "Final", and "Third-Place"). It will return true if any of them match the match settings in rigdio.
home: nulltakes no tokens (note that either
nullis required to indicate that none are provided!) and returns true if the team is at home.
once: nulltakes no tokens and returns true exactly once.
most goals: stringtakes zero or one token, the name of a player, and returns true if that player has scored the most goals in the match. If
nullis provided, it will return true if the current player has scored the most goals in the match.
every: numberreturns true if this player has scored a multiple of the given number in goals.
time: numberreturns true if the goal was scored after the given game minute (SENPAI required).
"Magic" conditions are shorthand for other conditional setups; they don't correspond to a Condition object within Rigdio, but can be used with
null tokens to easily construct common objects.
brace: nullis treated as
brace+: nullis treated as
hattrick: nullis treated as
hattrick+: nullis treated as
comeback: nullis treated as
first: nullis treated as
team goals: ["==",1].
Meta-conditions are conditions which operate on conditions. They are considered to be for advanced users, with the exception of the relatively simple
not. Rather than taking tokens, meta-conditions take a list of conditions.
- not takes a single condition and returns the opposite of it.
- or takes a list of conditions and returns true if any of them are true.
- and takes a list of conditions and returns true if all of them are true. (Note that this is the default behaviour of condition lists, and thus is only necessary inside other meta-conditions.)
- if takes three conditions. If the first one is true, it returns the result of the second; otherwise, it returns the result of the third.
start: timetakes one token, a time (in seconds or minutes:seconds form) which is used to pick the start point for a song.
pause: typetakes one token which is either "continue" or "restart". "continue" specifies the default behaviour: when a song is paused it will resume playing from the same spot later. "restart" tells the song to start from its start time every time it is rewound.
end: typetakes one token which is either "loop", "stop", or "loop start". "loop" specifies the default behaviour: when a song reaches the end, it will continue immediately from the beginning of the file. "stop" will end playback immediately upon reaching the end of the file. "loop start" will repeat an associated
startinstruction's beginning time.
Examples of Full YAML Files
/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/, 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: Akkarin: - 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 Befriending/Feito: - 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 Homucifer: - conditions: - opponent: vr - not: - first: null filename: u - vr Homu - Magia 8bit.mp3 - conditions: - not: - first: null filename: u - u Homu - Magia.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
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
sharedkey, containing a string which indicates the location of the song.
- Optionally, a
conditionskey, 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
instructionskey, 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
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
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:
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/ YML file, we have simply
This key is required!
This key should contain a song list containing all songs which
This key takes the same values as
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
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/ 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
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.
This key should contain a map with any of the following keys:
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.
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!
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
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 (
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.)