The Pains of Kit Building

As I mentioned in my last post, all the complex corner-cases for production happen in T2 manufacturing.  Where putting together the bill-of-materials was difficult due to T1/T2 linking, the "build kit" step is painful due to intermediate building.

In a sloppy first-pass, it's pretty easy to just say "I'll build everything".  The code is not too difficult: once the parts are linked, it's just a matter of taking second (or third) passes on those products to work down to raw materials.  Unfortunately, it would be a massive waste of all this programmatic power to not allow for a little flexibility.

Problem: I want to be able to build some of the intermediates, but not others

The basic inspiration starts with EVEHQ's Prism tool.  

In this view, it's pretty easy to select each product that can be built and adjust the final bill-of-materials for that product.  Though EVEHQ does support a batch tool, I find it too rigid for my work.  Also, there is a lot of data missing from this view:

• Build vs Buy cost for intermediates?
• Build vs Buy time for intermediates?  Added intermediate time will detract from final ISK/hr calculation
• No flexibility for partial builds
• Product-by-product adjustment

Though the amateur or intermediate T2 manufacturer may just write off those functions as "too much trouble", I personally worry about these points and use them in my current production practices.  Doing partial builds on components saves me character-days of otherwise wasted production time.  

Solution: Replicate Current Resupply Methodology

Today, when I am picking up production kits, the todo list looks something like:

1. Figure out what products to build for sale
2. Pick-and-choose what intermediate products to DIY build
3. Purchase everything: raw materials, T1, components

Regardless of how I organize my tools, it will require 2 passes.  First pass to list raw materials + intermediates, second pass to figure out additional raw materials.  Though I can write some decision conditions to automate step-2, as a first draft I should stick to just processing it with expected human input.

As a draft set of outputs:

STEP1: Design a "Kit"

STEP2: Adjust intermediate products

STEP3: Get Shopping/kit list(s)

These views give me an intermediate point to deliver programming logic without the overhead of UI design.  Also, it gives me a springboard to play with UI without having to completely redesign the code.  Though I need to tweak the intermediate build step to be more intuitive, I think this is a pretty decent spot to start the next major leg of code development.

What's In The Works

I have spent much of the last week getting the pieces in order and starting work on actual EVE API code.  The hope here is that I can load each contributor into the program and do the BPO math off their actual skills.  This will help define bill-of-materials on anyone, and better define costs on the other end.  

I recently teamed up with a friend from #tweetfleet to start focusing more completely on tool development.  We're splitting the work up to finally solve some of the bottlenecks that have been holding me back from hiring help.  The hope is, by spring, to have most of the alpha tools banged out so we can bring on players to help with the industry half while we work on more ambitious back-end work.  It's gearing up to be a pretty epic year!