Match details giving incorrect results
RvGaTe.6501:
Match details API call is going nuts
Multiple objectives getting flipped on every capture? Noticeable on all API driven applications that look for flipped objectives on the match details results…
Live example on Piken Square vs Gunnar’s Hold vs Drakkar Lake on Red border (Drakkar Lake): http://mos.millenium.org/eu/matchups/map/1886/red
Added screenshot in case it doesn’t happen anymore…
Something changed/broken???
smiley.1438:
The timers are only approx since there’s currently no reliable way to get the exact cap time from the API (i hope for this feature in v2). Therefore it may happen that more objectives have changed during 2 consecutive API polls, which was most likely the case when you made that screen.
RvGaTe.6501:
@Smiley, pretty sure this is not the case, objectives are actually going to neutral and back to a owner… thus resetting the timers from the applications
smiley.1438:
Depends on how the application is written – the objectives don’t change to neutral during a capture. You may check out my overwolf app, which does basically the same than millenium.org plus cool stuff.
RvGaTe.6501:
Happened on all the overwolf apps, and yes, it does change to neutral.. (not talking about the center objectives)
RvGaTe.6501:
Even on your app.. your timers act exactly the same like all the others… put it on the same matchup and you’ll see
smiley.1438:
Thats in fact interesting, because it seems it’s just the camps on the red map.
"maps": [
{
"type": "RedHome", "scores": [
32257,
2950,
2950
], "objectives": [
{"id": 32, "owner": "Red"},
{"id": 33, "owner": "Red"},
{"id": 34, "owner": "Neutral"},
{"id": 35, "owner": "Green"},
{"id": 36, "owner": "Blue"},
{"id": 37, "owner": "Red"},
{"id": 38, "owner": "Red"},
{"id": 39, "owner": "Red"},
{"id": 40, "owner": "Red"},
{"id": 50, "owner": "Neutral"},
{"id": 51, "owner": "Neutral"},
{"id": 52, "owner": "Neutral"},
{"id": 53, "owner": "Neutral"},
{"id": 62, "owner": "Neutral"},
{"id": 63, "owner": "Neutral"},
{"id": 64, "owner": "Neutral"},
{"id": 65, "owner": "Neutral"},
{"id": 66, "owner": "Neutral"}
], "bonuses": []
},IDs 50-53 are the camps, 62-66 the ruins, which are usually neutral.
Filovirus.6258:
On our current MU it’s in EB that everything is screwed up, and pass through the “neutral” state regularily (and it’s a mix of camps and towers with SM too, pretty much the same 10 or so everytime, no Keep though).
smiley.1438:
Would be nice to know the match_id or at least the world you’re playing on, interesting for me (and probably others) to investigate.
https://api.guildwars2.com/v1/wvw/match_details.json?match_id=2-4 <— camps on red BL flipping to neutral
Sol Solus.3167:
Sometimes the API seems to get overloaded and returns a short error message instead of the expected JSON. The problem is these apps are assigning neutral to every objective when that happens instead of actually checking if the owner field of each objective ID exists and has changed. My Rainmeter map doesn’t have this problem.
It’s not good practice to design a network connected application around the assumption that the network connection is infallible.
Filovirus.6258:
Would be nice to know the match_id or at least the world you’re playing on, interesting for me (and probably others) to investigate.
https://api.guildwars2.com/v1/wvw/match_details.json?match_id=2-4 <— camps on red BL flipping to neutral
MU is RoS/FoW/UW, i’m playing on RoS.
The “problematic” ones are : Rogue’s Quarry, Speldan, Mendon’s, SM, Pangloss, Ogre, Anza, Golanta, Quentin Lake, Langor, Umberglade, Durios, Bravost (and it looks like Valley Keept too).
(it’s quite huge)
Filovirus.6258:
Sometimes the API seems to get overloaded and returns a short error message instead of the expected JSON. The problem is these apps are assigning neutral to every objective when that happens instead of actually checking if the owner field of each objective ID exists and has changed. My Rainmeter map doesn’t have this problem.
It’s not good practice to design a network connected application around the assumption that the network connection is infallible.
It does actually, since it’s the main one i use.
GW2 eventer has the same problem, GW2.co too (from what i gathered tonight), same thing for the WvWintel.com and GW2wvw.org websites/maps.
edit : not sure i have the latest version though, i will check that tomorrow and see if it solve the problem.
smiley.1438:
Sometimes the API seems to get overloaded and returns a short error message instead of the expected JSON.
Thing is, that is not the case. Have a look at the snippet above – the JSON was returned correctly but the state of the objectives was neutral – thats clearly an error on the API side, no hiccup or overload or whatever.
Also, any decent javascript library nowadays checks if a request was successful (e.g. http://api.prototypejs.org/ajax/Ajax/Request/) – you can rely on that pretty much and just check for the data you expect.
Pat Cavit.9234:
There’s something weird going on with the WvW maps, the WvW team is tracking it down. The issue they’ve been discussing sounds suspiciously like something that would cause the behavior you’re seeing.
Bugabuga.9721:
I wonder if one of the front-end IIS instances temporarily times out when accessing whatever the back-end is running
(I’ve noticed that after the Patch API decided to redirect all http calls into https, so defenitely some config changes happened)
That way whenever timeout happens everything flips to “neutral” and then on the next API call back to whatever color it actually was
RvGaTe.6501:
There’s something weird going on with the WvW maps, the WvW team is tracking it down. The issue they’ve been discussing sounds suspiciously like something that would cause the behavior you’re seeing.
Thanks for confirming and good luck on resolving this issue (if its not you personally, please pass it on to the people that are on it).. hopefully its fixed before tonights raid :P