carlst99 / uvocbot Goto Github PK

Expected behaviour: the command lets the user know what they did wrong in a user-friendly manner.

Camera would like a custom command that he can use to escape a voice chat. His personal description is as follows:

a command that moves me to a private 1 person channel with a music bot that plays James Blunt's "You're Beautiful" on loop

I suggest that the channel be created dynamically, with view permissions disabled for the 'everyone' role. Will have to keep tabs on the channel, to ensure that it is removed when Camera leaves.

A voice solution will be required for this.

• The help and version commands should include a link to this repo in the URL field of the embeds.
• The version command should be aliased to info / about.
• The version command should become a general-purpose informational embed.
• The current guild's prefix should be shown in the help and version embeds.

Expected behaviour
Retweets that have not yet been posted will be relayed

Observed Behaviour
No retweets are relayed

Currently, we skip all retweets as they're often replicated between the devs. However, we should hold an in-memory queue of the last 100 tweets (including the base tweet, in the case of a retweet) and then compare incoming retweets to this list.

Add functionality to the bot enabling people to use the command '!bonk ' and send them to a channel '#rowdy-gaol'.
EDIT: and play this sound https://www.youtube.com/watch?v=c4wopc9-SJU&ab_channel=AviatorAlex1

When using the team generation functions on a large number of members, the embed character limits may be exceeded. Utilising the pagination functions of the DsharpPlus.Interactivity extension should overcome this hurdle.

See https://dsharpplus.github.io/articles/interactivity.html for more information.

Currently if a command errors, a reply message is sent with the full stacktrace. I propose instead only sending the exception type, and any message included in the exception for release builds / production environments.

Currently, replies that a Twitter user makes are not relayed. An option should be added giving guilds the choice of having these tweets relayed.

Suggestion by yummygoat - leaders should be able to setup recurring reminders for squad ops, etc.

I envision this could be done through an interactive process - the command sequentially leads the user through selecting a message, specifying roles to ping, the time and day on which the notification should be made, and how often it should recur (in days, weeks or months)

An issue with the current account distribution process is that it sends accounts to everyone with the specified role. This means no-shows get accounts, which isn't good practice.

A better way to manage distribution would be to have a default option, where the comand issuer is required to be in a voice call, and only those in the voice call alongside them will receive accounts. There should also be an overload that accepts a params value of users to send accounts to.

Both of these methods will require the bot to keep a record of who has received which accounts, in order to support multiple distribution calls for the same account block.

E.g. when a new player joins the outfit, have reactions that they can tap to indicate that they're new to the game. Have leadership notified and offer them training. Etc.

Letting a guild pick their own command prefix would be a significant QoL improvement.
I propose this is done using a prefix command - ub!prefix <new_prefix>.

To implement this, a custom command handler will be required. See the SharpPlus docs for more info.

A Prefix property will also need to be added to the GuildSettings object.

Finally, the client will need to know each guild's prefix. I propose this workflow:

• Client caches all guild/prefix pairs from the database on boot
• On each command, if handler finds a guild/prefix pair this is utilised, else the default prefix is used
• On a change in prefix, the client updates both the database and its local cache

When using the help command to get information about a command that has no parameters, an InvalidParameters exception is thrown. This results in the following message being returned to the command issuer:

You haven't provided valid parameters. Please see ub!help for more information.

An example of such a command is help group list

Transferring as little data as possible is of course the best solution. Try and keep each map below 2mb in size. JPEG compression on LOD2 (for the larger maps) should achieve this.

With this feature, Guilds could select an in-game outfit for UVOCBot to follow and collate various statistics about. Suggestions include:

• Congrats message on player rank-up, with customisable interval
• Report on outfit's average scores (total kills, avg. kpm/kdr etc.) over the past week
• Comparison or chart of historical averages
• Monthly VIPs - most time spent, best KDR, best KPH, most TKs

These features should all have individual toggles. Furthermore, each guild should only be able to track up to four outfits each (or whatever the current number of in-game factions is) to prevent unnecessary load on the bot.

The default help formatter presents information in a manner that's a little hard to chew. I propose the following changes:

• Top level groups are listed first, and separately from top level commands
• Commands have a line each and show their description, e.g. ping - Pong! Checks that UVOCBot is awake
• A demonstation of how to use the help command to view information on specific commands is included
• The guild's custom prefix is shown - see #24

The /worlds/ endpoint is not consistent with the actual status of the PS2 servers. Instead, the global game_server_status endpoint should be queried, as it is more accurate. However, this endpoint does not expose information for Soltech or Jaeger (although Briggs has been removed... F in chat plz). Jaeger status can be inferred from Emerald's status, but Soltech will have to continue using the current method.

https://census.daybreakgames.com/s:example/get/global/game_server_status?game_code=ps2&region_code=live&c:limit=100

Commands such as the team generation can be computationally expensive, and should be ratelimited

Moving people between channels is a regular occurence, and painful because members can only be shifted one at a time.

• Move all to another channel
• Move a pre-determined group to another channel