Ha! First issue! Can't take that title from me

Describe the bug
Sometimes, (only happened once), when the bot is stopped when writing inside JSON file, the file is voided (it's empty).

To Reproduce
Steps to reproduce the behaviour:

1. Get 420% of bad luck
2. Stop the bot,
3. See a JSON file (under /JSON) be voided
4. Bot dies when restarting (if it's moderators.json) or when using JSON file

Expected behaviour
Do not void JSON :'(

Additional context
An idea: fetch JSON from GitHub each time the bot is started, and also sent JSON files to GitHub each time the bot is stopped (aha F)

See:
https://github.com/Compliance-Resource-Pack/JSON/commit/0c43cc8670a0f04cb8e868a034d1bd8c52564191
https://github.com/Compliance-Resource-Pack/JSON/commit/a59cbe518b51f1cdeec28916ce7d2797549240e4
https://github.com/Compliance-Resource-Pack/JSON/commit/505a21c4fc99c65cd59846573d560218534b7b61
https://github.com/Compliance-Resource-Pack/JSON/commit/167b444e53f57d70b6a96c9bb8cfcf54bf8fc1d5

And likely some more which I didn't find.

Describe the bug
When executing the GetResults function, everything seems to works, but when checking the local JSON, contributors are not updated and the JSON commit is empty (-> no file modified)

To Reproduce
Steps to reproduce the behavior:

1. run the function GetResults
2. See that nothing changed inside JSON files

Expected behavior
Authors should be added

Additional context
Might be, (but idk honestly) related to the file handler system.

Messing around from a discord bot 👀

We now have programmer art branches on the Default-Java repo for versions 1.14 and above. It would be great if it were possible to search for these just like you can already search for regular vanilla 16x textures.

How it should work:
Vanilla 16x (Programmer Art) should show up among the other projects when choosing one from the menu.
If the user selects a version ≥1.14, the PA branches are used. Otherwise, the regular ones are used (as they're already programmer art by themselves)

Note: Ideally #30 should be implemented before this feature is.

Describe the bug
When a version is updated from the webapp, the bot is desync regarding its own settings.json, which broke the /missing command if the version updated is the latest one

To Reproduce
Steps to reproduce the behavior:

1. Update the latest version from an edition (ex: java) of the settings.json (on database.compliancepack.net)
2. Do /missing 32 java
3. Bot dies

Expected behavior
the local settings.json should always be up to date with the distant one

Additional context
Fix by itself when the bot is restarted (the file is fetch at start)

This only happens on specific textures, for example the black_candle. (/texture 16 black_candle)
The choice embed shows 2 results and after adding both reactions, it instantly chooses the first one without any user interaction. So far this hasn't happened on any other texture.

From looking at the code I have no idea how this can happen, and even just on specific textures. I'm really clueless.

Is your feature request related to a problem?

No.

Describe the feature you'd like

Pretty much what it sounds like, when running /texture on CF 32x PA for a bedrock exclusive texture, currently it does not show up.

This should ideally function exactly as the main Faithful packs, and Classic Faithful 32x Jappa do currently.

Notes

Pretty high priority but not an absolute must.

I think it would be better for the /instapass command to post its messages in #results rather than #submit-java or #submit-bedrock. This would make compiling changelogs a lot easier for me.
Additionally, instead of the embed just displaying "the council has decided to instapass this texture", it should show the author, the texture, and the file name, just like the other messages in #results.

Is your feature request related to a problem?

No response

Describe the feature you'd like

Similarly to how the 32x Jappa submission channel pushes to both the Java and Bedrock repositories, please make the 32x programmer art channel do the same.

This previously was not the case since there was no 32x PA for bedrock during the initial setup, but now it has been out for a while and should definitely be connected.

The GitHub URL of the repository in question can be found at https://github.com/classicfaithful/32x-programmer-art-bedrock.

Screenshot(s)

No response

Notes

No response

Describe the bug
When executing the /about me command, if you select the second reaction (the 1 emoji) before the bot can give the third reaction, the bot clears all reactions except for the last one (the 2 emoji) and then stops and doesn't do what it's supposed to

To Reproduce
Steps to reproduce the behavior:

1. Do /about me
2. React to the second reaction before the third reaction pops up
3. That's it.

Expected behavior
Bot edits message to show contributions list after receiving the reaction

Screenshots

On which discord did it happen?

• Compliance 32x

Additional context
fosho

This issue is to keep track of what needs to be done before releasing the submission system v3

Submission System v3

"Frontend" part

• Create a special event that runs when a user is sending a message inside a submit channel
  • Set up submission channels inside a global config file for both discord & teams (groups of discord servers)
• Create an automated function that checks for submission
  • Submission should be stored on the bot & saved into a .json file on any changes

"Backend" part

• When a submission is over (and successfully ended), the file should be:
  • Create a contribution to the API
    • all API endpoints should be written
    • ALL the current contribution system should be converted to the new format
  • Downloaded on the local git repo
  • Pushed to each branch the texture exists with a commit that contains the information:
    • Contributors
    • Texture name

Features

• No more daily push, everything is doing synchronously per texture; this will allow us to:
  • Also specify contributors in the submission git commit
  • Being able to reverse a git commit that wrongly comes up to the pack
• The user is able to submit a .zip with multiple textures
• The user is able to submit .tga (MCBE) files
• A compared version of the textures is shown inside the submission embed
  • The compared version should be animated when the texture is registered as being animated
• Votes are anonymous
  • They can only be seen by:
    • the submitter (of course)
    • #202
    • council members
    • admins
• Contributors can be listed without being mentioned (only writing their names should work)
  • #168
  • #159
• Submission now clearly shows their status within a specific colour for the embed
  • yellow: instapassed
  • green: added to the pack
  • red: invalidated
  • black: not added to the pack
  • crimson: in council
• Timed events should be configurable:
  • Should be in the config JSON
  • Time before the council is customizable (default 3 days)
  • Time before pushed is customizable (in council phase/default 1 day)
  • Council can be skipped / disabled
• Contributor role is automatically added to the user if the contribution succeeds (instapassed/added)
• Matching default resources should be displayed (programmer art when the pack is progart OR jappa otherwise)

What happened?

The command, /todo add was added a few months ago. It was meant to be a replacement for the todo list currently stored in a Google doc. Council can add things to that list, but we have no way of removing them.

To reproduce

Do /todo add
There's no command to remove the items from the todo list.

Screenshot(s)

No response

Notes

No response

It would be good to have a version tag for the /texture command, to view older textures of the game.

For example, if you would want to see the old 1.16 ore textures, then you could use:

/texture 16 diamond_ore --ver 1.16

If you would want to see the newest one, then you could just not specify the tag.

Describe the bug
Sometimes, JSON files are read and updated at the same time, causing desync issues.
Ex: mute command: if someone is muted while the bot actualizes the mute countdown, the newly muted user could be not muted or the countdown is not decreased.

To Reproduce
Steps to reproduce the behaviour:

1. Try to mute someone when the bot updated muted list.

Expected behaviour
A working database

Additional context
Do not change the countdown time process, if the bot updates the file less than each 30s, you can't write in the file anymore
Might be related to the autopush issue (contributors removed between 2 push)

Describe the bug
When doing any texture command which has multiple results, the bot only listens to the emoji reactions after it is done reacting itself. You would need to react again if you already reacted before.

To Reproduce
Steps to reproduce the behavior:

1. Any texture command that has multiple results, for example /texture 32 oak
2. React any emoji before the bot is done reacting

Expected behavior
That the bot already listens to the reactions before it is done.

Screenshots

On which discord did it happen?

• all of them

Is your feature request related to a problem?

We're going to support some default Forge and Fabric textures soon. These are not in the minecraft namespace, meaning that omitting the initial part of the path would produce misleading and incorrect results.

Describe the feature you'd like

Title.

Screenshot(s)

No response

Notes

No response

Is your feature request related to a problem? Please describe.
Earlier today [He who will not be named] joined the server and was promptly muted. However, he started typing in the submission channels. This should not be the case. I realize the feature of being able to submit textures while muted came up while I was muted, but there was a time when I had previously mentioned making submissions available to muted contributors and not every muted person.

Describe the solution you'd like
Only let muted people with the contributor role speak in submission channels

Additional context

What happened?

When using /restart to restart the bot, the bot is actually restarted without being correctly killed first, leading to an infinite loop of errors such as: DiscordAPIError: Interaction has already been acknowledged because the bot is trying to respond to interactions for each instance of itself (but it works 1 time only)

To reproduce

1. Be a developer and do /restart
2. The bot restart, yeet
3. Do /ping
4. Observes the DiscordAPIError: Interaction has already been acknowledged error loop

Screenshot(s)

Notes

• This might be related to this line of code which is weird because the destroy object instantiates itself again and again
• I put the security flag on it since it could lead to API spam which could lead to the bot being banned from using the API? (Maybe idk)

Describe the bug
Since db migration (I suppose), choice embeds are broken and can't give us the correct output.

To Reproduce
Steps to reproduce the behavior:

1. Do thisGo in a text channel
2. type:

/cmp snow 16j 32j 64j

3. Bot gives you undefined propositions

Expected behavior
It is supposed to give a clear and concise description of the texture

Screenshots

Additional context
I'm hungry

Describe the bug
When submitting a texture, the bot is supposed to add people that are pinged in the comment as co-authors. The bot, however, does not do this if said pinged user is not in the server.

To Reproduce
Steps to reproduce the behaviour:

1. Upload a valid texture to #submit-textures (any)
2. Ping any user that's not in the server (for example <@!373928073176809485> (LethalChicken) in the comment
3. Pinged user is not added into the Authors field

Expected behavior
The pinged user should be added as a co-author.

Screenshots

(https://canary.discord.com/channels/773983706582482946/773987409993793546/933532626906665030)

Describe the bug
The displaying of the bot latency is displayed wrong. That is happening because the bot is using "message.createdTimestamp" to calculate it's ping and the command suggestions are awaiting the user's reaction before executing and thus increasing the "ping".
The issue is, that I don't know of any different way of doing this, that's why this issue is marked with "help wanted".

Also see: https://github.com/Compliance-Resource-Pack/Discord-Bot/blob/master/commands/Bot/ping.js#L50

Screenshots

Describe the bug
The bot crash after doing /contributor or /push
The bot executes the command, then don't respond to any new commands & goes offline (crash).

To Reproduce
Steps to reproduce the behavior:

1. Get a computer
2. Get a keyboard
3. Get a discord account
4. Go anywhere where the bot is
5. Type /push <anything that's works>
6. Bot dies

Expected behavior
Do not crash?

Screenshots
Nothing showing up in the console

Additional context
Might be, and have to be related to #33

What happened?

When looking through the stack.log given by an unhandled error (or the /log command (untested)), the order of the last 50 actions is kinda weird, not always ordered by the timestamp (which it should be)

To reproduce

1. Create an error/use /log
2. Download the stack.log file & open it
3. See order being messed up

Screenshot(s)

Notes

• The order should be: 50 the most recent, 1 the oldest.

What happened?

When using the missing command, if the pack reached 100%, the bot sends an empty file (which is useless)

To reproduce

Use this command /missing pack:Faithful 32x edition:Java version:1.18.2

Screenshot(s)

Notes

No response

This would be a hassle on restart since we have to ensure that it gets a message before a command; not a big deal but also should be patched

What happened?

In the string "Command.Profile.noContent", in the file "messages.json", in the Discord-Bot (or CompliBot) project, the word "Minecraft" is improperly capitalised as "minecraft".

To reproduce

N/A

Screenshot(s)

No response

Notes

No response

by PedroESP_01

There's a problem around compliance with the voting system. That problem is Bandwagoning. People usually vote on what they see as more popular. I feel this is also the case for new users as well. They aren't truly voting for something, rather voting for what other people are saying.

one solution would be to introduce a button voting system as well as menus as nick has done done before. Combined with this, there should be an option in the menu to see the votes which will only be visible to the author. This ephemeral post could also have a timestamp for when the last person voted on the texture.

Additional Context: Nick knows everything and has been working on this before the typescript transfer.

Describe the bug
When using the star emoji to instapass the texture, the texture is sent to #results but nothing happens after

To Reproduce
Steps to reproduce the behavior:

1. React any textures anywhere in submissions channels with the star emote
2. See #results
3. Nothing

Expected behavior
Push to GitHub + Contribution added to the database.

Additional context
I haven't coded anything for that yet (oofed).

What happened?

undefined is shown instead of the pack name in the outputted embed

To reproduce

Use this to reproduce /missing pack:Faithful 64x edition:Java

Screenshot(s)

Notes

No response

yeah

By utilising button, context and menu interactions in djs v13, the bot can handle things when received instead of listening for reactions making bot ui better with a reliable, elegant and usable solution.

This could be done by using an interaction handler and a few files of js to replace the emoji ui. Since context commands have to be registered like slash commands, i suggest adding options for magnifying,tileing, palleting and guidelines as those are commonly used (but keep original commands to them aswell)

note: i have done this before to a previous bot that used emojis and it took a week but was well received by my - now inactive - server.

What happened?

When instapassing a texture in any classic faithful submission channel, the embeds and buttons work fine, but the textures do not get pushed to any branch.

To reproduce

1. Submit a texture to any Classic Faithful submission channel (#32x-submit-jappa, #32x-submit-progart, or #64x-submit-jappa).
2. Open the instapass/invalid menu using the gray arrow button and press instapass (the gold star icon).
3. Check the #github channel, no pushes appear. The embed colors change fine, and the buttons seem to work, but on the site and GitHub desktop no commits appear to pull.

Screenshot(s)

No response

Notes

The workaround is to simply cherry pick any changes by hand, however 32x-programmer art has almost every branch entirely maintained through autopush, and as a result any changes made have to be manually backported to around 15 branches, which takes a very long time to do.

The whole setup was also working entirely fine until July 23rd, so I'd suggest to look for changes made around that time period.

When clicking the "See older contributions in the WebApp" link in the /texture embed, the user should be sent to the specific texture they searched for, instead of just the gallery like it is right now.

Describe the bug
When adding is intelligent enough to know if it is a bedrock texture, remove only removes it on the selected edition.

To Reproduce
Steps to reproduce the behavior:
Add a texture contribution which is on java and bedrock
Remove the contribution of the previous result and push
See committed bedrock contribution

Expected behavior
Remove both

What happened?

The title pretty much describes it, when searching for a texture using /texture but the search fails, I'd expect the bot to tell me that something went wrong. Instead, nothing happens at all.

To reproduce

1. Search for a non-existent texture with /texture
2. No error message is shown

Screenshot(s)

No response

Notes

No response

Is your feature request related to a problem?

Yes, the current feedback system duplicates the current possibility to create issue on the repo

Describe the feature you'd like

Using the bot account & the GitHub API, fill out the following forms used for issues/feature request & push them to GitHub

Screenshot(s)

No response

Notes

No response

Use submodules repo from /repos/* for the /missing command instead of cloning the repo in a temp file

by Juknum

• Implements slashs commands
  • Fix handler for guild only and global commands

  slash commands are deployed per guilds, if the bot join a new guild, slash commands are fetched & bot restarted.

  • Basic setup
  • Add subcommands
  • Watch for implementing command group (Not needed)
• Extends class to add methods where it's needed
  • Extends EmbedMessage to add a default color ('BLURPLE')
  • Extends Message with warnUser(text: string) (now renamed warn)
  • Extends Interactions classes:
    • CommandInteraction
    • ButtonInteraction
    • SelectMenuInteraction

Describe the feature you'd like

Oftentimes, particularly when backporting or changing versions, certain textures that are not necessary or shouldn't be there can slip in. While there is a tool that can already do this, it would be far more convenient within the Discord client, very similar to how /missing works.

References

https://mctools.mullak99.co.uk/textures and https://nera-w.github.io/packchecker.html already do similar, the latter one has not been updated in some time however.

Notes

Pretty low priority overall, just a nice quality of life feature to potentially consider.

When the bot tries to get the contributor when (for example) displaying the output of the /texture command, but the contributor is not in the server the command is executed in, only the user ID gets displayed, which is not helpful at all. (this is supposed to be Hozz.)

It would be really nice if, instead of this, the bot could check whether a given contributor is in the server, and if they're not, display the contributor's name instead. A less clean workaround would be to do something like [contributor mention] (contributor name) for every contributor, skipping the server check.

/compare a command to compare a texture with the corresponding vanilla texture (with magnifying built-in)

As example I'll take the texture command and its reactions.

When using the texture command and for example the tile reaction, due to the bot replying with the tiled image to the texture command message, the bot is the "author" of the command and then also replies with the magnified tiled image to itself, even though the original message author didn't react to magnify.

If you ignore the bot's reaction using if (user.bot) return the bot doesn't magnify its own image, but also doesn't listen to the original message author, due to the bot still being the "author" of the texture command message.

This issue also applies to the texture submission reactions.

Describe the bug
When you use Complibot in DMs, a few commands such as /quote works; however, I cannot do /texture 16 (or 32) whenever I want to grab a texture. For example /texture 32 dirt, won't work, nor does the /animate command.

To Reproduce
Steps to reproduce the behavior:

1. Go into CompliBot DMs.
2. Do either /texture 16 dirt, /texture 32 dirt, or /animate (on a texture that can be animated).
3. Bot doesn't respond.

Expected behavior
It's suppose to give me the dirt texture or any other texture that I requested.

Screenshots

What happened?

/clear doesn't clear any amount of messages and returns unknown message as its error

To reproduce

type /clear 10

Screenshot(s)

No response

Notes

No response

Syntax: /remove [texture file path]
What it does: The same stuff as /push, except it deletes textures from the repo.

Syntax: /instapass [message link from #submit-java or #submit-bedrock]
What it does:

1. Removes all reactions from the message
2. Reacts with ⏩
3. Gets the name and other arguments from the message title
4. Gets the image texture
5. Pushes the texture to all available branches, according to java.json

Describe the bug
Transparency goes brr when magnifying an image which has transparent pixels

To Reproduce
Steps to reproduce the behavior:

1. use /texture 32 tinted_glass
2. use the magnifying glass to automatically magnify it
3. see those transparent pixels become opaques.

Expected behavior
Pixels using alpha values should stay transparent after process.

Screenshots

Additional context
Should be related to the output extension which is JPEG (JPEG doesn't support transparency) (I might be wrong)