subkamran's forum posts

  • 12 results
  • 1
  • 2
#1 Posted by subkamran (14 posts) -

I mean the entire site search is also borked, so it's not just an API issue. You'd think you'd roll back to a stable version while this got fixed? It's been 16+ days since this was reported. There's a lot of people depending on this API (including my site). I'd be willing to pay for access if it meant stability and regular updates :)

#2 Posted by subkamran (14 posts) -

I was just hoping changing the protocol would work.

This essentially precludes the ability for my site to work under SSL, since I can't link to Giantbomb images since browsers won't display them. That leaves me two choices: implement a workaround to not have to use SSL or to cache all the images locally (ugh).

On my end I think I can workaround having to use SSL for the game pages but it would be nice not to have to. It's been 6 months, have you guys re-considered?

#3 Posted by subkamran (14 posts) -

Why do people keep reverting the release to 2013? Clearly the planned release is for May 14, which I submitted but it's been reverted again.

#4 Edited by subkamran (14 posts) -

Hey guys,

Is there a way to craft an HTTPS URL for GB images returned from the API? I noticed if I try this:

https://static.giantbomb.com/uploads/scale_small/8/87790/2293393-box_re6.png

It actually has a bad certificate; i.e. Akamai is serving the image but the cert is for GB, so browsers deny it unless you add an exception.

This is sort of a big deal if you intend to serve your site over SSL.

Any ideas?

#5 Posted by subkamran (14 posts) -

I would love raw dumps... then I could just cache everything locally.

#6 Edited by subkamran (14 posts) -

@frobie, is it by design to add a container around platforms in search results? Previously it was simply an array of platform objects, now it's an array of containers with a "platform" property that points to a platform. This is messing with my deserialization strategy :( I just noticed this recently. Was there a reason to change it? It's inconsistent now. The game detail resource still acts correctly, "platforms" is an array of platform objects.

Another question: how come all the images are crazy big? Small is still pretty big (601W) and Medium is huge (902W). Fun fact: if I change the URL for a Medium image to use "scale_tiny" it's a more palatable size (300x320). However, "tiny_url" returns a square cropped image, not "scale_tiny" as I'd expect. I'm using Last of Us as a reference.

#7 Edited by subkamran (14 posts) -

Awesome, thanks! I think that clears up my issues.

#8 Posted by subkamran (14 posts) -

@frobie said:

Looks like a ninja push actually happened. Woot!

EDIT: Will fix the expected release date logic.

Awesome. The misspelled "date_last_udpated" field still looks to be outstanding but getting releases by ID and abbreviation are fixed.

Thanks again!

#9 Edited by subkamran (14 posts) -

@frobie: Thank you!

I also noticed last night that the expected_release_month is included even when expected_release_quarter is there, is that a known issue? So my notifications from my site read: The Last of Us now has an estimated release date of Jun Q2 2013 (was 5/7/13). Previously if quarter was present, the month would be left off.

It's a little bit of a pickle, because how can I accurately determine whether a game's expected release really is the month it says vs. the quarter it says? For example, if quarter is present, it could trump, but then you have cases like The Last of Us (see below) where it really is June, not estimated to be Q2. It's really an expected_release_date vs. something that's not a solid estimate. I could say, if day and month are present, they trump quarter. But that still leaves cases where we know a game will come out in April 2013, yet the API will return Q2 April 2013, but "Q2 2013" has a different meaning than "April 2013".

For example:

Q2 begins in April, so if a game was expected to be released in April, the response would be:

  • "expected_release_day": null,
  • "expected_release_month": 4,
  • "expected_release_quarter": 2,
  • "expected_release_year": 2013,
  • "original_release_date": null

What would you display? Q2 2013 or Apr 2013? Both have very different meanings to gamers.

My hope would be that one of those fields will be null if the other is present, and not include values for both (same as v1).

Also, the site AND the API list Watch_Dogs as being released in 2013, rather than unreleased but estimated to be released in 2013. I wish it were true, but I got a notification from my site saying it was released :( Same issue with Metro: Last Light. Looks like the estimated release year isn't being set correctly.

  • "expected_release_day": null,
  • "expected_release_month": null,
  • "expected_release_quarter": null,
  • "expected_release_year": null,
  • "original_release_date": "2013-01-01 00:00:00",

With Destiny, I'm getting expected release date of January 14, 2014, yet the site just says 2014 (which is right):

  • "expected_release_day": 14,
  • "expected_release_month": 1,
  • "expected_release_quarter": 1,
  • "expected_release_year": 2014,

It also seems the logic for expected vs original has changed. For example, The Last of Us is expected to be released Jun 14, 2013. In APIv1, that would be in original_release_date but now it's part of the expected_release_* fields. I do like this better honestly, but is that the new standard going forward? Just want to make sure that's intentional.

  • "expected_release_day": 14,
  • "expected_release_month": 6,
  • "expected_release_quarter": 2,
  • "expected_release_year": 2013,
  • "original_release_date": null

Lastly, I see you guys added DLC to game pages... any timeline on when that'll be added to the API? It would be awesome to track DLC releases on my site as well :D

PS. Please don't take my posts as any criticism... I love GB, after all you guys make sites like mine possible, I just want it to be the best it can be!

#10 Edited by subkamran (14 posts) -

Some of these changes do break existing libraries (like mine) but I've been able to accommodate the changes (namely, if you try and deserialize the JSON platforms for a game to an array you'll run into issues when GiantBomb returns a comma-delimited string for list resources, same with original game rating).

Some bugs I found:

  • I'm still not getting data back for Morrowind's GOTY release: http://giantbomb.com/api/release/3050-29726/?api_key=<KEY>&format=json (500 error)
    • I can workaround this by using releases/?filter=id:29726 but then I lose out on some properties
  • In release and platform resource (at least!), the date_last_udpated is spelled wrong
  • Platform resource abbreviation seems to be missing
  • Seems like some games' release dates got messed up unless somebody knowingly allowed Skyrim to be edited as being released February 7, 2012. I submitted an edit to fix it.
    • Same is happening with The Witcher 3. On GB, the wiki editor says it's a 2013 release date. But the API is returning Jan 15, 2013 which means it's released. I would expect expected_release_year == 2013, not original release date to be filled.

Man, some of these bugs are really throwing a wrench into my site... which is totally based on accurate release dates for games. Hope you guys can fix it soon.

I'll be releasing an update to GiantBomb-CSharp that works with the latest API.

  • 12 results
  • 1
  • 2