Showing Posts For Kegsay.7068:
The z-axis measurements would be more useful if your projections were on a 3d map, but in all probability it isn’t. You can only partly represent depth on the current map via the “floor” of the map. You could potentially work out the z-value of each floor (e.g. -1500 to -500 for floor 3, -500 to +500 for floor 2) and then correctly display the events which are designed to still be visible on different floors. Of course, you have to be careful with this because AN seem to use some floors to mean completely different maps.
For the most part though, this is overly complex for extremely little gain, and it’s far easier to just ignore the concept of floors / z values given in the response.
I believe they are used to show you the area you must be inside in order for the event to display on screen. They are formed as 3D shapes (which I guess you could maybe utilise the z-axis for checking if the event is visible on multiple floors?).
From what I can see:
type = a hint on how to generate the the 3d box
center = the center of the event as [x, y, z]
radius = how far out from the center it goes (sphere/cylin only)
height = z length of the event, can probably be ignored if you don’t care about depth, though bear in mind this is the height wrt the center z coord.
z-range = the literal z-min and z-max coords as [min, max]
points = a series of xy coords which make a polygon, as [x, y]
rotation = No clue, as I have no idea on what axis it is rotated around (which I assume it must be axis rotated else a rotation key for a sphere is meaningless)
Basically, if you’re just projecting this onto a 2d map, you can probably get away with:
if sphere or cyl then:
event range is a circle around key ‘center’ with radius ‘radius’.
else if polygon then:
join the dots on the list of ‘points’ and be done with it.
Hope this helps.
You could probably do this in a low bandwidth setting by prodding build.json for a change in version. If there is a change in the version, enumerate all map tiles with an HTTP HEAD at a given zoom level (too far in is pointless, too far out may miss subtle changes like Kessex). You could further optimise this by prioritising user-visible tiles.
Of course, this isn’t going to be quick, but you’ll make significant bandwidth savings over time by just HEADing for changes in Last-Modified or the ETag.
Yeah, it is pretty tedious having to go through and deal with some interesting JSON structures from the various endpoints we can hit. That being said, it’s also not difficult to just parse it out.
At this point, it would be far more damaging to change the spec and break everyone’s stuff, so I would prefer it if no changes were made. However, presenting a consistent format for all new APIs going forward would be a great idea.
“As for the additional files.json entries: I’ll try to get what I can included as soon as possible and will reply when updated.”
Thank you!
Just a quick fix I hope for this one. Someone touched on this previously:
The API at https://api.guildwars2.com/v1/files.json has no entries for:
- Vista (seen)
- Vista (not seen)
- Skill Challenge (complete)
- Skill Challenge (not complete)
And whilst I’m at it, these are also not available but still noteworthy:
- Merchant (coins icon)
- Trading post
- Bank
- Repair NPC
- Weapons dealer
- Armor dealer
- Commander
- Party member dot (the blue dot)
- All the crafting icons
- Asura Gates
- Event type icons (e.g. the icon for ‘NPC wants you to bring them stuff’)
I think that is mostly it. It would be great if someone could just toss these in the JSON.