Dr. McKay

I've not verified whether this works, but reading over the docs it seems like this would be the way you'd check if a user has a given permission: Call setSessionActiveGroups on startup to get Chat Room Group State Record the Chat Room Member data from Chat Room Group State. This data includes member role IDs. Record the Chat Room Group Header State data from Chat Room Group State. This data includes Chat Role Actions. When you want to see if a member has the permission you want to check, look them up in the Chat Room Member list from Chat Room Group State, and see in Chat Role Actions if the roles that map to their role IDs include the permission you want to check.

https://steamerrors.com/15

That just kind of happens, in my experience. Not sure why. I'd advise just using passwords instead.

Sorry, this isn't currently available.

With new Steam chat, incoming trade offers are also delivered as a message, I believe using the [tradeoffer] bbcode. You need to check if the message contains only bbcode and ignore it.

To get which apps have card drops available, you'll have to scrape the badges page. There's no better way to get that data. You can check how I did it in Steam-Card-Farmer for help. To exclude "basic apps", you'd want to filter out appids that are granted to you only by package id 0.

There's no reason why it should ever be 12, that isn't used internally or anything. Maybe Steam is just really really fussy for your account or something? Maybe 12 is a value used internally by Valve for something and something's buggy with your offer(s). Could you set up a script to monitor the API directly and alert if it notices a value of 12?

What is the oldState when it emits when you believe it shouldn't?

You need to check the descriptions array of the item in question and look for the unusual effect tag (after making sure it's a TF2 item, of course). And you can check the color to see if the item is of Unusual quality.

Show your code and the entire output.

You'll probably have to keep using v3 if you want compatibility with some other module that requires CMClient.

Yes, take a look at how node-steamcommunity does it: https://github.com/DoctorMcKay/node-steamcommunity/blob/master/components/users.js#L422

You probably have some sort of race condition somewhere resulting in you attempting to accept a confirmation before you actually call login. That particular error happens if you attempt to accept a confirmation without ever having logged in before (on that SteamCommunity instance), so this isn't a case of expired cookies.

https://steamerrors.com/26

Firstly, look into using acceptConfirmationForObject in place of the confirmation checker. Secondly, you have a potential bug in using the disconnected event to log into a new account. The disconnected event can also be emitted if the connection to Steam drops temporarily but will be automatically re-established. You should probably set a flag when you call logOff() so you know if the disconnected event was in response to that. Finally, to your main question, you should call manager.shutdown() when you log out of an account before logging into a new one. That should solve your problems.

getUserDetails cannot be called unless an offer is active, so you need to use it before you send a counter offer. Using the counter() method will return a new, unsent trade offer object which, when sent, will be sent as a counter offer. Each offer can only be countered once, so if you try to send two counter offers (either by calling counter() twice or by calling duplicate() on a counter offer), it won't work. In essence, the ID of a trade offer sent to you can be used in place of a trade offer access token (sort of, not literally) in order to send a trade offer, but only once. Once you send one counter offer, the original offer goes into "Countered" state and it can't be countered again.

Spoofing a built-in event is almost never the right way to accomplish something. In this case, your second snippet is the more correct way to do this.

To handle errors: client.on('error', function(err) { // do something with err (which will never be null or undefined in this event) }); You aren't going to be able to do anything with limited inside of the loggedOn event. The data isn't going to be available yet. loggedOn gets emitted when Steam sends us back the logon response saying that your logon was successful, but Steam doesn't send us our account limitations for another second or so, which is why the data is undefined/null inside of the loggedOn event.

https://github.com/DoctorMcKay/node-steam-user#chatmessagerecipient-message-type

I'd do something like calculate the total amount of scrap required (so e.g. 1.33 is 12 scrap). Then you could do something like this to calculate how much of each metal type you require: let refRequired = Math.floor(scrapRequired / 9); scrapRequired %= 9; let recRequired = Math.floor(scrapRequired / 3); scrapRequired %= 3; // scrapRequired is now how much you need after ref and rec

manager.getInventoryContents is only used for getting the current account's inventory. If you want to get some other user's inventory, you'll have to use manager.getUserInventoryContents.

From?

I don't really know how SDA works as I've never used it, but you might try exiting it for a day or two and see if that helps. Have you tried using a different IP address? It seems to me like sometimes Steam just flags a particular account or API key on a particular IP. You might try using a different IP, or check where you might be using that API key besides just in the bot. The code you posted here looks fine, though.

Sure, you could use steamstore for this.

No, all you can do is work out what the error code could mean. https://steamerrors.com/15