Dr. McKay

Oh yeah, it's an object. Object.keys(client.myFriends).filter(steamID => client.myFriends[steamID] == SteamUser.EFriendRelationship.Friend).length

client.myFriends.length

Unless you want to dive into the code and try to figure out what's wrong, you'll have to wait until I have time to look at it, which probably won't be anytime soon. Sorry.

I've added ban methods in v4.10.0.

The module itself is definitely supported. There are some deprecated methods and such, but only because newer things have replaced them. I did a test myself and I got about a half-second round-trip time, counting from when I hit enter and stopping when my bot responded to me. That doesn't seem unreasonable to me. I just haven't gotten around to adding a feature to ban people from a group chat yet. If that's something you need, I'll see if I can prioritize it.

I don't know why you would call this a "legacy module", but any lag is on your end. Either in your code, or in your connection to Steam.

Auth session tickets were never really tested. It's pretty likely that the code to retrieve and activate them doesn't work properly.

getPlayerCount is an asynchronous method. You need to either handle the Promise, or attach a callback (user.getPlayerCount(504370, function(err, count) { ... })). But you also need to wait for the loggedOn event before you do anything after calling logOn.

The first argument needs to be an enum value, not a string.

Games.join("\n")

No.

You're welcome to use the module by downloading it from Github, but that's ill-advised. You should be using npm install steam-user on the command line to download the library. But if you really really want to download from Github, you'll need to run npm install inside the module directory to download dependencies. Once you're logged on, you should be able to use user.getPlayerCount(...)

What version of steam-user do you have? Are you using the steamGuard event?

I still can't reproduce that. That shouldn't be possible, since the property gets initialized to 0 right before the loggedOn callback fires.

In general, Valve's GCs don't actually respond to messages using job IDs (which is the mechanism used when you pass a callback to sendToGC. Only if the GC supports using a message as a job will the callback be invoked. ClientHello is not a job-based message. Are you sure that ++this._currentGCJobID is returning NaN? I can't reproduce that on my end, and I see no way in the code that this would happen.

It's not part of node-steamcommunity anymore. You should use the WebAPI instead.

Run npm update and it will throw properly.

You're somehow passing a bool to two_factor_code in the logOn method.

Yep, that looks right. Although be aware that your callback function there is going to be called once for every item in your inventory that has a matching name. Put a return statement after the callback invocation to avoid that.

I would hazard a guess that badvar is not defined.

You have a misunderstanding of how asynchronous code works in JavaScript. You need to pass a callback to getID and call it with the item ID you're looking for.

Protos.SteamDatagramTicket.decode(body.slice(4)).data

Skip the first 4 bytes, and this schema will decode it: message SteamDatagramTicket { message DataWeCareAbout { message NamedInteger { optional string name = 1; optional fixed64 value = 5; } message LoneInteger { optional fixed64 value = 16; } optional fixed32 unknown1 = 1; optional fixed64 steamid = 2; optional fixed32 unknown3 = 3; optional fixed64 server_steamid = 4; optional fixed64 unknown5 = 5; optional int32 app_id = 7; repeated NamedInteger arguments = 8; optional fixed32 unknown9 = 9; optional int32 unknown10 = 10; optional bytes unknown11 = 11; optional LoneInteger steamid_again = 12; optional LoneInteger server_steamid_again = 13; } optional fixed64 unknown2 = 2; optional DataWeCareAbout data = 3; optional bytes unknown4 = 4; } This was produced by reverse-engineering. The field names are definitely not the same as what Valve uses.

You shouldn't increase the limit. You should figure out why you're attaching so many listeners to friendRelationship.

What do you get if you call buffer.toString('hex')?