Guild Wars 2

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.

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.

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.

While not being targeted for the question, let me just state that for me it works out just fine.
However, I wouldn’t claim it makes that much of a difference to a non-celestial mix really.
Best return of investment is iirc helmet, chest and legs, might wanna double check that though.
Generally, I wouldn’t go full, which would lack a little in power, precision, toughness for my taste. Given that we have quite some thoughness from the spec here, I’ve primarily pushed power and precision up to my comfort zone and have condi dmg delivered solely from the celestial items – so there’s some tendency towards a power build stat wise, but I’m cool with that.

That should be the Mistlock Observatory in the Fractals of the Mist.

Well, there’re two timer widgets and I just found out smiley’s gmaps-location has appeared, too.
Seemingly semi-redundantly I happen to code one based off the leaflet variant myself, with some extra fluff like using CrossTalk as position server.

maps.json is affected, too.

Hi folks,
I’ll try to explain.
Traditionally, positional data was aquired by reading the game’s very own ram.
This means, that for each game the positions in ram for the player positions needed to be recherched, often also again for game updates.
That’s both a lot of work and has this damocles sword of game companies making trouble on it.

MumbleLink as a solution to that is actually one of the oldest tricks in the book regarding “Inter-Process Communication”: Meeting on neutral ground, shared memory. However that means the developer himself must add support for that.

When a game company announces support for mumble link, it declares that it copies the relevant (positional) information out of it’s own memory into a shared memory object called “MumbleLink”.
You can imagine a shared memory object being a file in your user folder, it’s actually “owned” by the operating system and not by any party involved, with contents like:
game: “Guild Wars 2”
player_x: somevalue
camera_x: somevalue
and so on.
Yep, it’s even necessary to write the game name into that, because the processes don’t make any contact at all – they just pay a visit to the same place without ever shaking hands.
50 times a second the game writes the info to it.
x times a second whoever has a look at the contents.

Result, those problems, the previous need to attach to game ram, having to have individual recherche for a game as well as the fragileness with game updates are solved.

The sole thing that involves more work, is that when using the traditional method, with enough sniffing around you’d be able to get positions for other players. MumbleLink only covers the player avatar itself. Note that this is not a technical limitation, but just how the “convention” how our shared memory looks like is currently. That’s why CrossTalk, Mumble etc. need to communicate positions over the TS/Mumble server, as it takes at least two to have a directional relationship.
Imo that’s ok, since it elevates the users privacy of his own position although it caused a lot of trouble for me fighting with Teamspeaks anti-spam system since they had only rare user interactions in mind for plugin communication, not the higher frequency required for position updates.

For official stuff, as far as it gets would be: https://forum-en.gw2archive.eu/forum/community/api/Map-API-Mumble-Mashup/2256444
where the API team encourages using this data even for non-voicecom related stuff.

For questions regarding CrossTalk, unless you’re on GitHub or the Teamspeak forums, you can always drop me a line at https://forum-en.gw2archive.eu/forum/community/links/CrossTalk-adds-Positional-Audio-for-Teamspeak

Hm, I only had a short look on mantras again, but what bothered me the most is their CD being bound to the last usage instead of their charge or first-use.
This, unless I’m missing sth., derives to spam-using-them-up being generally more versatile than using them in dosages, where you’d get screwed-over-time.
Let’s say start-fight, after 5 sec use all heals + (cd + charge time), versus use heal on 5 sec, 15sec + (cd + charge time) -> Next Heal up 10 secs later in comparison.
This effectively counters the concept of charges.

I’m fine if I’m wrong about that, it’s just my perception of mantras ;D

Actually the (single closed source) component waiting to be deployed in CrossTalk uses SHA-1 already to generate what I guess is some sort of keyed-hash message authentication code (HMAC) out of a variety of variables, that’s good enough for me
However, since one of those obviously has a certain relation to the world id, I’d currently inherit certain enforcements to have that work.
Imagine a commander disconnecting, reentering on LA overflow. Invalid key generated, no enter.
I’m not gonna be the one receiving complaints about that, so anyone will have to stick with manually setting passwords (aka shared key) until then.

I’m way more dedicated to user comfort than on security here, I want the manual user interaction out of the equation on that part, as I find hassle-free usage (I know we wouldn’t name shared keys as a hassle, but looking at the default user I think it is, given that there are server voicecoms without passwords since it’s too much drama/work apparently) is the breaking point to a wide-spread usage of the tools created by the community. Obviously I’m mostly trying to convince the devs here that the status quo isn’t suffice

