seiyria.4792:

Hi all,

I suspect what I want to do is against the ToS but I want to ask anyway. I just got a Corsair K70 and it’s pretty neat to say the least.

I wanted to make use of some client data to “theme” my keyboard depending on character / class and some other things, like so:

  • Have my current stamina shown visually across f5-f12
  • Have my HP shown in vertically on the numpad (ie, less hp = fewer lit keys)
  • Color my keyboard according to race / profession (sylvari would have a green keyboard, with an elementalist having WASD colored red, for example)
  • Have certain F1-F4 keys colored based on profession, ie, for an elementalist we have fire, water, air, and earth, so my F1 would be red, F2 would be blue, etc.

Or maybe there’d be some sort of scriptable API like WoW has in the future?

Thanks!

Lawton Campbell.8517:

The only bit of data we currently expose is the current character’s profession. You can get this info from the super poorly-documented Mumble link API (see this thread). Specifically, the identity field of the Link data contains a JSON blob which looks like

{ “name” : “character name”
, “profession” : 1
, “map_id” : 2
, “world_id” : 3
, “team_color_id” : 4
, “commander” : true
}

Where “profession” has the following mapping:

1 = Guardian
2 = Warrior
3 = Engineer
4 = Ranger
5 = Thief
6 = Elementalist
7 = Mesmer
8 = Necro

“map_id” corresponds (or, should) to a map accessible via /v2/maps, “world_id” to an id in /v2/worlds, and “team_color_id” to a color id which can be resolved against /v2/colors (I … think). Oh, and “commander” is set to true iff you’re running a commander tag.

seiyria.4792:

Hm. So I could write a desktop program that interfaces with gw2.exe (not querying a web service)? Just want to be clear on how this API works.

