UncleGoogle / galaxy-integration-humblebundle

Humble Bundle integration for GOG Galaxy 2.0
GNU General Public License v3.0
187 stars 18 forks source link

Humble Choice effected by keys config (or seperate config) #123

Open tauqua opened 4 years ago

tauqua commented 4 years ago

Is your feature request related to a problem? Please describe. The config option to enable display of humble keys does not effect the Humble Choice subscription. I choose to leave the keys option disabled because I often use my keys for gifts or trading and when I do use a key for myself I don't want the redundancy of Humble and the platform I redeem it on both showing up. For these purposes Humble Choice is no different than any other bundle, but there is no way to disable Choice games from showing up.

Describe the solution you'd like I'd appreciate either the show keys option also effecting Choice keys, or a separate option with the same effect for keys.

Describe alternatives you've considered Disabling subscription import for the plugin works for this, but it also removes Humble Trove, which I would like to keep.

UncleGoogle commented 4 years ago

Hi @tauqua, thanks for report.

I'm not sure if understand correctly, but you probably mean Subscription games like this one: https://i.gyazo.com/f0d54a7a69f01aac048bc6f97570e890.png (marked as "Choice"). It is just Choice entry to be chosen. One game entry can contain multiple keys, or multiple DRM-free downloads as well theoretically. I have information if particular choice has keys but on the other hand I have no information if it contains any DRM-free items. Those are 2 different interfaces, but I understand a problem.

Have you tried to bookmark different view, like only Owned but no Subscriptions? See https://github.com/UncleGoogle/galaxy-integration-humblebundle#recommended-humble-choice-view but this won't show Trove as you said

You can also disable Choice Games via Galaxy Settings->Features, but the problem is you will have to do it for each subscription month (and again when a new month is come).

Maybe separate configurarable mode could be good solution for problem like that, see last comment, last point of this thread: https://github.com/UncleGoogle/galaxy-integration-humblebundle/issues/115 In your case when you deselect both "choice mode" and "keys" then only DRM-free subscription games will be returned from get_subscription_games method. Drawback: you would need restart Galaxy to apply changes.

Another solution would be to have config checkbox to "show choice as separate months". Then you can deselect it to group all Choice games as one "subscription", restart Galaxy, go to Galaxy settings-> Features and disable "Humble Choice" at all. Drawback: no extrases nor DMR-free choice games.

How do you think?

tauqua commented 4 years ago

Personally I think a config option for "choice mode" would make the most sense since it seems more intuitive to understand than "show choice as separate months". Either could work though.

Thanks for pointing out the ability to disable individual months, I wasn't aware of that so that helps already.

nosyn00b commented 3 years ago

I copy here your interesting post from #147

Could't you simply ignore (not passing the single games to GOG) if the the game is in status 3 and "show reveled keys" is not flagged?

I do that already in get_owned_games interface. The game is still visible in Galaxy because it is returned from get_subscription_games interface.

In the second interface I have no information about keys state.

But yes, those interfaces could theoretically depend on each other using cached games from one of them, something like:

def get_subscription_games(self, subscription_name):
    sub_games = ...
    if not self._settings.show_revealed_keys:
        revealed_key_games = [g.machine_name for g in self._owned_games if isinstance(g, Key) and g.key_val]
        yield [game in sub_games if game.machine_name not in revealed_key_games]
    else
        yield sub_games

that's one idea. I don't remember why I didn't want to go that direction, need to recap potencial drawbacks.. otherwise that's briliant and can be used to fix #123

EDIT one obstacle is that in current implementation you have to have checked "keys" and not checked "show_revealed_keys".

If you unselect "keys" self._owned_games does not contain keys at all.

I think there are two ways of solving this obstacle.

The first one is going your way, but maintening in the plugin a parallel list of revealed_key_games, even if they are not in the _owned_games list that you probably use to pass the games collection to the GOG client.

The second one is looking better in the events node of a subscription JSON. When choosing a game the event is registered there. I don't know if "revealing a game key" is also registered there. I'll have a better look at that if I can!

UncleGoogle commented 3 years ago

The first one is going your way, but maintening in the plugin a parallel list of revealed_key_games, even if they are not in the _owned_games list that you probably use to pass the games collection to the GOG client.

yes, exactly.

The second one is looking better in the events node of a subscription JSON. When choosing a game the event is registered there. I don't know if "revealing a game key" is also registered there. I'll have a better look at that if I can!

Looks interesting, I didn't know about those events. I don't think revealing keys is there - but yes - please check if you can. Maybe it is also connected with this https://github.com/UncleGoogle/galaxy-integration-humblebundle/blob/master/src/webservice.py#L226 ? It would be awesome to have list of ever-donwloaded troves... (there is issue about that already)


The third way, that I prefer (but I have no much time recently, too much privet stuff) is to make a few steps back and see the whole image. The UI. Gather list of all possible use cases people tend to use their Humble library, choices, keys and so on and then decide on what and how we can implement it in the most straightforward and robust way. It is bigger effort, but may safe time and painful code "despaggetting" in the future.