In a standalone context that’s probably the best bandaid indeed.
That said, the relevance of the issue at hand remains, as with every user interaction necessary a vast portion of the potential client base gets lost.
People are lazy.

He’s going to use the positional data for showing the positions of folks participating. It’s a given that user choice ain’t feasible there ;D

The most primitive option is to have a manual registration system, but having to verify home worlds manually for every single user ain’t really where one would want to be going.
Via Mumble Link, you can partially get there methinks using a combination of team color id, world id and the API. However this check only works when the player is on a wvw map, since otherwise the team color id will be 0 (dunno if an oversight or limitation). However, after all Mumble Link is attackable from local. It’s a barrier just until someone writes those lines of codes to break it.
In the end, we need this verification to be an API call.

I’m facing a similar problem with my positional audio module of my Teamspeak plugin. Luckily I can at least refer to TSes security mechanisms implementing the manual approach until then. I’m quite positive I could do a feasible protection, including an AntiSpy mechanism for TS if I had a better way to tie players to a home world (still excluding multi accounts ofc).

Since squads, unlike parties, do have a leader, the leader name/identifier would suffice (for me, at least).
Via character names that should total in (4+1)*40 = 200 bytes altogether isup.

I wouldn’t swear an oath that there’s an out of combat downed state, but yeah, sth. like that
If there ain’t I’d probably go
0: 00 not up, not incombat = dead
1: 01 not up, in combat = downed
2: 10 up, ooc
3: 11 up, ic
just in case, for the fun of it and have a couple of bits left for other bools.
But after all that’s details the devs will know best what they wanna do that.

Given that there’s a lot of space left, from the perspective of a Teamspeak 3 plugin dev, I actually could make most use of having the groupmembers and commander name (replacing the bool in the progress?) if in a squad.
Think whispering to your group only etc. up to (if the ids play along) the option to talk to your team in single join tournaments if a server hosts that for a region. Hu, maybe that last one ain’t a good idea hehe.

From the former thread I think guild tag or name would be worth a honorable mention.

Hm, depending on what high frequency is the target, one could think about just using another transport mechanism for those, e.g. a “GWLink”, to meet the requirement of rare updates set by Mumble.
Personally I prefer the context blob method over the JSON string.
The last char of the character name being a null char? Putting that there should avoid messing up the mumble default gui with the data which would be nice indeed.
I guess in_combat could be added to state, saving a byte.

I was aware that anyone active in here could do that.
You could also have multiple accounts, then oauth bye bye.
It’s always just hurdles someone has to have the motivation and ability to break first.

So, I’m back from vacation and looking at the added info on idendity.
On first sight, it appears, world id and map id are duplicating the information from the context blob.
I’m just wondering if my original request, being the home world id (as opposed to guesting) got lost in the mail/translation.
Anti Spy won’t be possible without that, or a combination of smiley’s request for account name + a potentially upcoming API function to request that info for an account.

Given the voicecom espionage issues folks complain about I’d just thought hey, I could help out with that and additionally add quite adequate protection of the mumble data, as has beeen requested.
Personally I can live fine not having that, just pointing out the addition isn’t opening new options for that and am wondering if I should shelve that idea altogether with osx/linux users being excluded and the hassle of a plugin installation.

I’ve been using 8 for crit damage iirc, derived from comparing the celestial trinkets. However, the results are comparable.
Celestial I too found to be particular interesting in the reverse order for gear one used to rate the crit damage roi before:
Shoulder, Hands, Foot
Chest
Leg, Head
→ Reverse
as in where Std/with crit looks particular bad versus Std in your table.

However, I guess once I made my mind up, my Ele might be priority for them

I’m not onto it

Agreed, for me it’s labeled a bandaid, not a fix even though they stuck with it.

Ah I see, they reference to GetLastError returns ERROR_ALREADY_EXISTS for checks. Well then.

I’d still try to open it first, before I create it.

http://msdn.microsoft.com/en-us/library/windows/desktop/aa366537(v=vs.85).aspx
If the object exists before the function call, the function returns a handle to the existing object (with its current size, not the specified size), and GetLastError returns ERROR_ALREADY_EXISTS.

Just creating it would, as I read it, render it incompatible to simultaneously running applications, like the Mumble client or the CrossTalk TS3-Addon.

Also, I dunno why one would want to add execute to the standard implementation’s PAGE_READWRITE.

