|
|
(158 intermediate revisions by 25 users not shown) |
Line 1: |
Line 1: |
− | == Suggestions == | + | {{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.}} |
− | === Things that should be fixed in the Steam Web API system ===
| + | {{Archive list|archives = [[/Archive 1|1]] [[/Archive 2|2]] [[/Archive 3|3]]}} |
− | *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.
| |
| | | |
− | Short version: this
| + | [[Category:WebAPI|Feedback]] |
| | | |
− | "result": {
| + | == Dota 2 — item rarity == |
− | "status": 1,
| + | 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) |
− | "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:
| + | == Improperly formed JSON float_values for decal attributes - still not resolved == |
| | | |
− | "result": {
| + | 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) |
− | "status": 1,
| + | : 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) |
− | "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) | + | :: 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) |
| | | |
− | ===Methods that should be added to ITFItems_440=== | + | == Painted items == |
− | *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)
| |
− | *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)
| |
− | *A method that returns inventory images, or links to images. Currently the biggest hurdle of an update is digging all of the new data out of the tf2 gcfs. The three files at the moment are: items_game (partially covered by the GetSchema), tf_<lang> (Partially covered by GetSchema), and the backpack images (No solution). The images are also the most time consuming part. [[User:FireSlash|FireSlash]] 17:02, 5 July 2010 (UTC)
| |
− | ::Biggest hurdle? Extract tf/materials/backpack and run it through VTFEdit's batch converter. [[User:Netshroud|Netshroud]] 23:27, 5 July 2010 (UTC)
| |
− | :::As far as time consumption yes, since I also need tor resize and recompress images. items_game and tf_english are just a matter of extracting and uploading each file. Where in the images I have to sort through all the images in the gcf, dig out the new ones, extract convert resize and upload. If the images were available online, I could automate the process. [[User:FireSlash|FireSlash]] 00:58, 6 July 2010 (UTC)
| |
| | | |
− | ===Things that should be added to the next version of GetSchema===
| + | 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. |
− | *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)
| + | 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) |
− | *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=== | + | == custom texture lo - Invalid JSON == |
− | *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===
| + | 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. |
− | *Allow developers to pass a vanity URL "ID" as an arguement 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)
| + | <pre> |
− | : 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) | + | 1:34 PM - Drunken F00l: I know why it's printing bad values, yes |
− | :: 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)
| + | 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) |
| | | |
− | === Use these on the wiki? ===
| + | : 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) |
| | | |
− | Surely there must be a way to use these, they seem very cool. Namely the News and Percentage of achievements. Anyone able to figure out a way? -- [[User:Smashman|Smashman...]] <sub>([[User_talk:Smashman|t]] • <span class="plainlinks">[http://www.steamcommunity.com/id/smashman2004 s])</span></sub> 11:57, 2 July 2010 (UTC)
| + | :: 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) |
− | :Way ahead of you. Jeff has a list of things he would like to try, and he added WebAPI integration just for me! :D -- [[User:Pilk|Pilk]] <sub>([[User talk:Pilk|talk]])</sub> 23:10, 2 July 2010 (UTC)
| |
| | | |
− | === Numbered Gibus? === | + | ::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) |
| | | |
− | Not sure if this is a bug or not, but were the 10,000 Gibus's that were given away during the Halloween update numbered? I thought they were, but their numbers have never been included in the API. --[[User:Pc Madness|Pc Madness]] 18:35, 18 August 2010 (UTC)
| + | == Item Origin == |
− | : No, the only number they have is the serial number found in all non-common items. [[User:Lagg|Lagg]] 01:45, 19 August 2010 (UTC)
| |
| | | |
− | == Problems ==
| + | 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. |
− | ===GetSchema===
| |
− | I'm still seeing "TF_Unique_Achievement_FireAxe1" returned from GetSchema with language=en defined. --[[User:STUART|STUART]] 03:50, 5 July 2010 (UTC)
| |
− | : Indeed. It seems to do this for every achievement-unlockable weapon.--[[User:RJackson|RJackson]] 04:15, 5 July 2010 (UTC) | |
− | :: You can use the information files tf2_<language>.txt to pull the names of the items based on the name provided. e.g. TF_Unique_Achievement_Shield in tf2_english.txt = "The Chargin' Targe". Not a perfect system, but it will give you the in-game names. These files are in orangebox/tf/resource (from the directory in which the 'steam' binary is located). I agree though, bit of a pain in some ways to have to use local data, but as I said, it ensures consistency between in-game and what you see outside of it if you do it that way [[User:Swixel|Swixel]] 01:15, 9 July 2010 (UTC)
| |
− | ::: item_name now seems to be assigned the correct localised string, however "The" is excluded as well as the propername attribute. The addition of the propername attribute in the schema feed or just straight up prefixing "The" to the relevant names should solve the problem, propername is preferred however. [[User:Ath|Ath]] 21:27, 26 July 2010 (UTC)
| |
− | : This also happens with at least 1 attribute (#Attrib_Scattergun_NoReloadSingle) [[User:Lagg|Lagg]] 23:14, 15 July 2010 (UTC)
| |
| | | |
− | The Dalokohs Bar buff attribute and Crit-o-Cola minicrit attribute have the same description token. [[User:Lagg|Lagg]] 23:14, 15 July 2010 (UTC)
| + | -- [[User:Ruiner|Ruiner]] 18:48, 24 April 2012 (PDT) |
| | | |
− | "'''referenced id item low'''" and "'''referenced id item high'''" don't have description_string set. -- [[User:Lagg|Lagg]] [[File:Backpack_Stickybomb_Launcher.png|24px|link=User:Lagg]] 12:38, 31 October 2010 (UTC)
| + | == Unexpected EOT character in Chinese (zh-tw) custom item name == |
| | | |
− | Despite it being easy enough to use "Hat" when printing the item_type_name for non-misc. headwear, I think we should have a string for TF_Wearable_Hat to be consistent. [[User:Lagg|Lagg]] 03:02, 23 July 2010 (UTC)
| + | Backpack in question: 76561198038762828 |
| | | |
− | If its not to much trouble, could we get minilevel added back to GetSchema? If you're trying to display items on pages other than showing someones backpack (eg debug pages, crafting), you're forced to show them all as Level 1's. --[[User:Pc Madness|Pc Madness]] 17:31, 7 November 2010 (UTC)
| |
| | | |
− | ===GetGoldenWrenches===
| + | TF2B: http://tf2b.com/tf2/76561198038762828 '''FAILED''' |
− | What appears to be Wrench #74 (itemID 103444671, has a timestamp between #73 and #75) is listed with a "wrenchNumber" value of 76. --[[User:STUART|STUART]] 21:54, 8 July 2010 (UTC)
| |
| | | |
− | When using Yahoo Pipes to access the Wrench Info it displays all steam ids as 0 --[[User:ILOVEPIE|ILOVEPIE]] 03:18, 19 August 2010 (UTC)
| + | OPTF2: http://optf2.com/tf2/user/76561198038762828 <del>'''FAILED'''</del> '''SUCCESS (Thanks)''' |
| | | |
− | === Image assets ===
| + | TF2Items: http://www.tf2items.com/profiles/76561198038762828 '''SUCCESS''' |
− | Is Valve providing hosting for backpack image files anywhere? Or, if not, is anyone aware of a script for the extraction of image_inventory VTFs and conversion to PNG? Since this is a web API, I'm not sure how image_inventory is expected to be used without the image assets available. [[User:Maqr|Maqr]] 16:06, 11 July 2010 (UTC)
| |
− | : I don't think they're available, no. It would be nice if they were. Usually I extract the VTF's from the GCF and then convert to PNG with a Photoshop plugin.--[[User:RJackson|RJackson]] 16:08, 11 July 2010 (UTC)
| |
− | :: Fair enough. What plugin are you using and do you have it batched in some way? It'd be great if someone put together a downloadable archive with image names that matched image_inventory results. Also, do you think there are licensing issues with doing this? I'm not sure how strict Valve is. [[User:Maqr|Maqr]] 16:47, 11 July 2010 (UTC) edit: Nevermind, VTFEdit will convert entire folders :) [[User:Maqr|Maqr]] 19:20, 11 July 2010 (UTC)
| |
− | :I made a backpack viewer iPhone app (currently awaiting approval), but I just used VTFEdit's batch convert feature, then a small shell script to recursively rename *_large.png to *@2x.png
| |
− | :They are not available anywhere at the moment. I hope to change that someday. Until then, feel free to use the images from the GCF in any way permitted by the Steam Web API Terms of Use. [[User:Joe|Joe]] 01:34, 21 July 2010 (UTC)
| |
− | ::Backpack images for all items are now available. See the image_url and image_url_large fields in GetSchema. [[User:Joe|Joe]] 21:13, 30 July 2010 (UTC)
| |
− | :::Nice! Thanks Joe. -- [[User:Smashman|Smashman...]]{{bur}} <sub>([[User_talk:Smashman|t]] • <span class="plainlinks">[http://www.steamcommunity.com/id/smashman2004 s])</span></sub> 21:36, 30 July 2010 (UTC)
| |
− | ::::We really need to develop a plugin for this wiki that'll get the information from the API. That'd be most handy. -- [[User:Smashman|Smashman...]]{{bur}} <sub>([[User_talk:Smashman|t]] • <span class="plainlinks">[http://www.steamcommunity.com/id/smashman2004 s])</span></sub> 21:37, 30 July 2010 (UTC)
| |
− | ::: Joe, could you please fix the transparency on the _large images for Scrap Meta, Refined Metal and Reclaimed Metal? Thanks. [[User:Netshroud|Netshroud]] 02:24, 1 August 2010 (UTC)
| |
− | :::: Same problem with the Texas Slim's Dome Shine images, but the Scrap Metal ones appear to be fine. [[User:Lagg|Lagg]] 21:30, 2 August 2010 (UTC)
| |
− | ::::: The large images for refined and reclaimed metal are fixed. I'll try to get the hatless images fixed tomorrow. [[User:Joe|Joe]] 02:09, 3 August 2010 (UTC)
| |
− | :::::: The nohat images for scout, sniper, and engineer are fixed now too. Just leave a note here if you see any more backpack images with problems. [[User:Joe|Joe]] 21:56, 4 August 2010 (UTC)
| |
− | ::::::: Thanks Joe [[User:Lagg|Lagg]] 06:39, 5 August 2010 (UTC)
| |
− | ::::::: A couple more things: CheatDetectedMinor and CheatDetectedMajor have bogus image URLs, and <nowiki>http://media.steampowered.com/apps/440/icons/c_syringegun_large.png</nowiki> 404s. [[User:Netshroud|Netshroud]] 08:39, 12 August 2010 (UTC)
| |
− | :::::::: I wonder what should be set for pseudo-items like that in the future. Perhaps a transparent PNG? Removing the key altogether might break some code. [[User:Lagg|Lagg]] 18:54, 12 August 2010 (UTC)
| |
| | | |
− | Looks like the URL for the [[Lumbricus Lid]] is bad. [[User:Lagg|Lagg]] 20:39, 26 August 2010 (UTC)
| |
− | :: Joe, any chance we could get the [[Lumbricus Lid]], CheatDetectedMinor, CheatDetectedMajor and and <nowiki>http://media.steampowered.com/apps/440/icons/c_syringegun_large.png</nowiki> fixed? [[User:Netshroud|Netshroud]] 02:46, 26 September 2010 (UTC)
| |
| | | |
− | URL for [[Rimmed Raincatcher]] (<nowiki>http://media.steampowered.com/apps/440//icons/drinking_hat.png</nowiki>) appears to be broken.--[[User:Geit|Geit]] 07:55, 2 October 2010 (UTC)
| + | ''ValueError: Invalid control character at: line 766 column 44 (char 12881)'' |
− | : [http://optf2.com/item/from_schema/216 Fixed] [[User:Lagg|Lagg]] 21:51, 15 October 2010 (UTC)
| |
| | | |
− | === Ambassador, Lugermorph, Sydney Sleeper, Scottish Resistance, Eyelander, and Big Kill Names Are Wrong ===
| + | http://i.imgur.com/5o6C9.png |
| | | |
− | The Ambassador's localized name appears in the schema as "The Ambassador" rather than "Ambassador". [[User:Lagg|Lagg]] 18:48, 28 August 2010 (UTC)
| |
− | :It's that way for a lot of weapons, but we always remove the "The" from names — [[User:WindPower|<span style="font-weight:bold;">Wind</span>]] {{adm}} 20:40, 28 August 2010 (UTC)
| |
− | ::Er, if by "a lot" you mean just the Ambassador, Lugermorph, and Big Kill then yes it's that way for a lot of them. I think you're misunderstanding the problem though. Look at the "item_name" values in the schema and you'll see why it's wrong. Deciding whether to prefix "The", "Community", "Developer", etc. is something that should be left for the code using the API to decide. Updated the section name to reflect the other two weapons (just discovered these were wrong too). [[User:Lagg|Lagg]] 00:42, 29 August 2010 (UTC)
| |
| | | |
− | proper_name is progress, but all 4 of these are still wrong. proper_name should be false for these. [[User:Lagg|Lagg]] 00:37, 7 October 2010 (UTC)
| + | I hope this is the last error I find. |
− | :proper_name should be set to true for these items, the additional "The" present for these items in item_name however should be stripped out. I brought the lack of proper_name/propername to Robin's attention so I'll send him a follow-up email regarding these items and see what happens. [[User:Ath|Ath]] 01:26, 7 October 2010 (UTC)
| |
− | :: It is set to true, but if the extra "The " is there it should be false. I didn't think this required an explanation. [[User:Lagg|Lagg]] 01:34, 7 October 2010 (UTC)
| |
− | :: This also seems to be the case with the Eyelander and Scottish Resistance. [[User:Lagg|Lagg]] 01:57, 7 October 2010 (UTC)
| |
− | ::: The "The" prefix should be stripped from item_name and proper_name retained at a value of true. That's the entire point of proper_name, so the end-developer can just prepend the correct prefix rather than strip/replacing "The" for "A" as an example. I didn't think this required an explanation. [[User:Ath|Ath]] 02:03, 7 October 2010 (UTC)
| |
− | :::: So you would rather it be true and have "The " in it? I don't see your reasoning. Obviously "The " needs to be removed from the names but I was operating under the assumption Valve wouldn't change the names. They haven't since I first mentioned this more than a month ago after all. [[User:Lagg|Lagg]] 02:08, 7 October 2010 (UTC)
| |
− | ::::: I'd rather the items in question stick to the convention like all the others do in both the WebAPI and tf_english/items_game. tf_english does not have "The" present in it's definition for #TF_Unique_Achievement_StickyLauncher, so I don't see why it should be any different in the WebAPI. [[User:Ath|Ath]] 02:14, 7 October 2010 (UTC)
| |
− | :::::: So would I, and no it doesn't. I'm simply assuming that the names might not get changed (which isn't an unreasonable assumption). I too prefer the saner fix, don't get me wrong. [[User:Lagg|Lagg]] 02:21, 7 October 2010 (UTC)
| |
− | ::::::: So if you're simply assuming that they won't change the names (Which I agree could be viewed as a change beyond the purview of the current API version), why didn't you just say that to begin with? We could've avoided this messy arguement. Regardless, let us cease this discussion or take it elsewhere lest this get out of hand. [[User:Ath|Ath]] 02:31, 7 October 2010 (UTC)
| |
| | | |
− | === Abandoned Syringe Gun Images ===
| + | [[User:Base1024|base1024]] 04:51, 27 May 2012 (PDT) |
| | | |
− | The abandoned syringe gun's (index 33 in the schema) small image is 256x256 when it should be 128x128 like all the other images. The large image is 404.
| + | == Unexpected SOH character in Russian custom item name == |
− | Also, all 3 of the abandoned medic weapons have a quality of 255. Not sure if this is intentional but as it is it's a bug because there's no matching ID in the quality name objects. [[User:Lagg|Lagg]] 11:54, 25 September 2010 (UTC)
| |
| | | |
− | : Looks like Valve removed these from the schema during the [[Polycount Update]]. I approve. [[User:Lagg|Lagg]] 01:14, 4 October 2010 (UTC) | + | Backpack in question: 76561198045241951 |
| | | |
− | === Polycount Update Bugs ===
| |
| | | |
− | The attribute "set item tint RGB" which is for the Paint cans is missing a hidden property. They're in the items_games.txt, but not in the feed. I think "cannot trade" (153) and "attach particle effect" (134) have the same problem. :) [[User:Pc Madness|Pc Madness]] 17:09, 2 October 2010 (UTC)
| + | TF2B: http://tf2b.com/tf2/76561198045241951 '''FAILED''' |
| | | |
| + | OPTF2: http://optf2.com/tf2/user/76561198045241951 <del>'''FAILED'''</del> '''SUCCESS (Thanks)''' |
| | | |
− | Also, whats the correct way of converting the Steam ID's for Gifts into a profile ID? I know that you're supposed use them to create a "STEAM_0:" number but I'm not sure how you're supposed to tell if a 0 or 1 should follow after the first 0. --[[User:Pc Madness|Pc Madness]] 18:09, 2 October 2010 (UTC)
| + | TF2Items: http://www.tf2items.com/profiles/76561198045241951 '''SUCCESS''' |
− | :This is what I managed to work out based on the existing functions and the format in which the SteamID was provided by the WebAPI <nowiki>http://pastebin.com/aac6cayD</nowiki> - Basically, Id's that are even are :0: (id/2), Id's that aren't are :1: ( (id-1)/2 ) [[User:Geit|Geit]] 23:00, 2 October 2010 (UTC)
| |
− | :: What value is given that then needs to be converted into a string? If it's the 64-bit SteamID, then that's well documented - see <nowiki>http://developer.valvesoftware.com/wiki/SteamID#Steam_ID_as_a_Steam_Community_ID</nowiki> [[User:Netshroud|Netshroud]] 10:56, 4 October 2010 (UTC)
| |
− | :::It's not a 64 Bit Steam ID, it's the final numerical part of the 32 bit SteamID*2 and if it's from auth server 1 then +1--[[User:Geit|Geit]] 19:41, 5 October 2010 (UTC)
| |
− | :::: So the 64-bit SteamID is just '<value> + 76561197960265728LLU'? "Add 1197960265728 to this value and prefix it with 7656 for a 64 bit Steam Community ID" sounds like it was written by someone who doesn't know about 64-bit unsigned integers. [[User:Netshroud|Netshroud]] 22:28, 5 October 2010 (UTC)
| |
− | ::::: Eh? I wrote it assuming the reader would know that "prefix" means concatenate "7656" and the string representation of the value added to the magic number, of course you do seem to be the only one having trouble with it. There's also example code for this in optf2. [[User:Lagg|Lagg]] 22:36, 5 October 2010 (UTC)
| |
− | :::::: I'm partly having trouble with it because I can't find a test backpack that has an item with this attribute. Why though would you concatenate and store a string for a numeric identifier? If you're adding a number to it, why add and prefix instead of just adding a larger number? The way you wrote it has left me utterly confused. [[User:Netshroud|Netshroud]] 22:43, 5 October 2010 (UTC)
| |
− | ::::::: Because it's more efficient. There are no API calls or anything that uses the community ID in fact that needs it as an integer. It's also easier if your code is running on platforms that might have a different endianness and in all cases you will be converting it to a string anyway. It's also cleaner code wise to concatenate the two string representations. [http://agg.havoc.ift.uni.wroc.pl/tf2/pack/item/76561197972546338/140785038 Here] is a user that has a gift item. [[User:Lagg|Lagg]] 22:51, 5 October 2010 (UTC)
| |
− | The attributes "duel loser account id" and "gifter account id" have no localised description string. [[User:Netshroud|Netshroud]] 10:56, 4 October 2010 (UTC)
| |
| | | |
− | === Missing descriptions? ===
| |
| | | |
− | I'm looking through the Schema, and it provides negative attribute descriptions and positive attribute descriptions. I don't see neutral attribute descriptions, or item descriptions(such as the Holy Mackerel's 'Getting hit by a fish has got to be humiliating').
| + | ''ValueError: Invalid control character at: line 2233 column 37 (char 39047)'' |
| | | |
− | Do I -NEED- to have it parse the items file? Does VALVe host an items file anywhere? Or, am I just missing something with the schema?
| + | http://i.imgur.com/RKud0.png |
| | | |
− | [[User:Netham45|Netham45]] 19:56, 9 October 2010 (UTC) | + | [[User:Base1024|base1024]] 05:12, 27 May 2012 (PDT) |
| | | |
− | : No you're not missing anything. Valve hasn't provided any description strings yet. [[User:Lagg|Lagg]] 21:05, 9 October 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) |
| | | |
− | ::Okay, Do you know if they have any plans on supporting them? [[User:Netham45|Netham45]] 23:16, 9 October 2010 (UTC)
| + | == Date/Time of when the item was acquired? Also, ResolveVanityURL == |
| | | |
− | ::: Something will more than likely be added eventually, but no one from Valve has said anything about it as far as I know. [[User:Lagg|Lagg]] 23:18, 9 October 2010 (UTC) | + | 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. |
| | | |
− | :::: Okay, thanks. Also, do you know if there's separate pictures for the paint cans anywhere? [[User:Netham45|Netham45]] 01:46, 10 October 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. |
| | | |
− | ::::: Unfortunately there aren't any provided by the API right now, but now that we have usable tuples for tint attributes you could generate links to the ones here on the wiki. [[User:Lagg|Lagg]] 01:48, 10 October 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? |
| + | 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. |
| | | |
− | :::::: Okay. Do you know who I could contact at VALVe? I just want to know if it's worth it to work around the lack of strings, I don't want to do that just to have it obsolete in a week. [[User:Netham45|Netham45]] 09:18, 10 October 2010 (UTC)
| + | my two cents [[User:Pigophone|Pigophone]] 03:04, 27 April 2013 (PDT) |
| | | |
− | ::::::: With Valve's pace it almost certainly won't be in a week. The "official" API guy is [[User:Joe|Joe]] but he hasn't been around for a while. Robin may also do something if he gets around to reading the mails. [[User:Lagg|Lagg]] 09:22, 10 October 2010 (UTC) | + | : 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) |
| | | |
− | :::::::: This seems to be a bug, but custom names aren't escaped, I'm having my site fail when a custom name has a ' or a " in it. [[User:Netham45|Netham45]] 05:39, 12 October 2010 (UTC)
| + | == Inconsistent group IDs == |
− | :::::::: Edit: Looks like a bug in my code, not in the API. Nevermind. [[User:Netham45|Netham45]] 05:40, 12 October 2010 (UTC)
| |
| | | |
− | '''This is particularly important to have exposed in the API now that we have description tags and hat descriptions.''' -- [[User:Lagg|Lagg]] [[File:Backpack_Stickybomb_Launcher.png|24px|link=User:Lagg]] 12:25, 31 October 2010 (UTC) | + | 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. |
| | | |
− | === The <weapon> ===
| + | 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) |
| + | : 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) |
| | | |
− | In what cases is "The" inserted before the weapon name? My understanding was all Unique (achievement) unlocks have this, but there are the odd few like Natascha which don't. And Hats/Misc. [[User:Netshroud|Netshroud]] 02:38, 21 July 2010 (UTC)
| + | == Content of crates == |
− | :Usually you would want to use item_name instead, I believe name is something specific to the game client. If the localization wasn't broken you would normally check the quality of the item and if it was unique you would prefix "The " to item_name. [[User:Lagg|Lagg]] 21:30, 21 July 2010 (UTC)
| |
− | :: I am using item_name. [[User:Netshroud|Netshroud]] 00:04, 22 July 2010 (UTC)
| |
− | ::: Are you sure? Unless you're reading tf_english.txt there's currently no way to get the localized item name, if you are reading tf_english.txt instead of using the first block of names use the second block(which have "The" or lack of it already prefixed). If the quality for an item is unique, see if it exists in the second block, if it does use that string, if not use your own prefix. So for example I iterate through Robin's inventory, I hit an entry for natascha, I see if the quality is unique, I find the second "TF_Unique_Achievement_Minigun" in tf_english.txt, take it's definition and use that, if I don't find it (or the quality is not unique) I take the "TF_Unique_Achievement_Minigun" from the first block and write my own prefix. [[User:Lagg|Lagg]] 16:25, 22 July 2010 (UTC)
| |
− | :::: append &language=en to your GetSchema call. You get localised names. That's what I'm now using. [[User:Netshroud|Netshroud]] 23:51, 22 July 2010 (UTC)
| |
− | ::::: WOAH, Someone fixed the localizer! Thanks [[User:Joe]]! Correction, the localizer /was/ broken. In that case, what I said still applies if you want it exactly like the ingame viewer (don't pass a language and use the tokens with tf_english.txt's second block) [[User:Lagg|Lagg]] 00:23, 23 July 2010 (UTC)
| |
− | :::::: That defeats the point. I'm trying to break reliance on tf_english.txt. [[User:Netshroud|Netshroud]] 00:26, 23 July 2010 (UTC)
| |
− | ::::::: True, but it's the only way so far without hardcoding anything. Personally I don't think it's that bad, and there are only a few items that don't use "The ". [[User:Lagg|Lagg]] 00:29, 23 July 2010 (UTC)
| |
− | :::::::: I'm hardcoding Natascha, Jarate, and Crit-A-Cola in to not get prefixed with "The" (via defindex). There's got to be a better way though. [[User:Netshroud|Netshroud]] 01:31, 23 July 2010 (UTC)
| |
− | ::::::::: I'd settle for Valve using more consistent names, but as it is I'm not sure much can be done about it. Without the current system we'd have stuff like "Community The Kritzkrieg" again. One option would be to add a special attribute for items that shouldn't be emphasized as unique. We already have an attribute or two that isn't meant to be printed unmodified ("attach particle effect" for example). Maybe something like "unemphasized unique weapon", and we can easily handle it appropriately. That's the only non-breaking way that makes sense really. I have to admit though, prefixing "The " to everything unique even if it doesn't make sense grammatically sure brings me back, and I think whoever did it that way at Valve felt the same way. e.g. seeing loot called "Legendary The Firebane". Or maybe someone at Valve thought that we'd think that and were really just being lazy. Hmmm [[User:Lagg|Lagg]] 02:54, 23 July 2010 (UTC)
| |
− | :::::::::: When I used tf_english.txt, I worked around "Community The Kritzkrieg" or "Valve The Equalizer" by removing "The" if it was non-unique. On another note, this indentation is getting crazy. [[User:Netshroud|Netshroud]] 03:16, 23 July 2010 (UTC)
| |
| | | |
− | {{Languages}}
| + | 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:Valve]] | |
− | [[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)