Prototype Killmail Data

[a-tal]

As per the announcement by CCP Seagull during the Fanfest 2018 keynote, we have been prototyping an alternative killmail system. This new system runs outside of the monolith, and does not add any additional load to battles, etc.

There is no release date for this. We would like to gather player feedback around the data.

There is an accompanying commit for this issue which contains some example killmails from the battle of 9-4. Keep in mind these are not the final models for this data.

What follows is an example, cut down version of what you can expect from the new killmail system. For full examples please see the new_killmails directory in this repository.

{
    "allies": [
        {
            "owner_id": 911710003,
            "owner_ships": [
                {
                    "ship_id": 1016139319185,
                    "ship_items": [
                        {
                            "item_activation_amount": 2240.0,
                            "item_activation_count": 9,
                            "item_target_id": 1023459972182,
                            "item_type_id": 16451
                        },
                        {
                            "item_activation_amount": 448.0,
                            "item_activation_count": 13,
                            "item_target_id": 1023459972182,
                            "item_type_id": 16447
                        }
                    ],
                    "ship_type_id": 11987
                }
            ]
        },
        {
            "owner_id": 94689960,
            "owner_ships": [
                {
                    "ship_id": 1024261282294,
                    "ship_items": [
                        {
                            "item_activation_amount": 4928.0,
                            "item_activation_count": 11,
                            "item_target_id": 1023459972182,
                            "item_type_id": 16455
                        },
                        {
                            "item_activation_amount": 238.91807038459228,
                            "item_activation_count": 2,
                            "item_target_id": 1023459972182,
                            "item_type_id": 16447
                        }
                    ],
                    "ship_type_id": 11989
                }
            ]
        }
    ],
    "enemies": [
        {
            "owner_id": 93285732,
            "owner_ships": [
                {
                    "ship_id": 1026355872766,
                    "ship_items": [
                        {
                            "item_activation_amount": 36.0,
                            "item_activation_count": 1,
                            "item_target_id": 1023459972182,
                            "item_type_id": 14158
                        },
                        {
                            "item_activation_amount": 0,
                            "item_activation_count": 0,
                            "item_target_id": 1023459972182,
                            "item_type_id": 448
                        },
                        {
                            "item_activation_amount": 0,
                            "item_activation_count": 0,
                            "item_target_id": 1023459972182,
                            "item_type_id": 527
                        },
                        {
                            "item_activation_amount": 370.7250589254084,
                            "item_activation_count": 12,
                            "item_target_id": 1023459972182,
                            "item_type_id": 3082
                        }
                    ],
                    "ship_type_id": 29988
                }
            ]
        },
        {
            "owner_id": 96150783,
            "owner_ships": [
                {
                    "ship_id": 1026443961967,
                    "ship_items": [
                        {
                            "item_activation_amount": 467.5786904365719,
                            "item_activation_count": 1,
                            "item_target_id": 1023459972182,
                            "item_type_id": 9491
                        }
                    ],
                    "ship_type_id": 17732
                }
            ]
        },
        {
            "owner_id": 765184199,
            "owner_ships": [
                {
                    "ship_id": 1025207795128,
                    "ship_items": [
                        {
                            "item_activation_amount": 175.06290818742428,
                            "item_activation_count": 12,
                            "item_target_id": 1026624606651,
                            "item_type_id": 16451
                        }
                    ],
                    "ship_type_id": 11987
                }
            ]
        },
        {
            "owner_id": 93898272,
            "owner_ships": [
                {
                    "ship_id": 1026585408585,
                    "ship_items": [
                        {
                            "item_activation_amount": 0,
                            "item_activation_count": 10,
                            "item_target_id": 1026624606651,
                            "item_type_id": 16451
                        }
                    ],
                    "ship_type_id": 11987
                }
            ]
        }
    ],
    "killer": {
        "owner_alliance_id": 99002938,
        "owner_corp_id": 98389189,
        "owner_id": 1593413364,
        "ship_id": 1026629247321,
        "ship_kill_count": 1,
        "ship_name": "T-F-I",
        "ship_skin_id": 213,
        "ship_type_id": 17732,
        "weapon_amount": 1003.8719019683282,
        "weapon_type_id": 2961
    },
    "killmail_id": "f97778b9-05ea-464a-893b-af9af581ae1c",
    "sim_timestamp": 131612146562377872,
    "solar_system_id": 30004059,
    "timestamp": "2018-01-24T00:56:08.221787Z",
    "victim": {
        "owner_alliance_id": 1354830081,
        "owner_corp_id": 98370861,
        "owner_id": 95576839,
        "ship_id": 1023459972182,
        "ship_items": [
            {
                "destroyed": false,
                "flag_id": 5,
                "singleton": false,
                "stack_size": 9,
                "type_id": 32014
            },
            {
                "destroyed": true,
                "flag_id": 30,
                "singleton": true,
                "stack_size": 1,
                "type_id": 9491
            },
            {
                "destroyed": false,
                "flag_id": 31,
                "singleton": false,
                "stack_size": 11,
                "type_id": 28332
            }
        ],
        "ship_kill_count": null,
        "ship_name": "INS Glory",
        "ship_skin_id": null,
        "ship_type_id": 17738,
        "ship_was_piloted": true
    }
}