It’s not really my expertise, since I only used it in c++ for CrossTalk yet before I switched over to the Qt variant, but imo
CreateFileMapping(
WinBase.INVALID_HANDLE_VALUE, null, WinNT.PAGE_READONLY, 0,
5460, name)
looks rather suspicious.
Aren’t you creating a File Mapping that’s protected for read-only access? I figure GW2 would not be able to write to that then.

Shouldn’t just recreating the exact same variant that Mumble Link itself uses:
Try to open file mapping, if not create file mapping (read/write access) be the way to go?

The access rights in OpenFileMapping and/or MapViewOfFile could probably indeed be opted to some sort of read access, unless you want to imitate Link’s unlock function, which I’d rather do not.

Thanks for the information
I might use this later on to overcome overflow server disparity for Positional Audio in CrossTalk (for Teamspeak), but I’m sure non-voip related applications will make much more interesting use of those bits.

Might also help for the more-or-less-basic Anti-Spy Protection I’m looking into, but to leverage it to the next level it’d be helpful to have the home world id and possibly guild tag accessible. I’ve also been asked for the class to magically show as icon. While I’m totally fine with waiting for the API to reach those areas, I’ll just put it out there that I could spare you some network traffic by more extensively using idendity (note that game description would be unused yet, too), as mentioned in the Mumble Link description.

For example breaking idendity [255] into char_name[x], char[3]guild_tag, commander_and_whatever_flag[1], class[2], unsigned home_world_id.

Could also be used for options with commander flags, like syncing priority speaker or assigning server/channel groups.

You’re welcome
Let me prestate that I actually didn’t write the module nor the plugin because I’d prefer one software over the other, it just so happens that my guild uses Teamspeak. So, my drivings ain’t been to make Teamspeak better because it’d be the plattform of my choice (I don’t marry plattforms), I do care about audio experience, I do hope Mumble Link’s momentum as a de facto standard gets a push by becoming client agnostic so more game developers support it, the more people finally leave the grey world of mono for the joys of positional audio.

About the tag request, at this point I’m solely using the Mumble Link convention. This means the plugin knows Game Name, Character Name and some weirdo “Context” data. For now, all we know is that the map id is encoded in the context. Server, I dunno if it’s in there somewhere or not. Class, Guild cannot, as identity of the context is used to assign folks. Such additional info could be fed into via the gw2 api which I don’t use (yet?).

I don’t think it’s easily possible detecting foreign spies. After all, he’d just have to disable the plugin to avoid detection^^ The only thing that springs to my mind would additionally require a server bot that manages channel entry permission by map context (if that’s tied to server) which would enforce the plugin on all users in the particular ecosystem. I’m not particular positive about finding the time to code such a server bot, however would try to provide compatibility if someone does.

Since the topic came up here, the (update to my) Teamspeak plugin is now live:
https://forum-en.gw2archive.eu/forum/community/links/CrossTalk-adds-Positional-Audio-for-Teamspeak/first#post2328459

Currently exclusively using the TS Server for comm, but keeping an eye open on the development here

CrossTalk adds Positional Audio support for games to Teamspeak.

CrossTalk is a free Teamspeak 3 plugin that enhances the general audio experience and provides advanced features for team play.
Looking forward to the 50.000 mark on its official download page, the update to 1.4 now adds the Positional Audio module to the current feature set, consisting of Position Spread, Ducking, Radio FX and a variety of custom keybinds.
At the core of the module compatibility to Mumble’s Link convention is implemented, the increasing list of games supporting it includes ArenaNet’s Guild Wars 2, a variety of Valve games and other titles.

For more information on the Positional Audio module visit the dedicated module wiki on Github, the plugin can be downloaded here.

All trademarks referenced herein are the properties of their respective owners.

Considering I was sure such would be coming in february, it took quite a while^^

Which is why the ts plugin code went not-so-simple very fast However, it’s stable and just hasn’t been in public yet since I’m sorta paranoid about my personal QA’ing with the limited time I have for this. In this context however a server is already available (with new funny stuff to work around like flood protection setting), the ts server, sorta putting it out of the equation for now.

I’m not that big on all those fancy new webtech yet, but I had a glimpse on meteor js for another project, could imagine it might be attractive for this, looking at the parties example.

I’m having that in closed beta since a while in my ts3plugin and it will be released very soon. Takes a short while to get used to it, but then it becomes natural There is no plugin API for vent afaik.