We all know that SteamGifts (SG) does not identify many owned games. This appears to cause a lot of reroll and deletion requests, which also appear to be slow to occur. For this reason, I use ESGST to identify owned games so that I can 'ignore/hide' them on SG. I have not seen an instance where ESGST made a mistake, that is, mark a game as owned when it was in fact it was not owned by me.

I have also seen a number of suggestions to fix this SG 'bug' such as:

  • implement a warning for all games known to be affected (Steam is learning etc)
  • Software being sold that loads your owned game list and marks them 'ignored/hidden' on SG

It seems to me that if ESGST can correctly identify games, as well as other paid software which I have not tried and cannot verify, why can't SG? Rather than SG potentially spend resources to create a workaround for a bug, why not fix it?

Can anyone identify a reason why SG would not or should not?

5 months ago

Comment has been collapsed.

What is your preferred solution to the SG bug that does not correctly identify owned games?

View Results
SG is fine the way it is. I don't mind making reroll and deletion requests and don't see any better use of the mods time
SG should fix the bug so that games are correctly identified as owned the way that ESGST and other software are able to
Rather than fix the bug, SG should implement a warning to the effect of 'you may or may not already own this game'
(obligatory) potato

ESGST uses this link https://store.steampowered.com/dynamicstore/userdata/
And this link shows the data for your current logged in account.
ESGST can see it because you are logged in in your browser (and it will show you an error if you suddenly are not logged in).
So, on SG servers there is no your account logged in, so SG can't check it.

SG uses steam API, and this API does not return all that 'learning' things.

5 months ago
Permalink

Comment has been collapsed.

It has been a long time since I have done any programming. I am no longer a technical guy, so I am open to explanation as to why this is not possible. but I am sure that we are logged into Steamgifts accounts to be able to enter giveaways and post posts. Maybe I'm missing your point?

4 months ago
Permalink

Comment has been collapsed.

You must be logged in with your "steam account" for esgst to work. For example - I'm logged in on steamgifts for about 2 months without logging out. In the meantime steam logs me out automatically everyday :)

But i don't think it's a big problem. SG could save additional data when you are logged in with steam - you will just have to remember to log in occasionally.

4 months ago
Permalink

Comment has been collapsed.

Thank you. I appreciate the response, your time and effort

4 months ago
Permalink

Comment has been collapsed.

Well, there are two ways of retrieving data from Steam.

SG uses Steam API. It means that SG make a request to a special address, for instance https://api.steampowered.com/IPlayerService/GetOwnedGames/v1/?key=XXX&steamid=76561198005585830. This link has your ID in it as an example, so if SG makes this request - it gets your data, if I make this request - I too get your data, and so on. If I want to get my data, I need to change your SteamID with mine. The information we get with this link - it depends on how the link is formed (whose SteamID is in it, it's a parameter).

But there is another way. Imagine we have a link, like this: https://store.steampowered.com/account/licenses/
When you are visiting it from your browser, you see your information. When I'm visiting it, I see mine. But the link is the same, Steam has a cookie( or something like that) to identify the user who is trying to access the information, and that's why it shows you yours, and it shows me mine.
So what will happen if SG makes a request to this link, whose information will it get? It won't get anything (or maybe it will get cg's info, if there is some authorization data on the SG server, but I'm not sure on this part), because there is no SteamID in the link, there is no way to identify, which user's information we want to get with this link. (And it's done this way because this information is private, and should not be available via API.)

The same goes with this link https://store.steampowered.com/dynamicstore/userdata/
There is no way for SG to make requests to this link by adding a SteamID to it, cause this link is working only for the account, logged in currently in the browser. ESGST can access it because it's an extension, so it has some access to your browser data. SG can't access it, cause it doesn't have access to your browser data, besides some tiny things like your IP, cookies (for SG site only, it doesn't have access to your Steam cookies) and so on.

So here goes the difference: the API way is designed to be used by anyone else to retrieve any available information (unless you make your account private). The second way is designed to be used by individuals to retrieve their own information only.

I think I'm not very good at explaining things, and English is not my native, but I hope I managed to make it more clear for you.

4 months ago
Permalink

Comment has been collapsed.

Thank you. I appreciate the response, your time and effort

4 months ago
Permalink

Comment has been collapsed.

if ESGST can correctly identify games, [..] why can't SG

A comment I wrote up for an earlier instance of this topic:

