Guild Wars 2

Hello
I need for my app to get the position of my online character on PvE maps, with a request every 3, 4 seconds (would be great). Without the Mumble hack, is it possible ? The API can’t do that ?

No, the API can’t do that yet. Thats why we still use the Mumble Link API.

Thanks, okay… I just have to understand how use this mumble link api with an Overwolf app :/
“okay you can use my app but you need to install overwolf and mumble !” >< Great !

You can use the mumble api without having overwolf or mumble installed, as far as my understanding goes. I haven’t tried it, but in theory you can access the specific shared memory from every program the same way mumble does. But you have to run your app on the client and can’t use the mumble API on a website.

ilokogi.4015:

Thanks, okay… I just have to understand how use this mumble link api with an Overwolf app :/
“okay you can use my app but you need to install overwolf and mumble !” >< Great !

Oh, you’re using Overwolf, here’s help: https://github.com/meh/npapi-mumble-link
I’m using it in my location tracker app
https://github.com/codemasher/Overwolf-Locationtracker/blob/master/app/files/js/gw2location.js#L940-L978

Thanks you all
Don’t know how to use the npapi part, but i found a way in python from https://github.com/zeeZ/gw2-location/blob/master/client/location_senkitten
thanks to the python tutorial I read today

So what exactly are you doing? Do you write an Overwolf app or a python script? The NPAPI plugin was made for Overwolf.

I don’t find how to use the NPAPI plugin with my Overwolf app :/

Edit : type of mumble().identity is undefined

