Guild Wars 2

To whom it may concern in the ArenaNet Staff:

Can we get a clarification on exactly where left and right side arcs begin and the forward and rear arcs stop, preferably in a visual form? While there is some intuition about what this could be defined as, not everything matches intuition.

It’s straightforward to imagine what “behind” a character in Guild Wars 2 is, but the areas defined as “left/right flank/side” is ambiguous. It would be helpful to have a clear definition of these “facing areas” so that players can be more tactical about their movement, especially when dealing with classes and creatures that have bonuses or can nearly kill you in one hit with a flanking attack (i.e. thieves, Mordrem Wolves). I’ve certainly had moments where I’ve felt like I’ve had a creature/player in my forward arc, but they’ve still managed to get their flanking bonus damage.

To give an example of what I’m talking about, Privateer Press, the makers of the tactical miniatures games Warmachine and Hordes, utilize Front and Rear arcs in their game mechanics. DakkaDakka has a reference image for what templates used in marking front/rear arc look like in an article on their site. Flanking in the Privateer Press world is a special ability and may differ in function for individual units.

Furthermore, the 3.5 Standard Reference Document for Dungeons and Dragons also provides another definition for facing arcs and when flanking is triggered; flanking in the 3.5 D&D SRD world requires two people attacking the same creature in its flanks to get bonuses (not one like Guild Wars 2).

Thank you!

Chiuna.2538:

For the official API is there a way to generate a list of all items of a certain type?

I’m looking to create a database of all the minipets in the game (and automate the process of keeping the database updated when new minis are released). I can get the item type from the official items API and discard the results that aren’t minis, but that means going through a lot of non-mini ids too. It isn’t too big a hurdle since I won’t need to update my list very often, but maybe I’m missing an easier solution?

For my purposes I don’t really care about anything more than keeping an updated list of mini names, ids, and icon paths so if anybody has an alternative suggestion of a good source for this info that would also be welcome!

I submitted a Feature Enhancement Request to provide something similar for the Recipe endpoint. Perhaps they’ll extend it to additional endpoints in the future.

One way to formally ask for that kind of functionality is to just open a thread asking for that feature, along with specific examples of what you would like for it to do, how, and why. It may not get at the top of the list, but it never hurts to ask; the worst that happens is they don’t ever implement it and you’re stuck with the brute-force method of handling the data.

If you would like an example, albeit a non-definitive one, on how someone might submit a feature request with enough meat for the developers to at least chew on, take a look at my thread:

https://forum-en.gw2archive.eu/forum/community/api/FEATURE-REQUEST-API-Query-Search-Enh/first

For now, keep using the brute-force method; implementing new API features is probably very low priority on their list at the moment due to the imminent HotS release. However, if you document what you’re looking for, they can at least have something to put on their project plans for the next few quarters if and when they get cycles.

Alpha.6913:

Why dont you get all game items through theyr json and insert them in your database? By all items i mean all 40k items more or less. Sorting and any criteria you wanna apply is faster through getting them from your database.

I already know what I can do to resolve this problem, but that’s not the point of a Feature Enhancement Request.

The point of a feature request is to ask a developer if they would be willing to enhance their product to provide additional functionality. It’s not a demand, it’s an inquiry.

Also, I’m not interested in sorting through items, I’m interested in enhancing the recipe search functionality.

Strategist.6132:

I think it would be nice to have, but I wouldn’t put it as a priority.

No, this is definitely not a high priority; most feature enhancements are intended to be nice little things for software developers to consider adding to their code. If it was a problem, I should be filing a bug report instead of making a suggestion for a new API extension.

Strategist.6132:

I mean right now you can easily mimic what that API is supposed to do. AKA:

- Pull all items to your own server (using the /v2/items/ API)
- Make your own search API. (Which shouldn’t be that hard I guess)
- Let users or your own site/app/program use that API.

Yes, I could reinvent the wheel as many other people have; I could even consider using one of the other APIs that people have implemented; however, if enough people implement the same function when doing the basic data grab, before their application has even had a chance to actually do something with the data, what that says is that the API users may be better served by having ArenaNet implement that basic functionality into their API. That’s one of the reasons I’m making the suggestion.

