EVE Technology Lab

I present iveeCore, a PHP engine for calculations of EVE Online industrial activities and CREST library.

Purpose and target audience

The goal of this project is to provide its users with a simple but powerful API to get information about industrial activities in EVE Online such as bill of materials, activity cost and profit or skill requirements. By hiding the complexities of EvE's Static Data Export, iveeCore helps developers to quickly prototype scripts or develop complex (web) applications. iveeCore now includes a full-fledged CREST client which further increases its utility.

iveeCore will likely be most useful for developers with at least basic PHP knowledge wanting to create their own industry related tools.

These are a few example questions that can be answered with a few lines of code using iveeCore:

• "What is the profit of buying this item in Jita and selling in Dodixie?"
• "What do these items reprocess to? And whats the volume of that and it's sell value in Jita?"
• "How much does this EFT fit cost? How much is this scanned cargo worth?"
• "What is the job cost for building this item in this system? And when built in a POS in low sec?"
• "What is the total bill of materials to build these Jump Freighters and the minimum skills?"
• "Is it more profitable to build the components myself or buy off the market?"
• "Whats the total profit for copying this BPC, inventing with it, building from the resulting T2 BPC and selling the result?"
• "How do different Decryptors affect ISK/hour?"
• "How do Blueprint ME levels impact capital ship manufacturing profits?"
• "How much is a month of Unrefined Ferrofluid Reaction worth?"

FEATURES

• An API that strives to be "good", with high power-to-weight ratio
• Strong object oriented design and class model for inventory types
• Classes for representing manufacturing, copying, T2 & T3 invention, research and reaction activities, with recursive component building
• Market data gathering via CREST with realistic price estimation and profit calculation & DB persistence
• CREST data fetcher handling system industry indices, market prices and facilities
• Parsers for EFT-style and EvE XML ship fittings descriptions as well as cargo and ship scanning results
• Caching support for Memcached or Redis (via PhpRedis)
• Extensible via configurable subclassing
• A well documented and mostly PSR compliant codebase

The CREST portion of the engine (formerly the iveeCrest library) can be used in conjunction with iveeCore or independently. Some of its features include:

• Authenticated CREST based
• Methods for most endpoints reachable from CREST root are available, plus a few deeper endpoints. Easily expanded to support more (pull requests welcome!)
• Gathering of multipage responses
• Supports parallel GET requests with high performance asynchronous processing
• Multilayer cache design
• The index-less collections returned by CREST are properly re-indexed by IDs
• Includes a self-contained web-script to retrieve a refresh token
• CLI tool for automated CREST updates

Released as open source under the LGPL.

CLASS MODEL
Have a look at iveeCore's class diagram.

USAGE
Here are a few basic examples of how to use iveeCore:

//initialize iveeCore. Adapt path as required.
require_once('/path/to/iveeCore/iveeCoreInit.php');

use iveeCore\Type, iveeCore\IndustryModifier;

//show the object for 'Damage Control I'
print_r(Type::getById(2046));

//it's also possible to instantiate type objects by name
$type = Type::getByName('Damage Control I');

//Now lets looks at industry activities.
//First we need to get an IndustryModifier object, which aggregates all the things
//like system indices, available assembly lines, character skills & implants, as an
//industry context. Lots of configuration and customization options there.
$industryContext = IndustryModifier::getBySystemIdForAllNpcStations(30000180); //Osmon

//manufacture 5 units of 'Damage Control I' with ME 10 and TE 20
$manuData = $type->getBlueprint()->manufacture($industryContext, 5, 10, 20);

//show the ManufactureProcessData object
print_r($manuData);

//Lets create another IndustryModifier object for Jita, so we can calculate costs and 
//profits there
$marketContext = IndustryModifier::getBySystemIdForAllNpcStations(30000142);
//set default market station to Jita 4-4 CNAP
$marketContext->setPreferredMarketStation(60003760);

//print materials, cost and profits for this process
$manuData->printData($marketContext);

//get the data for making Damage Control I blueprint copy, inventing from it with a
//decryptor and building from the resulting T2 BPC, recursively building the necessary
//components
$processData = Type::getByName('Damage Control II Blueprint')->copyInventManufacture($industryContext, 34203, 1);