Is there any chance this will be expanded to provide some of the data above (current hp, max hp, stamina, race?

Lawton Campbell.8517:

Yeah, it’d be a desktop program that uses a shared memory-mapped file which uses the Mumble link data format.

There’s really only two fields in that format that we can put data into; each of them are only 256 bytes long. One of them, “context”, is used to determine which players should hear which other players (so we can’t change it). The other, “identity”, is documented as “shouldn’t change more than a few times per second if at all during a game”. So there isn’t really any place we can put real-time data without breaking existing usages of that API

seiyria.4792:

Great to hear that it’s a desktop API (sorry, I’m a web developer by trade so I am hardwired to think APIs are for remote locations, so I wanted to clarify).

Aw, now that is a shame. Maybe a new API for more “realtime tracking”? I would really like to get my hands on something like that; the possibilities are grand. Not only would I be able to do this thing with my keyboard, but I’m sure there could be some widgets made that do some very nice things, like enhanced alerts (for low hp or low stamina), or some neat conditional display based on race / profession.

Maybe if the map location were also put in this theoretical API, you could do a heatmap of the world too, to see where the players using this widget are, currently.

Of course, I’m not familiar with a codebase as complex as GW2 (probably) is, so I don’t really understand the level of effort something like this would take. Surely there isn’t a whole lot of data that people would want, though.

smiley.1438:

Great to hear that it’s a desktop API (sorry, I’m a web developer by trade so I am hardwired to think APIs are for remote locations, so I wanted to clarify).

Aw, now that is a shame. Maybe a new API for more “realtime tracking”? I would really like to get my hands on something like that; the possibilities are grand. Not only would I be able to do this thing with my keyboard, but I’m sure there could be some widgets made that do some very nice things, like enhanced alerts (for low hp or low stamina), or some neat conditional display based on race / profession.

Maybe if the map location were also put in this theoretical API, you could do a heatmap of the world too, to see where the players using this widget are, currently.

Of course, I’m not familiar with a codebase as complex as GW2 (probably) is, so I don’t really understand the level of effort something like this would take. Surely there isn’t a whole lot of data that people would want, though.

This is probably what you’re looking for:
https://forum-en.guildwars2.com/forum/community/api/Gw2-Location-Tracker/first#post2379754
https://forum-en.guildwars2.com/forum/community/api/Map-API-Mumble-Mashup

seiyria.4792:

This would not really cover most of what I was requesting, as far as I can tell, sorry The maps thing was just a spur of the moment idea, but it seems someone has covered that base already.

smiley.1438:

Oh i see, you meant espeacially for your keyboard (realtime tracking was the buzzword). Well, lets see what the future brings.

StevenL.3761:

I don’t know how, but it’s possible to tap into data that is meant to be consumed by certain types of gaming keyboards.

Here’s an example of how this can be used: http://www.gw2hud.com/

If anyone actually knows how to do this in code, that would be awesome.

seiyria.4792:

Nice find, StevenL! It looks like that has most of the data I want, just not HP or Stamina, but it’s distinctly possible that they send that information around as well.

StevenL.3761:

Well… I still don’t know how they did it. I can’t find any documentation on the matter. Not even a reference to the existence of the API behind it. Seems like gw2hud was an inside job(?)

Terrasque.8735:

http://support.logitech.com/en_us/article/21508?product=a0qi00000069vCHAAY might be of some help.

StevenL.3761:

Oh, wow. I’ve had that SDK installed on my computer for months without even knowing it. Let’s see what I can find.

(…)

Hmm… I think that the way to do it is to create a DLL (written in native code) that exports the same interfaces as the Logitech keyboard software. Then, somehow, you have to trick the game into calling your DLL instead of a Logitech DLL. What your DLL does with the data is up to you.

StevenL.3761:

Figured it out. When you install the “Logitech Gaming Software” application, it creates the following registry key: HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{fe750200-b72e-11d9-829b-0050da1a72d3}\ServerBinary

The value of this key is a path to the LCD’s API library. On my machine, the value is: C:\Program Files\Logitech Gaming Software\SDK\LCD\x64\LgLcdApi.dll (yours may differ)

Presumably, the game client uses this registry key to locate the entry point for the LCD. Replace the path with a path to any other DLL, and the game client will use that path as the entry point instead.

Beware that for people who actually have a keyboard with an LCD, this hack will disable communication between all games and the physical LCD.

Side note: you probably don’t need to install the LGS software. Just create the registry key manually.

seiyria.4792:

Hm. That seems like a lot of work for someone who wants this but I’ll definitely not rule it out. Obviously I would only be targeting people with the Corsair K70 which does not have an LCD, so I don’t think a collision of interest is an outcome that will occur. If it does, that can be tackled later.

StevenL.3761:

The phsycial LCD disconnect only applies to Logitech keyboards, so that shouldn’t be an issue.

Just to be safe, you could activate the official Logitech DLL from your custom DLL in order to forward game data and still keep the physical LCD display working.

So, now, how would we implement that DLL? The real DLL exports the following functions…

  • DllRegisterServer
  • DllUnregisterServer
  • GetInterface

The first two are specific to COM programming (used by regsvr32). The third one, I don’t know. Is anybody with COM programming experience willing to take a stab at this?

Terrasque.8735:

I have no experience with native programming, I’m afraid, but keeping an eye on this.

In principle it seems easy, make a DLL with the same exported functions as in the documentation, expecting the same arguments, then export it somewhere else (first pass, probably send the raw data to a file, just to see what data it gets). I just don’t know any language that will allow me to create such a DLL.

“LogitechGamingLCDSDK.pdf” page 9 list about 10 functions. Would be interesting to know which (if any) gw2 uses.

StevenL.3761:

Here’s a nice visual representation of how it’s supposed to work (taken from a piece of SDK documentation).
https://i.imgur.com/ZWXGZzb.png

Here’s an adjusted version of where and how GW2HUD hijacks this process.
https://i.imgur.com/Vpqysex.png

Source: https://github.com/Fire-Dragon-DoL/CsLglcd/tree/master/CsLglcd/Pdf

Aerodin.2795:

Here’s a nice visual representation of how it’s supposed to work (taken from a piece of SDK documentation).
https://i.imgur.com/ZWXGZzb.png

Here’s an adjusted version of where and how GW2HUD hijacks this process.
https://i.imgur.com/Vpqysex.png

Source: https://github.com/Fire-Dragon-DoL/CsLglcd/tree/master/CsLglcd/Pdf

I like how you made the broken lines all drippy looking.

Looking at the documentation, I could be wrong, but it looks like the interface allows for a passing actual bitmaps that are then drawn to the LCD display. There’s no contextual/generic information like what the mumble interface provides.

StevenL.3761:

Yeah. I suspect that the game client generates images with drawn text, so that the Logitech software has to do nothing other than render the images at a specified position.
You could use OCR to get the actual text, but we’re skipping too far ahead.

Light.7493:

Yeah, it’d be a desktop program that uses a shared memory-mapped file which uses the Mumble link data format.

There’s really only two fields in that format that we can put data into; each of them are only 256 bytes long. One of them, “context”, is used to determine which players should hear which other players (so we can’t change it). The other, “identity”, is documented as “shouldn’t change more than a few times per second if at all during a game”. So there isn’t really any place we can put real-time data without breaking existing usages of that API :(

Well, you could create a new shared memory file not related to mumble and give us the structure :3

StevenL.3761:

Well, you could create a new shared memory file not related to mumble and give us the structure

+1

Please?

seiyria.4792:

Yeah, it’d be a desktop program that uses a shared memory-mapped file which uses the Mumble link data format.

There’s really only two fields in that format that we can put data into; each of them are only 256 bytes long. One of them, “context”, is used to determine which players should hear which other players (so we can’t change it). The other, “identity”, is documented as “shouldn’t change more than a few times per second if at all during a game”. So there isn’t really any place we can put real-time data without breaking existing usages of that API

Well, you could create a new shared memory file not related to mumble and give us the structure

I was hoping for this as well!

NSKL.3174:

Any progress on this amazing project?!
I would love having a part of my K65 displaying my HP as well as the outer keys pulsing in red (as a frame) when in down-state and green / light blue when actively ressing and something similar for stomps as well.
Maybe hotkeys for skills light up in green when ready and red when on cooldown.
This would be nothing less than amazing!
I know nothing about programming so I really hop that someone will keep working on this

Best regards!

AllIsVain.6409:

Any progress on this amazing project?!
I would love having a part of my K65 displaying my HP as well as the outer keys pulsing in red (as a frame) when in down-state and green / light blue when actively ressing and something similar for stomps as well.
Maybe hotkeys for skills light up in green when ready and red when on cooldown.
This would be nothing less than amazing!
I know nothing about programming so I really hop that someone will keep working on this

Best regards!

I’ve looked at getting these things from the game before. What you can do is screenshot the game ~10-20 times a second then look at rgb data at the endurance bar and HP bar.

If the bars are missing = toggle downed state readouts.

Completely within the ToS

Archomeda.6472:

Just to clarify some stuff here that has been discussed after this topic started.

In order to have these features be the most efficient, the – let’s say – local client API (or Mumble Link API to be more precise) has to be improved and/or changed. The API devs have said that they want to do this, but it’s in its early stages, like, they’ve only thought of having it. That’s it. It’s probably far away on their roadmap. You have to keep in mind that instead, they’ve been very busy with the /v2 APIs. And this takes a lot of time.

Instead, let me introduce you to a different, but similar feature that GW2 natively supports. It’s called AlienFX. The saddest part about it, is that it’s only for Alienware devices. So for the last half year (a little bit more), I’ve been working on and off on extending it to, for example, Logitech devices. When I started, I’ve created a video showing what it does on my Lightpack: https://youtu.be/nBnYySAUF88.

It’s a pretty cool feature, but the data what GW2 sends, is only the color data for each separate light. Not the state of your game. So it’s impossible to read if a skill is off CD this way. Still, AlienFX is something fun to try out.

If you’re interested, go to my repository on GitHub: https://github.com/Archomeda/lightfx-extender. Currently, it only extends to Logitech and Lightpack, since these are the only devices I have available. Also, it’s entirely possible that this will crash your game in one way or another. A small note: I still have to release v0.4.2 with some significant changes/fixes.

If you are concerned about this plugin interfacing with GW2 and ToS, this plugin only intercepts the calls GW2 makes to Alienware’s AlienFX, does some stuff with it and forwards it to other devices. It does no such things as reading GW2’s memory.

Also, now that more than 50% of my post is about advertising my project, the last thing I want to add, is that I’m actually looking for enthusiastic people willing to implement support for other devices, like Razer’s and Corsair’s.

NSKL.3174:

Any progress on this amazing project?!
I would love having a part of my K65 displaying my HP as well as the outer keys pulsing in red (as a frame) when in down-state and green / light blue when actively ressing and something similar for stomps as well.
Maybe hotkeys for skills light up in green when ready and red when on cooldown.
This would be nothing less than amazing!
I know nothing about programming so I really hop that someone will keep working on this

Best regards!

I’ve looked at getting these things from the game before. What you can do is screenshot the game ~10-20 times a second then look at rgb data at the endurance bar and HP bar.

If the bars are missing = toggle downed state readouts.

Completely within the ToS

Hi AllIsVain.6409

Thank you for your reply!
It sounds interesting but I have very little knowledge on working with a computer so it seems I will have to wait for someone to actually write a finished program that I can install and enjoy

NSKL.3174:

Hi Archomeda.6472

Your project looks super cool
Keep me posted if you move on to Corsair!
Maybe they will give you a keyboard free of charge if you write them and show them what you’ve got going on. Seemingly they have been very good to reviewers and they were all over at the WTS so it seems they are very aware of GW2 as well.