Jump to content
McKay Development

What Comes Around

Member
  • Content Count

    34
  • Joined

  • Last visited

Reputation Activity

  1. Like
    What Comes Around reacted to Dr. McKay in Identifying Steam Items   
    Sometimes it can be a little confusing to identify a specific item in the Steam economy. There are several different types of IDs present in one particular item, and a lot of vague terminology. This guide aims to clear all that up for you.

    For starters, the "official" term for a Steam item is an asset. When I say a "Steam item", I mean a particular copy of an item. I'm not referring to the item's definition, name, image, or anything. I'm referring to a specific, unique copy of the item.

    In a general sense, every item on Steam must be owned by an app. An "app" is a game, software, or whatever on Steam. Every app has its own unique AppID. You can find a particular game's AppID by going to its store page or community hub and looking at the URL. For example, TF2's AppID is 440 so TF2's store page can be found at http://store.steampowered.com/app/440. CS:GO's is 730, Dota 2's is 570, and so on. Note that Steam Community items, Steam gifts, and other "Steam" items are owned by the "Steam" app, which has AppID 753. To identify an item, you'll need the AppID of the game which owns it.

    Of course, the AppID alone isn't enough. You also need two other IDs. Have you ever noticed how some games have multiple inventories, which appear in a drop-down list? An example is the Steam inventory, which has sub-inventories for "Community", "Gifts", "Coupons", etc. These "sub-inventories" are called contexts, and each context has its own context ID. If a game doesn't have a drop-down menu to select a context, that doesn't mean that it's without contexts. That only means that it has one single visible context. That single context still has an ID. For all current Valve games, the context ID for the publicly-visible context is 2.

    Context IDs can be a bit tricky. It's entirely up to the game's developer to determine how they work. For example, Valve games take the "single shared inventory" model in which there's one context ID which is shared by everyone. Under this model, an item belongs to one particular context and never leaves that context. Consequently, the item's context ID never changes. It is, however, possible for game developers to create contexts in any way they choose. For example, Spiral Knights uses the "per-character inventory" model in which everyone who plays the game has their own context IDs for their characters. Creating a new character creates a new context ID. This means that when an item is traded between users, its context ID will change as it moved out of a particular character's inventory.

    Those are the two different types of "containers" in the Steam economy. Apps own contexts, and contexts own assets. Every asset on Steam has, in addition to its AppID and context ID, an asset ID which is guaranteed to be unique inside of a given AppID+ContextID combination. Notice that this means that asset IDs are not unique across all of Steam. They aren't even unique across a particular app. They are only unique inside of a given context. For example, there could be two items with asset ID 1 in the same game, as long as they have different context IDs. An item's asset ID may be referred to as "assetid" or just plain "id".

    Context IDs and asset IDs are assigned by the game developer and can follow any pattern. They can change when traded or not. They may both be up to 64 bits in size. Consequently, Steam returns them (like all other 64-bit values) in JSON as strings.

    Still following? All of what we've learned so far leads us to this conclusion: in order to uniquely identify an item, you need its AppID, its context ID, and its asset ID. Once you have these three things, only then can you uniquely identify it. In fact, this is how you link to a particular item in a user's inventory: steamcommunity.com/profiles/steamid/inventory#appid_contextid_assetid. Here's an example: https://steamcommunity.com/id/DoctorMcKay/inventory#440_2_134161610

    What are these "classid" and "instanceid" values though?
    The observant reader may have noticed that there are two more IDs attached to a particular item which I haven't mentioned. These are the "classid" and "instanceid". These IDs are used to map an asset to its description.

    What's a description? A description is what you need in order to actually display an item. An item's description contains its name, image, color, market_name, whether it's tradable or not, whether it's marketable or not, and more. There are many endpoints on Steam which return JSON objects representing assets that only contain the asset's AppID, context ID, asset ID, classid, instanceid, and amount. An item's amount is how big of a stack it is. Unstackable items always have an amount of 1. Stackable items (such as Steam gems) may have a larger amount. Stacked items always have the same asset ID.

    What's the difference between a classid and an instanceid? In a nutshell, a classid "owns" an instanceid. The classid is all you need to get a general overview of an item. For example, items with the same classid will pretty much always have the same name and image. The instanceid allows you to get finer details such as how many kills are on a strange/StatTrak weapon, or custom names/descriptions.

    You can turn a classid/instanceid pair into a description using the GetAssetClassInfo WebAPI method. Notice that the instanceid is actually optional: if you only have a classid that's fine, you just won't get finer details for the item.

    Name? Market Name? Market Hash Name?
    Every asset on Steam has a name. Without a name, there's nothing to show in your inventory. The item's name is the name property of its description. The item's name may be localized if the game's developer has set it up to be.

    Every marketable item also has a "market name". This name may be the same as—or different from—the item's regular name. The item's market name is the market_name property of its description. This is the name that's displayed in the Steam Community Market when the item is up for sale. Why the distinction? There are some items which have value-affecting data that isn't in their name; for example, CS:GO skins have 5 different tiers of "wear", which isn't in their names. The wear tier is appended to each skin's market name however, so that the different tiers of wear are separated in the market. The market name may be localized or not, and may not exist at all if the item isn't marketable. It's up to the game's developer.

    Finally, every marketable item also has a "market hash name", available under the market_hash_name property. This name is supposed to be the English version of the item's market name, but in practice it may vary. For example, Steam Community items prepend the AppID of the originating app to each item's market hash name, but not to the market name. The market hash name is never localized, and may not exist if the item isn't marketable. Again, it's up to the game's developer. You can view the Community Market listings for any marketable item using this URL formula: steamcommunity.com/market/listings/appid/market_hash_name. Here's an example: https://steamcommunity.com/market/listings/440/Mann%20Co.%20Supply%20Crate%20Key

    Note that the Community Market has no concept of contexts. Consequently, market [hash] names are unique for a particular "class" of items per-app (and by extension per-context). This means that for marketable items, two items with identical market hash names will be worth roughly the same (with some exceptions, like unusual TF2 items).

    Questions?
    Ask below. I'm happy to help!
  2. Thanks
    What Comes Around reacted to Dr. McKay in How do I sellitem via httpRequestPost?   
    Unless you're doing something shady, I wouldn't expect Valve to pay any mind to you.
  3. Like
    What Comes Around reacted to Dr. McKay in How do I sellitem via httpRequestPost?   
    Only set Origin and Referer. Do not set Host or Cookie.
  4. Like
    What Comes Around reacted to Dr. McKay in How do I sellitem via httpRequestPost?   
    Get rid of the curly braces around requestoptions. And also quit using the confirmation checker as it's been deprecated for years.
  5. Like
    What Comes Around reacted to Dr. McKay in How do I sellitem via httpRequestPost?   
    You need to specify Origin and Referer manually, but all the other headers you're specifying should be left out as they're HTTP protocol-level headers that request will set on its own.
  6. Thanks
    What Comes Around reacted to Dr. McKay in Set account phone number?   
    I'm pretty sure that means that you need to verify your email before continuing. You can request a verification email with steam-user.
  7. Like
    What Comes Around reacted to Dr. McKay in Set account phone number?   
    The brackets just mean that it's an optional argument. store.addPhoneNumber('+310***', (err) => {}) is the same as store.addPhoneNumber('+310***', false, (err) => {}).
    If you want to bypass a confirmation, you'd do store.addPhoneNumber('+310***', true, (err) => {})
    The callback doesn't have any other arguments besides err.
  8. Like
    What Comes Around reacted to Dr. McKay in Set account phone number?   
    You can use steamstore to add phone numbers.
  9. Like
    What Comes Around got a reaction from null in Set account phone number?   
    So I am currently setting up bots with 2FA manually using steam desktop authentication, but I think it's time, it's time to use my brain again. So I have been looking through the steam community npm docs and I found 2FA methods but no add phone methods. I'd like to be able to take accounts with no steam guard, add a phone number, and then turn on 2FA, and finally console log all the information about the account, all the secrets and everything. Would this be possible? (mainly the phone part) Otherwise I'll have to use puppeteer but that's sorta resource heavy and not ideal (also I don't know cheerio).
    Any advice would be appreciated!
  10. Like
    What Comes Around reacted to Dr. McKay in Check if user accepted trade?   
    createOffer doesn't actually do anything on the network, so calling createOffer will never fail. You can check if the user's trade token is valid either by creating an offer and then calling getUserDetails, which will fail if the trade token is invalid (or the user cannot trade). You can also use GetTradeHoldDurations to check if a trade token is valid.
  11. Like
    What Comes Around reacted to Dr. McKay in Function doesn't return inventory   
    Thanks so much for the help @vrtgn.
    It may be worth noting that if you're using async, you don't need to use .catch((err) => . . .). You can use try/catch:
    try { const inventory = await getInventory(); // do whatever } catch (err) { console.error(err); }  
  12. Thanks
    What Comes Around got a reaction from vrtgn in Function doesn't return inventory   
    Yes I was mistaken, my bad. Thanks again! Your code is very clean, would have taken me a while to get all the mess I had perfected.
  13. Like
    What Comes Around got a reaction from vrtgn in Function doesn't return inventory   
    This makes perfect sense! I tried using a callback and it worked, but I didn't like the mess I created so I made the code in my original question. Your solution is clean and makes sense. Also I will use getInventoryContents. Thanks a bunch!
    Oh but one question. getInventoryContents has a steamid param, so I'd assume you can fetch other users inventories, but there is a getUserInventoryContents function for that. What's the difference?
  14. Thanks
    What Comes Around reacted to vrtgn in Function doesn't return inventory   
    I also made this mistake as a beginner. 
    You have a misunderstanding of asynchronous code in javascript. Fetching the inventory takes some time, and so by returning inventory, the variable is being returned before the program can even fetch your inventory.
    You will have to create your own callback and that works by taking in a function as a callback parameter, and then executing that function once the inventory has been fetched.
    const getInventory = (callback) => { manager.loadInventory(730, 2, true, (err, inventory) => { if (err) { callback(err); } else { callback(null, inventory); } }) } I personally prefer to check for errors first, but whatever you prefer you can change it to. 
    When we want to fetch the inventory we use it like so:
    getInventory((err, inventory) => { if (err) { console.log('error getting the inventory :('); } else { // code to do whatever you want with inventory here } })  
    I also saw that you are using the loadInventory method, it would be much better if you used the getInventoryContents method as it says this in the docs:
     
    EDIT: Callbacks are getting ugly nowadays imo so you can also use a promise if you prefer:
    const getInventory = () => { return new Promise((resolve, reject) => { manager.loadInventory(730, 2, true, (err, inventory) => { if (err) { reject(err); } else { resolve(inventory); } }); }); } getInventory() .then(inventory => { // do whatever here }) .catch(err => console.log('oops')); // OR // this must be inside a async function try { const inventory = await getInventory(); // do whatever here } catch (err) { console.error(err) }  
  15. Like
    What Comes Around reacted to Dr. McKay in Get steamid from partnerid in tradeofferurl   
    https://www.npmjs.com/package/steamid
  16. Like
    What Comes Around reacted to Dr. McKay in Get steamid from partnerid in tradeofferurl   
    const SteamID = require('steamid'); const URL = require('url'); let link = 'https://steamcommunity.com/tradeoffer/new/?partner=46143802&token=aaaaaaaa'; let steamid = SteamID.fromIndividualAccountID(URL.parse(link, true).query.partner);  
×
×
  • Create New...