The Steam API has two methods of access, the developer access (that is used by any 3rd party [eg, website] to access multiple user accounts) and the user access (that is used by a specific user to access their own account information, and which is utilized by browser scripts and idling software and the like).
The developer access doesn't give out information on DLC ownership, so you'll always be able to enter any giveaway on SG for a DLC, or for a package which includes at least one DLC [as it is impossible for SG to recognize if you own the content in question]. The exception is when you've previously won that DLC through SG, as SG can check against the site's history of your wins in that circumstance.

In other words, SG can't tell what DLCs you own because they're using their own login, rather than yours, and they thus don't have the permissions necessary to access some of your information. Unless Steam changes it so DLCs can be recognized by non-personal logins, there's nothing SG can do about the matter.

As far as your suggestion for SG to note which games are profile limited/etc, I'm under the impression that Steam doesn't send any of that information out through the API. So there'd be no way for any special circumstances games to be recognized by SG outside of staff manually flagging them, and that'd be too demanding and unreliable to be feasible.

5 months ago*
Permalink

Comment has been collapsed.

Does this suggest that if the login on Steamgifts was different, then the information would be available?

4 months ago
Permalink

Comment has been collapsed.

When Steamgifts pulls data for the site's general use, they're going to be using the developer login. I believe that Steamgifts currently doesn't make any use of individual user steam community logins past the initial registration. After all, I've been using the site without being logged to community [within the same browser] for years now. :P

I suppose in theory Steamgifts could just utilize community login to integrate such personal elements, especially since they're more a convenience factor than anything integral to the functioning of the site's core foundations. Unfortunately, the extent of my knowledge of the underlying mechanics involved ends around that point, so that possibility would be something you'd have to check against with those who've done more with Steamworks development.

The best people to ask would likely be the Steamgifts associated backlog/library management groups [such as Backlog Assassins]- after all, given their focus on organizing a user's library, they'll have likely considered such matters in depth. SteamDB, ITAD, and the other major steam community associated sites may be options as well, as I believe most of them have their own community discussion areas that could be made use of. There seem to be a handful of users with Steamworks development experience just floating around on SG, so it's also an option to just create a general inquiry thread.

Anyway, tl;dr, I can't tell you if Steamgifts could potentially access that information, I can only tell you that it has previously been clarified that Steamgifts' current structure cannot, and the basis given for such was what I described in my earlier post.

/

As far as profile features limited and so forth, I don't think there'd be any way to get proper info on those, since the issue there is related to what is coming off the store pages, not anything related to user data. Same basis for why there doesn't seem to be a way to fix [Daedelic/etc] point/contribution value inflations during sales [as that data actually screws up on Steam's end, as can be noticed via the same incorrect values being given through steam store searches during the sales].

4 months ago*
Permalink

Comment has been collapsed.

Thank you. I appreciate the response, your time and effort

4 months ago
Permalink

Comment has been collapsed.

Although SteamGifts could technically access that information just by making a client-side window.fetch request with credentials: 'include' to https://store.steampowered.com/dynamicstore/userdata/, which would make a request using your current cookies and, therefore, retrieve the list if you're logged in, this isn't possible because of CORS. Any requests made from SteamGifts to Steam would be blocked because they are not the same domain. ESGST is able to bypass this restriction because extensions don't belong to any domain (and same goes for userscripts on Tampermonkey, etc.).

4 months ago
Permalink

Comment has been collapsed.

Thank you. I appreciate the response, your time and effort

4 months ago
Permalink

Comment has been collapsed.

Despite everything said above, there is absolutely no reason for SG to avoid optional userdata upload, similar to barter.vg sync. While API sync should remain primary and mandatory (because nobody can tamper with data), userdata sync should be optional, allowing the user to correctly mark remaining packages as owned, therefore hiding them from results and making all of our lifes much easier. Writing userscript and backend for that is a few hours tops.

Problem is, since this data comes from the user, you can no longer trust it, therefore it has to be optional by definition.

4 months ago
Permalink

Comment has been collapsed.

Thank you. I appreciate the response, your time and effort

4 months ago
Permalink

Comment has been collapsed.

There really can't be any harm in users marking all the games as owned here preventing themselves from entering any giveaways for them can there? As long as you only take the additional information provided and don't allow users to unmark games the API already said they own.

4 months ago
Permalink

Comment has been collapsed.

Which is why I put emhasis on optional. Yes, at worst user can just limit himself further from joining giveaways, and I see absolutely no harm here. The key thing to understand here is that API way should not change in any way to prevent abuse. Userdata upload would be optional feature for users that want to make use of it, in order to forbid themselves from entering DLCs/learning/packages they already own.

