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.
 

[EVSCO/EVE-KILL] EPIC API (Yes, it is actually EPIC) (DEAD)

Author
Etil DeLaFuente
Aliastra
Gallente Federation
#61 - 2012-04-14 21:05:27 UTC
Thanks! :)

*goes to play with the api*
Karbowiak
Sacred Templars
Fraternity.
#62 - 2012-04-14 21:55:24 UTC
Fixed a but where the ships id wasn't shown in the involved party list, apparently the database field was changed from shp_external_id to shp_externalid..

Checking if there are any other similar bugs, that have creeped in. But there shouldn't be (Since every other function uses standard EDK calls)
Karbowiak
Sacred Templars
Fraternity.
#63 - 2012-04-17 09:50:03 UTC
Upped the mail limit 500, as some people needed to have it return more mails..

The default is still 100 tho :)
Karbowiak
Sacred Templars
Fraternity.
#64 - 2012-04-19 17:39:14 UTC  |  Edited by: Karbowiak
I have added two new calls, startDate and endDate.

They are both a little weird due to the way calls are handled, so if you write YYYY-MM-DD H:i:s - only YYYY-MM-DD H is actually passed on.

Instead you should write YYYY-MM-DD H.i.s, then it works Blink
Also it cannot span months, so it only works within a month, but it can be used to help get all mails for specific pilots, corps, alliances, ship etc. better than minKLLid and maxKLLid can.

Examples:
http://eve-kill.net/epic/victimCorp:Future_Corps/mask:262150/startDate:2012-04-17_00.00.00
http://eve-kill.net/epic/victimCorp:Future_Corps/mask:262150/startDate:2012-04-01_00.00.00/endDate:2012-04-04
http://eve-kill.net/epic/system:Jita/mask:1606910/mailLimit:250/startDate:2012-03-01/endDate:2012-03-02

Also startDate / endDate override year/week settings ;)

Remember, space is _ !
Karbowiak
Sacred Templars
Fraternity.
#65 - 2012-04-19 18:00:49 UTC
Updated the cache time of varnish, so instead of 60 minutes pr. url request, it's now 15 minutes.

Should hopefully not raise load too much (Not that many that's using it yet tho - so dunno)
Karbowiak
Sacred Templars
Fraternity.
#66 - 2012-04-20 19:31:18 UTC  |  Edited by: Karbowiak
added a new call, 'onlyAPI'

Set it to true, and it does what you'd expect.

Only show mails that are API Verified! ;)

Example:
http://eve-kill.net/epic/victimShipClass:Battlecruiser/onlyapi:true/mask:787423
Karbowiak
Sacred Templars
Fraternity.
#67 - 2012-04-28 13:04:24 UTC
And up we go! Cool
Karbowiak
Sacred Templars
Fraternity.
#68 - 2012-05-01 21:22:58 UTC
Added two new calls, NoTowers and FBPilotName.

NoTowers doesn't have a true or false statement, it's just added to the url (like onlyAPI) /epic/noTowers/stuff

And FBPilotName takes a pilots name, and uses it to sort for the final blow pilot.

Enjoy! :)
Penny Brothers
Doomheim
#69 - 2012-05-07 23:37:58 UTC
Question on startDate and endDate formats.

If I use a URL with an underscore for the endDate date time separator then the endDate seems to be being ignored

e.g.

http://eve-kill.net/epic/mailLimit:500/system:FD-MLJ/startDate:2012-03-01_11.20.00/endDate:2012-03-19_12.20/mask:557586

returns

