Making it possbile for users to set a text channel for music commands

[bemoty]

Why?

Often commands to control the music bot are being spammed by users all over the server into every text channel, no matter what the actual purpose of the corresponding channel is. This often makes it impossible to read older messages in a channel after someone abused it as their music command spam channel.

How?

In fredboat.commandmeta.CommandManager.prefixCalled(), line 132 (invoked instanceof IMusicCommand), the bot would have to check if the executed music command has been executed in the (if set) "correct" text channel (context.getTextChannel()).

Of course this would also require a command which makes it possible to set that specific channel (-> Writing a Command. The set channel for music commands could then be saved in the local configuration of the bot (fredboat.Config).

Anything else?

What do you think of this idea? Has something similar to this already been suggested before? At least the implementation of a feature like this doesn't seem too hard. :)

[freyacodes]

We usually just tell people to use permissions

[bemoty]

The problem in my case is that I have a private Discord server only for me and all of my friends on which (almost) everyone has got the "Administrator" permission, thus everyone has ADMIN bot permissions and can basically do whatever they want.

Yes, I know that this would also mean that everyone of them could change the channel for music commands, but it would already help me to kind of remind them to use the correct channel.

[Nanabell]

to me, this seems more like a moderation problem of your server. even if everyone has ADMIN permission doesn't mean the bot ignores discord's permissions. If you deny its ability to send messages or connect to a voice channel it won't accept command or cant join the channel. Just like you said "everyone could change it but it would help"

[bemoty]

that's actually a very fair point. thanks for the tip! :D just thought this might be a good idea as other bots like "hime hime" also got this feature.

[schnapster]

This could actually become a necessity. As FredBoat continues to grow, we will get close to the global ratelimit for messages sent per second at some point, which can only be worked around with webhooks (aside from making FB less chattery), and webhooks are bound to a specific channel. Offering, and at some point maybe even requiring, users to set up a channel for music commands which we will then serve via webhook would be a possible course of action. Currently we reach 40-50% of the global message send ratelimit during peak times (assuming a global ratelimit of 50 messages / s). This number is offset by a decent amount of message editing that we do, and I'm not even sure that those have their own global ratelimit (they do have their own ratelimit per channel). Worst case (the sending and editing share the same global ratelimit), we could be at 60-85% of ratelimits during peak times.

I did a bit of testing cause over DAPI noone actually knows anything. Created a bunch of channel in a guild (95) to avoid hitting the channel message ratelimit. It does appear that that ratelimit of POSTing and PATCHing messages in a channel is shared.

Eval scripts used: Only sending:

<<eval var counter = 0;
var AtomicInt =  Java.type("java.util.concurrent.atomic.AtomicInteger");
var sent = new AtomicInt(0);
var toSend = 400;
var timer = System.currentTimeMillis();
while (counter < toSend) {
    guild.getTextChannelsByName("asd" + (counter % 95), true).get(0).sendMessage("" + counter++).queue(function(message){
      sent.incrementAndGet();
    });
}
while (sent.get() < toSend) {
  //spin
}
var timeTaken = System.currentTimeMillis() - timer;
channel.sendMessage("Took " + (timeTaken / toSend) + "ms per message").complete();

Sending and editing:

<<eval var counter = 0;
var AtomicInt =  Java.type("java.util.concurrent.atomic.AtomicInteger");
var sent = new AtomicInt(0);
var toSend = 400;
var timer = System.currentTimeMillis();
while (counter < toSend) {
    var tc = guild.getTextChannelsByName("asd" + (counter % 95), true).get(0);
     tc.sendMessage("" + counter++).queue(function(message){
      sent.incrementAndGet();
      message.getTextChannel().editMessageById(message.getIdLong(), "oof").queue(function(ignored){
          sent.incrementAndGet();
       });
    });
}
while (sent.get() < (toSend * 2)) {
  //spin
}
var timeTaken = System.currentTimeMillis() - timer;
channel.sendMessage("Took " + (timeTaken / toSend) + "ms per message").complete();

Here are result from doing it with 400 messages (completely avoiding any channel rate limit hits) and 1000 messages (may hit channel ratelimits additionally to global one):

400, only sending: 400, sending and editing:

1000, only sending: 1000, sending and editing:

Even if the editing is chained behind the queue(), I would think that the increase should not be linear, if sending and editing global ratelimits were unrelated?