This unmaintained version no longer claims properly.

[ANTFOR7717]

At the current time, this bot can start but absolutely will not claim correctly due to some discord DOM edits and some logic. I've forked and fixed this and it works decently now on my server. If you want access to the new source code just DM me on discord. Nerdy_Koala#9470

[ANTFOR7717]

Yeah sorry I actually forked this and put it up on GitHub again awhile back

https://github.com/ANTFOR7717/AutoWaifuClaimerV3

Note there's two branches, one for using a container to run this on any system and the other if you've got a MacBook and Python 3.8

[ANTFOR7717]

No prob, add my discord tag: NerdyK#9470

[TheNanoMan]

Hi, Is it still working? I also would want a little help setting it up if it still works

[ANTFOR7717]

Yes its working again as of today @TheNanoMan

[TheNanoMan]

Great! Can I add you on discord? I think I’ll need some help to set it up

[ANTFOR7717]

Yeah go ahead

On Feb 6, 2022, at 10:00 PM, TheNanoMan @.***> wrote:

 Great! Can I add you on discord? I think I’ll need some help to set it up

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.

[LeLamasticorne]

Hello @ANTFOR7717, I have absolutely never coded anything, so I would like to know if you would mind helping me to set up all this ?

[ashchow95]

Hey! Try implementing your solution. The script goes up to $tu on my server and then fails to parse. Any idea? Tried adding your disc but you had blocked friend requests.

[ANTFOR7717]

My fault mate, my remote branch is a bit behind on my local branch. Ping me on Discord if you can I can get you the latest version. I'll try to get this GitHub repo up to date tonight.

[ANTFOR7717]

Hello @ANTFOR7717, I have absolutely never coded anything, so I would like to know if you would mind helping me to set up all this ?

@LeLamasticorne it won't be a problem, getting this started doesn't require any code just copy and pasting a few lines

[ashchow95]

My fault mate, my remote branch is a bit behind on my local branch. Ping me on Discord if you can I can get you the latest version. I'll try to get this GitHub repo up to date tonight.

Thanks boss! Couldnt add you to discord friend list. Try mine! Ky Abuser#7207

[LeLamasticorne]

@ANTFOR7717 Oh thanks, can you add me on discord ? Le Lamasticorne#2303

[Edszx]

Im currently getting "Could not parse $tu command, quitting (try again)" with the latest commit of @ANTFOR7717 fork, all IDs and tokens are correct and verified, logging-in works, but the bot never actually sends $tu, the bot also only appears online for a brief moment before going offline.

Thank you for your time working on this, i really appreciate it.

[ANTFOR7717]

Hey @Edszx,

You're going to want to manually put a $tu command in your discord chat before it times out after 30 seconds. It used to send $tu itself but it was very inconsistent and would occasionally fail to send it correctly and crash.

Also in main.py the bot is explicitly told to go offline, which you can disable if you'd like but it's purposeful behavior.

Since you're getting at the way to the $tu parse all your info is definitely correct so once you type in $tu in that chat yourself you'll be good! Also we found it can't parse overly customized tu commands, so if it struggles with yours you'll want to make it vanilla.

[Edszx]

@ANTFOR7717 Thank you very much, you're right, as soon as i sent a $tu with my regular account, the bot parsed the info, is there a way to send a $tu with the bot's account instead to make it use its own info? the $tu parsed may not coincide with the bot account's actual timers.

[ANTFOR7717]

@Edszx that was my original intent but it turns out Discord frowns upon bots communicating with other bots, and Mudae's bot will ignore any command coming from another bot. So bots essentially can't play at all. (But you actually can send them waifus and kakera). So the bot isn't actually playing it's reading all the info in the chat and sending it to a selenium engine that makes decisions on your accounts behalf.

[Edszx]

@ANTFOR7717 Ah, i finally managed to see it in action, but there's a big problem, the bot is not activating the roll task on the correct times, for example:

ROLL_DURATION = 60 TIME_TO_ROLL = 50

