Automation changes

[Valentin-Metz]

Hi, I'm currently the maintainer of the second-largest fork of the original repository.

We've done a lot of work over more than one year now to enable automated headless support for this miner.
As you are currently maintaining the new primary fork, I'd like to offer you an overview of what we've done and some suggestions into what you might want to merge.

In general, this fork is currently able to run completely autonomously within a Docker container and farm both linked and unlinked campaigns.
As this was never an intended target of the original repository, these changes were never merged by the original maintainer.

You'll probably want to merge at least a few things to make keeping the forks in sync easier, so that maintainers don't have to prepare separate versions of improvements for the different forks.

Here are a few of our improvements you might want to merge in:

1. Docker & unlinked campaign support (This is the easiest option. If you don't mind your fork supporting these features, I'd recommend this, as it'll allow me to pull request all future improvements into your fork directly and gives users the best support)
2. Everything without Docker (This keeps all code changes in-sync and I'll just add the few additional files related to Docker in my fork)
3. Better console logging support and variable names unification. (I'd still suggest that you keep the code changes we did for unlinked campaigns and simply disable delete the checkbox for it from the GUI)

If you have any questions or want more info on anything, I'll do my best to be of service.
After you decide whether you'll want to merge anything, I'll do a cleanup of the commits and try to offer a clean rebase onto your current state with whatever you want to merge.

[Windows200000]

@Valentin-Metz I should note, that I personally find not supporting CLI kinda wasteful, as I would personally just let it run on a remote server, so I don't have to leave my PC on for occasional limited campaigns. Similarly, I find a lot of his efficiency arguments pretty meaningless, since it's written in python. But since this is the de-facto main repo now and might eventually merge back, I don't want to do anything DevilXD doesn't approve of.

As for unlinked campaigns, I simply do not see the purpose. You can create an account even for games you don't own yet and link it. The only way I see it being useful is for farming a drop without knowing what that linked account will be, which again is a thing enabling "mass mining", which DevilXD doesn't want.

I would definitely consider the rest, but I do not want to do too many unnecessary changes to make merging back to DevilXD easier, if and when that occurs.

I think a bunch more logs would be useful, but I don't think any print statements make sense and more detailed logging should maybe have a second box or something, because while seeing progress there is nice, it is also useful to easily see multiple hours or even days of mining history.

[Windows200000]

@Valentin-Metz?

[jaredcat]

As for unlinked campaigns, I simply do not see the purpose. You can create an account even for games you don't own yet and link it.

Twitch themselves allows this, though. If they didn't want this to be possible, they could change it on their end. It seems odd to make a bot and then restrict it in this case when no one is asking for this to be done.

[Windows200000]

As for unlinked campaigns, I simply do not see the purpose. You can create an account even for games you don't own yet and link it.

Twitch themselves allows this, though. If they didn't want this to be possible, they could change it on their end. It seems odd to make a bot and then restrict it in this case when no one is asking for this to be done.

@jaredkotoff I understand that, I just do not see any use case at all, only the possibility of seeing something being mined and forgetting to link. Especially since the unlinked drops would then be categorized as completed. As I said:

You can create an account even for games you don't own yet and link it. The only way I see it being useful is for farming a drop without knowing what that linked account will be, which again is a thing enabling "mass mining", which DevilXD doesn't want.

[jaredcat]

You can't simply create an account if the game costs money. I use this constantly as I wait for sales to buy games.

If you have an issue with mass mining maybe don't make a mass mining bot...

[Windows200000]

You can't simply create an account if the game costs money

@jaredkotoff I have never played a paid game where you can't. From big publishers like Ubisoft to stuff like Klei Entertainment (making Don't starve), Rust (linking Steam), you could make a Minecraft account (even before it was Microsoft) without buying it etc. etc.

If you have some examples of such games that have Twitch drops, that would change things, it's just nothing I ever encountered.

[jaredcat]

Helldivers 2 didnt even let you link an account. (the way this drop worked had a link account button but it doesn't actually link in twitch.)
West Hunt requires you to own the game.
King of the Castle requires you to own the game.

Again I use this all the time. I can find more examples.

Update: I would also note there's a lot of games that are F2P but to link an account you need to download the games. While only annoying for me, this could cost money to people who have data caps where downloading a game could cut into their monthly budget.

[Valentin-Metz]

Unlinked campaigns are mainly useful if you don't know about a campaign existing yet, but still want the drop, or if the linking website of the publisher is down/overwhelmed (this happens occasionally on big releases).
Efficiency for this bot will never be an issue. Not because it is written in Python, but because it doesn't do a single thing that is computationally expensive. Everything that takes up time in this bot is either a sleep, or waiting for the answer to a web request.
My reasons for enabling console logs is, that I can pipe and filter log output with grep (and all the other tools designed to work on console output). This is great for debugging.
Example:

docker logs twitch_drops_miner | grep -E "Progress:|Claimed drop:|Started|Stopped|No available channels"

(in this case the bot got stuck on claiming a drop and was restarted; something to look into later)

[Windows200000]

Maybe we could make stuff in the priority list ignore unlinked? That seems intuitive, simple to implement and easy to revert, if DevilXD ever wants to merge back and doesn't like it.

I should update the "how to use" anyways.

[Windows200000]

Efficiency for this bot will never be an issue. Not because it is written in Python, but because it doesn't do a single thing that is computationally expensive. Everything that takes up time in this bot is either a sleep, or waiting for the answer to a web request.

@Valentin-Metz I think some very old laptops, that a surprising amount of people use, could see a noticeable difference from using python, but I am not worried about efficiency. As I said, I find DevilXD's level of care for it a little excessive.

But after some more consideration, I don't think I want unlinked campaigns, for now. DevilXD has expressed his wish to return and I feel like I've more borrowed this repository, not to it over. If DevilXD does not come back, I might look at it differently.

For now, the people that need unlinked can just use your fork, just like people who want a headless version.

As for the prioritize_end varname, if that's important to you, I would need to look into how GitLocalize would deal with that.

And there isn't much else, is there?

I would be willing to help make your job of patching easier, if that's possible.

[Valentin-Metz]

That's alright. I'd leave this pull request open, maybe that'll make the fork easier to find if anyone is specifically looking for automation.
The variable mostly came up because @jaredkotoff created a pull request in each of our repositories (which I appreciate), but there was a spelling mistake in the one to this repo, that's why I want to fix it before anything diverges.

[jaredcat]

Yea my code was merged into Valentin-Metz's fork first, I only opened the PR here as a courtesy to this fork. So the variable name diverging wasn't anticipated since this fork didn't have the functionality at the time the PRs were created.