4 months ago
Permalink

Comment has been collapsed.

It is not like we don't do that already with the filter list* so all that would do it is make it easier to add all the ones you own but don't show up saving a lot of effort.

*I have over five thousand on it myself.

4 months ago
Permalink

Comment has been collapsed.

Well, we kinda have this option already. One can make a userscript that will fetch user data and add all owned games to blacklist on sg. It's only partial solution, because SG does not indicate the game is in blacklist if you enter the GA by link, for example, if the GA is private. And that should be fixed.

4 months ago
Permalink

Comment has been collapsed.

They are two very different things. The API endpoint SG (and many other websites) use is a public, documented, and monitored (by the way of API Keys used to authenticate and authorize requests to it) API. That API is provided for integration with other platforms.

The way ESGST and other scripts pull data is by using a private, undocumented, subject to change at any time and without warning, API endpoint. That endpoint is used inside the Steam store website. As such, it's not public nor documented by Valve. You must dig into the code to find it. It also has different restrictions. One being you must be signed in with an account in Steam, so you are given the proper cookies to be able to make that request. Without those cookies, Steam wouldn't know which user you are, and therefore would return nothing.

Either way, SG wouldn't be able to make that request from the client-side like scripts and extensions do. Scripts and extensions can bypass something called CORS, Cross-Origin Resource Sharing. CORS is important, and is enabled by default (and can't be disabled in many) browsers. It prevents websites from making requests to other websites. This is done to prevent some malicious code injected in say X website, that otherwise would be secure, to send all your cookies and login details and such to any other website Y.

A client-side request, like scripts and extensions do, would keep the cookies needed for the authentication in with the request, so from a script or extension you don't need to know the login details (email and password) of a user. But as I pointed out already, it's not possible for SG to make a client-side request since CORS. And you might thing: "What about a request from the server side"? From the server side, the server would have no idea of what your cookies for authorization are, and no way of getting them. That is, unless you provided your email and password to the website, and the website on the server-side used those to login, and then got the cookies and made the request to the private endpoint that has the DLC info. This is a bad idea for many reasons. But basically, would you give your email username and password to any website that requested it? If you answered yes, I don't even know what to tell you.

4 months ago
Permalink

Comment has been collapsed.

Update. There are credible suggestions that this is possible and this does appear to have community support. I hope that the site does eventually consider possibilities suggested here. Until then, requests for deletions and rerolls, in my humble opinion continue to become slower. I have one deletion request that is now a few months old. I have been told that it requires a 'super mod' and have been assured that it will one day be addressed. I continue to believe that there is a better way than this.

4 months ago
Permalink

Comment has been collapsed.

The site's SuperMods are dedicatedly hard-working, professional, and pleasant. However, they also seem to have been inactive for some time now. There's a good candidate for becoming a new addition to that tier, but that's the kind of decision that doesn't come quickly, even to someone who doesn't have the kind of reputation for delay that cg does.

As far as there being "a better way".. Mandating community login is far, far, far more trouble than it's worth. For example, it's not uncommon for me to get an instance where Community'll decide to log me out every couple of minutes, repeated ad infinitum (a major factor behind the statement I made in my earlier comment in this thread, about my not ever being logged in to community while logged into SG). As such, it's rather unlikely that there'll ever be a true "fix" for the matter.

Of course, assuming there are no other barriers in play, that doesn't mean that cg can't implement community login elements as something which isn't mandatory, instead implementing it to only only function when the user is logged on. After all, it'd not only be a convenient feature for site users, but it's always a good thing when we can lower the demands on the site's volunteer staff.

Unfortunately, cg went quiet after May of last year, so there hasn't been a lot of hope for community feedback being given response, much less development effort. That said, he did pop back up just a couple of weeks ago, so at least we know he's alive. Despite the comment below to the contrary, keeping the matter visible is probably the only way you can really have a chance of perhaps getting a question or request to go anywhere.

4 months ago*
Permalink

Comment has been collapsed.

Thanks for the explanation. Appreciate it.

4 months ago
Permalink

Comment has been collapsed.

There are credible suggestions that this is possible and this does appear to have community support.

How did you get to this conclusion? Multiple people above explained why this is impossible. Only web-extension or manual data input will work, and it's not reliable and could only be optional (so if someone just don't care - they will still be able to enter and win giveaways for games they already own).

4 months ago
Permalink

Comment has been collapsed.

