What is your preferred solution to the SG bug that does not correctly identify owned games?
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.
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.
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.
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.
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].
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.).
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.
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.
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.
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.
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.
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.
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).
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
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.
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.
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?
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)
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).
Comment has been collapsed.
There is a reason there haven't been many replies to this thread. Give it a break.
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.
Comment has been collapsed.
i'm still at number one but, man... the kisses, oh the kisses
<3
Comment has been collapsed.
Who knows some might find it useful for their own applications. ^^
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
Comment has been collapsed.
here --> https://www.steamgifts.com/giveaway/xn2pH/
lil' "gift" just made for you.
you've said it, Ref.
good luck!
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
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).
Comment has been collapsed.
Comment has been collapsed.