EVE Technology Lab

Edit: After some thinking and some great input from Xe'Cara'eos the program will be a lot more ambitious!

Currently planned features are:

• Paste names from local and get an overview of players and connections
• Identify PvP active players
• Identify suicide gankers
• Identify hauler / miner gankers
• Identify carebears
• See connections between players (A is on killmails with B and C in local) as a graph
• Show recent losses / kills (fitting) from players with a single click

Help us brain storming via Trello! PM / mail for an invite to the board, ideas greatly appreciated!

---

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
Link 2 (sneak preview of the new GUI): also 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!

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. :)

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