EMMA 1.5.1.0 Asset change tracking guide

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 table holding pre-asset update data. 2. Memory Assets table matching data from API. 3. Memory List of changes to assets to 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.