I assume he is implying that there seem to be some indications in this thread that some would like this as an optional feature to avoid having to manually hide already owned games missed by the "normal" api

4 months ago
Permalink

Comment has been collapsed.

The problem is, as soon as it becomes an optional feature, cg is just going to go "Optional shit is for scripts, don't bother me."
Seeing as multiple scripts already integrate ownership checking, it'd be a bit hard to push the point.

However, what SG COULD implement, that'd be a bit different than scripts, is that it could add in a multi-point reference of a user's library, through their community login access. By comparing multiple records over time, SG could reliably determine which games are legitimately owned [versus quirked during a glitch] and thus allow retention of ownership flagging even while not logged into community. (It'd be easy to tie this to the current library syncing process, so presumably there shouldn't be too much extra load on the site, either.)

Likewise, as it's simply a flag, not a lockout, even if there does end up being a glitch, it doesn't become a meaningful one.
So yeah, there's definite benefit to it, if cg is willing to put in the time.

4 months ago*
Permalink

Comment has been collapsed.

I assume he is implying that there seem to be some indications in this thread that some would like this as an optional feature to avoid having to manually hide already owned games missed by the "normal" api

^ this, and then read further. A number of people have now posted that it is not possible, and then add unless you do this or that.

4 months ago*
Permalink

Comment has been collapsed.

A number of people have now posted that it is not possible, and then add unless you do this or that. You listed 2 yourself.

4 months ago
Permalink

Comment has been collapsed.

It's not possible, period. In no way.
There is some possibilities that are somehow similar, but not reliable. And, guess what - those possibilities are already implemented - it's called ESGST. Nothing BETTER can't be done.

4 months ago
Permalink

Comment has been collapsed.

those possibilities are already implemented - it's called ESGST

Sure, but can you get it to work on my Android mobile?

3 months ago
Permalink

Comment has been collapsed.

It's easy, it works for me. Just use a decent browser.
Also, do you understand that official solution would need extension too, and will cause same problem for you?

3 months ago
Permalink

Comment has been collapsed.

the need of a Super Mod happens when you make a multiple copies/keys giveaway:

you've created a 10 copies giveaway of Bad Rats, and you have 10 winners.

if one of those 10 winners has a problem (say, asks for a re-roll) your ticket will be handled by a Super Mod (a "normal" Mod doesn't have that "power").

so, is always better creating different giveaways, one copy per GA. even more when it comes to Profile Features Limited games ;-)

(for fairness: we also had rerolls in 2 seconds, tho)

4 months ago
Permalink

Comment has been collapsed.

Supermods probably have limited database access, and the issue is likely one of poor configuration on cg's end [where multi-copy giveaways are implemented as a single giveaway within the database, and no special access has yet been coded to modify the state of a single giveaway to that level of nuance]. In other words, another possible fix (of sorts) for the OP's concerns is for cg to simply improve the site's moderation functions (as there shouldn't be any reason such access can't be coded to be accessible through a standard moderation interface).

4 months ago
Permalink

Comment has been collapsed.

There is a reason there haven't been many replies to this thread. Give it a break.

4 months ago
Permalink

Comment has been collapsed.

I never understood members who make posts complaining about too many posts. Doesn't seem particularly helpful or intelligent to me. To clarify, I'm going to make posts as I see fit and within the rules of the respective site. You have no influence to prevent it. Maybe someday you will be accepted as a site moderator, or a spokesperson chosen by other members Good luck. Respectfully, until then you don't have much of a say in the matter.

4 months ago*
Permalink

Comment has been collapsed.

I clearly do have some influence, because you bothered to reply to me :)

I appreciate it.

4 months ago
Permalink

Comment has been collapsed.

That would make sense if your point was for me to post more, but it wasn't. So maybe there was no point of it.

4 months ago
Permalink

Comment has been collapsed.

Every time I reply, I don't know why.

You can't make sense of anything if you keep replying to me :)

4 months ago
Permalink

Comment has been collapsed.

This is the Steamgifts formatting tool for direct quotes, but some people think it should be used to display their whimsical random thoughts

You made a fake quote and then followed with another nonsensical answer. I might be dealing with a minor. So let's try this.... nananbooboo.... can't hear you.... can't hear you.

Bye. You'll have to amuse yourself. :)

4 months ago*
Permalink

Comment has been collapsed.

Sounds like you need to go back to school to understand the English language.
I guess you ended up devolving it into a show of denial instead.

4 months ago
Permalink

Comment has been collapsed.