This means rolls are set on the Mudae bot to reset every 60 minutes, and the bot should try rolling when the next roll reset is in 50 minutes, that means, 10 minutes after the last reset.

The bot doesn't activate on that time neither if:

• The current time is lower for example, if after parsing $tu the next roll reset is 45 minutes (less than 50) and there are rolls available, it doesn't automatically try to roll to cover for this period.

• If the time naturally goes down to 50 minutes, for example, after parsing $tu, the next roll reset is in 52 minutes, after two minutes when hitting 50, it doesn't start the roll task either.

Just as an example, with a fresh $tu parse that says that the next reset is in 42 minutes, the bot is reporting "Roll timer sleeping for 5520 seconds", which is 92 minutes, that's even higher than the whole roll reset timer from Mudae (60 mins), i don't know where is it even getting that calculation from.

This is all using vanilla $tu with no modifications.

Ps: im currently testing time_to_roll=50, but this also happened with the default 10, it didn't start the roll task when the next roll reset was 10 minutes away, the roll timer is always sleeping for way more time than it should, usually even higher than 60 minutes.

[ANTFOR7717]

@Edszx Yes! It's exactly as you said. Right now no matter what it will wait to start rolling until the next interval.

I expect the behavior of time_to_roll=50 would be it rolling 10 minutes into to the next interval. I haven't tested it though so I can't say with confidence.

But just about every-time the bot is initialized, the timer will be set longer then the 60 minutes. Since it won't attempt to roll until next interval. However it will claim and react instantly if available.

Future updates will give us a greater control of how it behaves without needing to mess with the source code directly.

[Edszx]

@ANTFOR7717 I see i see, thank you very much for your detailed explanation and your acknowledgment of the current behavior, i rest easy knowing that you're already aware of the issues, for now, i'll just manually roll whenever the bot doesn't want to, and let it handle the claims/reactions and kakera snipes.

Something else i want to report: the bot doesn't start the $dk task if $tu reports that $dk is available (it probably only does it on the next iteration, that being after 20 hours)

A quick question: does the bot also claims characters on the lovelist if someone else rolled for them and left them unclaimed? for example, our server has $togglesnipe 5 15, this means that if a character is not on your wishlist (which is pretty small/limited) and someone else rolled for them, you can't instantly react and steal them, you can only claim other people rolled characters after a 15 second safe period, if the bot is set to instantly react a single time, it's not going to catch these kind of claims, because any reaction before the 15 second period are not counted/valid.

As i said, i don't know if that's the current behavior, but i heavily assume so, in that case, i'll assume setting INSTANT_CLAIM_SPEED = 15 would be a workaround for that, with the downside that you would also be letting your own rolls wait for 15 seconds, allowing them to be sniped if the other person was some milliseconds faster than the bot.

A second quick question: What would be the best way to stop/pause the container where the bot is running? (in case the computer needs to be reset/shutdown), to allow it to continue from the saved state when started back up.

[ANTFOR7717]

@Edszx that is a very valid question and I'm glad you ask because that is not an edge-case I've accounted for yet.

In my server, we have a similar protect but it's only for wishes and last for 20 seconds. If I didn't also wish for the character then I'll certainly lose it unless I manually step in and claim (which I've done before).

For your case: the instant_react_speed=15 is definitely cumbersome because it can set you up to get sniped. But you'll also need it to snipe others.

I hadn't originally intended for it be set so high, and I remember there was a very strange bug that occurred when it was greater then 2. I hope that is isn't also the case for you.

But I think it would be best to implement a piece of logic that can filter between someone else's rolls and your rolls and apply the claim_attempt method based on that.

For now I'll add that into my TODO.

For stop/pausing that is something that won't be an issue if you use a cloud service to run your container. And at some point in the future I will make a web application that can orchestrate the creation of waifu-claim containers for users in the cloud.

[Edszx]

@ANTFOR7717 Something weird to report: I changed the server the bot was supposed to work on (removed the containers and images and built from scratch with the new settings/IDs)

