Steam Api Getownedgames
Rosalie Checca
GetOwnedGames returns a list of games a player owns along with some playtime information, if the profile is publicly visible. Private, friends-only, and other privacy settings are not supported unless you are asking for your own personal details (ie the WebAPI key you are using is linked to the steamid you are requesting).
GetRecentlyPlayedGames returns a list of games a player has played in the last two weeks, if the profile is publicly visible. Private, friends-only, and other privacy settings are not supported unless you are asking for your own personal details (ie the WebAPI key you are using is linked to the steamid you are requesting).
There is a new style of WebAPI which we refer to as "Services". They function in many ways like the WebAPIs you are used to, the main difference being that all service APIs will accept their arguments as a single JSON blob in addition to taking them as GET or POST parameters. To pass in data as JSON, invoke the webapi with a parameter set like:
You can identify if a WebAPI is a "Service" by the name of the interface; if it ends in "Service" like "IPlayerService", then it supports this additional method of passing parameter data. Some Service methods have parameters that are more complex structures and require this different input format.
No, some of them are even wishlisted games. And it's pretty hard to determine if they are from Family Sharing myself. One of my sharers is not my friendlist, so I can't simply check for every game if one of my friends (sharers) owns them.
Okay, I did some tests and it appears that indeed family sharing was a factor here. If family sharing was enabled on the PC getOwnedApps returned around 14K appids, and if family sharing was disabled, it returned around 10K appids. This seems about right, since with no family sharing I have 5K games in my library and with family sharing, I have 7K.
But it appears getOwnedGames still returns some games I don't own, regardless if family sharing is enabled or not. These games include Train: Simulator, Call of Duty: Infinite Warfare, Shank 2, Mordheim: City of the Damned, etc... I can't exactly tell how many "faulty" appids were returned, since they include tools, dedicated servers, "steam for linux" and that kind of stuff, that the steam store's dynamic userdata don't include. But if I included those, there were around 26 of 2000 appids I checked faulty. My guess is that they are/were maybe part of free weekend packages and somehow still detected as owned. Or maybe those free-on-demand packages I am adding to my account are messing things up. For example, is detected as Free in SteamDB. Probably because of its free on demand package. However, in reality, you can't own it unless you paid for it.
I want to get back to Steam Family Sharing behavior. Let me explain how it works. Let there be a steam user, called the host, on a device (PC) with shared libraries, called the host device. As long as the host is logged in to that host device, Steam will make all the shared games available to any device on any network where the host is logged in. Don't ask me why Steam is doing this, but some speculate it has something to do with Steam streaming.
Anyway, this can cause GetOwnedApps to also include shared games. Now, I came up with a method that can exclude shared games. You could query store.steampowered.com/dynamicstore/userdata/?v=VERSION to get the owned games (and packages) that guaranteed aren't shared and use the 'v' parameter to get the most up-to-date list. However, this may belong more to node-steamcommunity, as it uses web API, but I leave that choice to you. If you decide to include into steam-user, you could add an options-object or a boolean for getOwnedGames, to exclude Family Shared Games, through this method.
node-steamstore has a method which retrieves that URL. But yes, please do open an issue on GitHub (linking to this thread) about this as there should be some level of support for distinguishing family-shared games.
For those of you not aware, I built and maintainsteamrecommender.com. I originally thought I hadthis brilliant idea because the recommendations within Steam were not thatgood and there were no other recommendation engines that were making use ofthe data that would come out of the Steam platform. So, I started working onan ingestion system that would crawl all of the Steam users (eventually).Valve conveniently developed a webapi that I couldmake up to 100,000 requests per day.
My first idea was to generate a seed set of Steam users (which primarilyconsisted of my friends) and then make the right API calls to get theirpublic details. In this case the public details consisted of all of thegames that they owned with the number of minutes they have spent playingeach and a list of all of their friends. The first call would be to get allof the games for a known Steam ID.
The friend graph within Steam consisted of far more isolated subgraphs thanI had expected when I first started looking for users. I had to quicklydevise new plans to find additional users so that I could continue growingthe number of players in my samples. I soon discovered the Steam communitieswhere people could express interest in certain games and become part oftheir groups. At the time you could visit a page that contained a listing ofevery member of a group, so I would generate a seed set of popular games andwrote some code to scrape the Steam ids from these pages. Even with theseadditions growth was still slow. Note: Valve has since removed thelisting of the groups.
Another reason that I faced slow growth in the acquisition of new Steam IDswas that I wanted to ensure that I was always working with fresh data.Things change over time, users acquire new friends and new games. Therefore,I needed to build in part of the system that would actually refresh a userevery so often in order to have the latest snapshot. With the 100,000requests per day limit some fraction of my requests were going to refreshingSteam IDs whose data needed refreshed and another fraction of these requestswent to the backlog for Steam IDs that had not been loaded yet. That leftvery few queries for gathering new Steam IDs through the friends API.
Despite these hurdles I was able to gather enough player information tobuild a item-item collaborative filter that generated reasonablerecommendations. This allowed me to launch the website and begin playingwith improving the recommendations.
note1:
i change discussion title maybe one day could be helpful for others people
i add useful comments\links to my first post , maybe people like me don't know things can reach info easy.
p.s. Thank you to all people reply me in this thread and help me much,very good replies here useful and positive\creative.
Note2:
My old message\request:
"there is any way to create a steam link\search for check if one user own only one game?
Because go to =all
and then write the game name not work for me because it's so much slow for me with profiles own 5k+ games
"
Data returned will be "game count" = 0 if target does not own it. Or 1 with more details if they do.
Its meant to be used in a script for returning results but you can use the URL directly and just look at the results.
i try this 2 for now:
and both very very fast thank you,very thank you to all people help me this very useful know,later days i will try apikey method too but for now this 2 already much better thank you very.
The problem with this is first of all that this information can be made public/non-public so we can't be sure to get the whole picture. Also this way of fetching data is flagged as deprecated by Steam.
The main downside is that dynamicstore data is not public, and can be accessed only by the person it belongs to (and clientside scripts of course). Which makes it not that easily accessible as Web API, but still useful in some cases (like with steamdb extension, where the DLCs info is really important).
We can do this is a couple different ways. The more statistical approach would be to simply measure what percentile of the distribution of gamers I fall in in terms of playtime. Calculating this is rather expensive, though, and while SteamSpy has that data on hand to some extent, mining it is pretty difficult, since we need the distribution of total playtime data for each game.
A far faster approach that we can apply to all games in our dataset is to just look at the difference in our playtime hours compared to the median. That will give us some number, but then we can use a sigmoid function to more or less normalize that across the different games.
So for Geometry Wars, we have a bunch of categories and numeric values tied to them. Action: 46, Arcade: 41, Twin Stick Shooter: 36, etc. This is great because we can use this as the basis for a profile.
The issue with this, as we shall see, is that each game only has about 10 tags to it (some fewer). There are something like 120ish or so unique tags on steam, so each row of data is going to have lots of zeroes in it. The solution here is to keep it simple and just use a dot product between a profile of preferences and the tag data we have.
Most of the code chunk above is just pre-allocating for building out our dataset. We're loading libraries, setting up functions for calculating some stuff later, loading in our steam user data from a JSON file, selecting some relevant info from that, then setting the stage for our table of SteamSpy data.
As you can probably tell from the comments, we first take the appid from our user play list, find the corresponding SteamSpy site, parse the HTML on the page to get the median play time and the tag data, then slap all that together and bind it to our pre-allocated data frame from before. We then repeat this over the entire list of game IDs that a user has played.
In this step, we're taking the tag data to be from long form and re-casting it to be in wide form. This pivot or cross-tabulation is a common data manipulation tactic in SQL or Excel, and it's just as easy in R. Sean Anderson has a great writeup on how it works in R if you want a more in-depth tutorial on that front.
64591212e2