ObjectiveCaio

@jslack: @thefaxman: Same problem here. I've been getting many crash reports and user complaints due to the app reaching the rate limit. My app doesn't even rely on requests that much. During normal use, it only makes requests when searching and browsing games that haven't been opened, and once a day it refreshes the users' list of games (usually not too many), and that's when it hits the API a bit harder.

I've reduced API use for the next version as much as possible, adding some logic to searches and limiting users' ability to do manual list refreshes to one per day, but the app is just starting out, and as the userbase grows, I don't think this will make that much of a difference.

If we were able to see how hard we're hitting the API (with a dashboard on our GB profiles maybe), we'd be better equipped to find problems in our use of it.

The box art for Call of Duty: Advanced Warfare is not being displayed correctly on the wiki:

http://www.giantbomb.com/call-of-duty-advanced-warfare/3030-45359/

@chaser324: I thought so, but it's the only difference between his request and the way I make them.

@michael_lazzaro: You probably solved this by now, but in case someone else has this problem: you don't need to use the 3045 code, just the ID of the platform itself, so filter=platform:145.

Also to filter by more than one platform you would do, for example: filter=platform:145|146|94

I thought /search requests took care of special characters, as I don't recall having a problem with it. Anyway, this is great, as I search with /games (to filter by platform) and it doesn't have any special character filtering and I currently filter the string myself. This will make search much better in my app. Thanks!

@vickychijwani: I can't believe I've never seen that, it might have come out after I made my own solution last year. It was great to learn a bit of scraping and regex, but that part of my code is not very clean and always bothered me, as well as the problem with reliability. I'll look into it right away, thanks!!

@cracklepopflash: Apparently this is because of a bug in the API. I made a topic about it a while ago, there's more information there: http://www.giantbomb.com/forums/bug-reporting-33/original-release-date-instead-of-expected-release--1466659/#4/

I checked to see if releases were working correctly but they're not.

@mrpibb: Alright no problem, just give us a heads up before the change if you can. Dates are the most important and complex part of my app so I'll need to make the changes quickly. For now I'll just ignore the january 1st 2014 original_release_date.

Further discussion at the Bug Reporting forum.

@mrpibb: That's the problem, the expected release fields are all null for the games with original release dates filled, so even if I ignore the original release date (which, as you said, is only showing for these games because of a bug), I still won't be able to get release dates for these games. There seems to be a lot of games affected by this and it really screws up my app:

Only temporary solution I can think of now is to just ignore the original release dates for january 1st 2014, so the app will set them to TBA instead of a wrong date.