These forums have been archived and are now read-only.

The new forums are live and can be found at https://forums.eveonline.com/

EVE Technology Lab

 
  • Topic is locked indefinitely.
Previous page123Next page
 

CREST Killmails Endpoint

First post
Author
Previous Topic Next Topic
Faolan Volfe
Mackies Raiders
Wild Geese.
#21 - 2014-02-11 16:26:23 UTC
CCP FoxFour wrote:
Captain Thunk wrote:
FoxFour is definately the best Furry Dev


I... you... just no. No no no. Best dev, great. Furry dev? When have you ever seen me wear anything furry? CCP Nullarbor however... https://twitter.com/CCP_Nullarbor/status/367084848869310464


LEYIF is recruiting, CCP furries welcome

(Also a much much larger amount of the furry population has never worn something 'furry' than the portion that has, so don't worry about that stopping you)
Querns
Science and Trade Institute
Caldari State
#22 - 2014-02-11 17:35:26 UTC
CCP FoxFour wrote:
Hey guys,

You may have noticed in the client when viewing a killmail there was a new option called Copy External Kill Link. Well as of today that link is now live and good to go: When you click on it you should have something like this copied to your clipboard: http://public-crest.eveonline.com/killmails/30290604/787fb3714062f1700560d4a83ce32c67640b1797/

The idea behind this endpoint is that it takes a killmail ID and a hash of the killmail and if the hash is right for that killmail ID we return a response with the contents of the killmail. Assuming killboards build in support for it this means you can API verify a killmail without having to give out your API details.

If you run into any problems with this endpoint please let me know here.

Enjoy guys! :D

Amazing -- thanks a lot for your work on this! It's good to see some real meat and potatoes coming out of CREST. This particular functionality actually solves several problems I was having in situations where I would like for killmails to be posted manually, but couldn't necessarily trust the information I was being given. It's an elegant solution to this problem and it opens some real doors.

This post was crafted by the wormhole expert of the Goonswarm Economic Warfare Cabal, the foremost authority on Eve: Online economics and gameplay.
Luigi Thirty
Science and Trade Institute
Caldari State
#23 - 2014-02-11 20:04:18 UTC  |  Edited by: Luigi Thirty
It's rather annoying that the bizarre CCP MIME type means it doesn't open in my browser that has a JSON viewer. Why doesn't it just use application/json like everything else?
Raoul Estaban
Deep Core Mining Inc.
Caldari State
#24 - 2014-02-11 20:22:56 UTC
Luigi Thirty wrote:
It's rather annoying that the bizarre CCP MIME type means it doesn't open in my browser that has a JSON viewer. Why doesn't it just use application/json like everything else?

CCP like to be special snowflakes.
Luigi Thirty
Science and Trade Institute
Caldari State
#25 - 2014-02-11 20:42:05 UTC
Other things:

Why doesn't it send faction = null when someone's not in FW like the regular killmail API does?
Why does it send every number twice, once in int form and once in str form?
Why are corp/alliance icon URLs contained in objects when their only data is the URL?

Please don't tell me this is a hacked-together JSON converter on top of MSSQL XML output.
CCP FoxFour
C C P
C C P Alliance
#26 - 2014-02-11 20:51:13 UTC
Luigi Thirty wrote:
Other things:

Why doesn't it send faction = null when someone's not in FW like the regular killmail API does?
Why does it send every number twice, once in int form and once in str form?
Why are corp/alliance icon URLs contained in objects when their only data is the URL?

Please don't tell me this is a hacked-together JSON converter on top of MSSQL XML output.


In CREST fields can be optional, when something is null we just don't return it. Those fields are optional.
I cannot remember the exact technical reasons, but there was some reason for sometimes wanting a string representation. Something about JS not liking long numbers. I actually only put it in once, but CREST takes it and sends both the Long and String version.
Um... to be honest I don't know the design reasons for that. It is however the standard for CREST.

@CCP_FoxFour // Technical Designer // Team Tech Co

Third-party developer? Check out the official developers site for dev blogs, resources, and more.
Sentient Blade
Crisis Atmosphere
Coalition of the Unfortunate
#27 - 2014-02-11 20:54:48 UTC
Some (most) of the numbers blow the 32 bit boundary, putting them in string format makes them extractable by everything, not just those handling uint64 or 64 bit double.
Raoul Estaban
Deep Core Mining Inc.
Caldari State
#28 - 2014-02-11 20:59:43 UTC
Sentient Blade wrote:
Some (most) of the numbers blow the 32 bit boundary, putting them in string format makes them extractable by everything, not just those handling uint64 or 64 bit double.


Then they should only be sending them as strings. It's asinine to send it both ways when it's known one form is broken for most use cases.
Luigi Thirty
Science and Trade Institute
Caldari State
#29 - 2014-02-11 21:00:02 UTC  |  Edited by: Luigi Thirty
CCP FoxFour wrote:

In CREST fields can be optional, when something is null we just don't return it. Those fields are optional.


If you don't return all fields, is there a list of all possible fields it can return? I don't have access to enough killmails on my personal account to possibly find every field.

CCP FoxFour wrote:

I cannot remember the exact technical reasons, but there was some reason for sometimes wanting a string representation. Something about JS not liking long numbers. I actually only put it in once, but CREST takes it and sends both the Long and String version.


If the problem is numbers that are too big for 32-bit, why not just send them only as strings instead of an integer format that may break applications when it gets too big and let the application worry about manipulating them?
CCP FoxFour
C C P
C C P Alliance
#30 - 2014-02-11 21:27:19 UTC
Luigi Thirty wrote:
CCP FoxFour wrote:

In CREST fields can be optional, when something is null we just don't return it. Those fields are optional.


If you don't return all fields, is there a list of all possible fields it can return? I don't have access to enough killmails on my personal account to possibly find every field.

CCP FoxFour wrote:

I cannot remember the exact technical reasons, but there was some reason for sometimes wanting a string representation. Something about JS not liking long numbers. I actually only put it in once, but CREST takes it and sends both the Long and String version.


If the problem is numbers that are too big for 32-bit, why not just send them only as strings instead of an integer format that may break applications when it gets too big and let the application worry about manipulating them?


The documentation says whats what... but you don't have access to that until CREST is made fully available. Until then you guys will kind of have to put together some docs yourselves. Public CREST is not really a fully supported thing.

I will quickly say this:
Quote:

Killmail:
killID - Long
killTime - String
SolarSystem - Reference
- id - Long
- name - String
moon - Reference - Optional
- id - Long
- name - String
victim - MediaType
attackerCount - Long
attackers - MediaType

KillmailVictim
character - Reference - Optional
- id - Long
- name - String
- icon - External Reference
corporation - Reference - Optional
- id - Long
- name - String
- icon - External Reference
alliance - Reference - Optional
- id - Long
- name - String
- icon - External Reference
faction - Reference - Optional
- id - Long
- name - String
- icon - External Reference
damageTaken - Long
shipType - Reference
- id - Long
- name - String
- icon - External Reference
items - MediaType - Optional

KillmailItems
itemType - Reference
- id - Long
- name - String
- icon - External Reference
quantityDropped - Long - Optional
quantityDestroyed - Long - Optional
singleton - Long
flag - Long
items - Array - Optional
- itemType - Reference
-- id - Long
-- name - String
-- icon - External Reference
- quantityDropped - Long - Optional
- quantityDestroyed - Long - Optional
- singleton - Long
- flag - Long

KillmailAttackers
character - Reference - Optional
- id - Long
- name - String
- icon - External Reference
corporation - Reference - Optional
- id - Long
- name - String
- icon - External Reference
alliance - Reference - Optional
- id - Long
- name - String
- icon - External Reference
faction - Reference - Optional
- id - Long
- name - String
- icon - External Reference
securityStatus - Float
finalBlow - Bool
damageDone - Long
shipType - Reference - Optional
- id - Long
- name - String
- icon - External Reference
weaponType- Reference - Optional
- id - Long
- name - String
- icon - External Reference

@CCP_FoxFour // Technical Designer // Team Tech Co

Third-party developer? Check out the official developers site for dev blogs, resources, and more.
CCP FoxFour
C C P
C C P Alliance
#31 - 2014-02-11 21:28:29 UTC
Luigi Thirty wrote:
If the problem is numbers that are too big for 32-bit, why not just send them only as strings instead of an integer format that may break applications when it gets too big and let the application worry about manipulating them?


This way an application gets to choose and the consumer should be aware of the limitations of their language. Either way it doesn't really matter, it's not something that is up for discussion at this time and I wouldn't be the person to discuss it with.

@CCP_FoxFour // Technical Designer // Team Tech Co

Third-party developer? Check out the official developers site for dev blogs, resources, and more.
Draleth
Aliastra
Gallente Federation
#32 - 2014-02-12 03:13:53 UTC  |  Edited by: Draleth
Here's a comparison between the sample CREST killmail endpoint data and the result of my recursive transformation code on the V2 XML data; they're actually surprisingly similar, excluding the foreign references: https://gist.github.com/amcgregor/194ccbe33e199b2d785e

I'm disappointed that the new API, after having been given a clean slate, continues to invent "unique" (in terms of I've never seen that done by anyone before) edge cases especially ones that correct primarily non-issues.

