Jump to content
McKay Development

KTVS

Member
  • Posts

    16
  • Joined

  • Last visited

Everything posted by KTVS

  1. KTVS

    Steam Market WS

    Hi Dr. McKay, Wondering if you know anything about the steam market websocket endpoint - more specifically if you know of any feeds other than the default "Market.PopularByCurrency" when you visit /market
  2. Do you know anything about the occasional trade that cant be canceled/declined or accepted and will still be marked as active and open even if items from the trade are traded away? Usually it sorts itself out, but this is after hours or sometimes days. Do you know about these types of trades and potentially any tricks to get rid of them?
  3. Alas, non-craftable tools do exist. That was one of my first thoughts too, but Name Tags, Description Tags, Decal Tools, paint cans, and even the special variants of the crate keys all come in non-craftable flavors.
  4. That's hugely helpful; you certainly have a more diverse backpack to test with than I do. I had missed the can_craft_if_purchased attribute in the schema, which would explain the inconsistency I saw a while ago with items with a purchased origin. Unfortunately though, still no explanation as to why Mann Co. Supply Crate Keys remain craftable despite being purchased. Now I just assume it's something like "if(item in some_secret_list_of_very_special_boys){ craftable = true; } I also just got a preview item from the store to check out the GC "Preview" flag, but the entire flag value is still 0. 🙃 A mess indeed.
  5. My mistake, I spoke too hastily. It looks like some attributes are given by the GC per item but some attributes are simply looked up in the schema based on the item's defindex. The GetPlayerItems endpoint redundantly provides both while the GC only provides attributes which are unique to that item instance. That should include the attributes you mentioned, but I haven't encountered them or any others except the "crafted by", "gifted by", and "gifted at" attributes. In which case, literally the only other thing missing from the GC which is present in the api response is the flag_cannot_craft and flag_cannot_trade. The API will also resolve the username of a gifter or crafter, so I guess whatever magic is happening on the client to determine craftability also happens behind the scenes with the API before the response is sent.
  6. As time went by since posting, I had a worse and worse feeling that this was the case. I've tried comparing craftable/non-craftable versions of the same item to each other, but the only difference is the origin and, consequently, those two flags. As you just mentioned in my other post, those two flags could actually be named differently than the enums (I had originally suspected they were all reversed by mistake, which actually prompted that other post about them in the first place, but I of course have no solid reason to believe that) but the flags are still not unique to craftable or non-craftable items. The item attributes you mentioned are visible when requesting an inventory from the tf2 api, but are not visible to the GC. With my limited number of testing items, the only two item attributes I ever saw were the "gifted by" and "crafted by" attributes. An item's origin does not necessarily dictate which items are displayed as non-craftable, and neither does the existence of those two flags (whatever they might be). Based on everything we've discussed, I can't help but feel like there is simply a list of items which are destined to display as non-craftable when they have a purchased origin. Unfortunately, no such list exists within the schema, and items capable of displaying "not usable in crafting" don't line up with the items which are listed for sale in the store at the GetAssetPrices endpoint. I give up. Maybe in a few months I'll give it another swing. Thank you for your patience and, as always, your endless insight.
  7. Looking into this more, I don't actually believe this is the case. I strongly suspect detailed item information is provided to the client through a separate message which is not the same as the one which triggers the backpackLoaded event. I obviously don't know what message that is, since there don't seem to be that many messages being sent to the client, but I believe it exists. My main reason for suspecting this is related to gifted and crafted items. Crafted items will always show the *current* username of the crafter, not their username when the item was crafted. Additionally, their name isn't provided as an item attribute from the GC, their Steam3ID is. So somewhere, somehow, the crafter's username is being provided to the client. Interestingly though, when the crafter's name is changed, the client doesn't update for a while. Even the inventory api will reflect the name change before the client, so the player info could be cached locally instead of fetched on each backpack load. It's possible that this is a completely separate mechanism which is responsible solely for updating these player names, in which case my whole theory is bunk. Even if there were some elaborate rules for determining craftibility just from the GC info, there is without a doubt *some* additional information being obtained for items before they're displayed. I'd love to hear any thoughts you have about this, since you're in a much better position to speculate what messages are being sent for what purpose.
  8. Hi Doctor McKay, I've decided to revisit the problem of discovering item craftability/tradability from the info provided by the GC, but a had a question about the item flags. I was hoping you could tell me what the Preview and NotEcon flags are. From my small test sample, these flags are always set on items whose origin was "Purchased", and the NotEcon flag is set for all items whose origin was "Found in Crate". To my original end, it seems like these flags are worthless since, from what I can tell, all non-craftable items come from store purchases, but, frustratingly, just because an item was purchased from the store does not make it uncraftable. Regardless, I'd still like to know more about the flags if you have any info on them. Thanks
  9. Ahh I see. I also suspected that it might not be possible since that would feel like an oversight if it was, but I was looking for a concrete reason to believe that it wouldn't work. If app tickets must be validated, then that would be a reason.
  10. Based on your assumption, it really comes down to if Steam is okay communicating inventory updates to a non-secure server. Correct me if I'm wrong, but it looks like the authentication of the app ticket only needs to be done on secure servers, and as long as that authentication step doesn't need to be 'passed on' to whatever inventory server is spitting out item events, then it might be possible to subscribe to an arbitrary user's inventory events from an insecure server. This at least gives me a bit of hope to keep pursuing the idea.
  11. Wow, never saw this website for the Steam API before. I've just been looking at the official docs for years ... I'll definitely be making use of the GetTradeStatus endpoint now that I know about it. Hot tip, thank you
  12. I was curious how the server implements those chat messages when someone acquires an item from a trade, and I ended up stumbling across a sourcemod plugin that you made a little while ago here. The questions I have are pretty specific, but seeing this plugin made me think you might have the answers. I mentioned in another thread that I was running into rate limit issues for Steam's inventory, so these questions all spawn from the goal of avoiding those limits. Is the fact that a user acquired a new item told to the server by the user themselves? Or is the server forwarded these events from steam for all user's in the server? If the item notifications are sent by the client, what's stopping someone from spoofing these messages? If the server gets special events, is it possible to write an 'inventory listener' program which is a partial implementation of a source server for the sole purpose of knowing when a user obtains new items? If so, would it be able to listen to an arbitrary user? Or is there some kind of authentication information that needs to be forwarded by the server to steam in order to subscribe to those itemAcquired events for each user?
  13. I'm satisfied enough with this answer; if you say it's that bad then I'm sure the enormous headache outweighs the benefit. The main issue I'm facing is re-finding items after they've been acquired in a trade. Trades that don't require confirmation can have the new item's asset ids determined by looking at the trade receipt, but I haven't seen a way to get the trade ID for the trade receipt when the offer required confirmation or was a sent offer that was accepted. Luckily enough, the asset ids are right there in the message from the GC... but I don't know to what items they belong and I don't want to be making educated guesses. Due to the nature of my program, I run right up against Steam's web inventory rate limit (100 calls every 2 minutes). I would definitely benefit from trimming unnecessary inventory calls, especially those that are just updating my own inventory, but I still need them anyway to determine which items are currently tradable and which aren't based on the inventory cache. It seems like an unnecessary hassle forcing steam to uncache my inventory every time I want to send a trade offer, so for those two reasons (the headache of parsing the craftability/tradability and handling cached items), it looks like the web calls must stay. This sounds like a nightmare that, as you suggested, probably isn't worth trying to figure out. My core issue of Steam's inventory rate limit actually brings me to another question, but it's unrelated to this topic so I think it's best to start a new one for clarity. As always, thank you for your help!
  14. As a side note, I realize that my example used freshly crafted metal, but I wouldn't be able to send trade offers including freshly-crafted metal to begin with due to the inventory cache. This is mostly for new items from trade offers.
  15. I was hoping to get an elaboration on this post that was made a year ago. Similar to this fellow, I'm wondering how to get the craftability & tradability of an item sent from the GC, but, as you eluded to, am struggling with the various conditions. At first I thought it was just a matter of the the 5th bit being set in the flag attribute for non-craftable items, but this lead to all supply crate keys being flagged as non-craftable. I pretty much gave up after realizing this and started reloading from the web, but I noticed that steam's inventory endpoints have some lag to them which caused issues when reloading soon after crafting metal (old metal would still show and new metal wouldn't). I've effectively resolved the issues by using the GC just to get the asset ids of items that are in my inventory, and the names get filled in whenever they're seen by the web inventory. That solves the problems, but it would be fantastic to not have to reload the inventory from the web at all. Is it actually possible to accurately get the craftability & tradability of an item just from the info the GC gives back? If so, is it possible to get (to your best knowledge) the key attributes I need to be looking at? Your help is deeply appreciated.
  16. What information can I save/reuse to log in between process restarts? I frequently get rate limited when testing due to so many logins.
×
×
  • Create New...