[sbatman]

Will this include local boosters (drugs etc ) the pilot was taking ? Any chance of getting coordinates of all pilots at moment of death ? (i would love velocities if possible) and would make creating representations of the kill possible?

[ghost]

1. How will this handle the new abyssal modules? Are the dynamic item attributes going to be returned within the ship_items block? e.g. an associative array containing the modified attributes?

2. as @sbatman pointed i too think out coordinates would be helpful!

3. The victim corporation and alliance is snapshotted within the killmail, would it also be possible to do this for all other related pilots?

4. Would it be possible to show if a module was online/active or not at the time of death for the victim? e.g. if the victim was currently in siege, industry mode or bastion mode or if one of their guns was offline because they ran out of CPU on their fit?

5. Would it be possible to show the current (de)buffs and active timers for the affected pilots?

[sbatman]

Heat level of modules would also be a plus as some ships get massive gains from overheats

[ghost]

Heat level of modules would also be a plus as some ships get massive gains from overheats

Maybe just return all item attributes that differ from the original attributes as defined in the SDE?

[DaneelTrevize]

What would killer's weapon_amount, weapon_type_id, and other objects & properties be for self-destructs?
Put another way, what commonly used aspects would have to be declared optional, or not always assumed to contain a resolvable value, because of such edge-cases?

[jameson2011]

With ship names now persietent and distributed around the world do you envisage filtering (I wont apply any personally... but others might and others will forget) or would you drop the name from the map altogether?

EDIT: please ignore this. Publish all names freely and without restraint.

[antihax]

Please include bounty, insurance, and LP payout.

[jameson2011]

As sbateman and others have said coordinates are essential. Only way to discriminate gate camps, etc

[jameson2011]

Would it be possoble to include, in addition to 3d coords, ids /names of transient celestials such as FW plexes, anomalies, ice fields, etc?

[ghost]

Implants and rigs that were pulled slightly prior to death.

[ghost]

@jameson2011 probably. I'd want to investigate a little before I stamped it definitely technically fine. I'd say it's mostly a question of how we present that data. Those objects are, as you say, transient, so we couldn't have another endpoint for querying their item ID's for details because the data would just vanish next downtime. We might be able to stamp it with something like "near Ice Field (Glacial Mass)" as a purely textual thing.

Current killmails already have coordinates, and we are aiming for new killmails to be a strict superset of current killmails, so coordinates are confirmed.

[ficti0n1]

Currently Killmails can already break if theres too much lag /TIDI in the system. Is making Killmails a load more complex not going to make this work?

