Wait. Wait wait wait. A console battle log's RoomID is different from the API's battle_id ?? In that case, what is the console log's RoomID? And more pertinently, is there no way to connect information from the console's info to the API's info? $:^ ` EDIT: I just ran a verbose log test, and no apparent connection there, either -- not that verbose would be ideal in the least, but just trying to see if anything works. I really hope I'm just missing something obvious here... Regards, Bob P.S. Oh yeah. Bug. The API page's note on errors sounds like I should get 502 in the header and a JSON string including "error" in the body, but instead what the returned body gives me what I quoted above.
The Battle ID does appear to be lacking in the console log, the Room ID missing from the API response, and the two not being the same thing. So yes it doesn't look like there's an obvious way to connect information between the console and API. On the bright side at least you can fudge something together. Whereas I still cannot practically use the API for retrieving item information. Spoiler: Retrieving Items against Production API times out * Connected to api.cardhunter.com (54.221.203.26) port 80 (#0) > GET /items?battle_id=3277099 HTTP/1.1 Host: api.cardhunter.com Accept: */* * Empty reply from server
Your badge is hilarious. $F^ } Besides any obvious thing, it could be just as nice to have some undocumented thing, like @Farbs once used with demarcation... I already tried /rooms/ and such fwiw. EDIT: Actually, no, I cannot use the API for battle data in the current state if the API requires me to know the battle ID -- which I apparently cannot get without first using the API, i.e. sifting through pages and pages of battles to find the first one that matches Scenario, both Players, probable gameType (via console parsing), number of rounds (accuracy related to console log's nearness-to-end-of-battle), etc., which should be done without exceeding request limits (hope shot right there), and would still only come up with a best guess because more than one battle can easily match these soft identifiers. EDIT2: Eh, if you're saying I can still do my thing without the use of the API, then technically, yes. I just lose out on a lot. The /battles/ JSON gives me a quicker and safer verification on a couple things which I can parse from the console log myself (and frankly already mostly do), but stuff like characters? I don't look forward to writing the routines to scour a whole log for clues to piece together which characters are what -- especially since some players insist on using the same name for characters and the game can't stop 'em, ugh. Otherwise, I already know my fallbacks, which will be far from pretty.
Worth a new post instead of more editing: Oh. Nevermind. I can't use /characters/ due to timing out anyway. $:^ [ (It works on test-api like items.) Fallbacks and eventual log-clue-scouring it is, then.
