Tuesday, April 15, 2014

Everything Is Changing


Looks like the summer expansion is gearing up to be a big shake-up for industry.  First, big reprocessing changes, and now big manufacturing changes.

Most of the major points are easy to understand.

  • Damage Per Job is going away for R.A.M. and R.Db items
  • Extra Materials are being removed, all materials will be affected by reprocessing/production efficiency the same
  • Market groups are being reorganized to make a little more sense
  • Industry slots are going away, replaced with a demand charge
  • POS standings requirements are being removed
  • Remote BP access will not be shared between POS and NPC station.
    • Copy speed is being reduced to make it easier to distribute copies.
The unifying theme to watch in these devblogs is nothing will be free in industry any more.  Refining will have variable yields depending on space/equipment, but never be 100%.  NPC manufacturing will have meaningful costs to production above-and-beyond raw materials.  There are no more free lunches.

Before I get into my review, I want to start with a TL;DR: The proposed changes are bad for cooperative industry and strongly incentivize solo industry as-is.  Though the changes aren't a catastrophe for corp-level/frontier industry, a lot of the changes will make many of the tools people use difficult.  I will cover my complaints in depth at the end of this post, but changes as they exist in the dev blog have me worried.

Death to Slots

Slots, as we know/hate them, are going away.  They will be replaced with a "cost scaling system".  TL;DR: you will be able to install a job anywhere that has science/industry services today, but will have to pay varying fees as a % of base cost.  What hasn't been explained yet is how this will affect POS.  More info will come out soon(tm) I am sure about the POS design.

Personally, I'm a fan of this for the most part.  Outside a few corner cases (newbie systems, outposts), I think the change is good.  NPC slot scarcity has been an unnecessary bottleneck on production.  It has pushed a lot of casual players out of the market, and left a "POS or GTFO" attitude.   Also, with a raw ISK cost, it should be obvious to producers what is impacting their bottom line.  This should stomp down some of the "time is free" attitudes out there.  I'd still like to see a time efficiency mechanic in station lines... as the lines get more crowded, overall productivity drops, but I can take what is given here.

Death to Standings

In a one-two-punch, not only are in-station industry resources going to become less constrained, POS ownership is going to become much easier.  All limits to anchoring a POS are being removed.  This means a tower can be dropped by a corp in any security (except special systems, same as POCO restriction), with no standings requirement.
I am a pretty big fan of this change.  It means we should see a dramatic decrease in moon-holding POS.  It will be much easier to get a moon, and use it or lose it.  There will still be a war requirement to clear towers, and regions with hubs will still be prime real estate, but those willing to compromise should be able to get POS a lot easier.

The unintended consequence here is when you remove slots, what will that do to industry POS?  POS layout has been a game of getting the slots you need and paying with CPU... if equipment needs are being decreased, will there be more dickstars?  Less POS?  More info about POS changes are promised in a later devblog, so we'll see.

BPO Risk

This is the crux of my unease with the proposed changes.  BPs in stations will not be accessible in POS.  Though this increases the risk to loss in a war (net good change), it makes corp theft a MUCH LARGER problem.  With how little control corp roles give you at a POS, if something needs to be moved between labs for work (Copy-->Manufacture, Invention-->Manufacture, Research-->Manufacture) then people need take rights.  And either you're stuck with a wild-west "anyone with POS access can take" rights scheme, or "only ultra-trusted members can move crap around for people".

With copy bandwidth/availability going up substantially, it's easy to say "just risk copies", but there are a bunch of unintended consequences with those changes.  Imagine my T2 component library: 10x of each component BPO.  That library took a long time to research.  Should I be spending money/time on copies or put the library at risk in a POS?  If I go with copies, I could very easily blow past the 1500 items/hangar limits, leaving me with more logistical headaches than security.  If I am spending my time copying all these BPOs, when will there be time to invent the T2 stuff?  My choice is to bring in help for copy bandwidth, or lock out people for BPO security.

If you put your BPO in the POS, you could be out those originals.  If you put a pile of copies there instead, you could have that time stolen from you.  There is no good way to keep a modicum of security at a POS without a lot of overhead for managers.  Couple this headache with the very low bar to owning a new POS, it stands to be much easier to give yourself a solo corp where those BPOs can't be stolen than cooperate with internet strangers at the risk of a library that could have years of research in it.

What Should Be Changed

