Suggestions for Improvements and Quality of Life

[BellaDona007]

The bot relies heavily on the $tu command to indicate that a roll has ended. In my case, since I have over 70 rolls, it ALWAYS behaves this way: when there’s one roll left, it uses $tu, then rolls, and then uses $tu again. This pattern makes people suspect that you’re using a bot.

I’ve been playing around with Antigravity to add some features, but every time I tried to implement something, it ended up breaking the previous feature. Still, I managed to get it working, even with a few issues (I’m not a programmer, hehe):
The bot counts the keys during the roll (whether you got 1 or 2 during the roll)
It identifies if you received any BKU bonuses and displays them as bonuses, including when the BKU resets due to Starwish
A safety pause for when there are a lot of rolls; in this case, I implemented it so that every 20–25 rolls, it pauses for a few seconds (the duration varies) before resuming

At the end of the roll, it shows how many keys and kakera you got in that run and how many you’ve gotten that day; it saves this to a file named statistics.json with the following structure:
{
“Server”: {
“channels”: {
“channelID”: {
“display_name”: “Channel Name”,
“history”: {
“2026-04-26”: {
“total_kakera”: 1318,
“total_claims”: 0,
“total_keys”: 5,
“from_claims”: 0,
“from_dk”: 0,
“from_rolls_bonus”: 1318,
“from_clicks”: 0
}
}
}
}
},

And it also generates a text file for each channel; sure, there are some unnecessary extra details, but that's how it appears in the text file

--- EARNINGS REPORT (April 26, 2026) ---
Server/Channel: Server- #Channel

TOTAL: 1,318 ka

DETAILS:

• Captures: 0 ka (0 characters)
• $dk Bonus: 0 ka
• BKU/KEYS6+: 1,318 ka
• Keys Obtained: 5 keys

---

Last update: 10:52:59

And the bot itself already showed the daily total at the end of the roll; I was going to set it to show only that roll's total, but it displays it like this
[2026-04-26 11:36:07][ALL ROLL] - Total: 12,227 ka
[2026-04-26 11:36:07][ALL ROLL] - Captures: 0 ka (0 people)
[2026-04-26 11:36:07][ALL ROLL] - $dk Bonus: 0 ka
[2026-04-26 11:36:07][ALL ROLL] - BKU/Keys 6+ Bonus: 8,500 ka
[2026-04-26 11:36:07][ALL ROLL] - Click Kakeras: 3,727 ka
[2026-04-26 11:36:07][ALL ROLL] - Keys Earned: 39 keys

And I ended up translating the bot into Brazilian Portuguese using Antigravity.

Sorry if my English isn't great—I'm using a translator.

[misutesu-desu]

Hello! Thank you so much for this amazing feedback. I really love your ideas and how you made them work!

For the $tu spam problem, I already have an idea in my mind to fix it. I will work on it soon. Also, I can add your stats tracker idea and different language options for the menu in future updates. They are great features!

I would be very happy if you join my Discord server. I want to give you a special role there as a big thank you for your help and ideas.

Thanks again for making MudaRemote better!

[BellaDona007]

I asked angravity to explain how he implemented things as I asked him to do them. I’m not sure if this helps, but here’s what he said:

🛠️ Feature Implementations & Technical Improvements (MudaRemote)

This version introduces several core improvements to bot intelligence, humanization, and data persistence. Below is a technical summary of the key changes:

1. Kakera Registration & Consolidation System

• Gain Interception: In the on_message event, a listener uses a Dynamic Regex based on user identifiers (client.user.name and display_name). The pattern rf"(?:{names_pattern})[, ]*\+([\d,.]+)" captures Mudae's gain confirmations.
• Sanitization: Values are sanitized via re.sub(r"[^\d]", "", value) to handle thousand separators (dots/commas), allowing for integer arithmetic.
• JSON Persistence: Data is managed via update_daily_stats, indexed by [ISO Date] -> [Preset Name]. It follows a Read-Modify-Write pattern to ensure stats are preserved across bot restarts.
• Report Aggregation: An export function parses the JSON and sums categories (from_claims, from_dk, from_rolls_bonus) into a human-readable .txt report.

2. Variable Cycle Logic & Humanized Pauses

• Randomized Intervals: Between roll batches, the bot uses asyncio.sleep(random.uniform(20.0, 25.0)). The uniform distribution ensures wait times are non-repetitive floats to mitigate detection.
• Micro-Jitter: A variable delay (0.5s to 1.5s) is injected between individual commands within the roll loop to simulate manual typing latency.

3. Intelligent Bonus & Key Detection

• Universal Key Counting: Uses re.findall(r'\(\s*\**\s*(\d+)\s*\**\s*\)', text) across the entire embed body (description + footer), enabling detection of multiple key lines and high-affinity levels (Keys 10+).
• Position-Based Bonus Detection:
  • The bot identifies a Separator Token (the key emoji 🔑 or custom key ID).
  • The description is split into segments: parts = dbg_desc.split(key_marker, 1).
  • Validation: If the captured value (dbg_kv) exists within parts[0] (Top section), it is classified as source="bonus". Otherwise, it is logged as source="click".

---

These changes aim to provide better transparency on earnings while significantly improving the bot's "stealth" and reliability.

[BellaDona007]

3. Intelligent Bonus & Key Detection (Value Extraction Logic)

• Regex-Based Extraction: To capture the numeric value from the embed description, the bot uses a specialized regex: r"\**([\d,.]+)\**\s*(?:<:kakera\w*:|ka|💎|💙|💜|💚|💛|🧡|❤️|💖|✨)". This allows the bot to identify the value regardless of the emoji used or if it's formatted with bold/italics.
• Universal Key Counting: Uses re.findall(r'\(\s*\**\s*(\d+)\s*\**\s*\)', text) to scan the entire embed, summing up all keys (Gold, Chaos, etc.) and identifying total affinity levels.
• Strategic Embed Segmentation (The "Bonus Gate"):
  • Step 1 (Pivot Detection): The bot locates the Key Marker (🔑) in the description.
  • Step 2 (Structural Split): The description is split into top_section (everything before 🔑) and bottom_section.
  • Step 3 (Validation): The bot sanitizes the top_section (removing dots/commas) and checks if the extracted numeric value exists within it.
  • Decision:
    • If Value exists in Top Section -> Marked as BONUS (Pre-key bonus).
    • Else -> Marked as BASE VALUE (Intrinsic kakera).
  • This logic prevents misidentification even when the bonus value is identical to the base value.