Dr. McKay

Okay, the timeframe was a bit sooner than expected. You can now change account email (which trade bans you for 5 days) and password (no trade ban) in v3.13.0.

No, that's the actual solution. Errors are a fact of life (especially when you're working with Steam). You need to handle them, or else you'll crash.

You aren't checking the error. In every callback, if err is truthy, then there was an error and all other arguments are undefined.

Correct. steam-tradeoffer-manager will handle all that polling for you.

1) I'd keep your login checker code in there. The manager will only notice that your session is gone when you try to send/accept an offer. Normal polling and canceling offers uses the WebAPI and your API key, so the session isn't actually used there.
2) That's more than fine. 5 requests per minute is super low.
3) You're correct, your first snippet generated the code once on boot. It ceased to be valid once you used it.

That all looks fine to me. sessionExpired is only emitted when a request you make fails because you aren't logged in. It doesn't check automatically, it only checks whenever the library makes a request somewhere.
 
Starting a new confirmation checker without stopping the old one is just fine. It'll stop an old one if you call it while one is running.
 
I recommend updating to v3.23.1 if you're going to use webchat.

Please read the documentation. You need to call setCookies and wait for the callback before you try to do anything else, and that is invalid input for getOffer.

https://github.com/DoctorMcKay/node-steamcommunity/wiki/SteamCommunity#uploadavatarimage-format-callback

The steamID property will be null if you aren't connected. It'll be a SteamID object if you are.

1. If you want to get all active offers and that's it, you'd use this:
{ "get_sent_offers": 1, "active_only": 1, "time_historical_cutoff": 2147483647 } 2. You'd check the trade_offer_state. If they accepted it then they received the item you sent them.
3. If you want all offers from a time period you'll need to just leave out both active_only and historical_only and filter the result.

There might be some confusion here. The expires property is Steam's expiration date, which is always 14 days from creation time and can't be changed. cancelTime works independently of it.

I want to know what you're using node-csgo for.

You need to do it yourself.

That looks fine to me.

Because you're adding a new listener every single time you request item info.
 
Just use the callback and you won't need to worry about it.

node-globaloffensive is using an option where instead of underscores, you should provide protobuf fields in camelCase. Basically, just remove the underscores and capitalize the next letter.
 
However, I've added that functionality in v1.1.0.

WebStorm is giving you an error because csgo doesn't exist when you're trying to listen for an event on it. Create your GlobalOffensive object at the same time as when you create your SteamUser object.

WebStorm sometimes has trouble resolving Node dependencies.
 
Do you have the Node.js plugin installed in WebStorm?

Your crash log gist 404s.

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!

Ever wondered what's behind that big long number that we call a "SteamID"? It isn't just random; there are actually four numbers packed into it.
 
A SteamID has four parts:
Universe - The "instance of Steam" in which this ID is used. There is only one public Steam instance. Its name is "public", and its number is 1. The other universes are used internally at Valve for testing. Type - A SteamID can actually stand for several different types of accounts. The most common is individual, which is an individual user account. There are also types for clans (Steam groups), gameservers, anonymous gameservers, anonymous users, and more. Instance - This number is a bit finnicky. For the most part it's just a static number. For example, for individual SteamIDs the instance is pretty much always 1 (for desktop). Account ID - This is the actual ID of the account. Account IDs increment over time. If you know what universe, type, and instance an ID is for, then this is all you need to uniquely identify the account. As I mentioned previously, a 64-bit SteamID is actually broken down into four parts:
8 bits for the universe 4 bits for the type 20 bits for the instance 32 bits for the account ID This means that in order to get an account ID out of a 64-bit SteamID, all you need to do is steamID & 0xFFFFFFFF.
 
Warning: The Steam WebAPI and Steam Community website actually don't care about the instance as long as you've set the type and universe correctly. This means that if you're taking user input for SteamIDs, you could end up with duplicate accounts. For example, the SteamIDs 76561198006409530 and 76561202301376826 are considered identical because the universe, type, and accountids are the same. Try it for yourself: https://steamcommunity.com/profiles/76561198006409530 https://steamcommunity.com/profiles/76561202301376826
 
Failure to take this into account can result in such exploits as this:
 

 
(Yes, those are actually the same Steam account)
 
Common SteamID Confusion
SteamID aspects are a common source of confusion. For starters, what do you call various SteamID formats?
This is the 64-bit SteamID (or just SteamID) format: 76561198006409530 This is the Steam3 format: [U:1:46143802] This is the Steam2 format: STEAM_0:0:23071901 (or the newer Steam2 format: STEAM_1:0:23071901) The "partner ID" in trade offer URLs is actually the account's account ID.
 
Reading Rendered IDs
Here's how to interpret the rendered ID formats.
Steam3 Format
[T:U:A] or [T:U:A:I]
T - This is a single letter (case-sensitive) which tells you what type of account this is. The characters are documented on the Valve developer wiki. U - This is the universe to which this SteamID belongs. Unless you work for Valve, this will always be 1. A - This is the account ID for this SteamID. I - This is the SteamID's instance number. May be omitted if the instance is the default for that ID type or can be determined in other ways. Steam2 Format
The Steam2 rendered format can only be used for individual SteamIDs.
STEAM_X:Y:Z
X - This is the universe to which this SteamID belongs. Older games use 0 to stand for public, newer ones use 1. Y - This is the SteamID's accountid modulo 2. Z - This is the SteamID's accountid halved and rounded down. Working with SteamIDs in code
If you're using Node.js, you can use node-steamid to parse, create, and deal with SteamIDs.
If you're using PHP, you can use php-steamid.
If you're using C#, SteamKit has a SteamID class.

Just my own experience. I've updated the readme to reflect this fact.

Are you going online on chat properly with client.setPersona?

The tag for accepting needs to be allow, not accept.

You really aren't meant to do it that way.
 
That said, this is really, really bad and really, really horrible, but will work:
 
 
var offer = manager.createOffer("[U:1:1]"); offer.id = 1; offer.state = 3; offer.tradeID = your_trade_id; offer.getReceivedItems((err, items) => {     // as I said, horrible. });