Guild Wars 2

Illconceived Was Na.9781:

Yes, please. Also for Vistas. The game has the coordinates; we should get them too (even if only as a linkable location).

You can already link vistas; unfortunately, ctrl+clicking on the map doesn’t work. However, the wiki provides the chat-links on each sector’s page, e.g. https://wiki.guildwars2.com/wiki/Blighted_Depths shows the chat-link [&BOUIAAA=] for the vista there. (The wiki’s vista names are unofficial and are intended to describe what the vista shows.) So while it’s not exactly convenient, it is possible.

(In the API, PoIs, waypoints, and vistas are all subtypes of the “point_of_interest” category of map markers (PoIs themselves are called “landmarks” in the API), so it makes sense that they all function similarly with regards to chat-links.)

Forgotten Legend.9281:

A) will there be a setting in game or in my account page so that i can set a definitive “no app is allowed to access my account / character information, ever, even if the app is able to produce the proper credentials” option? (please answer yes. this seems to me to be a “must have” option.)

All access to authenticated APIs is opt in. That means you have to explicitly give permission to specific apps/websites to access your data on those APIs.

If you do nothing, no one will be able to access your account/character data.

@Forgotten Legend.9281: Two-factor authentication should render all of those concerns moot.

Lawton Campbell.8517:

I’ve also been toying with the idea of exposing SHA1(character-guid ++ salt) as another alternative. Not sure how much I like that approach (has some minor issues on the backend w.r.t. resolution back to character-guid), but it seems like a somewhat reasonable workaround.

Mmmm… salt. I like that idea better.

TranquilInSpirit.6291:

Lawton Campbell.8517:

ID is immutable, Name is not. There are situations where an account’s name will change, though they are rare.

Characters do not have an immutable identifier that we can expose

Would their profession fall under immutable (assuming it’s accessible)? If that could work, maybe doing something with the character’s creation date could mix with that to make some form of ID.

Account ID + character creation time would work: it should be impossible for two characters on the same account to have been created at the exact same time. Base64-encode it or MD5-hash it to make it look something like a GUID.

The recipe for crafting Xunlai Electrum Ingots hasn’t been implemented to the live game yet, so that item should not be appearing in either API endpoint.

Alaska II.5819:

Is there anything that allows to pull outgoing damage? Like how much damage you are dealing to an enemy, everything (flat damage, condis) included. Possibly pull data from the combat data that’s already implemented as a chat option?

The devs have stated repeatedly that they do not have access to real-time data. All of the API’s data is cached and usually at least 5 minutes old.

World boss event start times are not in the API, no.

Chokapik: What smiley was referring to is the color_id attribute of the consumables detail object on the /v2/items endpoint. If you have an item database available, you can join your consumables to your colors on that field.

You can do that as soon as /v1/builds.json reports a new build ID.

However, you should be updating periodically in between builds anyway in order to catch new items that get discovered – just query /v2/items, determine which IDs you don’t have, and then pull the details only for those new IDs.

You’re reading too much into how the wiki treats the MF recipes.

The only MF recipes that we document through the Semantic MediaWiki system are those that have fixed inputs and outputs (other than variable quantities, e.g. material promotion – the output item is still fixed). These types of MF recipes look very similar to crafting recipes, so instead of developing two separate frameworks (one for crafting, one for MF) that would look nearly identical, we decided to use the same framework for both.

MF recipes with variable inputs/random outputs, on the other hand, look nothing like crafting recipes, so we can’t document them in the same framework. That’s why on pages like Carnelian Nugget, for example, you only see Jeweler recipes in the list, and you don’t see the variable-input/random-output MF recipe for combining gemstones.

That is why the wiki documents (some) MF recipes the same as crafting recipes, not because we think they’re actually equivalent.

Actually Steven, you don’t need user input at all if you’re using JS – there’s a built-in function for this.

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Date/getTimezoneOffset

We use it on the wiki, in the function autoConvertUTC() in conjuction with Template:UTC time.

Ah, I see. The only constraints I have in the database are on ID fields. The way I went with lower-level validations like that was to check them within my API-to-DB object builders and note any errata in a “warning” field on the primary record (items_tb.item_warnings, recipe_tb.recipe_warnings, etc.). This way my project is mostly immune to any bugs that slip into the API, but I can still find out about them.

