Dr. McKay

Accepting a specific offer by ID without retrieving its data first isn't a supported use-case for TradeOfferManager, since it's designed to make the process as simple as possible and performs various checks and such. You'd need to either fetch the offer first using getOffer or manually craft the HTTP request that TradeOfferManager makes.

Added in 3.44.0.

let friendsList = [array of steamids]; let chunks = []; for (let i = 0; i < friendsList.length; i += 100) { chunks.push(friendsList.slice(i, i + 100)); } let chunkResults = await Promise.all(chunks.map(ck => new Promise((resolve, reject) => { try { let result = await axios.get(`https://api.steampowered.com/ISteamUser/GetPlayerBans/v1/?key=&steamids=${ck.join(',')}`); if (result && result.data && result.data.players) { return resolve(result.data.players); } reject(new Error('Malformed API response')); } catch (ex) { reject(ex); } }))); let vacFriends = []; chunkResults.forEach((chunkPlayers) => { chunkPlayers.filter(player => player.VACBanned).forEach((bannedPlayer) => { vacFriends.push(bannedPlayer); }); }); Untested and might have bugs

That seems fine.

I should mention, if you want to be absolutely sure that a trade completed (and hasn't been rolled back), you should take the tradeID property from the trade offer and plug it into GetTradeStatus. The values for the status property are documented here in ETradeStatus. Or just use getExchangeDetails.

This is not the best way to make sure you have the correct item IDs when crafting items. Just use node-tf2's backpack property, which contains an always-up-to-date copy of your backpack. To find metal, just check the defindexes. If memory serves, 5000 is scrap metal, 5001 is reclaimed, and 5002 is refined.

I've never seen a trade offer go from Accepted to some other state and actually mean that the trade didn't go through. Once it goes to Accepted you're pretty safe to say that it's completed. It used to be possible for trades to go to InvalidItems after Accepted, but the trade had still gone through. I don't think that's possible anymore though.

Steam is Steam and Steam sucks. It happens sometimes and you should probably either delay a little while before marking a trade as definitively closed, or otherwise allow for reopening trades in whatever system or database you're using if the offer should become Accepted.

Because you're mixing up async and sync. forEach returns before your requests complete. Also, rather than looping through the friend list, you should split it into chunks of 100 and make one request per chunk, to avoid getting rate limited by the API.

Sorry, I don't know. I wouldn't be surprised if Valve just hardcoded a list of items that can't be put into storage units in the game client.

That schema entry is pointing to a musickit_prefab prefab. Check the prefabs section for an item by that name, and use that as a base for the item's data. I don't plan to decode every individual attribute onto the item object since there are tons of them. If you need to check the value of an attribute that isn't already decoded, you'll just need to decode it yourself.

A little bit of both. Mostly I used Charles Proxy to snoop on the traffic, but these days that requires a rooted phone if you're using Android since apps won't trust user-installed root certificates by default.

Make multiple requests. steamcommunity.com has stricter limits.

It could be that you're running into rate limits. Checking multiple users for VAC bans is better done with the WebAPI.

Ah yeah, there is a problem, but your fix doesn't properly fix it. Here's the proper fix: client.on('friendsList', function() { let friends = Object.keys(client.myFriends).filter(steamId => client.myFriends[steamId] == SteamUser.EFriendRelationship.Friend)); console.log('All Friends: ' + friends.length); });

Sounds like you aren't providing valid SteamIDs.

steam-user is specifically intended to implement the Steam client protocol. Anything that must be done via web should go in node-steamcommunity.

Not at the moment.

What is the error you're getting?

If you're trying to get your own friends list and you're already using steam-user for other things, then you might as well just use steam-user for that. Although your code can be simplified to: client.on('friendsList', function() { let friends = Object.keys(client.myFriends.filter(relationship => SteamUser.EFriendRelationship.Friend)); console.log('All Friends: ' + friends.length); }); Your code as written will also include people who you've sent a friend request to, people who've sent a request to you, and blocked users as friends. If you're not already using some other feature in steam-user, then it'd be easier to just use the WebAPI. And if you're trying to get someone else's friends list, you'll have to use the WebAPI.

The events have the same name, yes.

There's a limit on logon attempts (failed or successful). I don't know exactly what the limit or cooldown is, but I think it's somewhere around 10 per hour.

Apptickets need to be validated by all servers, secure or not. I highly doubt that you'd be able to subscribe to an arbitrary user's inventory.

If you know the ID of the trade offer you're trying to map new item IDs for, this is actually really easy. GetTradeOffer includes the trade_id of the completed trade, and GetTradeStatus includes the mapping of old to new asset IDs for all items. It even has the new asset IDs in the original user's inventory if the trade was rolled back (due to an error in the middle of committing, or canceled escrow).

I've never actually first-hand tried to figure out how servers are notified of items being acquired by users. That plugin just hooks the message that the server sends to its clients (which is what triggers the native chat message), suppresses it, extracts the data from it, and sends its own messages. It's an event called item_found, and it's generated by the server in response to some notification that an item was found. The following is my best guess as to how it works: When a TF2 client joins a game server, the server authenticates their Steam app ticket. Once that's done, the GC sends the full contents of the player's inventory to the server, which keeps it in a memory cache. This is necessary so the server can make sure you actually own the weapons and cosmetics you're equipping. As long as the player is connected, the GC informs the game server in real time of updates to the player's inventory (in the same way that the GC informs the player's game client of updates to its own inventory). When a player connected to it receives a new item, a game server receives an "item created" message (SO_Create), and then the game server extracts the item's data (using the origin field to determine the acquisition method), and then broadcasts item_found to all its clients. The biggest problem I have with that explanation is that I don't think the origin field changes to "Traded" when an item is traded for, so how would a game server determine if an item was traded for? Maybe the origin field in the GC's item data changes to Traded but the origin field in the API doesn't or something.