EMMA 1.5.1.

0
Asset change tracking guide
How to use EMMA’s asset tracking system ....................................................................... 3
Interface overview .......................................................................................................... 3
Causes of gained assets................................................................................................... 4
Found .......................................................................................................................... 4
Bought via contract ..................................................................................................... 4
Was never missing ...................................................................................................... 4
Cancelled contract....................................................................................................... 5
Causes of lost assets........................................................................................................ 5
Destroyed or used ....................................................................................................... 5
For sale via contract .................................................................................................... 5
Tracking assets across characters and corps ................................................................... 6
Issues and Loopholes ...................................................................................................... 7
The purpose and theory of tracking eve assets ................................................................... 9
Why track assets?............................................................................................................ 9
How do you track assets?................................................................................................ 9
Setting the foundation ................................................................................................. 9
Keeping up to date .................................................................................................... 10
Asset API update process.......................................................................................... 10
How to use EMMA’s asset tracking system

Interface overview

Grabbing data from the API works exactly the same way as it always has. The only
difference being that, by default, you do not have control over which areas are updated.
The four checkboxes for transactions, assets, orders and journal have been replaced by
one for each char/corp:

Optionally you can go back to having one checkbox for each update type (settings -> api
update settings). However, this is not recommended as for maximum asset tracking
accuracy, updates must be completed as close together as possible and in a particular
order. With the single checkbox, EMMA manages this for you.

When EMMA detects changes to assets, it will display them for you in the new
‘unacknowledged asset changes’ window:

In the above example, my salvage alt has been busy as you can see by the list of gained
items. There are also a few metal scraps missing because I trashed a stack of them that I
had lying around.
Note that the ‘bill of materials’ section is currently non-functional.

Now that you have a list of the assets that have been gained or lost, you need to tell
EMMA how they were gained/lost.
You can just ignore it and click ok but EMMA will be able to provide more accurate data
if you can help it out with a little extra information.

Causes of gained assets

Found

Gained assets default to the ‘Found’ reason. This indicates that the asset has been
obtained by the player and has effectively cost nothing in isk.

This applies to salvage, loot, mining, planetary interaction P0 items, etc

You could argue that there is a ‘cost’ to loot in terms of the ammo used to destroy the
target ship, etc. In this case, we’re not interested in that.

Items marked with this cause are stored to an ‘items gained’ table in the database that will
be used in future to generate more reports, etc.

Bought via contract

Assets marked with bought via contract are in fact, items that you have bought through
the contract system. Because there is no contract API, these items cannot be accounted
for automatically by EMMA.

The assets are marked with the flag in the database.

When you create the matching item exchange contract within EMMA (see the tutorial for
how to do this), the system will find that marked asset and set it’s cost based on the data
entered for the contract.

If EMMA cannot find an asset marked with the ‘bought via contract’ flag then it will look
for regular assets that have a cost of zero.

Was never missing

This is used when EMMA has incorrectly flagged something as having been missing and
later finds it again. This can happen for several reasons, please see the loop holes section
for more details.

From EMMA’s point of view, these assets are treated the same as those marked with
‘found’ except that the cost will be automatically recalculated based on historical
transactions when creating reports, etc. i.e. the cost is not locked to zero like it is for
‘found’ assets.

Cancelled contract

Indicates that the item was up for sale in a contract but the contract has now expired or
been cancelled.

EMMA will search for matching assets that are currently set as ‘for sale via contract’. If
it finds any, it will set their status back to normal.

Causes of lost assets

Destroyed or used

By default, lost assets are set to ‘destroyed or used’. This essentially indicates that the
asset is gone and you got nothing in return.

It should be used for depleted ammo, destroyed ships and items, redeemed plexs, etc.

Items marked with this cause will be stored in a ‘lost assets’ table in the database that will
be used in future to generate new reports, etc.

For sale via contract

Assets that are put up for sale through the contract system will be registered by EMMA
as lost.
Marking them with this cause will ensure that the profit is calculated correctly when/if
the contract is completed. Additionally, the item will be handled correctly if the contract
expires or is cancelled.
Tracking assets across characters and corps

