notchum / nyah-bot Goto Github PK

Is your feature request related to a problem? Please describe.

no

Describe the solution you'd like

If either waifu for a round has a GIF cached, the thumbnail should also be a GIF to support it.

Describe alternatives you've considered

Currently, the GIF would only be in the waifu embed within the thread, but only the first frame would be in the thumbnail.

Additional context

.gif -> temp folder (1.jpg, 2.jpg, ....) -> resize each image in temp folder -> loop(place each image in bb -> save each full image bg+fg -> overwrite images in temp folder) -> generate final .gif from temp folder -> remove temp folder

Is your feature request related to a problem? Please describe.

Describe the solution you'd like

Describe alternatives you've considered

Additional context

• waifu modification command

  • waifumod modify_waifu_entry
  • slug option
  • uuid option
  • url option (parses slug from embed if message)
  • husbando option true/false

• waifu addition command

  • at first, just accept fandom links (E.g., https://clonewars.fandom.com/wiki/Ahsoka_Tano)
  • parse fandom for core info
  • waifus.core.source = "fandom"
  • create channel in support server to review entries before adding to waifus.core
  • later, create custom waifu command (possibly on a per guild basis)
  • increase RNG for custom waifus

Is your feature request related to a problem? Please describe.

The bot is stuck on Python v3.10.4 but should be updated to the latest version. Also, all database query calls are blocking calls.

Describe the solution you'd like

Update the Python version. This entails updating the RethinkDB Python wrapper; however, the latest official release doesn't support 3.12. Using these PRs with the wrapper should allow for 3.12 compatibility:

• rethinkdb/rethinkdb-python#296
• rethinkdb/rethinkdb-python#298
• rethinkdb/rethinkdb-python#300
• rethinkdb/rethinkdb-python#302
• rethinkdb/rethinkdb-python#303

Additionally, the ReQL calls throughout the code can be (should be) adapted to use async. An example:

import asyncio
from rethinkdb import r

async def main():
    async with await r.connect(db='test') as connection:
        await r.table_create('marvel').run(connection)

        marvel_heroes = r.table('marvel')
        await marvel_heroes.insert({
            'id': 1,
            'name': 'Iron Man',
            'first_appearance': 'Tales of Suspense #39'
        }).run(connection)

        # "async for" is supported in Python ≥ 3.6. In earlier versions, you should
        # call "await cursor.next()" in a loop.
        cursor = await marvel_heroes.run(connection)
        async for hero in cursor:
            print(hero['name'])
    # The `with` block performs `await connection.close(noreply_wait=False)`.

r.set_loop_type('asyncio')

# "asyncio.run" was added in Python 3.7.  In earlier versions, you
# might try asyncio.get_event_loop().run_until_complete(main()).
asyncio.run(main())

Describe alternatives you've considered

N/A

Additional context

This update will not be backwards compatible with Python version <3.11.

Is your feature request related to a problem? Please describe.

Describe the solution you'd like

Describe alternatives you've considered

Additional context

Character Images

• Right now, I use GIS to search for extra character images. This uses Google's API, which is limited to 100 requests per day. DDGS is a good alternative for image searching that doesn't seem to have a rate limit (TBC) - however, the accuracy of anime-related images aren't as good as Google.
• Preferably, I'd like to have a "gallery" of images associated with each character in the database. At a larger scale, user-submitted and user-verified images are the best bet to add new images. But, at the current scale the only solution is web-scraping for these images. The website that shall not be named has an plethora of images for each character in the database - however, these images are locked behind a user-login.

Commands

• /leaderboard needs to be paginated. Only create embeds for top x amount of users?

Duel Arena

• Database index "guild_user" allows for only members playing other members. Using only "user_id" would allow for cross-guild duels.
• Matchmaking algorithm will need reworked to be more dynamic when finding neighbors.

Waifu Wars

• Should only be hosted in main server.
• Should have a cap for each war, but can create channels for each ongoing war at will.

Deployment

• Shards. Don't know how to do this.

Describe the bug

In the top-level messages for Waifu War rounds, the winner is displayed with green check boxes around their name. If their opponent (the loser) is a real user then their name will have red crosses around it. However, if their opponent was 'BYE' (for a bye-match), then the red crosses don't appear properly.

Expected behavior

The 'BYE' should have visual indicators of loss.

Screenshots/Logs

Additional context

N/A

Proposed Solution

Perhaps detect if the embed's field is a bye-match during creation of the embed itself, and instead of putting team color emojis first just put the green checks or red crosses.

Is your feature request related to a problem? Please describe.

No.

Describe the solution you'd like

A command that buys a "pack" of waifus at a cost. (i.e. /pack)

Describe alternatives you've considered

N/A

Additional context

It should be pure random. Wishlist should not affect odds.

Is your feature request related to a problem? Please describe.

Currently, a waifu war match up just shows images of the two characters and asks users to vote. What are users voting for that they like better about one character versus the other?

Describe the solution you'd like

Instead of just asking users to vote, ask them a question about the match up. For example:

• "Which of these characters would look better in a wet t-shirt?"
• "Which of these characters stinks the most?"
• "Whose outfit is the most fashionable and stylish?"

Creating a list of prompts by hand could be cumbersome. Perhaps a generative text LLM could help here (i.e. ChatGPT)

Describe alternatives you've considered

N/A

Additional context

N/A