-
-
Notifications
You must be signed in to change notification settings - Fork 161
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Priority list for channels #105
Comments
Please see #70. Having #70 in mind, none of the rest of the features you're suggesting make much sense. If the goal is to get the drops only, it doesn't matter much which channel is going to be watched. Besides, there already is a priorities system implemented for the game's list, and adding channel priorities on top of this would just add more complexity for little benefit. The current system sorts the final channels list by the amount of viewers it currently has, for a lack of a "started at" field that'd let me know the length of the stream, with the assumption that more popular channels tend to stick around ONLINE for longer periods of time, requiring less switching between channels. No other sorting method made much sense to me, maybe besides sorting by channel points - no idea what that'd represent though. |
I suggested this feature only because of the user wanting to choose his favorite channel for points farming. I don't see any reason to not implement a feature like this, even if the project started with other intentions. It's strictly related to watching streams, and expanding is not a bad thing. There is no need of changing name too. I can understand if you are not going to implement this because of time or will. |
I understand this, however as I said, this is a drops-focused application - earning the points here is simply a byproduct of that. Things such as displaying the amount of points in the app's window were simply a matter of one more column and one more line of code in the display function, and claiming the bonus 50 points were just a matter of handling an event I was already receiving and adding a few more lines to not let the unclaimed points go to waste. Again, adding an entire additional priority system to channels, on top of the already existing priorities system, accommodating displaying that information in the UI, as well as letting you setup that list (more UI changes), plus adding logic for it to do what you want here, simply isn't worth the effort IMO. If you'd like to focus on earning channel points specifically, please search for a different application that's focused on doing so - again, this is a drops-focused one. As a side note, I was considering adding a checkbox to the channel list that when ticked, would prevent auto-switching away from the currently selected channel. It's primary use would be to prioritize drops from a particular game via a particular channel, in case the mining target would be a set of tiny campaigns (like Rust and it's one-per-streamer drops). It could have a bunch of other uses like what you've just suggested, but would be limited only to the currently selected channel and nothing else. Easy to implement as a feature with no state saving (like the inventory filters), and easy to handle in the logic too - at least in theory. It's no "proper" priority list, but would probably do. I've never specified it's semantics though, for example:
Also, this would not come with any ability of adding a particular channel you'd want to the list, so if there would be no applicable campaign that could cause it to show up on the list - no way to prioritize it. This is, again, something I don't see a point of adding, simply because the miner already adds all applicable channels for drop mining on it's own. |
Is it possible to add a priority list for channels that need to be watched for a drop? It should check if the channel is online, and if so watch it instead of choosing the first one in the list.
It would also be nice to be able to watch channels without the need of a drop. Just to collect channel points.
The text was updated successfully, but these errors were encountered: