Pages: [1] :: one page |
|
Author |
Thread Statistics | Show CCP posts - 2 post(s) |
Jack Mensen
Specter Force Security
0
|
Posted - 2014.04.19 13:00:00 -
[1] - Quote
Hello Capsuleers! o/
Got bored of getting blown up while doing exploration in nullsec (new character alert!) and thought about how I could make my life a bit easier. Today I want to share my little tool I created yesterday (yup, version 0.0 so don't expect too much) to quickly check the guys sitting in local.
Usage: Local: CTRL+A -> CTRL+C, switch to Local Checker: CTRL+V
Quick screenshot ([img] not working?): Have a look
Link: from my dropbox
Next step besides from making it a bit more beautiful is integration with ZKILLBOARD. This would allow to select a guy from the list and see his recent PvP activities (losses / kills) in a matter of a second. After reaching that milestone I would evaluate if I can get the required information from ZKILLBOARD to make connections between the guys in local, i.e. check if Person A is in kill mails with Person B but not in the same corporation or alliance (possible alt). This information could be displayed nicely in the main view then and make you aware of possible camps / roams.
Thoughts, ideas?
Technical side node: This program uses the EVE API and checks for character information in batches of 10, up to a total amount of 50 characters. So no quick JITA lookup, sorry!
|
|
CCP FoxFour
C C P C C P Alliance
3056
|
Posted - 2014.04.19 13:05:00 -
[2] - Quote
Jack Mensen wrote:Hello Capsuleers! o/ Got bored of getting blown up while doing exploration in nullsec (new character alert!) and thought about how I could make my life a bit easier. Today I want to share my little tool I created yesterday (yup, version 0.0 so don't expect too much) to quickly check the guys sitting in local. Usage: Local: CTRL+A -> CTRL+C, switch to Local Checker: CTRL+V Quick screenshot ([img] not working?): Have a lookLink: from my dropboxNext step besides from making it a bit more beautiful is integration with ZKILLBOARD. This would allow to select a guy from the list and see his recent PvP activities (losses / kills) in a matter of a second. After reaching that milestone I would evaluate if I can get the required information from ZKILLBOARD to make connections between the guys in local, i.e. check if Person A is in kill mails with Person B but not in the same corporation or alliance (possible alt). This information could be displayed nicely in the main view then and make you aware of possible camps / roams. Thoughts, ideas? Technical side node: This program uses the EVE API and checks for character information in batches of 10, up to a total amount of 50 characters. So no quick JITA lookup, sorry!
I assume you are doing name to ID resolution at up to 250 a time? Then ID to detailed information 10 at a time? CCP FoxFour // Game Designer // @regnerba
|
|
Jack Mensen
Specter Force Security
0
|
Posted - 2014.04.19 15:55:00 -
[3] - Quote
CCP FoxFour wrote: I assume you are doing name to ID resolution at up to 250 a time? Then ID to detailed information 10 at a time?
Name to ID (https://api.eveonline.com/eve/CharacterID.xml.aspx) with up to 50 names as parameter (1 request) into a ID to character info (https://api.eveonline.com/eve/CharacterInfo.xml.aspx) in chunks of 10 parallel requests till I reach the maximum of 50. I think that is a sane amount and doesn't put too much pressure on your API endpoint. Open for input from your side though!
Greetings, Jack |
Wafflehead
Hurricane Research
92
|
Posted - 2014.04.20 20:56:00 -
[4] - Quote
There is a similar program EVE Pirate's Little Helper (http://eve-plh.com/) https://forums.eveonline.com/default.aspx?g=posts&t=285837
I don't believe the project is still going, would be good to add some of the features that they had :). |
|
CCP FoxFour
C C P C C P Alliance
3059
|
Posted - 2014.04.21 09:47:00 -
[5] - Quote
Jack Mensen wrote:CCP FoxFour wrote: I assume you are doing name to ID resolution at up to 250 a time? Then ID to detailed information 10 at a time?
Name to ID (https://api.eveonline.com/eve/CharacterID.xml.aspx) with up to 50 names as parameter (1 request) into a ID to character info (https://api.eveonline.com/eve/CharacterInfo.xml.aspx) in chunks of 10 parallel requests till I reach the maximum of 50. I think that is a sane amount and doesn't put too much pressure on your API endpoint. Open for input from your side though! Greetings, Jack Edit: Just found EveLib which claims to obey the EVE API caching rules. Sounds nice, but for https://api.eveonline.com/eve/CharacterID.xml.aspx the currentTime and cachedUntil fields are the same and update with every request. Gonna do my own caching in a future version to get the amount of requests down a bit (even though my app with its 10 parallel requests at a time till 50 in total shouldn't be that much of a problem).
I would highly recommend if at all possible using the OwnerID endpoint. It's slightly more efficient AND returns the groupID for whatever you have looked up so you can confirm it is a character and not something else.
The cache time is set to the same as current time, because yea... so it turns out we cache DB calls not pages. In the case of something like this call each name -> ID is cached individually, which means each name could have a different cache time. If someone looked up a name at 12:30 and then another name was looked up at 12:45 and then you looked them both up at 13:00 there would technically be 2 cache times. Really though I think we cache those names to ID lookups for 24 hours or something because how often does a name change (don't quote me on that cache time, not at the office to double check).
I suppose I should add some kind of cache time to the page so that people trying to obey cache timers can do so. Probably just end up having it always set at 1 hour no matter when you look at it though...
Anyways, back to your thing...
All of our endpoints that take multiple IDs/names should all max out at 250, so you can feel free to do the name to ID resolution with 250 names... I think... would have to double check but it should be...
As for getting more information from an ID... what you are doing sounds appropriate. Not sure what else you can do... You seem to care about time of employment and security status so you will need to use the characterInfo endpoint. If you just wanted corp/alliance/faction information you could get it in bulk from the CharacterAffiliation endpoint in bulk.
Not sure how long your thing takes to run, but you could consider doing a bulk name to ID in batches of 250, then using the affiliation endpoint in batches of 250 to get basic information, and then in the background populate the rest of the information. That would offer a way to quickly get the basic information to help your user right now while detailed information comes ASAP.
Just a thought. Really is up to you, just keep the error rate down, include a custom user agent, and aim for no more than ~32 requests a second. :) CCP FoxFour // Game Designer // @regnerba
|
|
Jack Mensen
Specter Force Security
1
|
Posted - 2014.04.21 10:20:00 -
[6] - Quote
CCP FoxFour wrote: I would highly recommend if at all possible using the OwnerID endpoint. It's slightly more efficient AND returns the groupID for whatever you have looked up so you can confirm it is a character and not something else.
The cache time is set to the same as current time, because yea... so it turns out we cache DB calls not pages. In the case of something like this call each name -> ID is cached individually, which means each name could have a different cache time. If someone looked up a name at 12:30 and then another name was looked up at 12:45 and then you looked them both up at 13:00 there would technically be 2 cache times. Really though I think we cache those names to ID lookups for 24 hours or something because how often does a name change (don't quote me on that cache time, not at the office to double check).
I suppose I should add some kind of cache time to the page so that people trying to obey cache timers can do so. Probably just end up having it always set at 1 hour no matter when you look at it though...
Anyways, back to your thing...
All of our endpoints that take multiple IDs/names should all max out at 250, so you can feel free to do the name to ID resolution with 250 names... I think... would have to double check but it should be...
As for getting more information from an ID... what you are doing sounds appropriate. Not sure what else you can do... You seem to care about time of employment and security status so you will need to use the characterInfo endpoint. If you just wanted corp/alliance/faction information you could get it in bulk from the CharacterAffiliation endpoint in bulk.
Not sure how long your thing takes to run, but you could consider doing a bulk name to ID in batches of 250, then using the affiliation endpoint in batches of 250 to get basic information, and then in the background populate the rest of the information. That would offer a way to quickly get the basic information to help your user right now while detailed information comes ASAP.
Just a thought. Really is up to you, just keep the error rate down, include a custom user agent, and aim for no more than ~32 requests a second. :)
Heya! Thanks for your post, really appreciate it! The affiliation endpoint sounds interesting, I will have a look at it (I yet have to figure out what information are the most important ones).
About the caching: Thought about it yesterday and I think I came up with some good approach I want to implement next, going to post some details when I'm done with it.
ZKILLBOARD also has all the information I need to make connections between players in my graph, just thinking about a good visual representation at the moment. Anyways, thanks again for the input! |
Jack Mensen
Specter Force Security
1
|
Posted - 2014.04.21 11:01:00 -
[7] - Quote
Had a quick look at the features yesterday, sounds amazing! The last version from the tool was from march 2014 on the linked website, so I seems pretty much active. Gonna download it now and play a bit with it, maybe it does already what I want to do...
Edit: Ok had a look, nice program! I pulls stats from ZKILLBOARD and labels easy targets as carebears. My idea is to build a graph of player connections based on kill mails and give you a quick look at recent fittings, doesn't overlap with the Priates Little Helper tool. The dscanner tool is pretty nice! :P |
Jack Mensen
Specter Force Security
1
|
Posted - 2014.04.26 16:46:00 -
[8] - Quote
Bump for Trello, check out the edited first post. |
|
|
|
Pages: [1] :: one page |
First page | Previous page | Next page | Last page |