Outer joins are used when you want to append fields from another table, but you still want to retain all records from the driver table. (Inner joins only return records where the join key exists on both tables.) Any records where the join key doesn’t exist on the lookup table will have nulls appended.

However, constructing a single “master” view to flatten absolutely everything may not be the best approach. Outer joins are less efficient than inner joins, and stacking that many of them into one view will make it very sluggish.

My approach would be to construct separate views for each primary type, where I would use an inner join on item_id. Then I would use an outer join for any subtypes. This mockup assumes that all fields are named uniquely across your tables. If they’re not, you’ll have to replace the * with an explicit field list with aliases on the duplicate field names.

CREATE VIEW consumables_vw
AS
SELECT *
FROM [items]
INNER JOIN [items_consumable] ON [items].[item_id] = [items_consumable].[item_id]
LEFT OUTER JOIN [items_unlock_dye] ON [items_consumable].[item_id] = [items_unlock_dye].[item_id]
LEFT OUTER JOIN [items_unlock_recipe] ON [items_consumable].[item_id] = [items_unlock_recipe].[item_id]

I’m not sure why you have separate tables for dye and (I’m assuming) recipe unlocks, they don’t have any additional data structures.

The only way to “upgrade” a piece of equipment is to find one with a higher required level or a higher rarity. That’s it. All stats are directly related to those two properties. (Except for leveling items, which have a lower required level than stat level, but the best stat level available on them is 74.)

What does “signature” mean in this context? /confused

What if you approached it from the other direction? Presenting the same data with the vendor as the focus would make more sense. The data could be organized to reflect the vendor window in the game – a list of the tabs within the window, then each of those is a list of the items (and their costs) offered on that tab.

As for the accessibility of vendors, would it be possible to implement a “discovery” system similar to what’s already in place for items/recipes/skins?

Once again, this isn’t the forum for general game suggestions.

Looking good now, thanks Pat!

It seems like the APIs are having trouble updating with new info from the Tangled Paths release.

• /v2/items lists quite a few new IDs starting from 67961, but trying to access those IDs via /v2/items/<id> returns {"text":"ErrBadParam"}
• /v2/recipes is the same with new IDs starting from 9896.
• /v1/map_floor.json doesn’t list the new locations in The Silverwastes.

You could just get the full lists of IDs from /v2/items and from /v2/commerce/listings, then do a list compare.

Those are “leftovers” of an old bug in the TP that allowed people to submit buy orders for items that aren’t enabled in the live game. I’m pretty sure that bug has been fixed, but these listings haven’t been removed from the TP. I think Pat has said they’re working on finding a way to do that, though.

Oh kitten it, you’re not listening.

DarkSpirit.7046:

On the other hand, the /prices endpoint may be implemented in a similar way: If the provided item id, given to /prices, does not exist within its set of valid item ids, it is regarded as an invalid item id. This is confusing. Classifying an item id as invalid because the item is not being sold maybe counter intuitive to customers which is the point of this thread.

Wrong. That is NOT what the /prices endpoint is telling you – that’s the whole point of what I’ve been trying to say. Instead, it’s telling you that it’s an invalid Trading Post ID, because that’s the limit of what /prices knows about.

DarkSpirit.7046:

That is what I fear that the idea of a valid item would have to boil down to the context of the endpoint which would be confusing because an item may be valid in one end point and yet be invalid in another even though it is a valid item in the game. But I would have to live with this.

It’s not confusing, at least not to me. Context is supremely important: you shouldn’t “boil down” to it, you should start from it.

The /items endpoint is the only proper place to determine the validity of an item ID precisely because that is this endpoint’s context. The context of the /commerce endpoints is limited to the trading post, and this limitation means that the validity of an ID in this endpoint does not imply the validity of that ID in a general context.

I’ll take a shot at explaining this a different way to try to help DarkSpirit understand.

The /v2/items endpoint tells you that a given number X is a valid item_id. Great, you know a valid item ID in the context of items.

You take this number X and pass it to the /v2/commerce/listings endpoint. It tells you it’s an invalid ID in the context of commerce.

The different endpoints have complete different contexts. Just because X is a valid ID in an item context doesn’t mean it’s also a valid ID in a commerce context. That’s all any endpoint will tell you: whether the ID is valid within the context of that endpoint. These endpoints have no knowledge of each other – commerce is only concerned with its own commerce context, it doesn’t care and it can’t tell you about whether X is valid in an items context.

