Frequently asked questions

Ranked.be and the bot do not really "lock" contests, but rather lock lists of entries. Therefore a contest can appear as locked if the entire list of entries of that contest is locked. So for the remainder of this explanation, the term "locked entries" is used for convenience.

Whether entries are locked is regulated by a "lock list", which is handled by those who can also modify the data in our internal database. An entry can either be specified as "indefinitely locked" (when nothing is known about the precise release date) or specified as locked until a specific point in time. With that in mind, the unlock rules (in their precise wording, with some omissions) are as follows:

• A partially rankable contest should never have 1 or 2 entries unlocked.
• For contests where broadcasters are not in charge of (or responsible for) releasing entries, entries should be unlocked only when all entries for a specific show are published. An entry is in any case considered published if it has been performed in the contest.
• Keeping in mind the above [...], an entry should be locked if someone cannot reasonably rank it, or cannot have reasonably ranked it [...].

The wording above is very specific because of some weird edge cases that have appeared over the years. But in the vast majority of cases, it boils down to the following:

• Contests can be ranked once 3 entries or more are available.
• If it's announced by a broadcaster when entries can be listened to, then this is the time the entries get unlocked. This also holds if entries are released on a day-to-day basis (keeping in mind the minimum of 3).
• In the case that a broadcaster leaves the release of an entry to the participating artists, a contest (or show) will only be available if all entries are out (including if the artists have released them), at the latest when the show takes place.

The rationale here is:

• Rankings of one or two entries have too little entropy to gain insights. So they can only be ranked if that's the total amount of participants in a contest (e.g. in sm2020). With three entries, there are already six possible ways of ranking something, which is why over the years it became an unwritten rule to only unlock rankings when three songs are out.
• From a maintenance point of view, it is very hard to keep an eye out on which songs are released and which ones aren't if it's not regulated by a broadcaster. To do this for each individual entry, one would have to keep a close eye on each individual artist and quickly update the data whenever it is posted on one of their platforms. This is not really viable and so (in those cases) a contest/show only becomes available if all songs are out.

Toggle your title preferences with the !usetitles command. You only need to run this command once and the bot will remember your preference. By running the command again, you "toggle off" the title preference meaning the bot will instead use country names (the default).

Although it should be technically possible to support this without too much hassle, this is mostly because of moral objections:

• A !bias command for JESC countries could lead to statements towards children of specific countries that I would very much not like to encourage. Whether positive or negative, it may encourage quotes like "wow, children from country x are so great" or "damn, children from country y really can't sing" which in turn may lead to very creepy conversations.
• Similarly, the !clog command puts a clown emoji after an entry if it has reached last place. Putting such an emoji behind the entry of a literal child is similarly discomforting.

So in short, although it is not hard to support the above functionality, it is not supported because of (potential) ethical reasons.

for !battle, !compare, and !entry.

This is something that was not always the case, but a behaviour change of Discord starting from (from what I remember) around the start of 2019. To keep a long story short: before, your client (Discord app) would cache some basic information of every user on a server, so that it can easily access that information whenever needed. For example, to convert a user mention from something like <@1234567890> to a username, you need this information.

Loading data for every user on a server is fine if the server is small. However, if a server has 100000 members (roughly the max at that time), loading in the data of all users would understandably cause issues on some devices. If the data would be just a kilobyte per user, you would download (with 100k members) 100MB of data whenever you open a server. Your phone's data plan may not like it, neither would your RAM.

So Discord introduced something they call "lazy loading" the member list. They don't cache all users, but only users that are likely to be relevant for you. For "small servers", this is still everyone. But for large servers, it's a mix of your friends and people who you've recently read messages from, up to some limit. Everyone else is not cached. If you run a command and some users show up as random numbers, it means that that user is not cached, and that the user somehow has to be added to your cache before you can properly see the name highlighted.

If you really insist on wanting to see who the user is, you can do the following to "force" the user into your cache:

• Copy the ID of the user (so the numbers). Let's use 273770135276355584 in this example.
• Perform a search, with as query from: followed by the ID. In this case: from:273770135276355584.
• Click on any result that pops up, preferably in another channel than the one you ran a command in.
• Switch back to your command. The number has now likely turned into a name!