It is very common for an asset to be transferred between a player’s alts or corporations.

EMMA can still track assets that move between characters and corps but it is not
immediately obvious how this works.

First, update a character/corp that has had some items moved to or from it.

It the example below, the character at the bottom of the list has just been updated and is
showing several gained items in the unacknowledged assets changes screen:

I know that these have been transferred from another character so rather than clicking ok
on the asset changes, I select to update the character they were transferred from.

When EMMA has finished working out this other character’s asset changes, it will cross
reference them with whatever is currently in the asset changes view.

It will now match up the assets that were transferred and keep original cost data intact.
Any assets matching in this way are removed from the asset changes screen.

As you can see below, the original character’s asset update status is still set to ‘waiting’
but the gained items have disappeared from the view because they matched items that
were missing on the other character.
Issues and Loopholes

Currently there are several scenarios that can cause problems for EMMA’s asset tracking
system: (There are others than those listed but these are the major ones imo)

 Manufacturing. BPs and components/materials will be seen as missing while

produced items will appear to have come from nowhere. This is something that
will be resolved in the future but is a fairly large piece of work so not in 1.5.1.0
 BP research/copying. BPs that go in for research or copying will go missing and
will only reappear once the research/copy is complete. In future, EMMA will
provide support for these activities.
 Invention and T2 reacting are both currently un supported. Items will just
disappear and appear as they are used/created.
 Reprocessing. Currently, reprocessed items will not pass their cost on to the
resulting materials. Again, I hope to support this in the future.
 Loaded charges/ammo. The assets API has a bug that causes it to not return items
loaded as charges or ammo when more than one item has been loaded. For
example, crystals and sensor booster scripts are fine but missiles and cap boosters
will disappear when loaded. This has been raised with CCP.
 Moving two items of the same type within the same asset update time window.
E.g. consider 2 damage controls (from now on DC for short). DC A was bought
for 10mil isk, DC B was found as loot. Both are moved to different stations and
 EMMA then runs an asset update. There is no way for EMMA to tell which DC
is which, one will be given the cost of 10 mil, the other, the cost of zero so
overall it will balance out. That said, it’s worth bearing in mind that EMMA’s
item costs may not exactly match with which items you moved where in-game.
 Buying and selling two items of the same type through contracts within the same
asset update time window. E.g. You have a true sansha warp scrambler with a
cost of 50 mil. You then sell it via contract and buy a new one via contract for 70
mil. When EMMA updates it’s assets, it will just see that you still have one TS
warp scram so the cost of 50 mil will be assigned to it. Note that creating the
contracts in EMMA at this point will result in the correct profit on the sell
contract, it’s just that you’ll still have a scram that EMMA thinks cost you 50 mil
but that actually cost you 70 mil.
 PI. Assets on a planet’s surface do not appear in the XML from the assets API.
They will only appear in EMMA once they have been moved into space and will
disappear again if you send any back down.
The purpose and theory of tracking eve assets

Why track assets?

In previous versions of EMMA, profit of sell transactions was calculated by trying to

match up the items being sold with previous purchase transactions. This is virtually
impossible and causes all sorts of incorrect results, not to mention being pretty processor
intensive and therefore rather slow.

If we were able to track items individually then we would know the original cost of an
item when the player sold it and consequently, could determine the profit accurately and
quickly.

Additionally, knowing what assets the player lost or gained and when, along with how
much those assets cost gives significant new data to be used to produce reports, graphs,
etc.

Unfortunately, implementing this individual asset tracking system is actually impossible

due to the way that assets in eve work. However, with some careful processing, we can
make a system that is accurate enough to be useful in all but the most complex scenarios.

How do you track assets?

Setting the foundation

First, we have to have a starting point. The first assets API update for a character/corp is
used to populate EMMA’s asset database. This data includes the location of the item,
quantity in a stack, etc.

There are some cases where the player still owns the assets but they will not show up in
the API:

 Asset is in a market sell order.

 Asset is part of a contract (courier or sell contract).

EMMA has market order data so after the asset data has been downloaded and processed,
the market order data is used to add the assets from current market sell orders. These are
given a specific status so that they are not confused with regular assets.