Every JS implementation I tested supported at least 15 digits (all nines) accurate representation for integers. In actuality the largest contiguous "integer" range an IEEE 754 double-precision floating point number can represent, as used by the ECMAScript standard is: ±9,007,199,254,740,992, or 2^53, the number of bits assigned to the mantissa of a 64-bit float. JavaScript is defined as using this representation, see: http://ecma262-5.com/ELS5_HTML.htm#Section_8.5

So far the largest ID I've seen for character, corporation, or alliance is 2,081,394,931, so there's some room for growth.

But, too late to fix it, I guess. Just more preprocessing for me to do later. Pirate

(Side note: if the number is being used for bitwise operations or shifts the limitation is somewhat stricter at a 32-bits.)
CCP FoxFour
C C P
C C P Alliance
#33 - 2014-02-12 09:21:54 UTC
Just to be clear, I don't fully know or understand the decision for both string and none string representation of numbers in CREST. If you would like to talk about the design of CREST come to Fanfest and those that worked on it I am sure would love to talk your ears off.

For now though, lets keep this thread focused specifically on this endpoint.

There are currently 3 known issues with the endpoint:
1) If a killmail has types on it that were deleted in the past, for example the old probes, the endpoint would choke and die. /sad panda.
2) If there was a sleeper or other NPC on the killmail that belonged to a faction and not a corporation the endpoint would choke.
3) The image links for corporations, alliances, and factions did not work.

