Mumble Link position incorrect
Archomeda.6472:
Currently I’m developing a plugin for TeamSpeak to show some information about users who are online in GW2 using Mumble Link. This also includes a comparison with waypoint locations to get the closest waypoint nearby.
All well and fun, until I got a weird positioning problem while trying this out on my other character who currently resides in Caledon Forest. It seemed that the current position of the player was slightly translated to the north. Okay, no problem, maybe I messed something up in my code. So I used my test application to show more detailed information from the Mumble Link, but it showed the exact same problem. Although the plugin is written in C++ and the test application in C#, the odds I made an error is still significant, albeit a bit less. Then I went to The Grove, and surprisingly, everything is fine there.
I made two screenshots. The first is from Caledon Forest on top of Astorea Waypoint, the second is from The Grove on top of Caledon Waypoint. I surrounded the calculated distance (based on continent positions) with a red color. And as you can see, it seems to be 128 units off (funny, since this is exactly 2^7). If you can figure out my overusage of the textboxes, you can compare my character’s current continent position with the waypoint continent position fetched from the API.
One small remark on the screenshots though: you need to interpret the text directions as “character is <direction> of that waypoint / POI”, and not the other way around.
Now I’m still not sure if I made an error here (although the odds are really low since Lion’s Arch and Gendarran Fields also seemed fine last time I checked). So I’d like someone to confirm my problem here (or not) to see if this is an error on my or GW2’s end. If it ends up to be an error on GW2’s end, then I’ll try to hunt down more positioning problems in other maps aside from Caledon Forest.
EDIT: I went ahead and tried to list every map other than Caledon Forest with the same problem. My results are as follows: Queensdale, Brisban Wildlands, Caledon Forest, Mount Maelstrom, Timberline Falls, Dredgehaunt Cliffs, Bloodtide Coast and Hoelbrak all have the same offset of 128 to the north in continent units. Still no clue why since the other maps are fine (I did not try to list instance maps as there are simply too many).
Elrey.5472:
You have one of the characters in the sylvari home area. Although i know nothing about mumble or the APIs of gw2, i think i did read somewhere that you couldn’t check in wich level the character was. Positioning of altitude was a problem and could mess up some stuff. (sorry about my broken english).
Try to search more info about that, maybe the altittude is a problem since the sylvari home place have so many different levels.
Archomeda.6472:
You’re correct about not being able to get the level where your character is at currently. But that’s irrelevant here. If I would forget parsing some levels specified in a specific map in maps.json, I would be missing waypoints, not waypoints/POIs that are slightly off (believe me, I encountered that already a few days ago when I only parsed the default floor and not all of them).
Let me explain something else too. The position of POIs/etc. are defined as 2D (x,y) coordinates only, which gives something like this:
{"poi_id":308,"name":"Astorea Waypoint","type":"waypoint","floor":1,"coord":[9955.92,
19833.2]}The coordinates you get from Mumble Link, are defined as 3D (x,y,z). After some conversions to get it in the right units, you can compare the (x,z) with the (x,y) of the POI. The “y” in (x,y,z) is the vertical axis a.k.a. the height. I completely neglect that value when comparing, because I have nothing else to compare it with.
Long story short: I only compare the coordinates in a 2D field because that’s the only option that’s available.
Nevertheless, I appreciate your reply 
but I think the problem lies somewhere else.
My thoughts are: either the client writes incorrect positioning data to Mumble Link, or the API incorrectly defines the map_rect or continent_rect of Caledon Forest (because that’s what the units conversions depend on), or I am doing something horribly wrong. That’s why I really want someone else to try confirming this with their own code. This way the odds that my code is wrong will be significantly less than what it is now if I’m indeed correct about this.
Also, a small note, I went to see if the coordinates of the waypoints of Caledon Forest are incorrectly defined in the API, but I can confirm visually with the help of some snippet that Cliff made and the ingame map that those coordinates are correct.
smiley.1438:
Have you tried checking it with our Location Tracker<"https://gw2apicpp.codeplex.com/SourceControl/latest">https://gw2apicpp.codeplex.com/SourceControl/latest
Oh btw. it would be great if your TS plugin would also feature sending the location data to a specified server too
Healix.5819:
For Astorea Waypoint, I get the coordinates:
-6819.29x, -39774.16y, -192.28z
According to the API:
continent_rect.×1 = 9344 px
continent_rect.y1 = 16128 px
continent_rect.×2 = 11264 px
continent_rect.y2 = 20096 px
map_rect.×1 = -21504 in
map_rect.y1 = -46080 in
map_rect.×2 = 24576 in
map_rect.y2 = 49152 in
coord.x = 9955.92 px
coord.y = 19833.2 px
Using the formula to convert pixels to in-game coordinates:
x = (coord.x – continent_rect.×1) / (continent_rect.×2 – continent_rect.×1) * (map_rect.×2 – map_rect.×1) + map_rect.×1
y = (1 – (coord.y – continent_rect.y1) / (continent_rect.y2 – continent_rect.y1)) * (map_rect.y2 – map_rect.y1) + map_rect.y1
x = -6817.922 in
y = -39772.78 in
In reverse, using the in-game coordinates to find the pixels:
x = -6819.29 in
y = -39774.16 in
coord.x = (x – map_rect.×1) / (map_rect.×2 – map_rect.×1) * (continent_rect.×2 – continent_rect.×1) + continent_rect.×1
coord.y = (1 – (y – map_rect.y1) / (map_rect.y2 – map_rect.y1)) * (continent_rect.y2 – continent_rect.y1) + continent_rect.y1
coord.x = 9955.863 px
coord.y = 19833.26 px
Archomeda.6472:
@smiley: I tested it and it was correct, and I see the problem now thanks to Healix.
A while ago when I started to mess around with locations, I read somewhere that the z-axis of Mumble Link was inverted. Without looking further into it I used it again (just putting a minus on the z-coord, as you probably can see in the screenshots). But now I see that it is incorrect in some cases.
In the incredibly extensive formulas Healix wrote down, I noticed that it is still somewhat inverted, only in another way. This part was my problem:
coord.y = (1 – (y – map_rect.y1) / (map_rect.y2 – map_rect.y1)) * (continent_rect.y2 – continent_rect.y1) + continent_rect.y1
What I did comes down to this:
coord.y = (-y – map_rect.y1) / (map_rect.y2 – map_rect.y1) * (continent_rect.y2 – continent_rect.y1) + continent_rect.y1
I manually checked some random waypoint in Bloodtide Coast, and with that small change in the formula, it is now correct.
@Healix: Many thanks for your effort! I really appreciate what you’ve done to help me identify the problem. The way how my calculated coordinates were correct for most maps clouded my vision and let me believe the problem was somewhere else. Now I only have to implement it.
@smiley again: I will put it on my todo list. Since I’m just a novice in C++ I need to work out how I can POST to websites (also a settings screen in TS, but first the core features). Really, this is the first time writing something of this scale in C++. Having a background of C# and somewhat of C certainly helps a lot. I’ll post in the API section again when I’m ready to release it, although you can already check out the source on GitHub if you want.
EDIT: Just a random note regarding to this, wouldn’t it be easier to put these formulas on the wiki for easier access? I notice a lot of people are having trouble with the conversion between coordinates.
Nekonome.9076:
I just fumbled on the same problem on my project, i was considering posting but you made it before i do
Thank you for the post, and Healix, for the answer !
smiley.1438:
EDIT: Just a random note regarding to this, wouldn’t it be easier to put these formulas on the wiki for easier access? I notice a lot of people are having trouble with the conversion between coordinates.
These are already over here in multiple threads – have a look at this one:
https://forum-en.guildwars2.com/forum/community/api/How-to-convert-from-Mumble-to-Map-API-Coords/
I’ve added the formula to the german translation of the API docs back when i did the translation:
http://wiki-de.guildwars2.com/wiki/API/v1/event_details
Since noone seemed to adopt it, i’ve added it to the english wiki too (right now):
http://wiki.guildwars2.com/wiki/API:1/event_details
Archomeda.6472:
These are already over here in multiple threads – have a look at this one:
https://forum-en.guildwars2.com/forum/community/api/How-to-convert-from-Mumble-to-Map-API-Coords/I’ve added the formula to the german translation of the API docs back when i did the translation:
http://wiki-de.guildwars2.com/wiki/API/v1/event_detailsSince noone seemed to adopt it, i’ve added it to the english wiki too (right now):
http://wiki.guildwars2.com/wiki/API:1/event_details
Looks nice! Although I’m not really sure about code examples in specific, it does its job to provide details of the conversion in just a few lines. And converting it the other way around should be easy to figure out too with this example. The only catch is that “1 – …” in the y-coords in my opinion.
smiley.1438:
Since most people tend to use a TL;DR version i think it’s totally ok in this case. If one wishes to see a further explaination, he could just hop over to the linked forum thread.
Healix.5819:
The only catch is that “1 – …” in the y-coords in my opinion.
The trick is that map_rect is given to you in a rectangle format that has been converted from x/y coordinates, causing the y-axis to be inverted. Instead of reading it as a rectangle [left, top], [right, bottom], it’s the axes [west, south], [east, north] where the x/y point [0, 0] is the center of the map and z<0 is above sea level.
If you prefer it, instead of going “1 – …”:
coord.y = (map_rect.y2 – y) / (map_rect.y2 – map_rect.y1) * (continent_rect.y2 – continent_rect.y1) + continent_rect.y1
Archomeda.6472:
Since most people tend to use a TL;DR version i think it’s totally ok in this case. If one wishes to see a further explaination, he could just hop over to the linked forum thread.
Agreed, that’s a valid point. We all want that nowadays, and if you are at least experienced in a language, you definitely should get the gist of it
The trick is that map_rect is given to you in a rectangle format that has been converted from x/y coordinates, causing the y-axis to be inverted. Instead of reading it as a rectangle [left, top], [right, bottom], it’s the axes [west, south], [east, north] where the x/y point [0, 0] is the center of the map and z<0 is above sea level.
If you prefer it, instead of going “1 – …”:
coord.y = (map_rect.y2 – y) / (map_rect.y2 – map_rect.y1) * (continent_rect.y2 – continent_rect.y1) + continent_rect.y1
Huh, it never occured to me that you could also see it that way. I will stick with the first one, since it’s easier with the way how I implemented the structs. But thanks for the explanation!
Wothor.4781:
It’s also completely implemented in CrossTalk including Server-Sent Events, soon switching to WebSockets.
It’s also on GitHub, so one might contemplate if it wouldn’t be more effective in joining me to improve one implementation instead of creating several, just saying.
Archomeda.6472:
It’s also completely implemented in CrossTalk including Server-Sent Events, soon switching to WebSockets.
It’s also on GitHub, so one might contemplate if it wouldn’t be more effective in joining me to improve one implementation instead of creating several, just saying.
I have seen CrossTalk, and although I haven’t tried it myself, I think it’s some pretty awesome stuff just to implement positional audio in TS. But that’s also the catch: I’m not implementing positional audio (also not planning to). What I’m doing is very specific for GW2 itself: provide GW2 location tracking information about other people on the TS server as you can see in the screenshot. I figured that this is a whole different usage concept than the one of your plugin.
Wothor.4781:
I do have the playing as info in it, I do have a server for a javascript/html fork of smileys running which shows the users on a map using the positional data of all users in the channel, all specifically for gw2.
The primary reason I did not add the positional info on the ts window itself is that I found it preferable to see such info on an overlay like overwolf and I found it more appropriate to do the Web API stuff there if you have a web app anyways.
Hence I don’t think it’s such different in the end, or to put it another way, I’d like to avoid ending up with having two plugins on an end-users machine that simultaneously parse the link as well as communicate the positions over the interwebs. At the latest point when you’d add plugin communication to show other ts users positions, we’d be conflicting for ressources, like Teamspeaks spam system applying to plugin communication, at which point we’d potentionally have to vice versa recommend to disable the other one. So I figured joining forces could be the lesser evil ;P
Otherwise it’d be adviseable to have a concept to work around such, which I feel could end up being more work afterall.
Archomeda.6472:
Ah, that’s something I haven’t found yet in your source.
And yeah, about Overwolf, personally I don’t like it for various reasons that will take too much space in this post if I explain it.
Anyway, it seems you share the same thoughts as me with providing location tracking and everything that comes with it. And I agree that the plugin commands restriction is somewhat annoying to work around with, the only solution is to limit the commands, which is what I’m effectively doing (standing still shouldn’t send any new location information, since it’s useless). But yeah, it’s possible to join forces. At least if we could also add some information in the client itself directly (like I’ve already started working on), and not only in an web app through Overwolf. Shouldn’t be that hard, since most people play 1 game at a time, so it wouldn’t take up space from possible information about other games . Also, it would be fantastic to show locations it in the normal browser as well, for second screen purposes (which I like more than having an overlay).
Wothor.4781:
The WebApp doesn’t care if it’s run in OW, Project Kryptonite or a web browser, once I allow LAN connections (in case of browser compatibility) it should even run on smart phone tablet stuff.
However, since there’s obviously a demand for showing some info in TS itself, I can let that overrule my initial preference of just pushing the info out, sure
Writing a pm to discuss further procedure.