Dr. McKay

That could be any number of things, likely coming from a steam-user method.

New version is up: https://github.com/DoctorMcKay/node-steam-session/releases/tag/v0.0.3-alpha

https://github.com/DoctorMcKay/node-steam-user/wiki/SteamChatRoomClient#ackfriendmessagefriendsteamid-timestamp

Not yet, but it will. Maybe this is a little vague, I'll try to rewrite it. This is only talking about a case where you supply a token that wasn't generated using EAuthTokenPlatformType.SteamClient. If the token is invalid for any other reason, you'll get the normal error event with an EResult value (probably InvalidPassword, but I haven't checked).

access_token (client._logOnDetails.access_token) and refreshToken are the same thing. The field in the logon message is named access_token, but steam-user accepts it as refreshToken to make it less confusing which type of token you need to supply (since steam-session returns both an access token and a refresh token). As far as I can tell, the refresh token you receive from steam-session is good for the full 200 days, so you can just keep using it over and over. I'm not aware of a way to get a new refresh token without going through the entire auth flow again. I wouldn't be surprised in the slightest of the official Steam client just pops up the login flow again in 200 days. It's up to you how you store your tokens. Encryption at rest is rarely a bad idea, but it's also pretty useless if you're also storing the keys alongside the encrypted data, for example. Sentry files aren't encrypted either, they're just blobs of random binary data by design.

What version of node and steamcommunity are you running?

You're probably overwriting av somewhere, it seems like it's not a string.

You must use EAuthTokenPlatformType.SteamClient to get a token that's eligible for use with steam-user.

That will log the IDs of the items before they were traded. To get new asset IDs, use the getExchangeDetails method on the TradeOffer object.

Sounds like you might not be up to date. I'd fetch all rows upfront, then request all personas at the same time. Seems good, I think Steam might send you a persona update via the user event for yourself when you set yourself to online; if it does, then waiting to see yourself as online might be all you need.

The order of parameters to the getPersonas callback is err, personas. You have it backwards. The getPersonas function accepts multiple IDs. Why are you calling it individually for each ID? You might need to delay some time after calling setPersona to set yourself online, as you're currently sending the getPersonas requests synchronously at the same time as setPersona, without giving Steam enough time to process that you're now online.

That's correct, if you want newOffer to be emitted again the next time the bot starts up, you'd want to make sure you don't save poll data.

I'm assuming that this log output is produced by multiple steam-user instances, since there shouldn't be any situation where multiple connections belonging to the same SteamUser instance would be open. If this isn't the case, there's a bug. In your screenshot, it does look like T1 and T2 are still connected. I don't honestly know what circumstance would cause the AlreadyLoggedInElsewhere error; normally if you log into an account that's already logged on elsewhere, it'll still work. If there's a logon ID conflict, the first session would get booted with LoggedInElsewhere (eresult 6, separate from AlreadyLoggedInElsewhere).

https://github.com/DoctorMcKay/node-steam-user#steamguard

No, you're responsible for removing your own event listeners.

That's correct.

Sounds like that might be a rate limit.

Nothing that steam-user does uses the WebAPI. There might be limits on various requests, but the WebAPI limit doesn't apply here. Using steam-user to listen for the user event doesn't make any requests at all; Steam pushes down profile updates as they happen.

As far as I'm aware, all CS:GO items have a trade cooldown when traded. I don't know why you'd be seeing different behavior.

That's just what happens for CS:GO items. Whenever an item is traded, the item server applies a 7-day trade cooldown to the item. Those market_tradable_restriction and market_marketable_restriction properties don't really do anything; they just get set on all items to show which cooldowns apply when an item is bought off the community market. It's up to the item server to actually apply any restrictions. I hadn't seen market_buy_country_restriction before, but I'm assuming it's the same: it just gets set on all items to prevent then from being bought by people in specific countries.

Most free games these days are free-on-demand, so you'd need to use the requestFreeLicense method before you actually own the title.

All of the details are already available on the objects in the data array.

You would need to use node-globaloffensive.

It's fixed now.

No.