The bot is already joined on the server and has permissions to see and interact with the target channel, the claimer reports that it successfully logs in to the account/server/channel, and waits for $tu, i manually send $tu from my account, but now it doesn't parse it, this server is also using vanilla $tu output.

Edit: It literally started working after bringing up the claimer again an hour later, with no changes at all, i'll assume it was discord being weird.

[ANTFOR7717]

@Edszx I had this issue the other night. It was remaining completely unresponsive at the $tu parse and timing out no matter how many times I sent $tu. I don't have the slightest idea why, but a full reset of my computer got it working again. I also refreshed my bot token.

It could be a discord bot related issue.

[Edszx]

@ANTFOR7717 Some notes after leaving the bot overnight:

• With instant_react_speed=15 the bot tried to get another person's roll correctly one time (it didn't win because the person claimed it first, but i saw my reaction was there), but the other time (in which the person actually didn't try to claim) the bot ended up putting the reaction on a random character 4 messages down the chat history (fortunately it tried to do so before the 15 second period for some reason, so the claim wasn't wasted), i'll have to change it to 0 or 1 and give up on auto-claiming other people rolls for now.

• Feature request: Would it be possible to re-parse/update $tu each time the main user sends it in chat? it would be specially useful in case you manually claim or manually use your rolls, that way the bot would change the timer for the roll and claim tasks, to prevent things like the bot sending $wa a dozen times with no rolls available.

• Less Priority: Would it be possible to set the bot to claim with / instead of $ but keep using $ for everything else? / commands give bonus when rolling, but not everything is implemented with /, so using $ for everything else would keep things working.

Again, thank you very much for your time an efforts.

[ashchow95]

Got a silly question. With the new version utilizing Docker, am I still suppose to update the WEB_DRIVER_PATH to a local folder?

I have attempted to use the one provided in the default config and although it does work, it will not parse my $tu command.

I have also attempted to use a local directory in window for it, however that would error out.

[Edszx]

Bug report: KAKERA_DURATION = 0 creates a continuous stream of kakera timer reset events that flood the console/logs, had to leave it at 1 to at least mitigate.

@ashchow95

With the new version utilizing Docker, am I still suppose to update the WEB_DRIVER_PATH to a local folder?

Don't change it from the default http://172.17.0.2:4444/wd/hub, if your $tu is not being parsed the error is somewhere else, it doesn't have anything to do with that variable.

[ANTFOR7717]

@ashchow95 So you don't want to change the WEB_DRIVER_PATH because it currently links so the Firefox container where the actual logic for the bot claimer is being hosted. as @Edszx mentioned as well. But this is also an issue that we have both run into which makes me wonder if this is related to new code that was added or if it's an actual Discord bot issue where it's not actually reading messages anymore. I will prioritize looking into this and trying to get it stable again.

Also @Edszx I really appreciate of the verbosity and semantics of your issue comments. I'll take note of it as bugged behavior in the projects README.md. To answer your comments chronologically:

• I had figured with the instant_react_speed=15 it would sleep for 15 seconds then execute the reaction method, which takes roughly 2 seconds to actually add a react. Because of that, this hack wouldn't be very effective and we would have to make a method that can determine the exact time to react much more accurately. Also, as you pointed out the reaction is indiscriminate and will place it on the most recent message in the chat. This is a known issue with no solution currently.

• I have though about implementing this feature for awhile now, as I noticed after 4-5 days of prolonged usage, the timers actually start to get inaccurate and it throws commands too early and doesn't realize it's failed. When I get a better understanding of how the current $tu parse works its definitely something I could and should implement.

• Currently with how browser.send_text() works, it is not possible to send a slash command, it simply doesn't register and nothing gets sent when a slash command is attempted as input. Possibly a future feature.

Again your feedback has been great and I think we should move these issues onto the currently maintained and forked repository:

https://github.com/ANTFOR7717/AutoWaifuClaimerV3/issues

I'll go ahead and close this one.