Everything You Never Wanted to Know: Google Spreadsheets

Spreadsheets and Spaceships; the classic rebuttal to EVE online's title.  This guide is a pre-post for another upcoming series reviewing existing tools.  This is to pair with the writeup for EVE-Central.  These two articles were written in parallel, so there will be a decent amount of overlap.

Most of the lessons covered in this guide are Google-specific commands.  Some will work in excel, but several functions will be Google-only.  We will once again be skipping the laser-focused specifics and remedial topics, focusing instead on those that may have a spreadsheet (or dozen) and wants to improve their existing tools.  Also, we will cover a few best-practices for design so as not to get bogged down with the slew of new features.  There will be a set of example spreadsheets to illustrate concepts.

Resources are at the end of the article.  After the break to save some screen space.

Introduction

Google Drive provides a suite of easily-shared common office tools.  Documents, presentations, forms, spreadsheets, everything a budding small business would need to thrive, and none of the cost of MS Office.  Also, being cloud-hosted comes with some additional benefits.  The cloud allows for incredibly easy access of live web data, without having to write clunky excel scripts.  Also, being able to share these documents means that you and your corp can control access to tools.  This guide is purely for the Spreadsheets toolset.

Basic Functions 

I write this because there was a suite of basic functions I did not know about when I switched into Google Spreadsheets.  Feel free to skip ahead if these get filed in the "duh" category.

Anchor reference ($)

This delimiter allows you to use the drag-copy function while anchoring specific references so they will not drag.  For instance, building 4 condors.  By making the first reference (mineral*$qty), you can then drag-copy across the other minerals (rows) to complete the reference in 1/8th the time.

Technically, the $ freezes whatever its next to:

• $A1: Will freeze COL to A
• Drag-copy COLs: reference will remain A1
• Drag-copy ROWs: ROW will update, but COL will remain A
• A$1: will freeze ROW to 1
• Drag-copy COLs: COL will update, but ROW will remain 1
• Drag-copy ROWs: reference will remain A1

&, JOIN(), REGEXEXTRACT()

Being code minded, I often want to programatically update string cells. Manually filling every cell with their real names, and then having to do it over again for the T2 variant sucks. Also, different groups might need to be added/stripped in more elaborate methods, hence what these string manipulators are for. Using these tools, you can add a lot of quick functionality for only a small amount of work.

• &: allows you to join strings (and references) together.  Think java string printing "hello "+x+" world"
• Great for joining small things together 
• A1=Target Painter I, A2=A1&"I"-->Target Painter II
• Great for adding cell references into string commands
• "api.eveonline.com/api/CharacterList?vcode="&vcode&"&apikey="&apikey
• Join(): works like most scripting join().  Delimiter, string_array
• Convert to csv string
• Join item id's for importXML()
• Use like an iterated &
• RegExExtract()
• Allows for regular expression parsing
• Regular Expression cheat sheet

Array Functions

• Transpose: swap rows/columns.  
• Example: make a list a header
• Sumproduct(): Multiplies each element by corresponding element then sums the outcome
• Example: cost of materials

ImportXML()

ImportXML is the single most useful function for EVE tools.  ImportXML allows you to automatically load nearly-live EVE market data.  Using the numerical typeID for items you want to track (like minerals, products, ships, etc), you can query the APIs of sites like EVE-central.  Also, you can filter out specific data using an xpath query.

Some resources for the uninitiated:

• Sample Spreadsheet
• typeID lookup
• EVE-Central API resource

Some notes to keep in mind:

