Dr. McKay

Yeah, class-values are a complete black box to Steam.

The first parameter to kickGroupMember needs to be a SteamID object.

I suppose you could say that. GetAssetClassInfo takes as input a list of classes and responds as output with a single description. That description corresponds to the entire list of input classes. So the response should correspond to all classes. Which means that I think you understand it correctly, Steam does cache the complete signature of classes.

Assuming you're talking about what the Steamworks documentation refers to as an "asset class" and that by "inventory provider" you mean an item server backend, which is kind of outside the scope of this thread but I'll answer anyway. Asset classes basically describe the "nature" of an item, and you define them yourself. For example, in Valve games each item has a definition index (defindex), which is a class. def_index: 1234 But each item can also have special attributes, for example a StatTrak CS:GO item. So you might have stattrak: true This means that each item/asset has multiple asset classes. You expose a class to Steam for every kind of attribute that changes how the item is rendered, so you end up with basically a list of display-affecting attributes. You could read the above as "this item has def_index 1234 and it is a stattrak item". Then Steam calls GetAssetClassInfo with that listing of classes and expects you to return a proper description, which gets cached indefinitely for that set of classes. So that means that your set of classes for a specific item needs to include all the data necessary to build a comprehensive description. The purpose of asset classes and descriptions is to decouple the display information from the actual asset. For example, every CS:GO Case Key is completely identical so there's no reason to store all the display information with each individual item. So instead the economy server requests the list of classes for the assetid from the item server, which replies with a list of classes that the economy server has already seen. Thus the econ server knows that it's seen this kind of item before and doesn't need to request display information.

You pretty much should use getExchangeDetails instead of getReceivedItems. getReceivedItems isn't useful for the vast majority of people anymore outside of a select few cases.

You should really just use the WebAPI instead.

offers.offer isn't valid. You need to use offers.createOffer which returns an offer object.

It totally works. Just tested it myself. You're doing something else wrong. Maybe you're running two instances of the bot?

Yes, call offer.getExchangeDetails and if the trade was rolled back (the likely scenario in this case) you'll have the post-rollback IDs there.

Not 'ActiveOnly', TradeOfferManager.EOfferFilter.ActiveOnly And also per the docs, just omit the time value if you only want stuff that's active.

Nope, you pretty much just have to check the name for "Case Key".

What you have there will work provided the user does have 350 gems in their first gem stack. It's possible to have multiple gem stacks, so you'd need to iterate the gems array and total up all the amounts to see how much the user has, then add the appropriate amount from each stack if they do.

Yup.

Is everything up to date? What's your poll interval?

Move your client, community, manager, logOnOptions declarations inside of the Bot function.

Yes, you do need to login once.

No, you need to not call webLogOn if you aren't connected.

Pulling one inventory every 2-3 minutes should be fine. A good poll interval for steam-tradeoffer-manager is 30 seconds (30000 ms).

GetFriendList gives you timestamps.

Correct. When you're using steam-user, your "login" is a connection to the CM. It's completely distinct from your web session. When your web session expires but you're still connected you don't need to reconnect. Just get a new web session which requests new cookies from the CM.

It doesn't retry, ever.

It's being called for a reason, and that reason is that your session expired. I assume that you're getting your session from node-steam-user, and you're calling logOn when it expires. That's wrong, you should call webLogOn.

Use both. If the callback returns success then send success immediately. If it returns error 16 (timeout) then wait for receivedOfferChanged.

let sold = JSON.parse(require('fs').readFileSync('TotalSold.json').toString('utf8')); sold.TotalItemsTraded.TotalKeys += something; require('fs').writeFileSync('TotalSold.json', JSON.stringify(sold, undefined, "\t"));

You can only cancel active offers (state 2). State 4 (Countered) means that the trade offer was countered. The offer that's in state 4 is no longer active, and a new trade offer with a new trade offer ID was sent to you with the counter offer.