Dr. McKay

Yes, you should set a timeout. The code a couple posts back will just spam Steam with login requests which will get you locked out. That's not how you set a timeout, though. You want this: setTimeout(function() { callback(SteamTotp.generateAuthCode(config.sharedsecret)); }, 30000);

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

Maybe someday, but I don't have any immediate plans at the moment.

No. No Steam services support IPv6 at the present time.

Correct! I'm glad you got it sorted out. That tutorial is outdated. Things move pretty quickly in this world. If you have any other questions, feel free to ask.

Okay, well getSteamID64 didn't work because it appears that you're using node-steam's friends handler alongside SteamUser, which is unnecessary. All functionality from node-steam is available in SteamUser directly. The getPersonas method requests data from Steam and calls your provided callback with the personas object once the data is received. You're correct, the properties of personas are objects. In this case, since you requested data for only one user, there is only one property. In cases where you request data for multiple users, there will be more properties defined. Each sub-object contains the data we received from Steam, which is where player_name comes from. The ? and : are the ternary operator, which is more or less an "inline if" statement. In this case, it's checking whether the persona data exists in order to determine whether to pull the player_name from the data or to fallback to a default value. In this case, it was unnecessary, I just didn't feel like checking whether it was possible for getPersonas to not return data for the requested user(s) (it's not).

There is presently no functionality available to do that.

There is no way to enumerate classids.

Your problem is that getPersonas expects an array as the first argument, and you aren't passing it an array. What you want to do is client.getPersonas([steamID], function(personas) { /* etc */ }); Also in this case, the callback is essentially mandatory for you. getPersonas doesn't return anything. The data is only available inside the callback. In your case, you want something like this: client.getPersonas([steamID], function(personas) { var persona = personas[steamID.getSteamID64()]; var name = persona ? persona.player_name : ("[" + steamID.getSteamID64() + "]"); // the player's name is now available as name });

Can you show the code you've tried with getPersona?

https://steamerrors.com/15

Are you sure that you're logged in? Also, are you up to date?

What exactly is the error message you're getting, and where? Also, please show the code that is generating and sending this offer.

Sometimes Steam just doesn't return any data. There's nothing we can do about it. Retry if you get unexpected results.

You can only use a code once. Subsequent uses will be rejected. Codes change every 30 seconds. In practice, this means that a second login within a 30-second interval will be rejected and ask for a new code.

When that happens, some server is probably down or being unstable. If you wait, things will fix themselves.

You'd use myCommunity as normal. Passing it in will cause TradeOfferManager to set cookies on it when you call offerManager.setCookies.

No, you can't access the auto-created instance if you don't supply one. Just create your own and pass it in if you need to use it for confirmations.

Asset IDs are unique, but not necessarily persistent. Only one item with a given asset ID will only exist at once within a given context (for Valve games there is only one context, so that can be expanded to "game-wide"), but it can also change to a new unique number at whim. As you discovered, you can use getReceivedItems to get the new IDs.

It could be implemented, but I wouldn't bank on it happening anytime soon.

Sorry, you're a bit confused as to what the function of the storage engine is. It isn't for Steam Cloud data (that hasn't been implemented in steam-user at all). Rather, it's for saving data generated by the module itself (for example, sentry files and server lists). By default that data is saved to a platform-specific application data path, but the storage engine allows you to redirect storage elsewhere.

I'm confused as to what you're talking about regarding an "actual game via steam". Can you explain exactly what you're doing and what you expect to happen?

I don't know exactly why you're getting "Malformed response", but your offer is getting declined somehow. Perhaps you have another bot running somewhere else that is declining offers?

I'm glad you got it working. If you haven't already, I suggest that you check all the breaking changes in v2 to make sure nothing else needs to be changed on your end.