Derived ownership

[Revadike]

Apps are always packed within a sub/package. One app can have many packages and packages can have 1 or more apps. When redeeming a steam key for a certain package will report already owned if you already own all the containing apps of the package the key activates, even if you don't actually own this package.

I'm suggesting an option to add packages/bundles to our barter library, if you own all its contents. This will help avoid traders from offering packages/bundles of games you already own, but barter hasn't picked up as owned directly from the steam API.

For example, you may own Dead Island, Dead Island: Riptide and all the DLC on steam. Then this option would automatically add Dead Island Collection to your barter library too.

[bartervg]

Thank you for the suggestion and for testing it. This is part of the library sync process now.

[Luckz]

Thank you for the suggestion and for testing it. This is part of the library sync process now.

Reminder that my concerns with this NEEDING a manual blacklist or even manual whitelist were never addressed. Some human eyes on it. https://barter.vg/i/61692/ https://barter.vg/i/63693/ Any search for 'LV' or 'low violence' shows a whole ton of those.

[Revadike]

What is barter doing wrong regarding these titles?

[Luckz]

They're packages that differ from the regular game based on depots, not app IDs.

https://barter.vg/i/47549/ is a non-regional example.

Chat from April 2019 about i/47549 during initial (?) development of this feature:

[15:03] barter: that seems unfixable [15:04] luckz: it would be EasyFix by having a SpecialDepotsPackage flag for items-that-contain-items [15:04] barter: your definition of EasyFix is not the same as mine

[19:13] barter: I'm not sure about this https://barter.vg/i/47549/ [19:13] barter: I have a bad feeling it will lead to depot tracking [19:13] barter: and reproducing SteamDB

[19:39] luckz: I don't say 47549 should be auto-detected as a depot-different extra-content sub, I'm asking how to a) enhance Short Distinguishing Description with a warning about this, b) ensure autopackagematch won't match it

---

If we view Barter not as a library tracking tool (hello @Tecfan and friends), but only as a trading tool, you can indeed view it as irrelevant that region locked or violence locked or region and violence locked titles packages appear as owned even when they are not. For your purposes of not being offered trades, it still works well.

