Dr. McKay

You're not using a supported version of steam-user, so I can't help you.

I don't know why you'd only be getting that data. Here's the response I got to the same exact call: { chat_group_summary: { chat_rooms: [ [Object] ], top_members: [ [SteamID], [SteamID] ], role_ids: [], role_actions: [], party_beacons: [], chat_group_id: '22328242', chat_group_name: 'Price Bot', active_member_count: 2, active_voice_member_count: 0, default_chat_id: '78507305', clanid: SteamID { universe: 1, type: 7, instance: 0, accountid: 42048766 }, chat_group_tagline: '"IN DEVELOPMENT..."', chat_group_avatar_sha: null, rank: null, default_role_id: null, appid: null, watching_broadcast_channel_id: '0', active_minigame_id: null, avatar_ugc_url: null, disabled: null, steamid_owner: null, chat_group_avatar_url: null, watching_broadcast_steamid: null } } Maybe your account is limited and limited accounts don't have all the data returned to them? Maybe you need to update steam-user?

Show the full code.

That's the same error and console output that your first code should produce. Did you run the wrong file or not save it?

The error is AccessDenied. Sounds like you don't have access to that group chat. But also that looks like the output your first code should produce. Did you run the wrong file?

Yes, there's a method to kick someone from a chat room group.

Having a limited account shouldn't affect activity status or accepting friend requests.

Sure, although I'm not sure what circumstances prompt a notification.

https://github.com/DoctorMcKay/node-steam-user/wiki/SteamChatRoomClient#getclanchatgroupinfoclansteamid-callback

requestRichPresence is not the appropriate method to set your persona state to online. Use setPersona instead.

Yeah, that should work for you. If you're logging in with an account name and password to an account that has mobile 2FA enabled, you need to provide a code every time even if you pass the steamguard string.

Are you setting your bot's persona status to online?

Are you giving it a two factor code?

The arguments passed to the login callback are err, sessionID, cookies, steamguard, oAuthToken. You've left out the cookies argument, which is why you aren't getting the correct value in steamguard.

Watching a match involves connecting to GOTV likely using Steam's datagram relay. Honestly, that's a lot of complexity that's probably not really worth reverse-engineering. I've yet to look into retrieving demos of previous matches, which is likely much easier.

I don't see a problem with that change. https://github.com/DoctorMcKay/node-steam-user/releases/tag/v4.23.0

Do you own the app in question? accountName is not a valid property of SteamUser objects, so that should expectedly be undefined.

I forgot about updating docs for this; I'll get that updated today. The filter function is the same as Array.prototype.filter, with the object passed to each invocation being of this format.

You can get other users' friends list from the WebAPI: https://steamapi.xpaw.me/#ISteamUser/GetFriendList

That functionality was indeed not implemented. I've gone ahead and added it for you in v4.21.0. Multi-user ad-hoc group chats are just a special kind of chat room group that is unnamed.

#justvalvethings

Maybe items with craft_class "tool" are always craftable. I don't remember seeing any uncraftable name tags or decal tools, for example. Also, it's probably worth mentioning that I have a recollection of seeing the NotEcon flag on contracts. Contracts are sent to the game client as CSOEconItems (because adding another SO type for contracts would be way too logical, and we can't have that), but they have the NotEcon flag which hides them from the backpack and other econ views. I could be mistaken on this, but I don't think so. I don't recall ever seeing NotEcon anywhere else. Based on this minimal research, here is my best (likely incorrect) guess at pseudocode to match Valve's actual code: function IsItemCraftable(EconItem item) { if (item.flags & NotEcon) { return false; } if (item.schemaDefinition.craft_class == "tool") { return true; } if (item.hasAttribute("never craftable")) { return false; } if ( (item.origin == Purchased || item.origin == StorePromotion) && !item.schemaDefinition.capabilities.can_craft_if_purchased ) { return false; } if (item.flags & CannotCraft) { return false; } return true; } function IsItemTradable(EconItem item) { if (item.flags & NotEcon) { return false; } if (item.flags & CannotTrade) { return false; } if (item.hasAttribute("tradable after date") && item.getAttribute("tradable after date") > time()) return false; } if (item.hasAttribute("always tradable")) { return true; } if (item.hasAttribute("cannot trade")) { return false; } if (item.origin == Achievement) { return false; } return true; } (hasAttribute and getAttribute also check the schema definition if the appropriate attribute is not present on the CSOEconItem instance)

You got me curious, so I dumped my backpack and checked out some craftable and uncraftable items. Tour of Duty Ticket Craftable: Origin 8 (Found in Crate) Uncraftable: Origin 2 (Purchased), flags +16 (unknown flag) Killstreak Kits Inherit "never craftable" attribute from their schema definitions Uncraftable weapon Origin 2 (Purchased), same flags as craftable ToD ticket (4) World Traveler's Hat Inherits "cannot trade" attribute from its schema definition Flags 16 Origin 5 (Store Promotion) Sir Hootsalot Flags 0 Origin 12 (Halloween Drop) Has "never craftable" attribute on the item Mann Co. Cap Flags 0 Origin 5 (Store Promotion) Inherits "cannot trade" attribute from its schema definition Gun Mettle Campaign Coin This one is weird. I haven't found a way to determine that it's uncraftable using only the schema from the WebAPI and the GC data Flags 0 Origin 0 (Timed Drop) The only attributes listed in GetSchemaItems are kill eater attributes items_game.txt also includes static_attrs for this defindex, which contains "never craftable" and "cannot trade", among other things I also went back to check if the Mann Co. Cap also includes "never craftable" in items_game.txt, but it only has "cannot trade". My suspicion is that origin 5 (Store Promotion) also makes items uncraftable. I only have 3 items with this origin (World Traveler's Hat, Mann Co. Cap, Mann Co. Online Cap) and all are uncraftable. Pyrovision Goggles I don't have a tradable pair to compare with, but the only identifying characteristic in the GC backpack data is origin 1 (Achievement). Flags are 0 and there are no attributes, and it shares the same defindex as a tradable pair of goggles. So as far as I'm concerned, that's proof that origin can determine tradability or craftability. SpaceChem Pin My instance has the "cannot trade" attribute, but the schema definition has the "always tradable" attribute, and my item is tradable. It seems that "always tradable" overrides the "cannot trade" attribute. I suspect that "always tradable" would also override the Achievement origin, but I can't confirm. The Ghastlierest Gibus has the always tradable attribute, and that's an achievement item. I wouldn't be surprised if the always tradable attribute was added specifically for the Ghastly Gibus Grab achievement. Notably, some item have a capability can_craft_if_purchased, which backs up my suspicion that items with origin 2 (Purchased) are uncraftable unless their schema definition defines otherwise. Yeah, I believe this is what's happening. There are flags that determine if items are untradable or uncraftable, but the WebAPI also resolves the various other conditions that make an item untradable and stuffs them into those props as well. For the most part, the only attributes that are sent in your actual backpack data from the GC are those that are specific to an item instance. That would be stuff like maker's mark (crafter name), gifter name, craft index, kill eater (strange kills), tradable after date, stuff like that.

All item attributes are visible in the data received from the GC. They're in the attributes array.

My assumption would be that the Preview flag is set on items that are temporary store previews (the "try it out" button in the Mann Co. store) and that NotEcon would be set on items that shouldn't be tradable or craftable. It seems that your experience doesn't match my assumption, which means that either your data is wrong, my assumption is wrong, or the actual values of the named flags in node-tf2 are wrong. Any of those could be possible; I don't think I got those flag names from any authoritative source.