//get the raw profit for running an Unrefined Hyperflurite Reaction for 30 days,
//taking into account the refining and material feedback steps, and refinery
//efficiency and tax dependent on character skill and standing, then selling in Jita
$reaction = Type::getByName('Unrefined Hyperflurite Reaction');
$reactionProcessData = $reaction->react($industryContext, 24 * 30, true, true);
echo PHP_EOL . 'Reaction Profit: ' . $reactionProcessData->getProfit($marketContext) . PHP_EOL;

DOWNLOAD
The repository and full readme can be found here:
https://github.com/aineko-m/iveeCore

Packagist:
https://packagist.org/packages/aineko-m/ivee-core

Feedback welcome!

I've not had a chance to dig all the way through the code, so I'm not sure if you're taking this isn't account, but the way you're calculating the waste factor suggests to me that you've missed it.

Materials in Extra materials are affected by production efficiency waste, if they also appear in the base materials. (they're never affected by the ME waste)

If I've missed you handling that correctly, then good

Improved Cloaking Device II Blueprint doesn't have anything that would be affected by extra material waste.

Take a look at a Dominix when you have less than Production Efficiency 5 (my site handles it properly, if you don't have a character with less than 5. The Eve client doesn't display it correctly, until it gets to actually producing it, and even then it's a bit messed up. Which is a pain.)

I can see reasons for leaving it out, mostly because any serious manufacturer has Production Efficiency 5. And it's not too uncommon for tools to miss it (Evemon, for example, doesn't handle it right)

It's not /too/ painful to code around, mostly requiring you to pull the data in two chunks, and process in code. I've played at getting complete BOM sql, but it doesn't work quite right when it comes to RAM. Eventually I'll fix it properly, so it doesn't round down things with damage. It's just something I need atm.


Aside from that, good work There's always /something/ that can be picked at. bad habit of mine.

Version 1.1 released.

- Added reprocessing calculations for Type objects
- Added volume attribute to Type classes and total volume calculation to process classes
- Moved material requirements from process class to its own MaterialSet class
- Moved skill requirements from process class to its own SkillSet class
- Added custom Exceptions
- More parameter sanity checks
- Note that the file iveeCoreConfig_template.php and the stored procedure iveeGetRequirements() were changed

This sounds like a very useful PHP library. I am kind of new to the whole coding and programming process that is required to make an application work, but i am willing to learn!

I have some experience with Ubuntu and installing applications on a headless vps server (i already own an Ubuntu 64bit VPS server that i use with my own version of ruTorrent for seeding torrents to private trackers), but when it comes to making an actual application using custom made code and using the API to receive data from another source i get completely stuck and don't know how to proceed further.

With that in mind, can you tell me how this PHP library exactly works, or how i can use it in an application myself? Where should i as an complete noob begin? Do you know any good toturials that i can use and learn from?

Version 1.2 released

- Added reaction calculations
- Rewrote type materials and requirements handling. This fixed reprocessing calculations and most off-by-1 errors. The
memory use of the type array was reduced by up to 30%. The stored procedure iveeGetRequirements() is obsoleted by this
change, which makes for more maintainable code.
- Bug fixes and more convenience functions
- Renamed MaterialSet to MaterialMap and SkillSet to SkillMap as it better describes the classes purpose
- Renamed CopyData to CopyProcessData, InventionData to InventionProcessData and ManufactureData to
ManufactureProcessData for consistency
- Added some PHPUnit test cases covering different parts of iveeCore
- Note that the file iveeCoreConfig_template.php changed, thus adaptation of the configuration file is required

Don't know if you're aware, but on environments with E_STRICT on, the following errors popup

v1.3.1 - Minor update for Kronos 1.0 released.

The upcoming, comprehensive changes to industry in EvE will require refactoring of at least some of the basic components in iveeCore. As there will be many more variables to consider to determine cost and profit of activities, some of which might or might not be queryable via API, major architectural changes might become necessary. I'm currently brainstorming and also waiting for more announcements from CCP in this regard...

I have been working feverishly on getting iveeCore compatible with Crius. I have been making good progress but I can give no clear ETA. As so much changed it is a major overhaul and the codesize is basically doubling compared to previous versions.

The upcoming release will be able to handle CREST data including system indices, teams & specializations as well as station specific assembly line bonuses. So basically you'll be able to say "I want to manufacture X in Station Y or POS in System Z" and everything else is automagically accounted for.

I have indeed been using the git repo only for releases, but this might change when people interested in contributing show up
If you'd like to contribute I'd suggest you wait for the Crius compatible version 2.0 to avoid double work. I'll be happy to look at pull requests or discuss other changes.