Searching what “<embed id=”mumble" width=“0” height=“0” type=“application/x-mumble-link”>" means and how to use the NPAPI plugin. Reading your files for Locationtracker but not easy ^^
My javascript crashes on this line :
if(navigator.mimeTypes[‘application/x-mumble-link’]){

Ok it works. Thanks !

See this thread: http://forums.overwolf.com/index.php?/topic/3043-mumble-link-plugin-released/

and these examples:
https://github.com/meh/npapi-mumble-link/tree/c5465a9a3e722535d9ff6289d16b3eb0c8835769/examples
http://forums.overwolf.com/index.php?/topic/3043-mumble-link-plugin-released/page-2#entry12257

I have accents problems with this.
“Mélandre” becomes “M?landre”

.charCodeAt(0) = 65533
… mumble().snapshot() use unicode without escaping/encoding ?! :/

Trying to compile npapi-mumble-link from github.com sources, maybe updated for utf8… but some problems :p file not found with mingw32-make

Hey!

Are you trying to make an Overwolf app? Have you tried asking for help on our development forums or shot an email over to Developers@Overwolf.com? We can help you out with the Overwolf specific parts if they’re giving you some headaches.

Lawton Campbell.8517:

smiley.1438:

No, the API can’t do that yet.

Just to note — real-time fine-grain access to character position is never going to be something we can provide. The closest we’d be able to get is which map they’re currently on, not where on the map they currently are.

Speaking of which, it would be very useful to me to have the following information with a low TTL (a minute or less)

• Online status (online/away/offline)
• Character most recently logged in (i.e. if status is online, this is the character they are on now)
• Current map
• Amount of supply carried

Might fit perfectly into the characters endpoint. May someone please reopen https://github.com/arenanet/api-cdi/pull/16

Overall, I like the course grained approach. It’d also tell you where you parked a character, info which is listed on the character select page, so I’d think it’d be cached somewhere convenient, but again, I’m not in your codebase.

This would be handy for me, since I tend to park my alts by rich ore nodes, and remembering which is where can be a chore.

Lawton Campbell.8517:

smiley.1438:

No, the API can’t do that yet.

Just to note — real-time fine-grain access to character position is never going to be something we can provide. The closest we’d be able to get is which map they’re currently on, not where on the map they currently are.

May I ask why this is not possible? Every character has an XYZ coordinate that is also being used to show to party-members (or WvW people).

I could imagine the API only reads information form the database and the character positions are obviously not in the database, however one would think you could ask the server that information (just as the cliënt does get that information).

It would be great if we could get that information, from my viewpoint not only from your own character, but from all guild-members, so you could show the location of all the members.

Lawton Campbell.8517:

Devata.6589:

Lawton Campbell.8517:

smiley.1438:

No, the API can’t do that yet.

Just to note — real-time fine-grain access to character position is never going to be something we can provide. The closest we’d be able to get is which map they’re currently on, not where on the map they currently are.

May I ask why this is not possible? Every character has an XYZ coordinate that is also being used to show to party-members (or WvW people).

I could imagine the API only reads information form the database and the character positions are obviously not in the database, however one would think you could ask the server that information (just as the cliënt does get that information).

The map instance servers are the only ones that have real-time character position data and aren’t designed to have arbitrary bits and bobbles connecting to them. Strictly speaking, it isn’t impossible, but I don’t want to couple them to the API infrastructure.

Thanks for the information. This does then also explains why you can’t see (group) player locations on other maps , while it does not explain why you can see it from players in the same map but another instance?.

Clearly it would be possible as the client is requesting the same information (at least from your map) but I guess those servers then don’t really have an general Api where the client can request such information but it’s more tangled together.

I would suggest at least keeping this possibility in the back of you mind so that if some work gets done on the ‘instance code’ that might make this a more viable option we might get that possibility at some point.

Purely from an Api user perspective the ability would be great but I understand that from a development perspective it would not be high on the list.

Again thanks for the information.

Lawton Campbell.8517:

Devata.6589:

Lawton Campbell.8517:

smiley.1438:

No, the API can’t do that yet.

Just to note — real-time fine-grain access to character position is never going to be something we can provide. The closest we’d be able to get is which map they’re currently on, not where on the map they currently are.

May I ask why this is not possible? Every character has an XYZ coordinate that is also being used to show to party-members (or WvW people).

I could imagine the API only reads information form the database and the character positions are obviously not in the database, however one would think you could ask the server that information (just as the cliënt does get that information).

The map instance servers are the only ones that have real-time character position data and aren’t designed to have arbitrary bits and bobbles connecting to them. Strictly speaking, it isn’t impossible, but I don’t want to couple them to the API infrastructure.

Would it be possible to pull information on the last waypoint or “landmark” a character passed?

Also, to the post above, the game does show where party members are in another map, just not with the fine detail as it would on the same map.

Over time, from listening to various comments that Lawton and other devs have made, I believe I have a rough understanding of the general types of servers that ANet employs to run the game. (Of course, I might be wrong, but what I’m going to say should apply in broad strokes).

There are several different classes of servers. At a minimum we have:

• Login Servers, which could also likely be called “Character Servers”. These are responsible for holding all of the durable information about your account and characters.
• Trading Servers, basically, the Trading Post, and likely the Gemshop as well.
• Map Servers. Each of these drive one or more map instances at a time.
• Asset Servers, which are what the client downloads textures, sounds, etc from.
• Config Server, where they are able to do things like disable a trait on the fly, or where gem store sales are turned on or off, etc.

When a character enters a map, they connect to the appropriate Map Server, when then contacts the Login Server, and checks out a copy of the character. The Map Server is in charge of player location, combat, etc. Any changes made to things like inventory are first applied at the Map Server, and then pushed to the Login Server on a frequent basis (details a bit fuzzy here, and rightly so, as this gap is where duplication bugs crop up in other games).

With the API system, they’ve added another set of servers, which I’ll call:

• API Snapshot Servers.

When an API request is made, it looks to see if it already has that information snapshotted. If so, it serves it directly. If not, it goes out and asks another server for that information. In order to ask those servers for information, an internal connection has to be built to allow for that. This can often take a lot of effort, since those other servers likely never expected to have these types of requests asked. Also, extreme care has to be given that these things are done correctly, so that the stability of the main game is not compromised. Thus, many of the delays in getting information are likely a result of coordination with the team which owns those other servers.

The first round of APIs were able to pull things from Asset and Config servers, and as such only gave you global information, which was mostly static. (Though I’m not 100% sure how event information was pulled). Later, we got a connection to the trading post added, which was later upgraded to give per person information. Most recently, we’ve gained access to the Login servers.

This request is about getting information about current location. This is strictly a function of the Map Servers. There’s several issues that come to mind with getting this:

• Update Speed. The API system is set up to take snapshots, and then serve off that snapshot for many minutes. Changing to a direct feed would require some rework.
• Potentially significantly increased load on Map Servers. Constantly getting this information isn’t free. Responding to requests takes resources, especially if many people do it at once. Think of a WvW map, where several of the major guilds are using this to coordinate attacks. Would this be worth it if in response to this side load, they had to lower the max map population by 15 people?

Overall, the effort needed to make this happen is very non-trivial. Meanwhile, there are lots of other things that can be done with the newfound connection to the Login servers, such as Wallet, Unlocks, and Guild info. From the Asset and/or Config servers, we can get things like Skills, Specializations, and Traits.

There’s also the overall question of the right tool for the job. Is a constant stream of pull requests against a REST API the right way to do this? Or should we instead look to expand on the Mumble model, where we’re getting information direct from the client, and thus avoid many of these issue. We’ve already got location and map information kludged into the Mumble API. Perhaps at some later point, we could get a similar direct memory tool which expands on this more cleanly. These things, however, almost certainly would require the effort from people on a team other than those currently working on this API.

Hope that helps.

PS – I’d love to know how wrong I am about your server structure.
PPS – I also understand if you’re not allowed to tell me.

“Potentially significantly increased load on Map Servers. Constantly getting this information isn’t free. " For the ‘API-server’ yes as it would now start to make sense to have a request every second or so, for the map server not really. Your Api server would basically act as one client and request locations of players on a map just as your client does now. I am not sure how fast this gets updated but lets say 1/30 of a sec. So the load on the Map server would be about the same as that from one player.

To come back to your snap-shot.. it would ‘snap-shot’ / hold that information until it gets updated 1/30 sec later.

People using the Api would not result in additional requests to the Map server and so even a DDOS attack would only kill the API server, not the map-server.

Knowing that the new WvW maps have the ability to show all players that walk by a tower it means it should not really be a problem to get the position of many / all other players, and relay that information to many clients. You would now do the same but only relay that to one other server, the API server and the API server would then relay that information back to anybody who asks him.

Maybe the problem is that I would not be requesting just locations of people on a map but locations from specific players. However if the API would be like a client that is on all maps / instances I would think it then does have the information it needs (an ID and a location).

Surely they are difficulties if Lawton says so, but I don’t think it would be the additional load for the map-servers.

Lawton Campbell.8517:

You’re not far off the mark, though there’s an order of magnitude more servers than the ones you’ve listed.

Cool. As someone who works on non-game systems that are just as complicated, that’s totally reasonable. I just haven’t heard you guys talk about the other servers, so don’t know what you’ve decided to lump together vs break off separately.

The 30s cached option sounds intriguing, though.

That is great to hear. So maybe we might get that information after-all..?

The fact that the position is not exact is not a huge problem if you just want to give an indication of where players / guild-members are.

Thanks for all the information. It’s really nice to know what we might see, what we might not see and be able to so directly tell what we would like to see and hear why some things might not (or different) be implemented anyway.