Strategist.6132:

I guess this also relieves some stress of the GW2 API servers.

It can, depending on whether they’re also utilizing their own API servers in-game. The bandwidth savings could be quite substantial all for having a dedicated search function that handles specific, repeatedly-used requests. That’s something for them to determine in-house to see if there is a benefit for rather than for us to speculate on, however. This function can, in theory, also be extended to or borrowed from the Black Lion Trading Post.

Strategist.6132:

Even though I don’t think the idea’s you provided would be that heavy to implement/run.

No, performing the initial query may not be so bad, but performing subsequent recursive queries only to throw away the data is, especially if your application updates that single dataset frequently. It’s wasteful of both a site’s and ArenaNet’s bandwidth if they don’t want all of the data.

Strategist.6132:

But for example a /v2/recipies?name= operation, where you search for recipes with a word in the title of the recipe, would quickly get spammed by autocomplete functions of developers and wouldn’t be a good idea.

Because someone can’t implement that now if they were so inclined? If there is a concern about constant queries from external, non ArenaNet sources, my guess is they’re addressing it. And if not, they might be soon. Who knows for sure?

Strategist.6132:

The idea is nice! But not really neccecary right now I think.

Thank you, and I agree; this feature isn’t something that needs to be implemented right this very moment. I expect that if Pat Cavit and his team take this on, this will be a slow burning project released over the next year or two, if that. I have no idea how many developers they have and with Heart of Thorns coming out in a few months, plus other balance and bug fixes, they have their hands pretty full. This is definitely a “would be nice to have” and I’m not holding my breath waiting for it.

Thank you!

Pat Cavit.9234:

We’re going to do some experiments around searching to see if we can’t start offering richer search APIs in the future. Can’t promise anything though.

Pat,

I definitely appreciate you guys considering it. My hope is that simplified searches will help reduce the overall number of queries, application processing, and network traffic required for someone to get a set piece of information. I know you all have a lot on your plate and there may not be adequate demand for these, but seeing as some of the in-game browsing also uses, or at least seems to use based on the APIs, HTTPS for communications (and likely processes the information gathered from these same JSON queries) this might be helpful in the long run as a slow-burner project.

If there’s anything I can do to assist, please feel free to reach out to me either in-game or via message here.

Thank you!

To whom it may concern:

Would it be possible to add in the following enhancements to recipe:search :

Search by Profession (i.e. Armorsmith, Weaponsmith, &c)
Envisioned as: http://api.guildwars2.com/v2/recipes?discipline=DISCIPLINE

Search by Type (i.e. Axe, Bag, &c)
Envisioned as http://api.guildwars2.com/v2/recipies?type=TYPE

Search by Profession Skill Tier (i.e. Novice, Adept, &c)
Envision as http://api.guildwars2.com/v2/recipies?tier=TIER
NOTE: This could simply be an alias to a query that knows to look for the floor and ceiling values of the Tier range. The back-end query, assuming an RDB, would be something along the lines of
SELECT PARAMETERS FROM DATABASE DATABASE WHERE min-range BETWEEN TIERSTART AND TIEREND

Multiple Constraint Returns (i.e. Search by Profession AND Tier)
Envision as http://api.guildwars2.com/v2/recipes?profession=PROFESSION&tier=TIER

Add Name as a field in Recipe Information
This reduces the number of client cross queries that have to be made. If using a RDB, then this could also be programmed as a view presented via the API. At the moment, I must make a query to recipe, then make a query to items and compare on items.

Eventually, it would be nice to fully implement the recipe:search function to be able to search on any of the multiple fields present within each recipe record. In lieu of that, however, this is probably the bare minimum needed to allow for end-users to retrieve specific datasets without having to gather ALL of the data at one and then sort through it manually.

Technically, some of these queries already exist in game. In essence, what I am asking is that the API provide some of the in-game sorting and querying functionality via the JSON Query Interface for consistency (and also so that API end-users don’t have to use brute-force when doing initial builds and retrieves of specific data sets).

If you have any questions, please contact me via whisper in-game.

Thank you!