• Tends to update on-the-hour
• Can force update by changing URL (add/remove "http://" from address)
• DB is most likely to fail request on-the-hour due to cron traffic
• Cannot script cron (as far as I know)
• Join() is your friend
• Join maxes out at 100 entries
• Google's complexity limit is 50 importXML calls.  For very-large sheets, be smart about queries
• Use join (or combine join's)
• Query more data per request:
• Ill-advised xpath: "//sell/min"
• Better xpath: "//sell" or no xpath
• More data per call means less calls for the same data
• xpath "|" does not work like you think it does.  Will concatenate on the END of the first query, not beside the first query #WorkingAsIntended
• Each importXML call will make the spreadsheet slower
• See best-practices notes for how to cope with these limitations

WARNING: Do not try to queryXML() EVE API data.  Whoever set up those XML's was a turd and did not make them xpath compatible.  It can be done, but you need to write an app-script to parse the data, existing functions will not do it.

QUERY()

Query is a tougher tool to use, but incredibly powerful for simplifying a lot of the manual work of updating spreadsheets.  Query allows a nearly-complete SQL-like interface for parsing data.  This becomes EXTREMELY useful for some more eloquent features or further staving off the need for custom code.  I am by no means a SQL pro, but a few simple cases can add a lot of power to your spreadsheet.

Uses:

• Quickly reference price data with a simple command
• Query('Price data'!A:X, "SELECT B where A='"&cell reference&"'",False)
• Group useful data:
• Automatically grab highest and lowest data without needed complex IF()'s
• List collections of data on a sortable variable
• Sort all the frigates out of a list of ships
• Group suitable products between a certain cost

Notes:

• When referencing strings (item names), make sure to include single quotes around value
• ='string' and close SQL query with a double quote
• Not fully formed, only need SELECT and sort criteria, no FROM
• Finicky just like SQL, some frustration will ensue
• Be careful about overrunning boundaries   CONTINUE() will stomp over cells and give precedence to whatever it is continuing

Best Practices

-Or- How I learned to stop worrying about complexity and trust importRange()

Import functionality takes a lot of processing power and will slow down your sheet significantly.  Pile on Query() and a lot of sumproduct() calls, and your sheet will not process.  Instead, make your more complicated tools modular and use importRange() to recycle common functionality.  

Personally, I use importRange() on my personal priceDB.  Also, importRange() is great for bringing in any other data you might care about.  Also, it allows you to protect the sensitive sheets (APIs, work you don't want to share) and import the useful data.  Protection isn't foolproof, it's a security-through-obscurity solution.  Technically, only authors with access to the source material can import into their controlled sheets... but this doesn't give feedback to the source owner as to who is remotely accessing the data.

The biggest lesson I can share is modularity.  Have one sheet for prices, one sheet for t1 building, and so on. Hosting ALL THE THINGS on one sheet will only make a crawling behemoth.  Also, have some patience with importRange().  If the range is dependent on something slower, it may take a minute or two to get the right values and propagate them through the sheet.

Being smart about sharing

Google gives 3 levels of access control, additionally with read/write access for each.  Though the obvious level is to switch the entire sheet on or off, there are some middle ranges that might be useful.

• Hidden sheets
• As long as sheets are protected, they cannot be viewed when hidden
• Collaborators still have access to hidden sheets
• Make a second public sheet
• Hide 100% of the secret sauce in another sheet
• Make a public shell that only shows final data

Personally, I wish "public" could force a sign on anyway, but only invited collaborators will show as non-anonymous.  

A note about Drive-Mobile

Because I am a non-stop nerd, I just want to share that Drive-Mobile is a great place to VIEW these complex sheets... but a terrible place to EDIT them.  Edit with EXTREME caution.  Functions cannot be written in mobile, and some dependent references may not populate as intended.

Resources

• Google Doc function help
• SQL for dummies
• XML for dummies
• Example Spreadsheet

A Wise Man

One of my terrible habits is a constant use of quirky sayings.  Today's entry is dedicated to the saying:

"A smart man learns from his own mistakes.  A wise man learns from the mistakes of others"

Today's blog is dedicated to the developer of Aura, the leader of Aideron Robotics, Marcel Devereux.

About Marcel

Marcel is an extraordinarily gifted contributor to the EVE development community.  Aura is the defacto Android app for all things EVE.  His personal corp site is one that all organizations should strive for. A suite of powerful tools that enable an enormous amount of feedback to his corp members and leadership.

After working with Marcel, I found that he was extremely charismatic and bull headed.  This is not to deride his behavior, but strong men are imposing and strong wills often clash.  I partnered with him at the start of 2012 to push my industry operation from middling to larger scale, and on that front we succeeded greatly.  We managed to generate the program I had always dreamed of, reaching sales figures upwards of 50B/mo.  

Also, in this time, Marcel taught me an enormous amount to bring my own game into the big leagues.  With his extensive knowledge of Google's wide assortment of tools, I was able to upgrade my capabilities and jump into brand new possibilities.

Also, I took away a series of lessons:

1. Don't Develop Alone

This first point is the most difficult in any creative project.  The project is your baby, no one can nurture it like you.  This may be the way to start, but it becomes a massive burden.  The more people that rely on your product, the more they demand of you.  If you're not careful, all of your time is sunk into a side project, and there's no time left to explode spaceships.

This was a major point of friction when working with Marcel.  I was not skilled enough to help take some of the load, and my demands were complicated and hard to implement.  This was one of the major reasons our project closed down; too much demand on one person.

2. Keep It Simple, Keep it Clean

I think it's extraordinarily important to go peruse Aideron Robotics website.  It is the foundation that the entire corp is built around.  The major reason it's so successful?  It's exactly what you need, and not overbearing.  The forums are light-weight (and mobile friendly), the application tools are easy to read.

Design has been a critical component to Aura and Aideron Robotics website.  It is a component that I have trouble replicating.  Many of my own tools get close, but end up failing to wall-of-text.  Time will need to be spent in the foundation focused on the front-face of Prosper.  Also, being an electrical engineer, my code tends to be utilitarian, not efficient... so focus will need to be paid to avoiding code pitfalls.

3. Be Honest, Be Open

One of the temptations that arose from being tied to Aura was to add restrictions to protect Aideron.  Farming APIs, barring war targets from the app, unscrupulous data farming for profit.  Marcel made a point to directly state that ANY use of Aura for covert personal gain would mean the complete death of the app and its place as a primary resource for players.  He is completely open about the behavior and operation of the app, while still retaining control over the development.

4. Be accessible

The reason Aideron Robotics was my favorite corp to be in was connectivity.  The forums were active, we chatted both in-game and out constantly, it was very easy to chat business or pleasure with anyone in the corp.  Also, with the extensive Google integration, there was a connectivity that fostered further connectivity thanks to the various tools that all interconnect between G+, Google docs, and IM.

5. It's a hobby, not a job

The first rule of any EVE venture should be for the pursuit of fun.  As soon as the GAME stops being fun, there is no reason to continue.  It's easy to get caught up in commitments to others, to think "they are depending on me", but there is no reason to be in this kind of project if it's not fun.  

Everything You Never Wanted To Know: Invention

Since it will be nearly a month until I have any decent results to show off, I might as well fill the blog with useful articles.  I hope to make this a weekly (or twice per week) segment on topics the general EVE public may not know about.  The sort of "mysterious black box" that scares most of the PVP elite off because of :numbers:.  These won't be in any particular order, so as to not take 3 weeks to get to the interesting parts.

Introduction

I could start with T2 BPOs and their weird niche, but it's been 4 years since invention replaced the BPO lottery.  If you've been around EVE that long, you've heard all there is to know about them.  Instead, we will focus on the mechanics around invention and the sort of industry that builds up around it.

At its most basic, invention is a chance-based mechanic that turns T1 BPCs into T2 BPCs.  These T2 BPCs are negative efficiency, so they take more materials and more time than BPOs, but make up for this shortfall with volume.  On the surface, the system looks like: throwing away money on datacores THEN throwing away money on inefficient building.  On the contrary, BECAUSE of that inefficiency, there are enormous profits to be had.

I cannot stress enough how much invention is a VOLUME game.  The temptation for small-time industrialists and T1 is to mine what you need and build it yourself... making it all free (wrong, by the way).  Invention has the dual problem of not being feasible to DIY materials (moon materials, enough datacores, etc), and produces very large quantities of product, that no one person is going to churn through in any short while.  Seriously, what are you going to do with 100 Ballistic Control Unit II's?

:Math:

Inventing

There are some excellent guides on the exact :math: on sites like Grismar and Chruker.  Go play with their tools to figure out the exact numbers.  I will review the top-level :math: and boil down the concepts.

One of the basic tenants of probability is: do something enough times, the probability falls out to a percentage.  Flip 1M fair coins, you'll be pretty damn close to 50/50.  Don't focus on the streaks, failures, successes; only focus on the long-term picture.  The secret to normalizing datacore costs is to invent enough to be able to use the P[success] numbers without tracking real successes.

This means settling on a build quantity BEFORE you start inventing.  With all-4 skills (except ships), this is essentially 50% success rate (48.5% if you want to be a stickler).  Factor in the datacores as a build expense by using:

• (cost per attempt) * (1/P[success]) = 1 Blueprint
• 1 T2 BPC (usually) = 10 runs
• Invention cost = [(datacores per attempt) * (1/P[success])]/(BPC runs)

Also, some answeres to basic FAQ's for invention mechanics:

• Copying: always max-runs (except ships).  T2 BPC output is modified by (runs/max runs)*(T2 BPC max runs)
• (30 runs/ 300 max) * (10 runs T2) = 1 run T2 BPC
• ME/PE research?  
• NO: T2 BPC output is only governed by decryptor or lack thereof.
• 0/0 BPO's are highly encouraged for invention BPCs
• Data Interfaces, Datacores, Decryptors, Meta Items
• Data interfaces: not consumed.  Essentially a "key" to allow invention
• Datacore: consumed every invention attempt
• Decryptors: consumed (1 per attempt), OPTIONAL
• Changes ME/PE and resulting runs
• Meta Items, OPTIONAL
• T1 has zero effect
• meta 1-4 increases P[success]
• 1 consumed per attempt

Manufacturing

The real bottleneck in T2 invention is manufacturing.  Due to the -4 PE penalty, and the requirement to consume the entire BPC to make up the datacore cost, build times can range from 8hrs/10-run to 3d/10-run or even more.  Therefore, a focus must be paid on how much throughput one builder can actually make.  Consider the following:

• 1 BPO can yield 20 copies at a time
• 20 copies * ~50% success rate = 10 T2 BPCs
• Build time of ~1d = 5-7x per week that "kit" can be run (with adv mass production 4)

The obnoxious thing that crops up is that no T2 BPCs match a normal human schedule.  2, 4, 8, 16, 24 hours fit well into a normal schedule.  Many products fit in 18, 22, 28, 36 hour schedules (even with POS bonuses).  This can make throughput tricky to calculate, since most people won't log in at 4a, or from work, to make sure their production chains are running 100% efficiently.  Take careful consideration of build time to understand what is actually possible to fit into a schedule.

Also, do not forget that T2 requires intermediate products.  Components like microprocessors are MUCH cheaper to build yourself, but take manufacturing time away from T2.  This is why T2 is such a great team-effort since work can be combined and more T2 can be produced as intermediates are handled in more efficient batches.

Kits

The easiest way to account for all the costs is to treat the process like a more-complicated T1 build.  Instead of only requiring minerals, your T2 kit will need to look like:

• BPCs (POS makes these essentially free)
• Datacores
• Components (or the moon materials to build them)
• R.A.M.
• T1 counterpart
• Minerals

This way, at the end you have purchased the above kit for X and sold the product for Y.  Profit = Y-X.  

Advanced Topics

Ships

Ships are a special case.  The P[success] is much lower, and the invention time is much longer.  This makes the previous assumption of "high volume simplifies probability" less valid.  Also, the problem of manufacture being the bottleneck is switched with invention, since the time required to generate BPCs is much longer than the product build time.  Also, with volumes reduced to 1 ship per blueprint, the existing BPO stock has a higher impact on profitability (though still a small one).  Lastly, ships are sexy, everyone wants to build ships, many people are not accounting their math right.  Very fine attention must be paid to profitability.  There is a lot of ISK to make on T2 ships, but it requires a lot more effort.

Tricks to keep in mind:

• Only make single-run BPCs.  Ships default to 1-run BPCs on success, max-run concept does not apply
• Get a POS: invent time is halved, copy time bonus helps too
• Component build is very large: Almost half the build time for ships is components
• Expensive kit costs (normalized by 20-copies per BPO):
• Frigs: 200M/BPO
• Cruisers: 1B/BPO
• BS/BC: 2.5B/BPO
• SOME ships benefit from decryptors, but MOST are barely worth the extra trouble

Decryptors

Decryptors modify the efficiency, P[success], and runs per T2 BPC.  Accounting for them is the same as datacores ((1 decryptor + datacores)* (1/P[success_modified]))/(runs_modified).  But since the resultant BPC is changed in ME/PE, it's not as simple to just add that cost to the existing calculation for the default -4/-4.  The math for handling the calculations is a little obnoxious, but EVE HQ's Prism tool can handle negative ME/PE correctly, so that's a good base point to start with.

Some tricks:

• The 3rd tier decryptors are most often the most useful
• Increases efficiencies to -1/-1
• Increases P[success] to ~60%
• Does not modify runs
• Basically ONLY for ship invention (reduces datacore costs)
• Will increase kit cost, but will also increase profit/unit

Conclusions (TL;DR)

The main point to take away from this guide is T2 invention is a large volume game.  Because the invention mechanic forces large batches to account for datacores, you will be producing items in the hundreds.  This is one of the reasons people shy away from invention; they cannot DIY all their equipment because of the various restrictions.

As such, I have always run invention programs as "cash generators".  Even if we went and bought the items we sold back, getting the cash to get the small volumes required for ship fitting was so much easier than accounting for surplus and stockpiling.  Also, to get effective stockpiles you would need to run a very broad program building nearly everything, which takes a ton of man-power and cash.  I will cover more topics on accounting in future segments

Previous Tools

As I work to generate the very first draft kind of tools, I'm filling this blog with various higher-level topics.  Once I can start showing off the innards, expect the topics to become more technical.

Today, I'll walk through the iterations leading up to this point.  Mostly the gdoc spreadsheets, since I don't want to host the original excel sheets.  Each of the headings below is a link to the project.

Initial Industry sheet

This is the very-latest revision of this tool.  The entire thing is extremely kludgey.  Originally the thought process centered around a few different problems/ideas:

1. "Group" products: many blueprints of a type share datacore types.  No need to train ALL the sci skills, just focus on grouped types
2. Can't make a shopping list in a spreadsheet.  There are so many extra types of materials, there is no quick way to boil down inputs
3. Dependent Products: Need moon materials to build components, need T1 to build T2

The end result is this first draft tool.  Constantly needing to paste one more thing is why it's completely unreadable under the hood.  Furthermore, the main interface was extremely confusing and took forever to explain to people.

Even worse was for nearly 2 years, this tool was not automated.  So, despite providing a mostly-useful shopping list, not all kits were used every week.  This lead to manually adding the values I actually needed (since I didn't want to delete the "mixes" I had made up).  Also, all price data had to be added by hand.  This gave no insight to actual profitability, only cost.  Only after I joined Aideron Robotics did I add automation through eve-central.  Price automation made the tool tolerable, but we quickly outgrew its effectiveness.

Build All the Things Sheet

This is the culmination of a team effort between TheAhmosis and myself to get a way to look over the ENTIRE T2 market in a few quick clicks.  Beyond just price automation, we devised new metrics to fine tune the product selection process.  

• Throughput: What one inventor can build in 6days.  This is rounded in such a way to estimate human-capabilities
• 16hrs to build: no one will wake up early or log in from work to flip.  Round up to 24 hours
• 26hrs to build: same problem as 16 hours, better to round up to 48hrs
• %Throughput: throughput/volume.  Margin means nothing if you can't sell what you build.
• %profit: Isk efficiency.
• Revenue: Throughput * Profit.  What is pocketed for the work
• Slot Cost: up front costs to build
• ISK/hr and adjusted ISK/hr: ISK/hr is just regular build time, adjusted accounts for throughput rounding

Also, locking down the under-the-hood calculations allows me to share this sheet with anyone and protect the work I've done.  This way I can save others from building similar tools, and allow a central place for number checking.  I still use this sheet to pick my products.

The downside is there is a LOT of data working in the background, and it's not optimized for efficiency.  This results in the price estimates falling over on bad XML calls, working slowly from sheet-to-sheet, and sometimes timing out.  Thankfully, the complexity seems to be within Google's bounds, so despite being slow, it's 90% effective.

EVE_Market-crunch Perl Project

This was an exercise in XML tied to some IRL work I was having trouble with.  This has a lot of power, but being Perl, is pretty hard to iterate.  This was the initial framework I tried to build for the goals of Prosper.  A quick run down of functionality:

• Priceparse.pl: processes market data to build an XML list of base material prices
• Marketcrunch.pl: uses the manufacture.xml list to build price data (like priceparse)
• Kitbuilder.pl: uses manufacture.xml and producers.xml to make a general kit list
• Manufacture.xml: all the T2 material requirements for everything (except rigs)
• Component.xml: All the materials for components (cap and normal) + RAM
• t1.xml: all the mineral requirements for t1 building (assumes researched)
• kits.xml: output of kits.  Contains per-char material list as well as a total shopping cart

This suffers the same fate as many of my first attempt code.  It's very kludgey and half-formed.  I ended up having to abandon development due to wanting to help Marcel on his updates.  Both projects fell apart, and I'm stuck with a mediocre tool set here in Perl.  I still use the kit builder to manage my week-to-week building.  Unfortunately, maintaining the build requirements in XML is incredibly time consuming and not exactly stable or sustainable.

FW LP Calculator 2.0

This was another large undertaking that suited itself decently to a spreadsheet.  There are a few interesting features going on here:

• Pseudo-DB of rewards: the All Rewards sheet is exactly that.  I can then use QUERY() on those values to do some interesting features that would not be possible otherwise
• Shopping list: Currently broken.  This allows people to pick their rewards and quantities to get info on both expected income and tag requirements

Unfortunately, this is pushing right against the complexity limits allowed by google.  As such, it was only possible to add Minmatar rewards to this sheet.  The lesson taken away from this project is making complicated spreadsheets modular.  Using the importRange() function, each background tool can be isolated and compartmentalized.  Also, that means I can have a central ALL THE PRICES database and import small parts of what I actually need.

I did start a newer version with all the rewards and a lot more efficiency, but with the faction warfare changes to LP coming in December, it is no longer a priority.  Also, the hope is to add LP functionality to the Prosper project once industry tools are finished.

API Crunching App-scripts

After talking with Cameron Zero at length about RVB's fitted ship program, he shared their sheet with me.  Though he was automating price data, asset stockpiles were still being entered by hand.  I had already had a half desire to have EVE API data in gdoc, so I jumped on trying to work something up for him

• CharList(keyID, Vcode): Returns character name, charID, corp name, corpID for a given API key
• stationAssets(keyID,vCode,charID,stationID): Returns all assets for one character at one station (Default Jita 4-4)

This is only the start of what I would like to provide for the EVE community in Google Spreadsheets.  But with CREST on the horizon (and a lack of simple ways to handle id->name translation inside app script), this project is on hold.

Day 0: An introduction

Welcome to the blog for Prosper, a suite of web tools for EVE online.  Or, at least, that is the goal.

About the Project

EVE Online boasts one of the deepest and broadest market and crafting systems of any MMO currently available on the market.  As such, there are many different levels people can participate in the creation, trading, moving, and destruction, of all the goods inside the game.  

There is a very active community of private and public tools, but sometimes you just have to do it yourself.  After wrestling with spreadsheets of increasing complexity for years, and trying to make due with half-formed solutions that were only okay, it's time to build something for exactly what I need.

Though the first revisions will be purely selfish (as I figure out what I am actually doing), the overall hope of the project is to publish the tools for others to save them the trouble of trudging the same path.  Though, with anything in EVE, everything has its price.

The hope is I can build a foundation in the form of an internal database and a lot of the EVE API handling and get assistance down the line to do the "pretty" parts.  For now, this serves as a personal learning project and may open up further as goals change.

About the Author

I am an electrical engineer, living in Boise ID.  The very first point I'd like to make is I am barely competent when it comes to code.  The purpose of this blog is to both log my thought process and allow a path to work back what I did right and wrong.  

In game, I am Lockefox.  Having been in EVE online since late 2004, I've done a wide range of activities, but settled into industry as an obsession   I've worked through all sorts of levels of activity, starting with the basics of any HS carebear, moving through high-volume production, and currently settling into industry as a means to fund PVP.  But knowing my cyclical nature for EVE projects, heavy industry will knock again, and I want the tools to be able to execute the full scope of my vision the next time I jump back in.

Goals for the Project

1. Generate and maintain a database of detailed price data.

Though tools like eve-central and evemarketeer provide great information for trading, they are severely lacking on the production front.  There is no way to query historical price data, no tracking "cost" vs "value".  Furthermore, other tools might track buy/sell data, but nothing accurately tracks build costs.  Also, without any build-oriented tool, there are no reliable breakdowns to drill into real costs to find the real culprits of price spikes and drops.  A dedicated database allows me to both get EXACTLY what I want, and clean up some of the useless stuff.

2. Allow in-depth tracking of products as they are built

While working with the team at Aideron Robotics, we had a powerful corp tracking tool that tracked member contributions.  Taking the ideas applied there, I hope to expand tracking to include a whole host of capabilities:

• Individual revenue tracking: what does each inventor cost/produce
• Hours tracking: Who is working on what, and allow for wage calculations
• POS utilization
• Allow tracking in account groups: allow alts across corps to track in one "project"
• Detailed buy/sell tracking: Not only for precise accounting, but trader tracking for individual productivity tracking
• Promote a decentralized architecture: Allow the project to transcend the boundries of an individual corp. 

3. CREST Automation

This will be gated on CCP's willingness to open up the appropriate CREST access to allow automation.  The pinnacle goal is a totally automated machine that picks products to build, buys inputs, arranges assets in kits, manages contracts for shipping/delivery.  The machines should reduce player input to "install and deliver jobs" as far as industry goes.  This will reduce the need to pay people for untrackable work, and reduce a lot of the tiresome bullshit that kills large-scale production

4. Total Market Dominance!

The end purpose of these tools is to allow for extremely high-volume production of equipment for all of EVE.  Though the first goal is to use Jita to turn work into cash, the longer term goal is to have independent teams supplying all of EVE.  This project should help take some of the bullshit and confusion out of industry and allow anyone (or their alts) to contribute to a central production behemoth.  Also, additional predictive tools to track the rise and fall of various products should be part of this goal.

5. A Front-End that is expandable to allow private accounts

Though running a massive carebear corp is its own brand of "fun", the tools should be accessible to others who still demand to do it themselves.  This should allow an automated billing system that requires users to contribute (ISK, most likely) for the processing time.  Also, an end goal of a mobile app (at least mobile-friendly website) should be considered, but will be a long ways off.

Why "Prosper"?

When it comes to titles, I am terribly uncreative.  I wanted something EVE enough to point to something RPish, but all the low-hanging fruit was already taken.  Most of the every day EVE lingo is taken by apps (Aura, Neocom, iClone).  As ambitious as this project is, I might as well pin my hopes to a Jove corp.  Also, the name highlights the end goal.  

I'm not focus-grouping this shit... just making it up