I think by now others made clear why it wouldn't work without an extension.. Removed games and DLC's are sadly simply not available to see for other users. Either SteamGifts could offer an extension/user script for it, or an input field for a user to copy-paste the https://store.steampowered.com/dynamicstore/userdata/ themselves. This both in addition to the available API data, to prevent users providing inaccurate data.

There are ways to detect the "Steam is learning about this" or "Profile features limited" games though, options are:


1) By using the Big Picture API
Tell Steam you are using the big picture mode when accessing a users games tab. Technically this is done by adding the header X-ValveUserAgent: panorama to the request (e.g. in cURL). Steam will then return a page made for Big Picture instead of the regular website. This page contains a script object holding the variable g_rgGameData with a JSON. I'm not sure how "easily" Steam may decide to change this, but given it should remain compatible with the Big Picture mode, it should remain more or less the same.

Example:
Install a tool that can add a header to a request (e.g. ModHeader for Chrome) and set the header. Then just go to https://steamcommunity.com/profiles/76561198005585830/games/ and you will find the data.

Bonus:
The request will also return the users wishlist (g_rgWishlistData JSON) and the users followed games (g_rgFollowedData JSON).


2) By using the XML API
Open a users game tab and add the GET variable XML with a value 1 behind it (e.g. ?xml=1). Officially the best supported way, but it is very slow and tends to break for (very) big libraries. It also has been deprecated for a long time now.

Example:
It's a simple as going to https://steamcommunity.com/profiles/76561198005585830/games/?xml=1 and the XML with the games list will be shown.


3) By scraping the games page
Grab the source code of the games page of a user. Inside you'll find a javascript with a variable rgGames, containing a JSON with the games. Steam may decide to change things on the page at any time though, by something as simple as changing the spelling or how they load/show it to visitors.

Example:
View the source code of view-source:https://steamcommunity.com/profiles/76561198005585830/games/?tab=all (Chrome link). In the source code look for var rgGames. This contains a JSON with the games.


For all requests to the Steam community goes that they are rate limited. Steam throws you an 429 - Too Many Requests when you go to fast. Rule of the thumb is 10 requests per 10 seconds, but I never tested the precise limit and can't find any official documentation about it. Perhaps there are more ways to grab the game list of users, but these are the alternatives I know about (next to the official Steam API).

Bottom line: it depends on how much SteamGifts/CG finds it necessary to accurately sync owned games and how much time they want to invest into making it work one way or another.

4 months ago*
Permalink

Comment has been collapsed.

i'm still at number one but, man... the kisses, oh the kisses

<3

4 months ago
Permalink

Comment has been collapsed.

Who knows some might find it useful for their own applications. ^^

4 months ago
Permalink

Comment has been collapsed.

my first and only "app" has been a clickable cat. i've also installed it on my phone: touch the cat to get a "meoow!" (it was the old Hello World app for Android).
times have changed, tho. now i have to click buttons to get, maybe, a spacecat. more the fun, if you ask me :P

it's Profile Features Limited, +Ref any way

4 months ago
Permalink

Comment has been collapsed.

Noice :D what features? xD

View attached image.
4 months ago
Permalink

Comment has been collapsed.

here --> https://www.steamgifts.com/giveaway/xn2pH/

lil' "gift" just made for you.

you've said it, Ref.

good luck!

4 months ago
Permalink

Comment has been collapsed.

Really, thank you for sharing this! 👀
I never knew about that Big Picture API, and I'm going to try using it in my own application thing (not public yet?) :D

4 months ago
Permalink

Comment has been collapsed.

yet?

is there an answer? :D

4 months ago
Permalink

Comment has been collapsed.

We'll see :p
I really need much time... But eventually I'll do it on Github

4 months ago
Permalink

Comment has been collapsed.

And thank you too, I'm very happy the information was useful. :)

4 months ago
Permalink

Comment has been collapsed.

or an input field for a user to copy-paste the https://store.steampowered.com/dynamicstore/userdata/ themselves

I mean, in regards to adding our ignored games through that method so we can update our hidden list on SG, we've been asking for that functionality since at least as long as I've been on this site. Given how that's a more useful consideration, and has been ignored despite heavy community support, it'd be a bit bizarre to see cg take that route with ownership information (at least, were he to do so preceeding responding to the other request).

4 months ago
Permalink

Comment has been collapsed.

Looks helpful. Thanks.

4 months ago
Permalink

Comment has been collapsed.

Sign in through Steam to add a comment.