All three issues have been fixed and should hopefully be deployed during Thursdays downtime.

Issue 1 was a tricky fix because there are a few ways to fix it none of which are really that good. The chosen solution is to carry on as normal but replace the name of the item with "Invalid item".

Issue 2 was due to some NPCs not being in a corporation. When the killmail is generated in those cases their corporationID is populated with a factionID and the endpoint would choke when trying to match a factionID to a corporation. I now have some special casing in there to deal with this and if a corpID is actually a factionID put it into the faction slot as it should.

Issue 3 was really just me not testing well enough. Characters use .jpg and tested fine but corps, alliances, and factions all use .png but I clearly didn't test that and thought they would all be jpg. I was clearly wrong. This has been fixed.

Sorry for the brokens but hopefully that should clear up most of the problems. If you have any further issues after Thursday please let me know and I will see about fixing them ASAP.

@CCP_FoxFour // Technical Designer // Team Tech Co

Third-party developer? Check out the official developers site for dev blogs, resources, and more.
CCP FoxFour
C C P
C C P Alliance
#34 - 2014-02-13 10:39:08 UTC
Due to me being terrible, occupied with far to many things, and just what not these fixes will not be going out today (Thursday the 13th). I will get them out at the earliest opportunity and will let you know when they go out. So sorry! :(

@CCP_FoxFour // Technical Designer // Team Tech Co

Third-party developer? Check out the official developers site for dev blogs, resources, and more.
Harvey James
The Sengoku Legacy
#35 - 2014-02-14 12:31:15 UTC
is this too replace the normal API killboards as they don't seem too work atm?

T3's need to be versatile so no rigs are necessary ... they should not have OP dps and tank

ABC's should be T2, remove drone assist, separate HAM's and Torps range, -3 HS for droneboats

Nerf web strength, Make the blaster Eagle worth using
Steve Ronuken
Fuzzwork Enterprises
Vote Steve Ronuken for CSM
#36 - 2014-02-14 13:05:07 UTC
Harvey James wrote:
is this too replace the normal API killboards as they don't seem too work atm?



This is to replace manual posting of kill mails, with a way that can be immediately verified.

Woo! CSM XI!

Fuzzwork Enterprises

Twitter: @fuzzysteve on Twitter
Peter Powers
Terrorists of Dimensions
HORSE-KILLERS
#37 - 2014-02-14 14:34:01 UTC
Harvey James wrote:
is this too replace the normal API killboards as they don't seem too work atm?

can you explain what you mean by that?

3rdPartyEve.net - your catalogue for 3rd party applications
Crasniya
The Aussienauts
#38 - 2014-02-14 16:37:37 UTC
This is fantastic, FoxFour, glad to see CREST finally moving forwards. :)