The wiki documentation was written players/users, not by Pat or Stefan or anyone else at Anet. If it’s wrong, change it (if you’re not in the API user group, then post on the talk page and ask for someone else to change it).

Remfin.4892:

I’m not sure why you would MD5 item data since AFAIK build+id+lang represents a unique piece of unchanging data; just replace it.

Because on my machine, computing and comparing the MD5 takes far less time than updating the database. Also, I want to track each time that an item changes, I don’t want to treat every item as having been changed after every build. Especially when Anet releases 3 builds in the same day.

Remfin.4892:

DarkSpirit.7046:

50 to 30 minutes is still too long for a user to wait while the app refreshes its local database, not mentioning mobile apps which would probably take longer and incur a ton of network traffic should the user specify a search for something that is not in its local database and the app decides to refresh it.

It should not take remotely 30-50 minutes on a PC, and it’s not that much data. My program pulls it down in 5-20 seconds (for one language, depending on how my connection is at the time), and the JSON is only 22meg (it’s a lot smaller when gzipped, although I can’t measure that currently).

Mobile may be a different story, but you just have to be smarter about it. But considering how (in)frequent builds are, those numbers aren’t out of the realm of possibility for mobile either.

Pulling the data can be done in seconds, yes. But parsing the JSON into a native data structure, computing an MD5 and comparing it to the known MD5 for change detection, running some transformations on the data (e.g. deriving the prefix name from the infix attributes), and posting it to a database (with proper logging and change tracking) takes significantly more time.

My program would certainly run faster if I had a better computer or made some more optimizations to my code – currently I’m building the data structure and computing the MD5 in the same function; if I split the MD5 into its own function, then 90% or more of the items wouldn’t have to be converted into a structure at all.

DarkSpirit.7046:

Are there plans to add a “Search” functionality to the items or commerce api?

Getting the item record only through its id is too limiting as items in the game gets added faster than we can update our apps.

My database program takes 50 minutes to scrape the entire items API. And that’s on the slow end – Smiley’s takes less than 30 minutes (IIRC).

AND that’s only necessary for the first run after a new build – after that, you just need to diff the item ID list from /v2/items against the IDs in your database and grab the new items (changes to existing items can only occur with a new build).

The relevant acronym here is UI, user interface. APIs are typically accessed by other programs, not directly by users.

This has nothing to do with the API, not sure why you thought it did. I’ve reported the thread, so a moderator should be along soon to move it to a more appropriate location.

On-topic, though, I agree with you.

Nearly all personal story/living world instances are located in that region. I don’t think an explanation has ever been given.

@peterpat: There are various systems in the game that have to “report” items to the API as being “discovered.” There are still some gaps in these systems where they fail to report items correctly.

(You’d think it would be as simple as a check on the inventory: whenever an item is added to any character’s inventory, report that item to the API. But apparently it’s not that simple.)

`Skill_type` would just be an attribute of the skill, like `item_type` for items. Similarly, `activation_time` and `recharge_time` (aka cooldown) would be top-level skill/trait attributes.

Range, damage, conditions, healing, etc. – all of these are skill/trait facts. There would be a list `facts` and each element of the list would be an object to describe each fact. The complexity would be contained to these fact objects.

The leftmost bits look somewhat like a continent ID.

0000 → dungeons (and maybe other instances as well)
0001 → Tyria
1000 → WvW
1100 → EotM

https://forum-en.gw2archive.eu/forum/community/api/Return-proper-error-codes/first#post2961806

API v1 was originally using non-informative HTTP codes, so I wrote my module to look at the returned JSON instead. I never bothered updating it after Stefan’s changes because my method “just worked.” I guess I’ll have to update now.

I found a bug with the errors returned for bad pagination requests – they don’t match the “standard” format returned for other errors.
Pagination errors:

{"text":"page out of range. Use page values 0 - 191."}
{"text":"page_size out of range. Use page_size values 1 - 200."}

Standard errors:

{"error":10,"product":0,"module":2,"line":427,"text":"invalid item_id"}
{"error":90,"product":71,"module":2,"line":378,"text":"CnConn: language not supported"}

My v1 code was relying on the presence of the “error” attribute to detect request errors. Would it be possible to standardize the pagination errors – at least give them an “error” attribute?

Threading is the bomb. I’m currently running on my work laptop – not the most powerful beast in the world (Core i5-3210M @ 2.50 GHz), but the LAN has very fat bandwidth. I’m using my custom Perl module posting to a MySQL database.

