|
|
| (59 intermediate revisions by 18 users not shown) |
| Line 1: |
Line 1: |
| − | {{Archive list|archives = [[/Archive_1|1]]}} | + | {{ambox|type=notice-2|image=Pictogram_info.png|contents=Please use this page for reporting and discussing possible issues or inconsistencies with the API documentation or API itself. This is not for learning how to properly use one.}} |
| | + | {{Archive list|archives = [[/Archive 1|1]] [[/Archive 2|2]] [[/Archive 3|3]]}} |
| | | | |
| − | == Suggestions == | + | [[Category:WebAPI|Feedback]] |
| − | === Things that should be fixed in the Steam Web API system ===
| + | |
| − | *JSON and VDF should use arrays rather than objects containing arrays. Having them structured differently from XML complicates code unnecessarily (and result.items.item[1] is redundant compared to results.items[1]). This seems to have been designed to preserve the element name used for the individual objects in XML (allowing multiple arrays to be defined in the event of mixed types, which should be structured as multiple arrays in XML as well). When everything in an array is of the same class, nobody in JSON cares about that class's name (only its index in the containing array, and anybody using VDF is using code that was written for the original data file, which ''is'' structured this way.
| + | == Dota 2 — item rarity == |
| | + | Can you add item '''rarity''' (not '''quality''') to the ''GetSchema API'' call? It`s very strange to not present rarity here. There is only quality now, but it is useless for Dota 2. --[[User:Ohar|Ohar]] ([[User talk:Ohar|talk]]) 03:52, 30 October 2013 (PDT) |
| | + | |
| | + | == Improperly formed JSON float_values for decal attributes - still not resolved == |
| | + | |
| | + | http://wiki.teamfortress.com/wiki/Talk:WebAPI/Feedback/Archive_3 has the previous thread. I'm still receiving the improperly formed JSON :( Just FYI - thanks! [[User:VMDX|VMDX]] 14:37, 21 November 2011 (PST) |
| | + | : Alright I've been on the lookout for this regression on my own logs for optf2 and asking around. I cannot find any reproductions. Care to give an id64 that exhibits this problem? -- [[User:Lagg|Lagg]] [[File:Backpack_Stickybomb_Launcher.png|24px|link=User_talk:Lagg]] 22:05, 30 November 2011 (PST) |
| | + | |
| | + | :: ex: in 76561198005981351 : "attributes": [ { "defindex": 152, "value": 1879034420, "float_value": 158326252166124510000000000000. }, { "defindex": 227, "value": 117757579, "foat_value": 0.000000 } ] |
| | + | :: Some json decoders break because the number doesn't have the 0 after the dot. I don't see this happen in PHP but I've heard others having this problem [[User:Ruiner|Ruiner]] 21:02, 22 April 2012 (PDT) |
| | + | ::: [https://plus.google.com/b/107947934768801101757/107947934768801101757/posts/ESL2ibu3VDR Yep I've spoken to an employee about it and they said they'll look into it tomorrow. Apologies for not noting this on the talk page sooner.] -- [[User:Lagg|Lagg]] [[File:Backpack_Stickybomb_Launcher.png|24px|link=User_talk:Lagg]] 21:15, 22 April 2012 (PDT) |
| | + | |
| | + | == Painted items == |
| | + | |
| | + | I noticed that the steam community inventory viewer has images with paints embedded in them. Would it be possible for the backpack items to include the encoded URL for the image with paint. |
| | + | ex: [http://cdn.steamcommunity.com/economy/image/HZzrHVtyDPzKTe4tK5JD9aXQIawfAgKiD4I1O4JoElrAlMX9DCVb5GOV9N8PsxFmtIshuhcCEqEajjoi3DFGA9HJza8Ue0jiaoeliFD7F2aqmTy_SkNe_guGJjeSbgtS6pLN_SpnWflp37-MVbhKaf3FZL4dHBXmT4JmYtQ1SAeDnJztTTMLsm_cqd5U60sz-5Zs8lVDSg==/96fx96f with paint] -- [[User:Ruiner|Ruiner]] 07:13, 25 February 2012 (PST) |
| | + | |
| | + | == custom texture lo - Invalid JSON == |
| | + | |
| | + | I had another talk with Drunken. This is the relevant part of his response on the matter. I'll be giving a language-independent workaround in a while if time permits. |
| | + | <pre> |
| | + | 1:34 PM - Drunken F00l: I know why it's printing bad values, yes |
| | + | 1:34 PM - Drunken F00l: it's just truncating |
| | + | 1:35 PM - Drunken F00l: I'll get it fixed but the fix probably won't ship until next week |
| | + | </pre> -- [[User:Lagg|Lagg]] [[File:Backpack_Stickybomb_Launcher.png|24px|link=User_talk:Lagg]] 16:10, 23 April 2012 (PDT) |
| | + | |
| | + | : Here is a temporary workaround for the problem, as promised. This call is for python's re module but should be similarly easy to modify as needed for basically any regex implementation out there. What the expression is doing is searching for a line with 0 or more characters of whitespace at the beginning, followed by the normal float_value key and then an arbitrary length integer followed by a decimal point and non-decimal character. The part of the string preceding the decimal point is captured and reinserted into a string suffixed with '.0'. I hope you find it useful. <code>re.sub('(\s*"float_value": -?\d+)\.[^\d]', '\\1.0', obj)</code> -- [[User:Lagg|Lagg]] [[File:Backpack_Stickybomb_Launcher.png|24px|link=User_talk:Lagg]] 21:08, 23 April 2012 (PDT) |
| | + | |
| | + | :: Fixed a small bit of the regexp. I'll let my commit message describe what the change was since it does it best: Because apparently I thought that the bug was choosy about what side of a 0 it appears on. -- [[User:Lagg|Lagg]] [[File:Backpack_Stickybomb_Launcher.png|24px|link=User_talk:Lagg]] 08:48, 24 April 2012 (PDT) |
| | + | |
| | + | ::replace(".\n",".0\n") [[User:Base1024|base1024]] 12:35, 24 April 2012 (PDT) |
| | + | ::: Keeping in mind that this will break on caching/minifying proxies -- [[User:Lagg|Lagg]] [[File:Backpack_Stickybomb_Launcher.png|24px|link=User_talk:Lagg]] 12:37, 24 April 2012 (PDT) |
| | + | |
| | + | == Item Origin == |
| | | | |
| − | Short version: this
| + | Item origin is buggy and/or incorrect. For example, many Bill's Hats are showing as timed drop. This was a promotional item and should be marked as such. There is also an origin flag "traded", but it's not clear when that attribute is used: Traded items usually do not acquire the origin to be set as "traded". For example, store purchased keys will keep their store purchased after being traded. My suggestion would be to make the item origin cumulative. If an item was purchased, then traded, it should be possible to tell what the original origin was, as well as the current origin. This way, we can tell in a user's inventory if the item has ever been traded, or if he is the original owner. |
| | | | |
| − | "result": {
| + | -- [[User:Ruiner|Ruiner]] 18:48, 24 April 2012 (PDT) |
| − | "status": 1,
| |
| − | "items": {
| |
| − | "item": [
| |
| − | {
| |
| − | "id": 18446744073709019323,
| |
| − | "defindex": 125,
| |
| − | "level": 1,
| |
| − | "quality": 3,
| |
| − | "inventory": 2149580806,
| |
| − | "quantity": 1
| |
| − | },
| |
| − | {
| |
| − | "id": 1029705,
| |
| − | "defindex": 36,
| |
| − | "level": 5,
| |
| − | "quality": 3,
| |
| − | "inventory": 2147483655,
| |
| − | "quantity": 1
| |
| − | },
| |
| − | ]
| |
| − | }
| |
| − | }
| |
| | | | |
| − | should look like this:
| + | == Unexpected EOT character in Chinese (zh-tw) custom item name == |
| | | | |
| − | "result": {
| + | Backpack in question: 76561198038762828 |
| − | "status": 1,
| |
| − | "items": [
| |
| − | {
| |
| − | "id": 18446744073709019323,
| |
| − | "defindex": 125,
| |
| − | "level": 1,
| |
| − | "quality": 3,
| |
| − | "inventory": 2149580806,
| |
| − | "quantity": 1
| |
| − | },
| |
| − | {
| |
| − | "id": 1029705,
| |
| − | "defindex": 36,
| |
| − | "level": 5,
| |
| − | "quality": 3,
| |
| − | "inventory": 2147483655,
| |
| − | "quantity": 1
| |
| − | },
| |
| − | ]
| |
| − | }
| |
| | | | |
| − | --[[User:STUART|STUART]] 04:23, 5 July 2010 (UTC)
| |
| − | : The lists are constructed the way they are because that's the way the underlying webapi system in Steam works. All lists in all Steam webapis are that way. That isn't likely to change because there are so many APIs involved. It's ugly, but it works. Hopefully it isn't causing any great pain.[[User:Joe|Joe]] 18:34, 23 November 2010 (UTC)
| |
| − | :: It isn't, and I figured that it had something to do with the layout of objects returned from the APIs this one uses. At worst it's a minor inconvenience to people if they're writing sane code. -- [[User:Lagg|Lagg]] [[File:Backpack_Stickybomb_Launcher.png|24px|link=User_talk:Lagg]] 02:39, 24 November 2010 (UTC)
| |
| | | | |
| − | ===Methods that should be added to ITFItems_440===
| + | TF2B: http://tf2b.com/tf2/76561198038762828 '''FAILED''' |
| − | *A method that returns all of a language's strings for a given language (like resource/tf_english.txt). This would allow simpler caching of GetSchema with regards to translation (clients would only need 1 GetSchema return for all languages, and could request each language individually without needing to get all of the schema data again, increasing the signal:noise ratio significantly for translation). --[[User:STUART|STUART]] 04:22, 5 July 2010 (UTC)
| |
| − | **Would the ability to set "language=All" help? [[User:Joe|Joe]] 18:36, 23 November 2010 (UTC)
| |
| − | *A method that returns the latest revision information for each of these, so systems know when they need to make the heavy call to GetSchema and other static methods. --[[User:STUART|STUART]] 04:22, 5 July 2010 (UTC)
| |
| − | *Dueling data (Wins, losses, ranking) attached to either dueling badges, or via a separate feed. [[User:FireSlash|FireSlash]] 15:06, 21 March 2011 (UTC)
| |
| | | | |
| − | ===Things that should be added to the next version of GetSchema===
| + | OPTF2: http://optf2.com/tf2/user/76561198038762828 <del>'''FAILED'''</del> '''SUCCESS (Thanks)''' |
| − | *The revision number, so systems can compare it (for stored data) against the latest revision (as described above). --[[User:STUART|STUART]] 04:22, 5 July 2010 (UTC)
| |
| − | *The defindex of attributes for items, rather than the attribute's name and class. If GetPlayerInventory uses defindex for its attributes, GetSchema should too. --[[User:STUART|STUART]] 04:22, 5 July 2010 (UTC)
| |
| − | *Add missing fields used_by_classes and craft_class [[User:FireSlash|FireSlash]] 16:17, 5 July 2010 (UTC)
| |
| − | *Add field propername to allow for simple construction of item name. i.e "A <Community> __" vs "The __", and "The Hound Dog" vs "Hound Dog". [[User:Ath|Ath]] 14:27, 12 August 2010 (UTC)
| |
| − | *Descriptions for the items would be very much appreciated. [[User:Netham45|Netham45]] 18:39, 10 October 2010 (UTC)
| |
| | | | |
| − | ===Things that should change in future versions of GetPlayerInventory===
| + | TF2Items: http://www.tf2items.com/profiles/76561198038762828 '''SUCCESS''' |
| − | *Ditch the "quantity" field. With a unique ID on the item, how can this be anything but 1? --[[User:STUART|STUART]] 04:22, 5 July 2010 (UTC)
| |
| − | *Separate the "inventory" field into an "inventory_slot" value and "equipped" object (with a "true" for each class the item is equipped for, and empty if no classes have the item equipped). This is a Web API: consumers shouldn't have to do binary operations to parse it. --[[User:STUART|STUART]] 04:22, 5 July 2010 (UTC)
| |
| − | *Add a "timestamp" field, similar to the GetGoldenWrenches method. This would be useful for statistics and curiosity of users. --[[User:AltPluzF4|AltPluzF4]] 11:44, 10 July 2010 (UTC)
| |
| | | | |
| − | ===Alternative WebAPI profile query methods===
| |
| − | *Allow developers to pass a vanity URL "ID" as an argument to the WebAPI or more easily convert a vanity URL to a SteamID64. The Steam Community XML feed breaks easily and does not properly sanitise community-side user input. (I.e. Non-UTF8 characters present in feed) [[User:Ath|Ath]] 23:18, 10 August 2010 (UTC)
| |
| − | : One thing you could do until this happens is just search for the tag without passing it to a full parser. It's less lines of code and works regardless of encoding on the rest of the page. This is what I do in steamodd, and this way you only have to rely on the tag name not changing. [[User:Lagg|Lagg]] 10:35, 11 August 2010 (UTC)
| |
| − | :: I make use of other parts of the XML too (May as well if I ''have'' to fetch it anyway :( ), so passing it to PHP's SimpleXML lib (through utf8_encode first) is simple and effective enough I find. Thanks for the suggestion though. [[User:Ath|Ath]] 14:27, 11 August 2010 (UTC)
| |
| − | :Another possible solution that'd remove the need for the community XML, would be to add an additional ?sid64=1 argument to community profiles, which would just returns the profile's SteamID64. This would be very useful if also applied to the community's Search page; But instead returning a comma-delimited list of the top-x results. This would greatly simplify profile discovery, and allow the XML to be deprecated in favour of GetPlayerSummaries. [[User:Ath|Ath]] 16:58, 25 November 2010 (UTC)
| |
| | | | |
| − | ===Backpack size discovery===
| + | ''ValueError: Invalid control character at: line 766 column 44 (char 12881)'' |
| − | *With the introduction of backpack extenders the size of an individual's backpack is not certain; An attribute declaring the total number of pages would be helpful in simply returning only those pages that are available to the end-user. ~ [[User:Ath|Ath]] ([[User_talk:Ath|talk]]) 15:58, 19 December 2010 (UTC)
| |
| − | : We know that they extend it by 100 cells, this is enough to pad if the position of an item is greater than the default size you set. -- [[User:Lagg|Lagg]] [[File:Backpack_Stickybomb_Launcher.png|24px|link=User_talk:Lagg]] 16:00, 19 December 2010 (UTC)
| |
| − | :: The most logical way to do this is find the item with the highest position in the persons backpack. Then you know how many pages there are, with the added bonus of not having to show all 10 pages if the user isn't using the last few. :) --[[User:Pc Madness|Pc Madness]] 16:15, 19 December 2010 (UTC)
| |
| − | ::: For accuracy I would prefer to display the number of pages that actually exist vs those that are used; This both reflects the behaviour of the actual backpack, and provides an end-user with an overview of how much room they/the owner actually has. ~ [[User:Ath|Ath]] ([[User_talk:Ath|talk]]) 16:40, 19 December 2010 (UTC)
| |
| − | :::: We can "guess" how many pages the player has, but it would be much better if the API provide such data. --[[User:TheJCS|TheJCS]] 01:59, 21 December 2010 (UTC)
| |
| | | | |
| − | ===Inline gift metadata===
| + | http://i.imgur.com/5o6C9.png |
| − | *To my current understanding, date and the gift giver's SteamID64 are encoded into attributes 185 and 186 on gifted items; requiring a secondary API query to retrieve the gifter's name. Could this information be provided inline? ~ '''[[User:Ath|Ath]]''' ([[User_talk:Ath|talk]]) 04:01, 25 January 2011 (UTC)
| |
| | | | |
| − | ==Problems==
| |
| | | | |
| − | === Breaking GetPlayerItems Bug ===
| + | I hope this is the last error I find. |
| | | | |
| − | With certain backpacks (for example, 76561197967454254, one of the PCGamer employees) there appears to be a floating point error inserted into attribute values without being checked before hand. This results in invalid JSON that most parsers will fail on.
| + | [[User:Base1024|base1024]] 04:51, 27 May 2012 (PDT) |
| | | | |
| − | Example:
| + | == Unexpected SOH character in Russian custom item name == |
| − | <pre>
| |
| − | {
| |
| − | "defindex": 127,
| |
| − | "value": 4294967294,
| |
| − | "float_value": -1.#QNAN0
| |
| − | },
| |
| − | </pre> -- [[User:Lagg|Lagg]] [[File:Backpack_Stickybomb_Launcher.png|24px|link=User:Lagg]] 09:43, 10 November 2010 (UTC)
| |
| | | | |
| − | :Oh joy. Glad to see serious issues like negative IDs were fixed though! [[User:Ath|Ath]] 19:42, 10 November 2010 (UTC) | + | Backpack in question: 76561198045241951 |
| | | | |
| − | :: The next update fixes this by not providing a float_value for values that are invalid. Long term I intend to provide more useful output for attributes than their raw value, especially in the case of particle effects like this one. [[User:Joe|Joe]] 23:33, 17 November 2010 (UTC)
| |
| | | | |
| − | === Invalid Encoding in Certain Item Names, Descriptions, Personas, and Real Names ===
| + | TF2B: http://tf2b.com/tf2/76561198045241951 '''FAILED''' |
| | | | |
| − | It appears that custom item names, descriptions, and community profile names and personas (and probably anything else that takes user input) isn't being sanitized before the JSON is generated. Invalid character encoding is also invalid JSON. -- [[User:Lagg|Lagg]] [[File:Backpack_Stickybomb_Launcher.png|24px|link=User:Lagg]] 19:50, 10 November 2010 (UTC)
| + | OPTF2: http://optf2.com/tf2/user/76561198045241951 <del>'''FAILED'''</del> '''SUCCESS (Thanks)''' |
| − | : If you see an example of an account with a custom item name or description that's broken in this way, please post it here. I believe that there's a bug in our encoding of names somewhere, I just need a repro case. [[User:Joe|Joe]] 23:31, 17 November 2010 (UTC)
| |
| − | :: Joe, would it be possible for you to grant either myself or Lagg a name/desctag to attempt to repro this? I had a report of an effected profile, but it's no longer exhibiting any issues. Thanks. [[User:Ath|Ath]] 23:35, 17 November 2010 (UTC)
| |
| − | ::: Hmm, is there anything that can be done about the characters being used by this guys backpack? 'TomasMarijanovic' It results in invalid JSON, even though it appears to be valid UTF8. He's got a backwards character in there as well which has some nasty side effects: http://www.tf2items.com/id/TomasMarijanovic hover over the Headtaker on page 2. --[[User:Pc Madness|Pc Madness]] 05:21, 25 November 2010 (UTC)
| |
| − | :::: Fantastic, I've been looking for a live example for a while now. It looks like an invalid control character in his headtaker's description. I don't think I'm going to work around this one. -- [[User:Lagg|Lagg]] [[File:Backpack_Stickybomb_Launcher.png|24px|link=User_talk:Lagg]] 13:50, 25 November 2010 (UTC)
| |
| − | ::::: Ah ha! I'll cull control characters from the names and descriptions. Thanks for the example. -- [[User:Joe|Joe]] 19:38, 26 November 2010 (UTC)
| |
| − | :::::: The fix for this is live now. Please let me know if you see any other examples of invalid encoding on names. -- [[User:Joe|Joe]] 00:22, 3 December 2010 (UTC)
| |
| − | ::::::: Think I've got an example of more invalid characters in JSON. TF2B isn't getting any output from json_decode() @ http://tf2b.com/?id=yeszz&debug=1 and Community profile @ http://steamcommunity.com/id/yeszz. According to the account owner the description for his Sticky Launcher "glitched out" and was replaced by various symbols. [[User:Ath|~~ Ath]] 00:17, 4 December 2010 (UTC)
| |
| − | :::::::: It looks like that name is parsing fine in some JSON parsers. Are you getting any errors or exceptions from json_decode()? (If the account owner files a support ticket about the glitched name he can get it fixed.) -- [[User:Joe|Joe]] 17:56, 21 December 2010 (UTC)
| |
| − | ::::::::: I'm seeing an error in optf2's logs as well. There's an invalid unicode character in it. What parser are you using, Joe? It should fail proper on invalid encodings. It appears that the problematic description is on 165438789. -- [[User:Lagg|Lagg]] [[File:Backpack_Stickybomb_Launcher.png|24px|link=User_talk:Lagg]] 20:45, 21 December 2010 (UTC)
| |
| − | :::::::::: json_decode() uses a strict parser as far as I know so it'll be choking on the invalid Unicode character as Lagg stated. Is it okay to pass the Steam support recommendation back to the owner? Or would you prefer to examine the issue closer first? ~ [[User:Ath|Ath]] ([[User_talk:Ath|talk]]) 22:44, 21 December 2010 (UTC)
| |
| | | | |
| − | === List of Problematic Attributes ===
| + | TF2Items: http://www.tf2items.com/profiles/76561198045241951 '''SUCCESS''' |
| | | | |
| − | Please feel free to edit or correct this list if I missed anything (I want to keep it all here to be more visible to Joe) -- [[User:Lagg|Lagg]] [[File:Backpack_Stickybomb_Launcher.png|24px|link=User_talk:Lagg]] 03:57, 14 November 2010 (UTC)
| |
| | | | |
| − | ; Attributes with no description string
| + | ''ValueError: Invalid control character at: line 2233 column 37 (char 39047)'' |
| − | :27 [http://optf2.com/attrib_dump#alt-fire_disabled alt-fire disabled]
| |
| − | :29 [http://optf2.com/attrib_dump#alt-fire_is_vampire alt-fire is vampire]
| |
| − | :43 [http://optf2.com/attrib_dump#scattergun_no_reload_single scattergun no reload single]
| |
| − | :53 [http://optf2.com/attrib_dump#fire_retardant fire retardent]
| |
| − | :116 [http://optf2.com/attrib_dump#mod_soldier_buff_type mod soldier buff type]
| |
| − | :117 [http://optf2.com/attrib_dump#dmg_falloff_increased dmg falloff increased]
| |
| − | :122 [http://optf2.com/attrib_dump#mod_demo_buff_type mod demo buff type]
| |
| − | :167 [http://optf2.com/attrib_dump#disguise_damage_reduction disguise damage reduction]
| |
| − | :183 [http://optf2.com/attrib_dump#aiming_movespeed_decreased aiming movespeed decreased]
| |
| − | :184 [http://optf2.com/attrib_dump#duel_loser_account_id duel loser account id]
| |
| − | :189 [http://optf2.com/attrib_dump#elevate_quality elevate quality]
| |
| − | ; Attributes with undefined description_string
| |
| − | :192 [http://optf2.com/attrib_dump#referenced_item_id_low referenced item id low]
| |
| − | :193 [http://optf2.com/attrib_dump#referenced_item_id_high referenced item id high]
| |
| − | ; Attributes with incorrect description strings
| |
| − | :195 [http://optf2.com/attrib_dump#always_tradable always tradable]
| |
| − | :196 [http://optf2.com/attrib_dump#noise_maker noise maker]
| |
| − | :144 [http://optf2.com/attrib_dump#lunchbox_adds_minicrits lunchbox adds minicrits]
| |
| − | ; Attributes attached to items they shouldn't be attached to
| |
| − | :144 [http://optf2.com/attrib_dump#lunchbox_adds_minicrits lunchbox adds minicrits] (attached to the [[GRU]]) | |
| | | | |
| − | :: The behavior on referenced_item_id_* is intentional. These are hidden attributes, so they don't have a description. Some of the others that have the wrong descriptions are also hidden and need their descriptions removed. The next webAPI update (which will happen soon) adds the hidden flag to what is provided for attributes, so it's easier to detect these attributes. I'll look at the others. -- [[User:Joe|Joe]] 22:20, 15 November 2010 (UTC)
| + | http://i.imgur.com/RKud0.png |
| − | ::: Great, but I strongly suggest setting description_string to null or an empty string on those attributes. Otherwise I need to mark it as optional in the docs. -- [[User:Lagg|Lagg]] [[File:Backpack_Stickybomb_Launcher.png|24px|link=User_talk:Lagg]] 01:46, 16 November 2010 (UTC)
| |
| − | :::: These are fixed as of the next update. Hidden attributes now never return a description_string or description_format field. I'll update the docs to reflect that when the update goes live. There are still a couple of unused attributes (alt-fire disabled and alt-fire is vampire, for instance) that don't have strings. If we ever use them for anything they will get strings at that point. [[User:Joe|Joe]] 23:29, 17 November 2010 (UTC)
| |
| − | ::::: Alright, most of these appear to be fixed but some of the hidden/unused ones still have the description token there instead of being empty. It doesn't matter at this point though since we have the hidden flag now (Many thanks, Joe). However the GRU still have the minicrit attribute attached, not sure if this is intentional (See [http://optf2.com/attrib_dump?att=lunchbox+adds+minicrits here]). -- [[User:Lagg|Lagg]] [[File:Backpack_Stickybomb_Launcher.png|24px|link=User_talk:Lagg]] 02:53, 20 November 2010 (UTC)
| |
| − | :::::: It's intentional. The name is poor, but since the attributes are hidden and the name never shows up anywhere but the webapi it hasn't been a big priority to change. [[User:Joe|Joe]] 02:54, 20 November 2010 (UTC)
| |
| | | | |
| − | ===Versioning===
| + | [[User:Base1024|base1024]] 05:12, 27 May 2012 (PDT) |
| − | What's the point of having the potential for versioning (e.g. GetSchema/'''v0001''') if it's not used? The recent update (November 20) removed description_format and desciprion_string from a whole handful of attributes, in turn breaking my iOS application. I was saving data out to [http://developer.apple.com/library/ios/#documentation/Cocoa/Conceptual/CoreData/cdProgrammingGuide.html#//apple_ref/doc/uid/TP30001200-SW1 Core Data] and had the description format and description string as required attributes for the backpack item attribute. Missing required attributes caused the application to crash when saving the data. This has since been patched and the fix has been uploaded to the App Store, but typical review times are a week. I've requested an expedited review, but nonetheless the latest API update broke my application which was essentially using the API in the way it was intended. Please version major changes such as removal of fields (or making them optional), or at least provide some advance warning. [[User:Netshroud|Netshroud]] 07:48, 21 November 2010 (UTC)
| |
| − | : I didn't roll the version number because I didn't consider the changes significant enough to warrant a version number change. I underestimated the impact they would have, obviously. Almost all of the API changes so far have been additional fields, so it hasn't been a problem.
| |
| − | : What do other people using the webapi think about version number changes? Would you like to see updates roll the version number every time and leave the old version in place for a while? (At least for updates that change the web api. That's many of them, but not all of them.)
| |
| − | : The safest way to use this (or any other web api for that matter) would be to treat most fields as optional. Particularly fields in attribute types and item types are likely to be present on only some types. That advice is a little too late to be helpful in this case though.
| |
| − | : [[User:Joe|Joe]] 18:23, 23 November 2010 (UTC)
| |
| − | :: I never saw a point to versioning the requests in the first place, it just makes it to where I will have to maintain documentation for different versions when they happen. It's true that anyone using a web API should assume that all fields will be missing. I would be for getting rid of the versioning entirely. -- [[User:Lagg|Lagg]] [[File:Backpack_Stickybomb_Launcher.png|24px|link=User_talk:Lagg]] 02:31, 24 November 2010 (UTC)
| |
| − | :::I see no reason for having versioning, if there are major changes inbound then to my mind all that is really necessary is adequate fore-warning. It may be useful however to have additional "versions" for certain tasks; a Beta feed and a feed that just returns an example backpack with every possible significant item variation for example. It would be helpful in aiding development/testing of new content/features/changes. [[User:Ath|Ath]] 03:00, 24 November 2010 (UTC)
| |
| | | | |
| − | ::::I like the idea of versioning. Nothing more annoying than finding out that your site / program has broken majorly due to a change. With versioning we can continue using the stable feed until we can make our projects compatible with the latest version. Although I'd only use it for major changes / deleting important things, not much point in increasing the version number for simple changes. I think the attribute changes would probably qualify as major. --[[User:Pc Madness|Pc Madness]] 13:00, 24 November 2010 (UTC) | + | : Hmm, I've known about this error for some time now but it looks like I misjudged where it actually was, and thought that it was fixed in optf2 for quite a long time, as did Athernar. This also happens with some english names that have certain non-ASCII characters in them if I recall correctly. So stuff that does strict encoding will fail on it. Well, at least now that '''FAILED''' for optf2 can be turned into '''SUCCESS'''. Thanks for providing me a real reproduction. -- [[User:Lagg|Lagg]] [[File:Backpack_Stickybomb_Launcher.png|24px|link=User_talk:Lagg]] 15:48, 27 May 2012 (PDT) |
| − | :::::The three methods we provide for TF2 are simple enough that versioning hasn't really come into play. If we ever add methods that do more complex things, it is much more likely that we will need to roll the version number for changes. There is really only one argument for each method at the moment (not counting the format type.)
| |
| − | :::::Next time I'm removing something I will definitely be more careful.
| |
| − | :::::[[User:Joe|Joe]] 19:44, 24 November 2010 (UTC)
| |
| | | | |
| − | ===Values=== | + | == Date/Time of when the item was acquired? Also, ResolveVanityURL == |
| − | float_value never matches value. In some cases (e.g. Mann Co. Supply Crates), float_value is correct and value is completely wrong. In other cases (e.g. Employee Badges), value is correct and float_value is way out. [[User:Netshroud|Netshroud]] 07:48, 21 November 2010 (UTC)
| |
| − | : float_value is the bit pattern in value interpreted as a float. They will only match if the value is 0. When the storage for attributes changed from floating point to int not all of the attributes came along for the ride, so things are little confusing. [[User:Joe|Joe]] 18:26, 23 November 2010 (UTC)
| |
| | | | |
| − | ===GetSchema Icons===
| + | Heres a suggestion: On each item in GetPlayerItems, it could also return the timestamp of when that item was found/bought/traded/otherwise appeared in the users' inventory. |
| − | The icon for the Carouser's Capotain is still the pre-Dec 2nd version, could this be updated? Thanks. [[User:Ath|Ath]] 03:42, 3 December 2010 (UTC)
| |
| − | : Fixed. I also uploaded all the icons for the TF2 public beta just in case anyone is using the webapi for that app. [[User:Joe|Joe]] 20:26, 3 December 2010 (UTC)
| |
| − | :: Thanks for the fix, the 128 version still seems not to be updated for me however; inquisitor_large.png is updated however. [[User:Ath|Ath]] 22:44, 3 December 2010 (UTC)
| |
| − | ::: Looks correct to me. It may take a little time to propagate the update through the CDN, so it might be minutes to hours before you see the update. -- [[User:Joe|Joe]] 22:59, 3 December 2010 (UTC)
| |
| − | :::: Ah, good to know. Thanks Joe. [[User:Ath|Ath]] 23:08, 3 December 2010 (UTC)
| |
| − | ::::: festive_crate.png and festive_crate_large.png are both absent, could these be added? Thanks. ~ [[User:Ath|Ath]] ([[User_talk:Ath|talk]]) 15:56, 11 December 2010 (UTC)
| |
| | | | |
| − | The Gunboats icon[http://media.steampowered.com/apps/440//icons/c_rocketboots_soldier.png] is bigger than the other icons, it should be cuted like the others. [[User:TheJCS|TheJCS]] 2:08, 21 December 2010 (UTC)
| + | This would allow people to check when an item was found and also could be used to make visual graphs about a users' item drops. |
| | | | |
| − | The Paint icons are all the same brown one. They should show the actual color of the paint, like in game. [[User:TheJCS|TheJCS]] 2:11, 21 December 2010 (UTC)
| + | Also, I don't see the point behind ResolveVanityURL. Why have it as a separate method? It just means that I have to query the API twice whenever I have a vanity URL, which slows things down quite significantly (when you're from Australia with ~250ms ping to api.steampowered.com, this makes a difference.) Why not just have a separate field in most things, so you either have to supply the SteamID or the vanity URL? |
| − | : The paint icons are all generated in game, you have to create those images manually. --[[User:Pc Madness|Pc Madness]] 17:42, 21 December 2010 (UTC)
| + | If thats not possible, you could also adjust ResolveVanityURL to take a list of vanity strings -- something like GetPlayerSummaries but with a list of vanity URLs instead. |
| − | :: Since they are different items, the API should provide different images. [[User:TheJCS|TheJCS]] 4:54, 23 December 2010 (UTC)
| |
| − | ::: It's not overly difficult to create these in the same manner as the game itself does. Since the color is provided, just snag the overlay image from the gcfs (or [http://tf2stats.net/static/images/items/original/paintcan_paintcolor.png here]) and use GD or ImageMagick to color them. Here's the code I use, though there might be a cleaner way:
| |
| − | $i = new Imagick('path/to/paintcan.png');
| |
| − | $p = new Imagick('path/to/paintcan_paintcolor.png');
| |
| − | $m = $p->clone();
| |
| − | $c = new Imagick();
| |
| − | $c->newImage(500,500,'#'.dechex($paintcolor));
| |
| − | $c->compositeImage($m,imagick::COMPOSITE_COPYOPACITY,0,0);
| |
| − | $p->compositeImage($c,imagick::COMPOSITE_MULTIPLY,0,0);
| |
| − | $i->compositeImage($p,imagick::COMPOSITE_DEFAULT,0,0);
| |
| − | [[User:FireSlash|FireSlash]] 20:16, 24 December 2010 (UTC)
| |
| − | :::: As far as I know part of the idea behind providing the icons via GetSchema was to remove the need for local storage of icons; Having to individually process or implement a system to obtain the tinted variants defeats the point somewhat. I think it's a fair request to ask for the variants to be provided. ~ [[User:Ath|Ath]] ([[User_talk:Ath|talk]]) 22:31, 24 December 2010 (UTC)
| |
| − | ::::: I think it's a fair request too. It just hasn't made it to the top of my TODO list yet. -- [[User:Joe|Joe]] 19:46, 27 December 2010 (UTC)
| |
| | | | |
| − | ===Unlocking Poker Night Items===
| + | my two cents [[User:Pigophone|Pigophone]] 03:04, 27 April 2013 (PDT) |
| − | Quick question, but when you unlock a poker night item they never appear in the item feed until you start up TF2, which informs you that you have new items waiting for you. Is this a bug or are those Poker guys just doing some dodgy method of adding items to your backpack (perhaps checking if an achievement has been unlocked when TF2 is loaded?) --[[User:Pc Madness|Pc Madness]] 12:12, 7 December 2010 (UTC)
| |
| − | :I'm pretty sure when you start up TF2 is checks for a Poker Night save file to see if you have unlocked the items. If so, it grants you them. It's not a bug, it's just how it works. People have actually taken advantage of this to unlock the items without playing the game by simply logging in on a computer that has Poker Night and has unlocked the items. -- [[Image:User Alex2539 Sig.png|47px|link=User:Alex2539|Alex2539]] - {{mod}} <sub>([[User_talk:Alex2539|talk]] | [[Special:Contributions/Alex2539|contribs]])</sub> -- 12:26, 7 December 2010 (UTC)
| |
| − | :: The item backend asks Steam for this stuff when you start up TF2. You will get your items even if you're on a computer that doesn't have Poker Night installed as long as you're logged into the steam account where you earned the Poker Night achievements. How those achievements get unlocked is a question for TellTale. :) -- [[User:Joe|Joe]] 17:36, 21 December 2010 (UTC)
| |
| | | | |
| − | ===Reason for being Untradable===
| + | : I agree with the timestamp. That would certainly be nice. As for the vanity resolver it was mostly a compromise between myself, Joe, and Athernar and possibly some other authors. For one reason or another they wouldn't write something to give vanity URLs directly to the methods. It's mostly to stop people from having to make requests to steamcommunity.com/id/whatever to get the id64s. So compared to that it's fantastic. One of the reasons gave for not just allowing the vanity url and id64 in the same parameter was ambiguity since people can make their vanity urls the same as someone's id64. Your suggestion for different parameters would work. But it'd be so much easier for them to just not allow people to do that and do the vanity resolves themselves since their database access is almost certainly going to be faster than a request. -- [[User:Lagg|Lagg]] [[File:Backpack_Stickybomb_Launcher.png|24px|link=User_talk:Lagg]] 03:55, 27 April 2013 (PDT) |
| − | If it's not to much trouble, could we get the reason why an item isn't tradable? From what I've seen in game theres - Achievement Item, Purchased Item, Store Item, Promotion Item. Not really important but would be handy. :) --[[User:Pc Madness|Pc Madness]] 12:12, 7 December 2010 (UTC)
| |
| − | : At one point these flags were available (see my edit in the log that added the documentation for them), but for some reason they were removed shortly after. -- [[User:Lagg|Lagg]] [[File:Backpack_Stickybomb_Launcher.png|24px|link=User_talk:Lagg]] 12:58, 7 December 2010 (UTC)
| |
| | | | |
| − | ===Another missing image=== | + | == Inconsistent group IDs == |
| − | The Prancer's Pride images are 404ing. -- [[User:Netshroud|<span style="color:rgb(78, 71, 63); font-family:'TF2 Build', sans-serif;">Netshroud</span>]] [[File:Killicon_backstab.png|22px|link=User:Netshroud]] <small>([[User_talk:Netshroud|talk]] | [[Special:Contributions/Netshroud|contribs]])</small> 00:48, 19 December 2010 (UTC)
| |
| − | : The case is wrong. It works from here [http://media.steampowered.com/apps/440/icons/prancers_pride.png]. I'll get the GetSchema results fixed up. -- [[User:Joe|Joe]] 17:41, 21 December 2010 (UTC)
| |
| − | ::The icons for the three new MNC items and the Nasty weapons bundle are currently absent. ~ '''[[User:Ath|Ath]]''' ([[User_talk:Ath|talk]]) 03:56, 25 January 2011 (UTC)
| |
| − | ::: Fixed. [[User:Joe|Joe]] 17:04, 25 January 2011 (UTC)
| |
| − | :::: We're currently missing the Hachimaki and the three new map stamps. ~ '''[[User:Ath|Ath]]''' ([[User_talk:Ath|talk]]) 01:35, 1 March 2011 (UTC)
| |
| | | | |
| − | === Gift Content Randomly Disappearing ===
| + | There's a problem with retrieving group IDs via the web API. If you use <code>ISteamUser/GetUserGroupList/v1</code> to get the user's groups, each group entry contains a <code>guid</code> which is supposedly the 64-bit ID of the group. '''But''', if you call <code>ISteamUser/GetPlayerSummaries/v0002/</code> with the same user ID, the group ID you get in <code>primaryclanid</code> is marginally bigger than any other ID <code>GetUserGroupList</code> gave you. When you go and check the group's page for links that contain the ID, like the "Invite Friends" link, you see the bigger group ID is the correct one. |
| | | | |
| − | Joe, would it be possible to make gift content visible before the gift drops in the backpack? I've also seen some cases where the gift contents dict isn't generated at all and then will reappear again later even if it is already dropped. Naturally this has been causing problems for those that trade because optf2 falls back to the schema ID attribute if it can't find the afore mentioned dict. -- [[User:Lagg|Lagg]] [[File:Backpack_Stickybomb_Launcher.png|24px|link=User_talk:Lagg]] 22:27, 29 January 2011 (UTC)
| + | Basically, it looks like <code>ISteamUser/GetUserGroupList/v1</code> returns older "32-bit" Steam IDs while <code>primaryclanid</code> inside <code>ISteamUser/GetPlayerSummaries/v0002/</code>'s data appears to be a correct, 64-bit Steam ID. [[User:Smiley|Smiley]] ([[User talk:Smiley|talk]]) 16:06, 16 September 2013 (PDT) |
| − | : I don't understand what you're asking. Is the item not dropping when unwrapping a gift, or is the item API just returning something unexpected? [[User:Joe|Joe]] 02:07, 1 February 2011 (UTC)
| + | : It's not really a matter of which ID is new or old. The smaller (32 bit) ones are merely condensed versions of the 64 bit ones which for the most part have static bits. It's an optimization choice on the part of valve since naturally it saves space when sending packets (it seems silly but in practice those 4 bytes really add up when sending out UDP packets). Getting a 64 bit ID is merely a matter of taking the most significant 32 bits of a given 64 bit group ID and ORing those on to the condensed group ID (note that these might be 33 bits long, I can't remember at the moment if the group ID width can be the same as a user). -- [[User:Lagg|Lagg]] [[File:Backpack_Stickybomb_Launcher.png|24px|link=User_talk:Lagg]] 17:01, 16 September 2013 (PDT) |
| − | :: The API isn't returning what is expected. I can confirm that contained_item isn't present when the gift hasn't been dropped in the backpack proper, and it also disappears when it is in the backpack which I can't reliably reproduce, but [http://optf2.com/item/234035656?contents=1 here] is a gift that at the time of this edit had no contained_item field. Other times it does. I apologize for it being hard to understand but I'm having trouble figuring it out myself. -- [[User:Lagg|Lagg]] [[File:Backpack_Stickybomb_Launcher.png|24px|link=User_talk:Lagg]] 04:49, 1 February 2011 (UTC)
| |
| − | :::To clarify, the contained_item is consistently never present when the gift hasn't been dropped (when it's in the "waiting to drop" queue). Once it drop in the backpack, its contained_item sometimes disappears. <!-- Also that's my hat :o --> — [[User:WindPower|<span style="font-weight:bold;">Wind</span>]] 04:53, 1 February 2011 (UTC)
| |
| − | :::: Something strange is going on with some small percentage of gifts losing their connection to the wrapped item. (The one you linked is one of those.) It sounds like you guys have seen a contained item exist for a while and then go away, but I don't know how that would happen. Is that definitely what you're seeing? [[User:Joe|Joe]] 19:45, 1 February 2011 (UTC)
| |
| − | ::::: Yes, without a doubt. -- [[User:Lagg|Lagg]] [[File:Backpack_Stickybomb_Launcher.png|24px|link=User_talk:Lagg]] 19:52, 1 February 2011 (UTC)
| |
| − | :::::: Curiouser and curiouser. Do you know what time the contained item disappeared, approximately? [[User:Joe|Joe]] 20:06, 1 February 2011 (UTC)
| |
| − | ::::::: I believe it reappeared about 2 hours after I linked to the gift but beyond that I can't say. I considered writing something to run every few minutes and check if the field is disappearing again. I can do this if it would help. -- [[User:Lagg|Lagg]] [[File:Backpack_Stickybomb_Launcher.png|24px|link=User_talk:Lagg]] 20:09, 1 February 2011 (UTC) | |
| − | :::::::: Alright the problem is showing itself again and I grabbed some API output and screenshots. The approximate time it disappeared when it was actually in my backpack was 00:31 UTC. [http://optf2.com/item/249152666?contents=1 here] is the direct link and [http://agg.optf2.com/contained-item-bug/ here] is a dir with the screenshots and API dumps. Note how it was present in afterdrop.png but not in beforedrop.png, when I was sent the gift but did not start the game to get it, and then later when I took postdrop.png it disappeared again while the gift was in my backpack. -- [[User:Lagg|Lagg]] [[File:Backpack_Stickybomb_Launcher.png|24px|link=User_talk:Lagg]] 01:40, 15 February 2011 (UTC)
| |
| − | :::::::: Also correct me if I'm wrong but it appears that the backpack specific attributes don't appear either (the medal number attribute in this case). I can provide a dump of the box's contained_item that shows this if needed. -- [[User:Lagg|Lagg]] [[File:Backpack_Stickybomb_Launcher.png|24px|link=User_talk:Lagg]] 21:42, 15 February 2011 (UTC)
| |
| | | | |
| − | === Steam ID === | + | == Content of crates == |
| − | Due to the way Steam IDs work, both [http://steamcommunity.com/profiles/76561197989867376 76561197989867376] and [http://steamcommunity.com/profiles/76561202284834672 76561202284834672] point to my user - the latter having m_unAccountInstance set to 2 instead of 1. ISteamUser/GetPlayerSummaries will return the correct information for both, but ITFItems_440/GetPlayerItems and ITFItems_520/GetPlayerItems return error code 8 (SteamID parameter was missing) instead of the proper (or an empty) backpack, or an appropriate error code. Probably nobody will actually run into this issue, but I figured I should mention it anyway. -- [[User:Netshroud|{{TF2B|text = Netshroud | quality = unusual | size = 13px}}]] [[File:Killicon_backstab.png|22px|link=User:Netshroud]] <small>([[User_talk:Netshroud|talk]] | [[Special:Contributions/Netshroud|contribs]])</small> 01:14, 1 March 2011 (UTC)
| |
| | | | |
| − | [[Category:Valve]] | + | Any way to get a list? The schema only stores the names. [[User:Klenium|Klenium]] ([[User talk:Klenium|talk]]) 14:35, 22 November 2013 (PST) |
| − | [[Category:WebAPI|Feedback]] | |
 | Please use this page for reporting and discussing possible issues or inconsistencies with the API documentation or API itself. This is not for learning how to properly use one. |
Dota 2 — item rarity
Can you add item rarity (not quality) to the GetSchema API call? It`s very strange to not present rarity here. There is only quality now, but it is useless for Dota 2. --Ohar (talk) 03:52, 30 October 2013 (PDT)
Improperly formed JSON float_values for decal attributes - still not resolved
http://wiki.teamfortress.com/wiki/Talk:WebAPI/Feedback/Archive_3 has the previous thread. I'm still receiving the improperly formed JSON :( Just FYI - thanks! VMDX 14:37, 21 November 2011 (PST)
- Alright I've been on the lookout for this regression on my own logs for optf2 and asking around. I cannot find any reproductions. Care to give an id64 that exhibits this problem? -- Lagg
22:05, 30 November 2011 (PST)
- ex: in 76561198005981351 : "attributes": [ { "defindex": 152, "value": 1879034420, "float_value": 158326252166124510000000000000. }, { "defindex": 227, "value": 117757579, "foat_value": 0.000000 } ]
- Some json decoders break because the number doesn't have the 0 after the dot. I don't see this happen in PHP but I've heard others having this problem Ruiner 21:02, 22 April 2012 (PDT)
- Yep I've spoken to an employee about it and they said they'll look into it tomorrow. Apologies for not noting this on the talk page sooner. -- Lagg 21:15, 22 April 2012 (PDT)
Painted items
I noticed that the steam community inventory viewer has images with paints embedded in them. Would it be possible for the backpack items to include the encoded URL for the image with paint.
ex: with paint -- Ruiner 07:13, 25 February 2012 (PST)
custom texture lo - Invalid JSON
I had another talk with Drunken. This is the relevant part of his response on the matter. I'll be giving a language-independent workaround in a while if time permits.
1:34 PM - Drunken F00l: I know why it's printing bad values, yes
1:34 PM - Drunken F00l: it's just truncating
1:35 PM - Drunken F00l: I'll get it fixed but the fix probably won't ship until next week
-- Lagg 16:10, 23 April 2012 (PDT)
- Here is a temporary workaround for the problem, as promised. This call is for python's re module but should be similarly easy to modify as needed for basically any regex implementation out there. What the expression is doing is searching for a line with 0 or more characters of whitespace at the beginning, followed by the normal float_value key and then an arbitrary length integer followed by a decimal point and non-decimal character. The part of the string preceding the decimal point is captured and reinserted into a string suffixed with '.0'. I hope you find it useful.
re.sub('(\s*"float_value": -?\d+)\.[^\d]', '\\1.0', obj) -- Lagg 21:08, 23 April 2012 (PDT)
- Fixed a small bit of the regexp. I'll let my commit message describe what the change was since it does it best: Because apparently I thought that the bug was choosy about what side of a 0 it appears on. -- Lagg 08:48, 24 April 2012 (PDT)
- replace(".\n",".0\n") base1024 12:35, 24 April 2012 (PDT)
- Keeping in mind that this will break on caching/minifying proxies -- Lagg 12:37, 24 April 2012 (PDT)
Item Origin
Item origin is buggy and/or incorrect. For example, many Bill's Hats are showing as timed drop. This was a promotional item and should be marked as such. There is also an origin flag "traded", but it's not clear when that attribute is used: Traded items usually do not acquire the origin to be set as "traded". For example, store purchased keys will keep their store purchased after being traded. My suggestion would be to make the item origin cumulative. If an item was purchased, then traded, it should be possible to tell what the original origin was, as well as the current origin. This way, we can tell in a user's inventory if the item has ever been traded, or if he is the original owner.
-- Ruiner 18:48, 24 April 2012 (PDT)
Unexpected EOT character in Chinese (zh-tw) custom item name
Backpack in question: 76561198038762828
TF2B: http://tf2b.com/tf2/76561198038762828 FAILED
OPTF2: http://optf2.com/tf2/user/76561198038762828 FAILED SUCCESS (Thanks)
TF2Items: http://www.tf2items.com/profiles/76561198038762828 SUCCESS
ValueError: Invalid control character at: line 766 column 44 (char 12881)
I hope this is the last error I find.
base1024 04:51, 27 May 2012 (PDT)
Unexpected SOH character in Russian custom item name
Backpack in question: 76561198045241951
TF2B: http://tf2b.com/tf2/76561198045241951 FAILED
OPTF2: http://optf2.com/tf2/user/76561198045241951 FAILED SUCCESS (Thanks)
TF2Items: http://www.tf2items.com/profiles/76561198045241951 SUCCESS
ValueError: Invalid control character at: line 2233 column 37 (char 39047)
base1024 05:12, 27 May 2012 (PDT)
- Hmm, I've known about this error for some time now but it looks like I misjudged where it actually was, and thought that it was fixed in optf2 for quite a long time, as did Athernar. This also happens with some english names that have certain non-ASCII characters in them if I recall correctly. So stuff that does strict encoding will fail on it. Well, at least now that FAILED for optf2 can be turned into SUCCESS. Thanks for providing me a real reproduction. -- Lagg 15:48, 27 May 2012 (PDT)
Date/Time of when the item was acquired? Also, ResolveVanityURL
Heres a suggestion: On each item in GetPlayerItems, it could also return the timestamp of when that item was found/bought/traded/otherwise appeared in the users' inventory.
This would allow people to check when an item was found and also could be used to make visual graphs about a users' item drops.
Also, I don't see the point behind ResolveVanityURL. Why have it as a separate method? It just means that I have to query the API twice whenever I have a vanity URL, which slows things down quite significantly (when you're from Australia with ~250ms ping to api.steampowered.com, this makes a difference.) Why not just have a separate field in most things, so you either have to supply the SteamID or the vanity URL?
If thats not possible, you could also adjust ResolveVanityURL to take a list of vanity strings -- something like GetPlayerSummaries but with a list of vanity URLs instead.
my two cents Pigophone 03:04, 27 April 2013 (PDT)
- I agree with the timestamp. That would certainly be nice. As for the vanity resolver it was mostly a compromise between myself, Joe, and Athernar and possibly some other authors. For one reason or another they wouldn't write something to give vanity URLs directly to the methods. It's mostly to stop people from having to make requests to steamcommunity.com/id/whatever to get the id64s. So compared to that it's fantastic. One of the reasons gave for not just allowing the vanity url and id64 in the same parameter was ambiguity since people can make their vanity urls the same as someone's id64. Your suggestion for different parameters would work. But it'd be so much easier for them to just not allow people to do that and do the vanity resolves themselves since their database access is almost certainly going to be faster than a request. -- Lagg 03:55, 27 April 2013 (PDT)
Inconsistent group IDs
There's a problem with retrieving group IDs via the web API. If you use ISteamUser/GetUserGroupList/v1 to get the user's groups, each group entry contains a guid which is supposedly the 64-bit ID of the group. But, if you call ISteamUser/GetPlayerSummaries/v0002/ with the same user ID, the group ID you get in primaryclanid is marginally bigger than any other ID GetUserGroupList gave you. When you go and check the group's page for links that contain the ID, like the "Invite Friends" link, you see the bigger group ID is the correct one.
Basically, it looks like ISteamUser/GetUserGroupList/v1 returns older "32-bit" Steam IDs while primaryclanid inside ISteamUser/GetPlayerSummaries/v0002/'s data appears to be a correct, 64-bit Steam ID. Smiley (talk) 16:06, 16 September 2013 (PDT)
- It's not really a matter of which ID is new or old. The smaller (32 bit) ones are merely condensed versions of the 64 bit ones which for the most part have static bits. It's an optimization choice on the part of valve since naturally it saves space when sending packets (it seems silly but in practice those 4 bytes really add up when sending out UDP packets). Getting a 64 bit ID is merely a matter of taking the most significant 32 bits of a given 64 bit group ID and ORing those on to the condensed group ID (note that these might be 33 bits long, I can't remember at the moment if the group ID width can be the same as a user). -- Lagg 17:01, 16 September 2013 (PDT)
Content of crates
Any way to get a list? The schema only stores the names. Klenium (talk) 14:35, 22 November 2013 (PST)