[ghost]

@ ficti0n1 short answer is that we expect p much everything to be better. That's not really a discussion for this ticket though, poke me on slack for more details :)

[jameson2011]

@tsuthers-ccpgames Thank you, that's great to hear: can't upvote enough. Some kind of anomaly type ID (as opposed to instance ID) would be more than enough.

[p-doyle]

Is this going to include any new ESI routes to query the killmails? For example the ability to search by character, ship type, etc.

[jameson2011]

A niggling point: is the lexical order of JSON elements (Allies, attacker, victim...) finalised? I ask because the prototypes show metadata (killID, time, location) at the end (similar to the current ESI ordering), and there is considerably more up-front data in these kills. Some parsers squeeze a little better performance by not eagerly parsing the entire string: metadata at the top would help remove the need to parse all the JSON. Helpful for statistics generators partitioned by victim/shiptype/solar system.

[ghost]

JSON objects are unordered, so unfortunately you can't rely on that sort of thing. I think ESI is pretty consistent about it's ordering, but if it is that's by coincidence and not guaranteed by the spec.

[Seavert]

Will all killmails be extended? If not, can you announce border date?

[jameson2011]

@tsuthers-ccpgames for sure. Just a niggling point. Cheers

[copyliu]

looks like it's missing the position (x,y,z)

[ghost]

@Seavert Old killmails will not be extended, we can't present data we didn't capture. The border date may be fuzzy, it's likely we'll run both systems side-by-side for at least a little while.

@copyliu Hrm, it is, very odd. Not sure why, but the final version will have x,y,z for sure.

[wtfrank]

I guess you would also want to be able to identify the owner of any structure that was involved and who was controlling it

[Seavert]

Modules can have ambiguous effect (e.g. Amarr Phenomena Generator). Such modules should probably be categorized as mixed (to put source in both sides of killmail) or excluded at all.

[cppctamber]

Additional data request

• velocity vector of destroyed ship
• position of involved ships
• velocity vector of involved ships
• position of ships within a limited radius of destroyed ship
• velocity vector of ships within a limited radius of destroyed ship

Listed in order of preference

Purpose

This information would allow us to create simulated 2d/3d battle replays for all kills, not just those recorded with the tourney tools/api.

Am willing to trade first born boy child.

[tehFred]

Velocity vector of destroyed ship would be useful, you could;

filter kills to all ships that died while not moving (afk) filter kills to ships that died on autopilot (given the warp exit point and burn direction towards gate, could roughly work it out)

[copyliu]

Request: extra attribute info in modules, eg. Abyssal modules.

[cvweiss]

Will older killmails reflect this new prototype structure as closely as possible with the missing information? Or will they be excluded entirely?

edit: I ask this because @tsuthers-ccpgames mentions running the two types of endpoints side by side for a bit, which infers the older endpoint will go away eventually. Does this mean any of the killmails not recorded by the new system will no longer be accessible, or will they be accessible via the new system with limited information?

[aebe]

Any chance of getting character ids of corpses that are in cargo?

So we can have e.g. "Aebe Amraen's Frozen Corpse" on the killmail instead of just "Frozen Corpse, Male"

[cvweiss]

Will these new killmails also include flags? Such as suspect, gcc, etc?

[itshouldntdothis]

Providing the item_id's would be nice to allow for abyssal module stats to be displayed.

[jowrjowr]

it would be really sweet if we could get the amount of isk sent to asset safety in the case of a structure killmail, so you can see how effective your structure frag was.

[w9jds]

Not even going to lie, That would be a terrible idea. This is just going to incentivize stalking people, as well as the stupid amount of intel this is. If you want to see what was in there, come to Wormhole space ;)

[CarbonAlabel]

As mentioned in https://github.com/esi/esi-issues/issues/896, to be consistent with the rest of ESI, these new killmails should return location flag IDs as enums instead.