• My original single-threaded version took about 7 hours to process all items back when we only had 30k of them.
• A few months ago I rewrote it to fork 4 child threads to process items in parallel, and this version only takes about 2 hours with 38k items now.

At least half of that is the new leveling items. By my calculations, there should be nearly 4,000 3,136 variants of the loot-dropped leveling weapons – taking all combinations of skin, level, and prefix into account (see here). That’s not even counting the containers (the actual drop that contains the weapons), but I can’t really estimate how many of them there should be.

Currently there are 1,696 of the weapons, or ~54%, discovered in the API. A major factor in this is that players are showing a strong preference for the Power prefixes (Mighty, Vagabond, and Forsaken), so the non-Power prefixes are under-represented.

[sorry, I keep editing this only because there have been no further responses :P ]

There are some available from /v1/files.json.

Just pretend that the /v2 stub doesn’t even exist, makes everything easier.

Megaservers.

• https://forum-en.gw2archive.eu/forum/community/api/Megaservers-and-API/first#post3915242
• https://forum-en.gw2archive.eu/forum/community/api/Looks-like-some-of-the-API-is-broken/first#post4120297

The /v2 page is just a placeholder, there’s been no announcement on when (if ever) it will be activated.

AysonCurrax.3254:

Dr Ishmael.9685:

AysonCurrax.3254:

well, they would just have to take the ingame map as it is now and cut that up into 2^n by 2^n pieces.

That’s already how the map is stored in Gw2.dat. Sometime last year I had gone to the trouble of extracting all the tiles and setting up my own custom map using the Google Maps API, but it was too much work so I mothballed the project.

if they already got it stored the way they need it, i dont get why they are too lazy to just update the folder where they drop the tiles for the tile service off to. I guess that shows just how much they care about the api and the developers using it at the moment. I highly dislike that my “live” map has a waypoint sitting in a covered part of dry top, because for some odd reason they updated that part of the api, but not all of it. :/

It’s not that easy, for three reasons. First, the in-game map is actually two sets of tiles: the painterly background and the detailed foreground. Second, the detail textures are set up with transparency layers necessary for the underwater areas. Third, the detail textures extend beyond the in-game boundaries.

So that’s three steps necessary to transform the textures into map tiles: 1) remove the underwater transparency from the detail textures and overlay a solid blue/green color on the underwater regions; 2) enforce the zone boundaries on the detail textures; 3) overlay the detail textures onto the background textures.

StevenL.3761:

Fun fact: the official Atlas has the same problem: http://atlas.guildwars2.com/en/#/map

That’s because the Atlas uses the tile service.

AysonCurrax.3254:

well, they would just have to take the ingame map as it is now and cut that up into 2^n by 2^n pieces.

That’s already how the map is stored in Gw2.dat. Sometime last year I had gone to the trouble of extracting all the tiles and setting up my own custom map using the Google Maps API, but it was too much work so I mothballed the project.

Time to practice my thread necromancy… ABRACADABRA! puff of smoke coughcough blink Hey, it worked!

Guess what guys? Floor 1 is fixed! I ran ElGreenGo’s fiddle, and all maps show 1 instance in the output JSON. I specifically searched for the 5 last known bugged map names, and all of them appear only once.

Just found an old post from Cliff about this:

https://forum-en.gw2archive.eu/forum/community/api/Possible-map-floor-API-bug/first#post2417992

Floors are used to determine what maps/sectors/points to display on the in-game map. A floor is basically an abstract plane along the x/y axes at a specific coordinate on the z-axis. Your character’s position on the z-axis determines which floor you are currently on, and that determines what is shown when you open the map. There is a floor-selection control in the bottom right of the map that lets you display floors other than the one you’re on. The effect is really obvious in Rata Sum and The Grove – the base map texture is different for each floor, and the points not on the displayed floor get faded out.

A map’s default_floor (and a point’s floor) is the floor on which it should be shown in full opacity. A map’s floors define when it should be shown at all – this is why story instances share floors with the standard PvE maps, but dungeons and other non-standard maps each get their own floors (and why the continent of Tyria has 64 floors).

Ah, I guess didn’t understand what your point was. This should be reported in the Game Bugs forum, not here.

The TP API isn’t officially supported (yet), so assuming this is intended as a bug report, don’t expect any response.