Dr. McKay

Fixed again, they changed a class name.

Acknowledging a received item is done by simply moving it to a backpack slot using setPosition or by sorting your backpack again using sortBackpack. sortBackpack only sorts your backpack once; it won't stay sorted when you receive new items.

This works fine for me: let manifestId = (await user.getProductInfo([730], [])).apps[730].appinfo.depots[731].manifests.public.gid; console.log(`Got manifest ${manifestId}`); console.log(await user.getManifest(730, 731, manifestId, 'public')); Please show your code.

They come from SteamDB, which itself dumps them from Steam using ProtobufDumper.

The hcaptcha widget appears fine for me in Firefox 113.0.2.

steam-user doesn't provide any way to specify your own sessionExternalIP value, but there's nothing stopping you from spoofing that field to be whatever you want, either. It's client-controlled and isn't authenticated by Steam as far as I'm aware. You could try changing the value directly in the steam-user code here and see what happens. Yes, the internal IP is determined from the private IP specified when you connected to Steam. By default, steam-user sends 0 unless you change the logonID value in the logOn method. You need to encode your desired internal IP as a 32-bit int, then xor it with 0xBAADF00D. For example, 192.168.1.2 encodes to 3232235778, then xor that by doing 3232235778 ^ 0xBAADF00D and you get 2158493696, which is what you should use for your logonID. Yes, ownership tickets are cached in userdata/your_account_id/config/localconfig.vdf under apptickets. Not as far as I'm aware You can use NetHook for that. When you inject it, you'll need to provide the filename of the game process you want to inject into.

It looks like Steam might have changed how product info data is sent. Update to 4.28.5 and it should be fixed for you.

I don't see why it would be.

My bad, I'd thought you said above that RemoveSticker did exist. Try using Language.ApplySticker instead. It may be that including the extra properties broke things for you.

Try this: GlobalOffensive.prototype.scrapeSticker = function(item_id, stickerslot) { this._send(Language.RemoveSticker, Protos.CMsgApplySticker, { item_item_id: item_id, sticker_slot: stickerslot, sticker_wear: 1 }); }

You'd need to use getPersonas for that.

No bother, I fixed the bug in response to this thread. It was in one of steam-session's dependencies which I maintain.

This was a bug. Run npm update and you should be set.

This is correct. Access tokens are only useful when using EAuthTokenPlatformType.MobileApp.

Between your two screenshots, it kinda looks to me like g_ProcessPersonaSemaphore is somehow hanging at some point. The semaphore is backed by a linked list, and I see a lot of prev pointers in your OP screenshot. I don't really see why it would hang though, all code paths end in releasing the lock. That would also cause SteamID objects to pile up, as you're seeing in your heap snapshot. In any case, try 4.28.4 and see if that fixes things for you.

You can intercept and inspect Steam traffic using NetHook to see what the game is sending to the GC. I didn't see any RemoveSticker protobuf definitions in the files, so my guess would be that it's using CMsgApplySticker for removals, but not setting sticker_item_id or baseitem_defidx.

If you only need to confirm the trade, you can do that directly with steamcommunity. If you need to accept the trade, this isn't a supported use-case for steam-tradeoffer-manager. You'd have to craft the accept request yourself.

I'm pretty confident that sharedfile IDs are just simple incrementing integers. No real way to determine if a given input is a sharedfile without making a request.

You don't need sessionid or steamcountry. There are no restrictions if you don't set them.

I'm not sure under what conditions DLCs show up in its output, but you could try using the GetOwnedApps WebAPI method.

Once you have cookies set, you're logged in (assuming they're still valid). You don't need to call login again. And yes, steamLoginSecure is all you should need, although you might run into trading problems if you don't also include steamMachineAuth<steamid>, if the cookies didn't come from steam-user.

CasketItemLoadContents doesn't return anything sane, because it's Valve. When you send it, you get back a bunch of SO_Create messages for the items in the casket. Basically, they get added to your inventory as if they were presently in your inventory, even though they aren't. That's where you need to check those two attributes to determine which items are in the casket.

setCookies expects an array.

You can't do it with steam-user.

You might run into fewer rate limits using steam-session to login and get your cookies.