Showing Posts For Tanis.5134:
My current strategy is to use the v1 matches endpoint to get the world ID → match ID mapping. That’s a relatively small dataset, and I can cache it week-to-week.
Lawton mentioned in the v2 matches PR that he is planning on adding something else for a v2 world ID → match ID mapping.
I’m also planning on submitting a PR to add a world ID parameter to the /v2/wvw/matches endpoint once the existing work has been merged in. This would allow querying for a match by the world ID instead of by the match ID, eliminating the extra step of mapping a world to a match.
Thanks Lawton, that makes me feel better about shipping everything I’m reasonably confident will work with the new APIs!
The tiles was definitely my biggest remaining concern, so knowing that they’ll be there is fantastic.
You also answered a question I didn’t ask- I will avoid caching the tiles for now since the desert borderlands are replacing the existing ones.
Why the haste? Sure, it’d be cool to have a site up on launch day, but y’know: when it’s done™.
Because I have users who I know will complain, and I would like my application to continue working anyway.
It will be hard to recover from the wave of negative Play Store reviews that will inevitably come on October 23rd from users who can’t see WvW data any more. I don’t particularly blame them either- if an app I use suddenly stops working, I tend to be annoyed as well.
Based on Lawton’s response there a month ago, it sounded unlikely, but I’m hoping that has changed.
To support the desert borderlands, I need one of two things, both of which unfortunately look unlikely right now:
A) Confirmation that the tile service will support the desert borderlands. This means that I can rely on the coordinates in the objectives endpoint to place the markers on the maps from the tile service. Yay for not hardcoding and manually finding coordinates!
B) The objectives endpoint to start showing desert borderlands information prior to 10/23, a map of the desert borderlands, and some way of seeing where each marker is supposed to go on the map. All three components are critical because we don’t know the IDs of any of the desert objectives, so thus even if we had a map we would have no idea which objectives on the map line up with which objectives from the API.
If someone else has a clever solution for supporting the desert borderlands using a different strategy, I’d be eager to hear it! Otherwise I will be updating my app this week to notify users that I cannot yet support the new borderlands due to waiting for API data. Then I’ll have an all-nighter on the 23rd to start supporting it (when I would much rather be playing!).
Will the Heart of Thorns maps be in the tile service at (or before) launch?
Specifically, I’m curious about the desert borderlands tiles, but it would be good to know if the Maguuma maps and new PvP maps will be in there right away.
I know that historically the tile service has been slow to receive updates to existing maps (such as Lion’s Arch), but I’m hoping that new maps will be there!
Found and fixed the issue. Github PR. It should go out with HoT release.
Woohoo! Thanks!
Out of curiosity, are there going to be any more API updates prior to HoT, or is this issue one that required some changes outside the API and that release isn’t happening until HoT?
I’m actually not sure how the game client places markers — my impression is that the sector centroid is used for the label placement, not marker placement. I need to dig up how the markers are placed; I’m not certain that they’re data-driven.
If you find out that they are not data-driven, it would be awesome if we could get access to the desert borderlands in the tile service so we could map out those objectives prior to the release of HoT.
I’m hoping I can find something in the API that will be reliable when objectives are changed or added, as I’m trying to update to support the new desert borderlands prior to the HoT release.
(edited by Tanis.5134)
This looks like a rounding error to me, but then again, the positions of the keeps are odd.
What library are you using? Leaflet? Google Maps?
I tried with Google Maps back with v1 and the sectors, and I believe I had the same result. I am currently using Mapbox’s Android SDK .
Here’s a JS fiddle using leaflet with the same problem. I know that the PR for this mentioned that the coordinates are just the centroid of the objective’s sector- perhaps that doesn’t actually line up with where the markers should be?
If that’s the case, is there a better way to get the “correct” location of markers without just figuring them out myself and hard coding them?
Has anyone had any luck using the coordinates in /v2/wvw/objectives? I can’t quite get markers to line up on a map created with the tile service.
Here’s what I am seeing for each borderlands: https://dl.dropboxusercontent.com/u/1096483/map_offset.png
Notice how the markers all seem to be offset towards the center of the map. My initial thought was that I had to play around with the zoom a little, but since it is happening on all maps and the offset is relative to each individual map (instead of the world as a whole), I’m starting to doubt that.
I’ll probably work on creating a Javascript fiddle tomorrow to see if it is just the library I’m using, but I’ve seen it on two libraries so far. I’m also not particularly fluent in mapping terminology, so if anyone knows what I should be looking for, I would appreciate pointers.
Awesome, thank you!
Could we get a test environment set up to hit during upcoming WvW tests such as this one?
It is probably too late for the first test (on July 9th), but it would be incredibly valuable to be able to see what types of data we will be getting from the new WvW maps prior to release, and doing it during the other WvW testing would get us “real” data to look at.
As the developer of a WvW application, I am concerned about whether we will have updated map tiles (judging by the lack of updated LA map tiles, probably not) and whether the API will be properly updated to reflect the new objectives (and how that data relates to what we get now). There has been lots of love going to other parts of the v2 API, which is great to see, but the lack of movement on the WvW endpoint requests is starting to worry me!
I was hoping by now to see official proposals related to the upcoming changes to WvW. Objectives will all be wrong, and anyone using the tile service currently has no idea which continent and floor to use. It would be great if we could start consuming the v2 WvW endpoints prior to the release of HoT to ensure that everything is working well.
Also, English is not my native tongue but I have a very good grasp of it and the post of the Arenanet employee is barely even understandable to me.
1. His use of the language is incredibly complicated and
2. His explanation is highly technicalI would love him to re-explain what he means, just for us “common folk” who also play the game and completely do not get what he has just tried to tell me…
Hello, you have found the API development forum! This forum is intended for software developers who want to incorporate data from Guild Wars 2 into their applications. The content in this forum is not intended for the “common folk” who play the game.
So do I understand right that the use of the Google Authenticator app is being stopped?
Nope, this is completely unrelated to the two-factor authentication system for logging into the game. This post is about a method that users can leverage to provide a limited amount of account information to third-party apps, such as an Android app developed by a Guild Wars 2 fan.
The World API appears to be returning empty arrays for all supported languages, and looks like it might have been doing that for the last few days.
Example: https://api.guildwars2.com/v1/world_names.json?lang=en
Any word on this??? My application has been hurting for days….
Stefan posted that they are aware of the issue and working on it here: https://forum-en.gw2archive.eu/forum/community/api/Looks-like-some-of-the-API-is-broken/first#post3999815
Hi All, thank you for the report. Turns out there were more APIs affected by megaservers that I originally thought. I am working on a fix and hope to have it out shortly.
Thanks for the update!
I’m a bit disappointed that this has been going on for 4 days now and we haven’t even gotten acknowledgement of the issue.
Definitely not instilling confidence in the API.
ArenaNet is working on bringing OAuth2 to the APIs, which would allow us to get information such as this.
About a month ago, the OAuth2 implementation was “basically complete”, but the APIs that go with it were not (see here).
No information has been provided on what information will be coming with OAuth, but you definitely won’t be getting player health information until then.
Obviously the Mad King cut down the forest to supply the wood for the doors.
Where else would he get enough wood for all those doors?
It does not appear as though the tiles service has been updated to show the new WvW borderlands maps.
Do we have an ETA on that?
I received a similar response to my support ticket. I kept getting told that there was a warning, despite the fact that the warning was not properly placed when I first entered. Lost somewhere around 15-16 hours.
Ticket 130904-001408.
Similarly, world_names is only returning four worlds, matches returns an empty set, and objective_names is returning an empty set.
A mapping of WvW objective IDs to POI IDs would be much appreciated. But this is already a few hundred steps forward from my current mapping system, so I’m happy!
I noticed this as well, and it is causing problems.
On one hand, I’m afraid to filter it out in case it is a valid world. On the other hand, I don’t want to simply set that world’s name to “null” because that’s clearly not a world name.
Couldn’t you make it a data file or something and just reference to it in your codes? You could use things like Enum, classes or well even static variables. I also found some sources that have converted the IDs to Names as a JSON format which you could use but I personally just hardcoded it somewhere.
Although this becomes a possible problem if the API IDs to Names mapping changes in the future
That’s exactly what I’m doing, and you pointed out why I don’t like doing it. I would like my app to be as future-proof as possible.
I also don’t personally feel as though a client application SHOULD need to map IDs to specific objectives. That sounds like something you would typically get from an API, not make up yourself.
I am successfully using the API in an Android app without manually specifying or installing a certificate.
We also currently don’t have a good way of mapping objectives from the API to an actual objective in the world. In other words, the API doesn’t provide a way to say “Objective 29 is a north camp.” I am currently relying on a manually created map from IDs to objectives, which is a pain.
If we could get that data from the API somehow, that would be awesome. Even outputting the objective IDs in a consistent order between borderlands would make interpreting the IDs a whole lot more simple.
Could we get the match start/end time somewhere?
I know that it is currently every Friday at 6:00 PM PDT, but it would be nice to be able to get that data from the API should it change again in the future.
Type consistency. I know it was acknowledged <a href="https://forum-en.gw2archive.eu/forum/community/api/Nit-Type-inconsistency">here</a>, but the string vs int world names are obnoxious to work with.
Either an API mapping WvW objectives to objective types, or standardize the “camp” type into one. The dozen or so different names for “camp” make for extra work for us, and I don’t think they are all that useful. I’m sure there’s a use for it, but…
Android WvW Monitor: https://play.google.com/store/apps/details?id=com.berbst.gw2.wvw
Currently shows an overview of the WvW stats for a match. Soon it will show details for each map, and eventually zoomable maps.