Let me boil it down again: I should not be afraid of my corp members.  A properly configured corporation should be able to secure its assets to view/take at appropriate levels.  What made this work up to now is that anything super-valuable could be secured using the Lockdown mechanic.  This meant the BPO was still usable from station for research/mfg, but it couldn't be moved without a corporate vote.  As CEO, I can volunteer my pricey BPOs, but sleep well at night knowing that only I can unlock them for moving. 

With this change, I can risk my BPO at POS to wardec, but the much greater risk is the team that needs access to them.  If I can get to a sufficient level of pseudo lockdown (pw protected, or no need to move prints around the POS) to keep my members from taking those BPOs, then I'm more than happy to share.  If I am stuck with a mountain of copies as my only recourse, then I will opt not to share, instead locking my friends out of my POS with the tools at hand.  

Also, time will tell, but I am not super enthusiastic about the new UI spoiler... unless batch install is part of the feature.

Monday, March 3, 2014

ColdCall: A zKB Recruitment Tool

Probably going to make some waves among the anti-API crowd with this one, but it was a seriously fun experiment.  zKillboard's API continues to be one of my favorite data sources, and a lot of work in January paid off into what I was hoping would be an exciting new tool.

Over the month of February, Aideron Robotics leadership wanted to push new membership.  Mostly to fuel our desire to be the 900lb gorilla in Essence, but the B-R5RB fight brought a huge surge of new players and that only doubled our desire for new members.  To facilitate this, an all out media offensive was waged: pushing fight videos to /r/eve, podcasts, forum spam, blogs and blogs, open fleet nights... and lastly, our sekret weapon ColdCall.

What is ColdCall?

How many times have corp leaders mused: "If only we could parse killboards to find PVPers in line with our goals"?  ColdCall is my attempt to answer that need.  By essentially building a local mini copy of zKillboard, recruiters can directly manipulate the pilots list with SQL, then use publicly-available EVE API feeds to get some basic information about those candidates.

In Aideron Robotics, we used a very basic query to identify Federal Defense Union (Gal FW NPC) pilots active in our timezones and would probably be picked up by someone in the warzone through open fleet or convo means.  Also, we have worked to expand the queries to include corps that might register as "dead corps" where one or two members are active.

We used the automated candidate list to then feed to recruiters.  Recruiters grade the candidates manually on "hireability" checking their kill/in-game records for info like:
  • Active Systems
  • General record (filter out farmers/lone-wolves)
  • Approximate age
  • Approximate skill level
  • Approximate activity level
Most of those criteria could be automated with a little more work, but I don't want to cut out humans to the point where we were just blindly sending out form letters.  Instead, recruiters identify high-quality NPC pilots, invite them to fly with us in an Open Fleet Night. The goal is to let candidates decide if Aideron is the right fit for them.  We filter out outstanding invitations, and only send out invites to newly identified candidates.  The idea is outreach, hopefully avoiding spam.

How Does ColdCall work?

TL;DR, ColdCall works in a 3 stage process.  We then upload the result CSV to gdoc for some filtering to avoid spamming outstanding invites.

Stage1: Scrape zKillboard

The first stage takes a very-wide query and scrapes back as many days as the script runner decides valuable.  In Aideron Robotics case, we keep a 45-day record of all kills/losses with factionID=galmil.  Then, using zkillboard's own participants table structure, ColdCall stores off all the participant data.  It also stores off fitting data, but I currently don't leverage that in AIDER's version.

The goal with the first stage is to scrape the lowest-common-denominator of kill criteria.  Trying to locally recreate the ENTIRE zKillboard database is a fool's errand.  Instead, limiting queries to specific criteria like region, ship group, date range, lowers a potential 30M+ kill list to <100k.  The narrower this first step, the faster the rest of the program will run.  zKillboard's API is the biggest bottleneck for this program.

Stage2: Filter A Candidate List

ColdCall accepts a SQL argument to filter the Stage1 results.  For AIDER, this looks like:
  • Active in US TZs
  • More than 5 kills+losses
  • Member of FDU
  • Activity in the last 20 days
This lends itself to iterations with different criteria.  For instance, we want to extend the view to look at EU candidates.  Also here is where we can identify other criteria like "Few active members in a med/large corp" or even filter further to look into fittings/preferred ships, or active area.  

As of release, this isn't as flexible as I'd like.  In a future release I'd like to make the only feed-forward requirement of this stage be CharacterID.

Stage3: Build a character profile