OTOH for packages that differ on game content via depot instead of app (untracked by Barter.vg for good reasons since #WeAreNotSteamDB and such) like 47549 and a few other peculiar ones, you have an impossible-to-find wrong implicit blacklist for a product you don't (fully) own, yet Barter thinks you do. If we really wanted, we could solve the DLC-as-depot issue manually using the existing system by creating our own fake app IDs 😹 and adding those to things like 47549, at the cost of also implementing another crutch that awards such FakeDepotIDs to anyone that custom(!)-adds the affected sub to Library. IMO it's a stupid workaround on top of a workaround, and my 2019 suggestion of blocking some packages by hand is better.

From a library tracking POV, packages that do or contain things you don't own/want (like apply Low Violence via depot or app or flag) shouldn't appear as owned. Extremists might even say packages that are not the exact subID they own should never appear as in-Library, but that view fundamentally misunderstands that Barter's packages are meant to play the role of tradables.

[Revadike]

I'm pretty sure if you attempt to activate any package you don't own, but own all included apps, steam reports it as AlreadyOwned, which is the whole basis of this idea. Having them be distinguished, would only make sense for the ultra rare cases where you'd first remove a package via steam help, activate this new package, and then restore the old one.

Either way, I think this feature of derived ownership, should be an optional checkbox next to the sync button. Default should be with derived ownership. That should solve this issue, right?

Wait, you're saying barter also marks packages as owned, even if you don't own all the apps inside? Do those cases exists too? That's a problem.

[Tecfan]

I'm pretty sure if you attempt to activate any package you don't own, but own all included apps, steam reports it as AlreadyOwned

This is not true. If a package has 67 apps you own, but just 1 extra depot exists in sub, Steam will swallow your entire key and waste it on that 1 depot. Has happened to me a couple of times,

Example: Free Metro 2033 sub (1 app): https://steamdb.info/sub/318565/ Retail Metro 2033 sub with 1 extra depot (1 app): https://steamdb.info/sub/2989/

activate retail sub if you already own free sub and the key will be taken away from you :(.

[Revadike]

Ah okay. I thought it was app based, not depot based. Good to know!

[Luckz]

Ah okay. I thought it was app based, not depot based. Good to know!

That's how the whole trap of activating violence-locked keys works: in the cases I listed on the screenshot above, it's depot-based. Usually an extra depot, so you can redeem it on top of your existing game and forever be haunted with censorship (while the package is alive). https://steamdb.info/sub/15707/depots/ https://steamdb.info/sub/1846/depots/

There's also the case that the low violence and regular game have entirely different depots, https://steamdb.info/sub/51390/depots/ vs https://steamdb.info/sub/91308/depots/ — so owners of the low violence can still redeem the other on top.

These minor app / depot differences are why it's entirely unsafe to "just try keys & see what they do". I've lost a 10€ value a bunch of times, and not only with games that actually have different DLCs and editions but even with something as trivial as Garry's Mod, https://steamdb.info/sub/218/ vs https://steamdb.info/sub/216/ .

[Revadike]

Thank you for the suggestion and for testing it. This is part of the library sync process now.

It does not seem to be working? I did an API sync and it did not detect I owned this package: https://barter.vg/i/4650/ Even though, I own all the included items, as detected on barter.

[bartervg]

Even though, I own all the included items, as detected on barter.

You own 8 of the 4 included games 🤪...😣

SteamDB has 9 included items. Barter has 9 in the database, but 5 of them are merged. This hides them from related, but not from the derived ownership. If there is there is a mismatch between the number of included games you own and the total count, no item is added to library.

One way to fix this would be >= total items, but this seems like it would hide problems rather than fix them. Instead, I've ignored merged profiles since this is more consistent with the visible information.

I ran the derived ownership sync and it added https://barter.vg/i/4650/ to your library.

[Revadike]

You own 8 of the 4 included games 🤪...😣

Huh?

[bartervg]

You own 8 of the 4 included games

I misread. It should be 9 of 4 included games.

At least on the Barter library, you own apps 34460, 34440, 34450, 34470, 8804 also. Due to inconsistent methods of counting, this resulted in you owning 9 of the packages apps, and yet the package's total number of apps was set to 4. Thus 9 of 4 included games.

[Revadike]

I think counting may cause bugs like these. It's better to explicitly check if the included items are all owned. It will likely take a performance hit, but hopefully not that much?

[bartervg]

I think counting may cause bugs like these.

It does cause bugs, but they should be fixable.

Another potential bug is that packages are auto added and never auto removed. If a package receives new apps, the package will still be listed in library despite the library not having all of the included apps.

I haven't tried the explicitly checking method, so I don't know what the performance would be. The current method took around 200ms for you (with no rows inserted).

[Revadike]

I think counting may cause bugs like these.

It does cause bugs, but they should be fixable.

Another potential bug is that packages are auto added and never auto removed. If a package receives new apps, the package will still be listed in library despite the library not having all of the included apps.

I think you can combat this manually, by periodically deleting everything from library and let it sync freshly. Because revokes are also a thing. In fact, I'm thinking of doing that now, or soon if you want to work on the new package checking method.

[bartervg]

I think you can combat this manually, by periodically deleting everything from library and let it sync freshly. Because revokes are also a thing. In fact, I'm thinking of doing that now, or soon if you want to work on the new package checking method.

Deleting and re-inserting seems inefficient, but it would be easy to delete all automatic library entries before running the derived ownership sync.

My idea would be to remove only the entries that were no longer valid, but this is a more complicated process than simply redoing the process from zero.

[Revadike]

but this is a more complicated process than simply redoing the process from zero

Perhaps you can do a hybrid solution: calculate the new collection and compare this with the old collection in the backend. However, it would be better to first check existing collection one-by-one for ownership, secondly calculate new owned entries (from steam API and/or custom input) and lastly look for derived ownership.

[Revadike]

Thank you for the suggestion and for testing it. This is part of the library sync process now.

It does not seem to be working? I did an API sync and it did not detect I owned this package: https://barter.vg/i/4650/ Even though, I own all the included items, as detected on barter.

This is working now, btw.

[Revadike]

It's still not working perfectly. I performed the following test.

1. Cleared library
2. Pulled/synced owned apps from public Steam Web API
3. Added owned apps (NOT owned subs) from the private Steam Web API (comprehensive sync, minus the packages)
4. Synced again to trigger derived ownership algorithm

In theory, it should add all my owned packages too (assuming barter's database is perfect). However, it did not add many of my owned packages, even though I own all included appids. A few examples: https://barter.vg/i/113076 https://barter.vg/i/130743

[Revadike]

There was no derived ownership calculated for https://barter.vg/i/150107/, even though I own the included game in the package.