There are many different activities that can affect assets in eve:
  Market transactions
 Contracts
 User or Destroyed (using ammo, getting your ship blown up, leaving drones
behind in a fight, redeeming plex, etc)
 Industry (production, invention, reactions, etc)
 Found (mining, looting, salvaging, etc)
 Transfer to another character or corp

EMMA makes use of the API for transactions so they’re ok but all the others must be
specified with the help of the user or inferred somehow.
(Note the killmail API and science and industry API can help here and will probably be
utilised in later versions of EMMA)

Keeping up to date

Whenever a market transaction occurs, assets are affected. EMMA uses market
transaction updates to update the assets database as well.
With buy transactions, an asset entry will be created with the appropriate location, item
type and quantity. Additionally, the price of the transaction can be used to set the cost of
the new asset.
For sell transactions, EMMA will remove assets at the appropriate station. If possible,
assets with a status of ‘for sale via market’ will be used. However, if there are not enough
then regular assets will be used instead. If even this is not enough then the asset quantity
at that station will be set to a negative amount.
Because we know which asset has been used in the sale, we know the original price paid
and can calculate the gross profit. This is stored against the sell transaction record.

In the future, EMMA will be modified to also update assets based upon the industry jobs
API.

Asset API update process

When the user next does an Asset update, we compare each individual asset entry with
what we are expecting and keep track of any differences. No updates are made to the
database at this point other than flagging assets as ‘processed’ if they appear in the XML
from the API. At the same time, we build a new version of the assets table in memory
that matches the data retrieved from the API.

e.g. EMMA’s database shows 3 standard missile launcher IIs at Jita IV moon 4 CNAP.
When we get the asset XML back, it has only 1 of this item at that location. Hence we
store a change in quantity of -2 for this item at this location.

After this is complete, we have the following data:

 1. Database – Assets 2. Memory – Assets 3. Memory – List of
table holding pre-asset table matching data changes to assets to
update data. from API. get from 1 to 2.

Next, all market sell orders are processed. Where the asset data from the database already
contains the expected asset with a status of ‘for sale via market’ and the quantity matches
the market order, no changes are made except to flag the asset entry as ‘processed’.
If the quantity does not match, the in-memory assets table is updated with the change and
the change in quantity is also stored in list 3. The same applies when the asset entry does
not exist at all.

e.g. a there is a sell order for 5 units of tritantium at Jita IV moon 4 CNAP. We check the
database and there is no tritanium with a status of ‘for sale via market’ at this station. A
new record is added to table 2 with status ‘for sale via market’ and the details from the
sell order.
A new record is added to list 3 showing change in trit at IV-4 of +5.

Next we add / take away assets for any transactions with dates after the assets update
effective date. This only really affects updates from XML files rather than direct from the
API so I’ll ignore it here.

To get the final changes to the asset data, we load in all asset entries from the database
that have not had their ‘processed’ flag set. These are assets which we expect to be there
but do not show up in the data from the API. For example, the user has moved a stack of
items from one location to another. The original location has none of the item left so it
will fall into this category.
All these assets are added to list 3 with the expected quantity multiplied by -1. i.e. Items
have gone missing from where we expected them to be.

Finally, we compare all of the changes that have been logged in list 3. Where we can
match items lost with items gained elsewhere, we can be fairly sure they have been
moved by the user and update the cost data accordingly.

Complete simple example:

5 units of trit are bought at Jita IV-4 CNAP for 10 isk per unit and are later moved to
Rens VI-8 BTT.
First, a transaction update causes EMMA to add 5 units of trit at CNAP station with a
cost of 10 isk per unit.
When the asset update runs, it shows 5 units of trit at BTT so a new asset entry is created
for that. However, the cost will be set to zero as we don’t yet know where they have
come from. An entry will be created in table 3 for +5 trit at BTT.
The 5 units of trit that were at CNAP will not appear in the XML so will not have the
‘processed’ flag set. This will cause an entry in table 3 of -5 trit at CNAP.
Finally, when the comparison is run, the +5 trit will get matched up with the -5 trit and
the cost figure against the stack that disappeared from CNAP will be applied to the new
stack at BTT.