Stage3 combines a look at public API data (corp history, join date, character name) with a second-pass of zKillboard data for more direct stats.  This results in a final candidate list with everything you'd want a recruiter to look at.  Currently, this stage is a little more rigid than I'd like, but it gives our recruiters what they need.  This stage is going to be the focus of future releases.

How Well Did It Work?

Before my inbox is spammed with screams of hax, cheating, spam, or what have you, I gotta say the results are not as hot as I had expected.

On the data side, ColdCall did exactly what I wanted it to do.  Identified candidates met our outreach criteria extremely well, and as a corp-advertising outreach it gave us a pretty decent signal boost.  Unfortunately, joining a corp is an extremely social activity and a cold invite, no matter how tailored, doesn't really get people to apply.  Also, data does not paint the whole story, and many candidates responded that they weren't ready to join a corp.  

In February, we identified 58 candidates through ColdCall, and 9 joined.  Compared with 3x the new-hires identifying High Drag as their inspiration to join.  The usual turn around time was over 2 weeks, so almost all our expectations on returns fell extremely short.  We still intend to use ColdCall to identify players, but it is definitely a 3rd tier option in our recruitment outreach.  

TL;DR for all the recruiters out there: nothing beats social operations.  Blogs, podcasts, and videos got the AIDER name out there.  Open Fleet Nights got candidates to interact with our existing staff.  ColdCall has only proved useful to check our conversion rate vs other galmil corps... not actively recruit them.

Feel free to fork a version for your own needs.  The repo has been left open.  The program will continue to grow as per AIDER specifications, but features should grow for general use.

Thanks Due

Huard Catanach: helped big time in getting the tool outlined and feedback on filtering candidates.  He handled all the outreach and most of the candidate grading.  

Marcel Devereux: Helped with sticky points in the code.  Specifically encouraging use of the zKillboard SQLs as a framework.  Also helped a while back get my head around eveapi and inspiration to push out a zkb.py module.   

This would not have been done if it weren't for Aideron Robotics and the dev-rich environment it provides.  It was easy to get quick feedback to move through the development process and release a usable alpha in record time.

Wednesday, February 19, 2014

Frequency: XKCD to EVE

On Monday, XKCD posted a piece called Frequency

Frequency Frequency Frequency Frequency Frequency
Frequency Frequency Frequency Frequency Frequency
Frequency Frequency Frequency Frequency Frequency
Frequency Frequency Frequency Frequency Frequency
Frequency Frequency Frequency Frequency Frequency
Frequency Frequency Frequency Frequency Frequency
Frequency Frequency Frequency Frequency Frequency
Frequency Frequency Frequency Frequency Frequency
Frequency Frequency Frequency Frequency Frequency
Frequency Frequency Frequency Frequency Frequency

Title text: This comic shows estimated average frequency. I wanted to include the pitch drop experiment, but it turns out the gif format has some issues with decade-long loops.
Reposting courtesy: Explain XKCD

Chatting with my friends in Aideron Robotics, the question came up: "Wouldn't it be cool to do that for EVE data?"  Conveniently, I happened to have that data somewhat handy.  Unfortunately, as I said in my previous post, I was lacking the time to work on it.

After putting out a call on #tweetfleet/#devfleet with "I have the data, if someone wants to make it happen", Lukas Rox of Pozniak.pl answered the call!  With a little bit of JavaScript hacking, he put together two awesome pages:
I already have a repository of destruction counts from zkb.  Using 2013's data to build averages, I sent forward the frequencies to Lukas, who in turn used JavaScript to get the same effect.  Unfortunately, this is averaged data, not live.  I would very much like to update it to match zkb's map function (broken?), but I need to write a different tool to hook into their STOMP service.  It's high on my TODO, but I don't have very much dev time handy right now.  In the meantime, a 15-60min lagging service is possible using my zkb.py to scrape recent kills... but STOMP would be so much better.

To keep this short and sweet: this was a lot of fun to collaborate on.  Where I had the data, Lukas had the know-how.  And the turnaround time, being published 2 days after XKCD posted, was phenominal.  We're still arguing behind the scenes about the time dilation factor (@ashterothi suggested a slider, which might solve everyone's issues).  We are chatting about teaming up on more data projects in the future, and I look forward to putting our tools together!


A few addendums.

@ashterothi originally suggested the "wouldn't it be cool if..." comment that compelled me to scrape the data and throw it out to #tweetfleet

Lukas also pushed an page that chronicles the big B-R5RB fight: http://pozniak.pl/evestats/br5rb/