EVE Technology Lab

Since the announcement of the (Crius compatible) version 2.0 beta a lot was done to improve the library and squash bugs. So now it is time to "officially" release version 2.0 (Hyperion compatible). TADA!

Feel free to use & break it. Feedback is always appreciated.

CCP announced reworked invention and reverse engineering activities in an upcoming expansion, but from the looks of it these are moderate changes, which should not be difficult to implement in iveeCore.

Version 2.2 relased.

Apart from Rhea support some notable refactoring was done. See RELEASENOTES for details.
Switching from EMDR to authed CREST for market data will be done in an upcoming release.

Note: Calculating Confessor build slot cost is currently not possible as public CREST is not returning the required adjustedPrice of an input material atm.
EDIT: CREST started returning adjustedPrice for Self-Assembling Nanolattice on the 17th, so this works now.

Version 2.4 released.

In a nutshell:
- Adapted to Scylla
- Removed Teams
- Replaced Redis support based on Predis with php-redis
- Refactoring of the cache design in preparation of the merging with iveeCrest.

Version 2.6 released!

The biggest new feature is a fully fledged CREST client by virtue of merging the iveeCrest library. It has been fully integrated, completely replacing all EMDR related market data functionality. With this change there's no more dependency on non-standard PHP modules or libraries, which also makes it 100% HHVM compatible.
iveeCrest brings lots of other goodies, one of which is the support for parallel asynchronous fetching of data from CREST, allowing for high speed bulk collection of data.

Head over to the github page for updated readme and full release notes.

A future update will bring a feature I've been wanting for some time: By enlisting the help of a math student we are going to be able to give you a compression calculator with a simplex based optimization algorithm. This means you'll be able to specify the desired amounts of minerals and the calculator will return the amount of (compressed) ores required to meet those targets while minimizing cost. All written in PHP, so no external external linear algebra solver libraries required.

Hi,

iveeCore is an engine/library that you can use in your own web apps or scripts, and it handles all the interaction with the SDE DB, CREST and does the calculations for you. It is not a ready to use application and thus doesn't come with an interface (not counting the CLI tool to run CREST updates and the webscript to pull refresh tokens).
Implementing MVC would not make sense, as iveeCore doesn't present anything and the controller part is something that would be completely dependent on the use-case of the developer using it. You could at most say iveeCore provides a (class) model for the SDE types, but it's strictly read-only as the data from the SDE is immutable.
You can, however, use iveeCore in an MVC framework. In fact, my own private web app is based on Yii and I have also written other web apps with Phalcon using iveeCore as an external library.

iveeCore does support recursive component building (the ProcessData objects are chained together forming trees of processes), but that currently doesn't include the reaction activity. I'm now looking into making the build recursion also allow reactions.
Regardless, you can do the reactions manually by getting the total MaterialMap for your process tree, iterating over the material types and checking the ones that are instance of ReactionProduct and replacing them with their ReactionProcessData equivalent.

As for minerals in compressed ore form: That's something in development. For this to be cost efficient, you actually need to do non-trivial linear algebra solving (reach target amount of minerals with compressed ores while minimizing cost). I enlisted the help of a math student for that, but it takes time (I want to avoid dependencies on external libraries so we need to implement it ourselves in vanilla PHP). The current prototype returns a valid result, but likely not the optimal one.