Guild Wars 2

My notifier is broken for a few weeks now. (https://forum-en.gw2archive.eu/forum/game/bltc/Zicore-s-Trading-Post-Notifier-Open-Source)

I was working on implementing the official API. My apps heart was basically the search function and there is currently no way to do that. So I tried to fetch all items to deploy the app with a local search later. Unfortunately the item_details.json only delivers one detail per request. Requesting all details in all languages would take a few days to complete.

I’ve read that the API v2 supports multiple items in one request, but it’s disabled.

• Is there any roadmap for API v2 especially items?
• Is it possible with the current API to make multiple requests at once (item_details.json)?

I would also suggest to implement an item search in the API.

1) “/v2/items API isn’t active yet as we’re still polishing up some bits.” (source / more info)
2) No.

Search endpoint might be coming [source], but i suggest keeping your own database to be able to search it the way you want and to have faster lookup times.

Don’t worry about how long it takes to populate a database. You only have to do it once for the lifetime of the installation.

Lazy solution: create a database table with just 4 columns:

• item_id
• build_id
• language
• name

Then, create a background service that periodically checks for new item identifiers, and also keeps existing items up-to-date based on their build_id. The end result is a searchable index of items that is updated regularly.

You can decide to add additional columns based on how complicated your search engine should be: item_rarity, level, description (…).

For everything that isn’t going to be used by your search engine, do use the item_details.json API.

Thank you guys. Probably going to implement a local database then. Any Ideas what to use for C#? I don’t want the end user to install MySQL or something so it should be lightweight.

StevenL.3761:

Don’t worry about how long it takes to populate a database. You only have to do it once for the lifetime of the installation.

Wrong. Do you know how often even the names of items change? There’s some more languages than just english. Also, if you want to offer an extended search, you need to run an updater after every new build. There’s a reason why so many people asking for a list of changed item ids for each patch.

TehGear.8702:

Thank you guys. Probably going to implement a local database then. Any Ideas what to use for C#? I don’t want the end user to install MySQL or something so it should be lightweight.

What about CSV? This way you could also easily offer updates.

smiley.1438:

What about CSV? This way you could also easily offer updates.

Well, I currently use JSON Files, but they would be huge and it would take a decent amount of time to load these files into the client. Whether I use CSV or Json wouldn’t make much of a difference I suppose.

Either way, I’m going to test how long it will take to load a 65k Items json file.

There’s for sure an advantage over JSON. You just need the seperator in CSV while you need all the braces and quotes in JSON, so CSV will save you a couple of bytes.

Also: if your app isn’t a web app anyway, loading times won’t matter that much i guess.

smiley.1438:

StevenL.3761:

Don’t worry about how long it takes to populate a database. You only have to do it once for the lifetime of the installation.

Wrong. Do you know how often even the names of items change? There’s some more languages than just english. Also, if you want to offer an extended search, you need to run an updater after every new build. There’s a reason why so many people asking for a list of changed item ids for each patch.

While the updater is updating the database, the search engine can still use the (partially) outdated data. The real problem is that right after installing the app, the updater hasn’t had a chance to bring the database up to date. So any given search would return 0 results until enough time has elapsed to populate the database.