[{"timestamp":"2012-05-07 22:42:00","victimName":"Cpt Angus","victimShipClass":"Covert ops" ....(snip)

however if I use a space in the URL as date and time separator for the endDate then all seems to work ok

e.g.

http://eve-kill.net/epic/mailLimit:500/system:FD-MLJ/startDate:2012-03-01_11.20.00/endDate:2012-03-19%2012.20/mask:557586

returns

[{"timestamp":"2012-03-19 11:00:00","victimName":"Ilya Dahmas","victimShipClass":"Battlecruiser","solarSystemName":"FD-MLJ", ... (snip)... {"timestamp":"2012-03-10 21:58:00"

however using space as a separator in the startDate
e.g.
http://eve-kill.net/epic/mailLimit:500/system:FD-MLJ/startDate:2012-03-01%2011.20.00/endDate:2012-03-19%2012.20/mask:557586

returns nothing.

Is this a bug or is it by design?
Jack O'Connal
Brutor Tribe
Minmatar Republic
#70 - 2012-05-10 00:50:28 UTC
I couldn't sleep last night so I threw this together to experiment with your API.

http://www.privatepaste.com/17f9e01ee5

I'm a bit of a noob with LINQ so if you see any way to improve this code I'd love to hear about it.

Karbowiak
Sacred Templars
Fraternity.
#71 - 2012-05-10 09:53:54 UTC
Penny Brothers wrote:
Question on startDate and endDate formats.

If I use a URL with an underscore for the endDate date time separator then the endDate seems to be being ignored

e.g.

http://eve-kill.net/epic/mailLimit:500/system:FD-MLJ/startDate:2012-03-01_11.20.00/endDate:2012-03-19_12.20/mask:557586

returns

[{"timestamp":"2012-05-07 22:42:00","victimName":"Cpt Angus","victimShipClass":"Covert ops" ....(snip)

however if I use a space in the URL as date and time separator for the endDate then all seems to work ok

e.g.

http://eve-kill.net/epic/mailLimit:500/system:FD-MLJ/startDate:2012-03-01_11.20.00/endDate:2012-03-19%2012.20/mask:557586

returns

[{"timestamp":"2012-03-19 11:00:00","victimName":"Ilya Dahmas","victimShipClass":"Battlecruiser","solarSystemName":"FD-MLJ", ... (snip)... {"timestamp":"2012-03-10 21:58:00"

however using space as a separator in the startDate
e.g.
http://eve-kill.net/epic/mailLimit:500/system:FD-MLJ/startDate:2012-03-01%2011.20.00/endDate:2012-03-19%2012.20/mask:557586

returns nothing.

Is this a bug or is it by design?


Sorry, end and startDate filters are a bit weird.

you don't _HAVE_ to add the time part tho.
As for how it's made to work right now, i'll rework it so it uses unixtimestamps instead. should work a million times better than the current implementation (No . or spaces)
Karbowiak
Sacred Templars
Fraternity.
#72 - 2012-05-10 09:54:13 UTC
Jack O'Connal wrote:
I couldn't sleep last night so I threw this together to experiment with your API.

http://www.privatepaste.com/17f9e01ee5

I'm a bit of a noob with LINQ so if you see any way to improve this code I'd love to hear about it.



Cool, i know nothing about LINQ, så yeah - to me it looks good :P
Desmont McCallock
#73 - 2012-05-10 10:08:15 UTC  |  Edited by: Desmont McCallock
Since .NET 3.5 there is native support for JSON. You need only to add reference to System.Web.Extensions and JavaScriptSerializer will be available for JSON serialization and deserialization.

Edit: LINQ can also be used as methods chain (with lamda expressions) for those who have difficulties understanding the syntax.
Etil DeLaFuente
Aliastra
Gallente Federation
#74 - 2012-05-12 11:07:55 UTC
Built-in json serializer engine is crap, json.net is far better and will become the built-in json engine for .net.



Etil DeLaFuente
Aliastra
Gallente Federation
#75 - 2012-05-13 13:55:54 UTC  |  Edited by: Etil DeLaFuente
Jack O'Connal wrote:
I couldn't sleep last night so I threw this together to experiment with your API.

http://www.privatepaste.com/17f9e01ee5

I'm a bit of a noob with LINQ so if you see any way to improve this code I'd love to hear about it.



You're wasting a lot of time parsing the json.

First, create your models, classes that represent what you'll need, than just deserialize the json. The json.net API has some nice features to achieve your goals.

Since i can't post an example without getting a forum error :CCP:, you can find the full code here : http://pastebin.com/JNPid67Q
Karbowiak
Sacred Templars
Fraternity.
#76 - 2012-05-15 17:03:04 UTC
Interesting to watch people actually make libraries for using EPIC.

I have started work on getting EPIC put into every EDK board out there (by making it part of EDK itself).
First i have to make a fetcher for EDK boards tho, but hey - easy peasy! :P
Khorkrak
KarmaFleet
Goonswarm Federation
#77 - 2012-06-15 01:49:54 UTC  |  Edited by: Khorkrak
Nice work! I've just finished writing some code to process kill data retrieved from your epic api. Next I need to write a process to automate fetching the data as I'd like to load relatively recent kills into my killboard from it. Hopefully, this api is far less resource intensive than the idfeed one is. Still though, how often should requests be made to avoid taxing eve-kill.net too much? What's the recommendation in comparison with the idfeed one where it's 50 kill mails per half hour?

The only issues I see with the data are that it appears there's no way to get the victim faction name and id from this unless I simply missed it. Also, for POS related kills, the victim name is the moon - like 'Moon 8' instead of being an empty string with a moonID field present and filled in with a non-zero value akin to the EVE API based kill mails. No big deal though. This is quite nice for testing things out. Thanks!

Note: it is possible to generate the JSON results directly in the database using group_concat and case statements thus avoiding having to do any string concatenations, looping and so forth in pokey PHP. While the queries to do so would be heinous looking it would nevertheless be far more efficient overall.

hmm I only get 1 kill mail from this:
wget -O results.dat http://eve-kill.net/epic/minKLLid:13000000/maxKLLid:13000500/mailLimit:500/mask:1607166

No different if I leave off the mailLimit.

Developer of http://www.decloaked.com and http://sourceforge.net/projects/pykb/

Karbowiak
Sacred Templars
Fraternity.
#78 - 2012-06-15 16:37:48 UTC
Khorkrak wrote:
Nice work! I've just finished writing some code to process kill data retrieved from your epic api. Next I need to write a process to automate fetching the data as I'd like to load relatively recent kills into my killboard from it. Hopefully, this api is far less resource intensive than the idfeed one is. Still though, how often should requests be made to avoid taxing eve-kill.net too much? What's the recommendation in comparison with the idfeed one where it's 50 kill mails per half hour?

The only issues I see with the data are that it appears there's no way to get the victim faction name and id from this unless I simply missed it. Also, for POS related kills, the victim name is the moon - like 'Moon 8' instead of being an empty string with a moonID field present and filled in with a non-zero value akin to the EVE API based kill mails. No big deal though. This is quite nice for testing things out. Thanks!

Note: it is possible to generate the JSON results directly in the database using group_concat and case statements thus avoiding having to do any string concatenations, looping and so forth in pokey PHP. While the queries to do so would be heinous looking it would nevertheless be far more efficient overall.

hmm I only get 1 kill mail from this:
wget -O results.dat http://eve-kill.net/epic/minKLLid:13000000/maxKLLid:13000500/mailLimit:500/mask:1607166

No different if I leave off the mailLimit.


Thanks for the kind words, as for how many times, i'd say once every 30 minutes would be fine, or every 60.
If you have any tips and ideas to what it lacks i'll gladly listen and see if i can't add it without alot of overhead.

Also, you should use the datetime stuff instead of minkllid / maxkllid, since the min/maxkllid stuff is rather dumb.
It easily jumps over kills and ignores others for unknown reasons (the query doesn't exlude mails, but it does for some reason anyway :\)
Khorkrak
KarmaFleet
Goonswarm Federation
#79 - 2012-06-16 14:03:09 UTC  |  Edited by: Khorkrak
Thanks that worked better:

wget -O results.dat http://eve-kill.net/epic/startDate:2012-01-01_00.00.00/endDate:2012-01-01_01.00.00/mailLimit:500/mask:1607166

Returns 500 kill mails yay. They are for kills in January however, not on January 1st, 2012 between midnight and 1:00 a.m. Instead It returned data for January 31st, 2012 between 2012-01-31 22:42:00 and 2012-01-31 23:59:00.

For example, kill: 22086310, 2012-01-31 22:42:00, America Shaftoe, Falcon

So it seems the 1:00 a.m. and January parts worked but not the day of the month and start time.

Developer of http://www.decloaked.com and http://sourceforge.net/projects/pykb/

Etil DeLaFuente
Aliastra
Gallente Federation
#80 - 2012-06-17 11:17:58 UTC  |  Edited by: Etil DeLaFuente
I have the same problem retrieving killmails history. The order is by date descending.

So if the max kill number is reached, make another request with the same starting date and the minimum date you received . You'll have to do it as long as you reached the limit.

Would be more logical to get kills ordered by date ascending tho.