Guild Wars 2

Greetings,

This post is aimed at the implementation and usage of DPS meters.

API proposal

Provide a json API that provides logs of the last fights. Something along the lines of

GET /v2/last_combats

[
    {
        "foe": "Sabetha the Saboteur",
        "success": true,
        "group_dps": 120154,
        "individiual_dps": {
            "player_a": 23053,
            [...]
        },
        "effect_uptime": {
            "player_a": {
                "alacrity": 0.92,
                "regeneration": 0.32,
               [...]
            },
            [...]
        },
        combat_events: [
            {
                "timestamp": 1491122052,
                "player": "player_a",
                "target": "Sabetha the Saboteur",
                "category": "damage",
                "amount": 1492,
                "type": "Condition",
                "subtype": "Poison"
            }, {
                "timestamp": 1491122053,
                "player": "some_druid",
                "target": "player_a",
                "category": "heal",
                "amount": 423,
                "type": "Boon",
                "subtype": "Regeneration"
            }, {
                "timestamp": 1491122054,
                "player": "some_warrior",
                "target": "player_a",
                "category": "boon",
                "amount": 1,
                "type": "Might",
                "subtype": "Phalanx Strength"
            },
            [...]
        ]
    }, {
        "foe": "Bandit",
        "success": true,
        "group_dps": 80152,
        [...]
    }
]

Current state

Players use 2 brands of memory reading DPS meters in Raids. In the following sections S will explain why I will not use them and why no one should.

Legal issues

From the User Agreement §8:

You acknowledge that You may not, without signed written consent from a legally authorized representative of ArenaNet, do any of the following:

[…]

(i) Use, obtain or provide data related to operation of the Game, including but not limited to:

????????(i) software that reads areas of computer memory or storage devices related to the Game;

[…]

In the GW2 AMA for Head of the Snake Chris Cleary wrote the following:

We have no problems with players using a 3rd party tool whose scope is only to collect and visualize combat data gathered directly from the game client. Anything beyond that scope is still considered a violation of the User Agreement.

This is not a written signed agreement though so in my laymans opinion DPS meter users are still in violation to the user agreement (Yes, I’m fun at parties). If ANet wants users to continue using these mods they should change the user agreement.

Security issues

Especially the B*** tool concerns me a lot regarding security. This tool contains auto-update functionality that makes it possible for anyone controlling the update server to execute arbitrary code. I do not think that the developers have the resources to ensure the safety of their infrastructure under the circumstances. Arbitrary access to thousands of GW2 Accounts make these C&C servers very high-profile targets.

The A** tool seems saner in this matter as the developer guarantees that the DLL contains no network functionality.

Anti cheating heuristics

Both A** and B*** employ techniques that are very common among cheats. Any heuristic from ANet that detects D3D9 wrappers will have no way to determine the legitimacy of these wrappers except whitelisting every version of every legitimate meter.

Tolerating these kind of tools may make it difficult for ANet to employ such techniques if they become necessary.

Summary

If ANet tolerates DPS meters they should provide a sane way for everyone to use this data. D3D9 wrappers are not a sane way at all. As it stands players without DPS meters have a huge disadvantage in raids because they have less feedback from boss fights which they can use to refine their gameplay.

You would be much more likely to see, eg, local combat log output than API based combat log output. That distributes the costs over a much wider area, without significantly changing the effort require by anet to implement. (eg: similar to how the wow combat logs work.)

Regardless, though, it’s a big effort, and the grudging acceptance of the memory reading DPS meters reflects a reality that this isn’t going to bring the sort of return on investment anet are likely to find worthwhile any time soon.

It could be a localhsot:8080 style implementation. This way it is more accessible to developers, as anyone with HTTP JSON experience in any language/platform would know how to use it.

However, I am not sure if Anet has that kind architecture in place.

voidvector.2780:

It could be a localhsot:8080 style implementation. This way it is more accessible to developers, as anyone with HTTP JSON experience in any language/platform would know how to use it.

However, I am not sure if Anet has that kind architecture in place.

That is significantly more costly than just writing a file to disk, FWIW, so … I’d not hold my breath for that.

SlippyCheeze.5483:

That is significantly more costly than just writing a file to disk, FWIW, so … I’d not hold my breath for that.

Uh. No. Socket interactions are way less expensive than Disk IO. And when it comes to development costs the real cost is in gathering the data anyway and whether you write it to disk (using existing libs) or write it to a socket (using existing libs) shouldn’t matter all that much.