Though I suppose this explains why Planetary Conquest hasn't been fixed. :/

Soraya Xel - Council of Planetary Management 1 - soraya@biomassed.net
Luigi Thirty
Science and Trade Institute
Caldari State
#39 - 2014-02-16 21:38:01 UTC
Harvey James wrote:
is this too replace the normal API killboards as they don't seem too work atm?


No they fixed that with a new endpoint already. This is for authenticating killmails so they can be entered immediately by a user.
CCP FoxFour
C C P
C C P Alliance
#40 - 2014-02-18 14:47:32 UTC
CCP FoxFour wrote:
Just to be clear, I don't fully know or understand the decision for both string and none string representation of numbers in CREST. If you would like to talk about the design of CREST come to Fanfest and those that worked on it I am sure would love to talk your ears off.

For now though, lets keep this thread focused specifically on this endpoint.

There are currently 3 known issues with the endpoint:
1) If a killmail has types on it that were deleted in the past, for example the old probes, the endpoint would choke and die. /sad panda.
2) If there was a sleeper or other NPC on the killmail that belonged to a faction and not a corporation the endpoint would choke.
3) The image links for corporations, alliances, and factions did not work.

All three issues have been fixed and should hopefully be deployed during Thursdays downtime.

Issue 1 was a tricky fix because there are a few ways to fix it none of which are really that good. The chosen solution is to carry on as normal but replace the name of the item with "Invalid item".

Issue 2 was due to some NPCs not being in a corporation. When the killmail is generated in those cases their corporationID is populated with a factionID and the endpoint would choke when trying to match a factionID to a corporation. I now have some special casing in there to deal with this and if a corpID is actually a factionID put it into the faction slot as it should.

Issue 3 was really just me not testing well enough. Characters use .jpg and tested fine but corps, alliances, and factions all use .png but I clearly didn't test that and thought they would all be jpg. I was clearly wrong. This has been fixed.

Sorry for the brokens but hopefully that should clear up most of the problems. If you have any further issues after Thursday please let me know and I will see about fixing them ASAP.


This fixes have been submitted and should be going out with tomorrows (February 19th) downtime. If you run into any issues after that be sure to let me know. :)

Again, sorry for the delay on getting these fixes out.

@CCP_FoxFour // Technical Designer // Team Tech Co

Third-party developer? Check out the official developers site for dev blogs, resources, and more.
Previous page123Next page