Anyway I’d still like to have an answer to my original concerns – preferably from ANet. Even something along the lines of “we are still trying to figure it out” would be sufficient. I just want to know this issue is not forgotten.

Thrill.6259:

SlippyCheeze.5483:

That is significantly more costly than just writing a file to disk, FWIW, so … I’d not hold my breath for that.

Uh. No. Socket interactions are way less expensive than Disk IO. And when it comes to development costs the real cost is in gathering the data anyway and whether you write it to disk (using existing libs) or write it to a socket (using existing libs) shouldn’t matter all that much.

haha, yeah, just writing raw data to either is approximately as expensive, but… you were talking about some sort of HTTP or WebSocket backed thing, not a simple raw socket, right? Running the stack to serve that up to an HTTP style client is more expensive than writing formatted data to a file handle, is what I mean.

It’s not the cost per “line” of output, it’s the cost of all the administrative overhead of making it work that adds difficulty.

An average fight can range from 100-250k events depending on length and composition. If I included single-stack buff removal events, this would be closer to 150-300k. If we had strike healing and passive healing, it would probably be in the range of 200-400k. Even compressed, making that kind of detail available via the web API is probably a bit too hefty.

Yah, WoW tracks this is the range of 150 to 300MB of data for a “night” of raiding, which is around three hours of concentrated play for 20 people, uncompressed, for some comparison. It does compress well, though.

Apart from the (very interesting) technical details implementing this is feasible “if” ANet wants to. I guess they don’t though. Seems like they’re hoping this problem will just go away by itself (Spoiler: It won’t).

This really is a shame. Solving this would single-handedly make raids more accessible to newcomers. The golem is OK for DPS classes but supporters need to keep track of their uptime. Even making the stats there more precise would somewhat solve this issue.

Maybe when the first wave of compromised accounts arrives ANet will act. Wouldn’t be the first time some shady after-market mod gets a little keylogging feature. I can already imagine the Headline “Thousands of Guild Wars 2 accounts hacked – Auto updater of approved third-party mod at fault”.

Thrill.6259:

Apart from the (very interesting) technical details implementing this is feasible “if” ANet wants to. I guess they don’t though. Seems like they’re hoping this problem will just go away by itself (Spoiler: It won’t).

This really is a shame. Solving this would single-handedly make raids more accessible to newcomers. The golem is OK for DPS classes but supporters need to keep track of their uptime. Even making the stats there more precise would somewhat solve this issue.

Maybe when the first wave of compromised accounts arrives ANet will act. Wouldn’t be the first time some shady after-market mod gets a little keylogging feature. I can already imagine the Headline “Thousands of Guild Wars 2 accounts hacked – Auto updater of approved third-party mod at fault”.

Possible*. Important distinction. We can’t speculate on the feasibility of anything about ANet’s client or server architecture because we had no part in writing it. In fact the only hint we have about the feasibility of a combat tracker API was that it would be client-local and that it’s a large undertaking. It’s very possible as well that ANet does not see this as a problem in the first place – perhaps the risk of one of the few meter developers stealing accounts is worth taking in comparison to the hours needed to create the infrastructure. Also important to note that ANet did not approve any mods – they approved hackish means as long as they are only used to get combat data out of the client. The risk is still on the user to determine if the mod is compliant or “safe”. Aaaand it wouldn’t be the first time an enthusiastic developer wrote a 3rd party mod for fun that will fade after the game fades.

HTTP+JSON doesn’t meant it has to be a web app. It can be a CRON job that periodically curls or a Graphite integration.

Interesting that ArenaNet had this in mind already.

voidvector.2780:

HTTP+JSON doesn’t meant it has to be a web app. It can be a CRON job that periodically curls or a Graphite integration.

Interesting that ArenaNet had this in mind already.

You are misreading on two fronts here:

First, the comments about HTTP/JSON vs anything else were about the complexity on the server side, not the consumer side. Your response deals with the consumer side.

Second, anet have given absolutely no indication of what, if any, thoughts they have on the subject. (Unless you mean the references to the terms of service, in which case that is more generic “everything is forbidden, unless it is permitted”.)

I don’t think we were talking about the same thing.

When I said “doesn’t meant it has to be a web app” I was referring to the conversation about the amount of in-memory data being enormous.

When I said “ArenaNet had this in mind” I was referring to this ticket of theirs