Talk:APIv2 Corp AssetList XML

From EVEDev

[edit] Idea for use: Container Monitoring

In my corp, I've set up container monitoring. By "container" I mean any item that contains other items (i.e. can be a ship, a POS, etc., or an actual container).

Basically, every day we grab the assets for our corp. As long as containers haven't been repackaged, the itemID for the containers will match across days. So what I've done is create a table which maps a container name (and some other settings) to a particular container's itemID. I've then created another table which defines which of the item TYPES in the container I'm interested in monitoring the levels for (we work with TYPES since in this instance we're interested in known the total amount of Tritanium, rather than 5 different amounts if we haven't stacked them in-game). After I've grabbed the assets in the daily download, I then go through the containers where monitoring is enabled, and for each monitored item type, I calculate the current levels.

For each monitored type, I also have settings for the "ideal" level, a "low stock" level, and a "critical" level. Essentially, I the use those 3 figures to display stuff in a front-end web tool which the rest of my corp has access to. They see a list of containers (view and manage access rights on each container of course), and if there are any low stock or critical levels in the container, that information is highlighted. When they click on a container, I show them the current levels for each monitored type in the container, along with a flag showing which ones are low stock and which ones are critical. There's also an option to view the low/critical items as a "shopping list", which basically says how much of each low/critical type is needed to return to the "ideal" level.

So how can this be used in practice?

Well, we have a number of containers in our corp hangar where we try and keep stock of certain item types. For example, in our corp we have a policy of providing free ammo to our members for mission running (to help justify a corp tax rate). What we found was that when certain ammo types were running out or running low, people weren't telling us like they should have been doing, and then the next person needing the ammo would complain and have to wait or buy their own off the market. What we do now that we have container monitoring is set up monitoring on those containers, and our producers responsible for keeping the ammo topped up can easily see when stock is running low before we actually run out, and can build more as needed. Using the "shopping list" function also tells them how much to produce. We use this not only for ammo, but other things too - use a bit of imagination and you'll come up with plenty of ideas for stuff to monitor in your corp too.

Another possibility is for keeping POS's fuelled. Since a POS is treated as a container, you can set up monitoring on your POS too. You can monitor the different fuel types, set up ideal (say 4 weeks worth), low-stock (maybe 2 weeks) and critical (1 week) levels for each of the fuel types. The guys responsible for fuelling the POS could then easily see when things are running low, and make sure they stay fuelled BEFORE getting those annoying 24 hour warning mails coming through. (you could also use the /corp/StarbaseDetail.xml.aspx API call for monitoring fuels in the tower. Note, however, that using the method described in here you can also monitor fuels in a corp hangar array, ammo levels in your batteries, etc).

Something else I ended up doing was creating what I call "Virtual Containers". Basically, Virtual Containers are not really containers in the game, but a collection of specific item types within a container. This is particularly useful if you want to monitor levels of stuff in your main corp hangars. For example, an industrial corp might want to monitor the levels of minerals they have available, or monitor the levels of their fuel stockpile for refuelling their POS'es, or a more combat-oriented corp might want to ensure they always have a stock of "disposable" ships and modules. The Virtual Containers allow for this, without having to put the items into physical containers in-game. Essentially, a virtual container is just a list of item TYPES that can be monitored (in our case, we actually pick the item GROUPs a Virtual Container "contains" rather than specific types, and then monitoring within the virtual container can be turned on or off for a specific type in the same way as is done with physical containers).

Anyway - I just thought I'd post this idea. We've found it very useful so far, and I'm sure we'll continue to find further uses for it as time goes by.

(Naturally, the directors can see all of the assets in another tool too - this discussion is just about finding a use for the data that everyone in your corp can benefit from)

To sum up... we download the current assets every day, replacing the previous day's list (since we're not bothered about low-level detail in terms of changes from day to day). We have a tool for naming containers and creating virtual containers (which are a subset of a particular container (such as an office) defined by a selection of inventory groups (invGroups.groupID)), and for enabling monitoring on those containers or virtual containers (along with specifying which members are managers of the containers, and which members can view the current levels) - this is also the tool directors can use to see all of the current corp assets. We then have a tool to allow the nominated managers of the containers to set up monitoring on the individual item TYPES within a particular container or virtual container, with functionality to allow them to see which items types are running low or are critical, and to see those items as a "shopping list" to get them back to the "ideal" level. And finally there is a tool available to the rest of the corp which is simply a read-only view on certain containers (not all are shown to everyone) showing the current levels and which item(s) are low/critical. This combination of tools basically allows us to have a decent process in place for helping the people responsible for maintaining stock to do so.

I hope this description gives a few people out there some further ideas for how this API call can be made useful in making their corp function better.

--Rye 09:53, 13 November 2008 (UTC)

[edit] locationID to StationID/itemID conversion

66000000 <= aleAssetItems.locationID <= 66999999 then staStations.stationID  = aleAssetItems.locationID - 6000001
67000000 <= aleAssetItems.locationID <= 67999999 then ConqStations.stationID = aleAssetItems.locationID - 6000000
60014861 <= aleAssetItems.locationID <= 60014928 then ConqStations.stationID = aleAssetItems.locationID
60000000 <= aleAssetItems.locationID <= 61000000 then staStations.stationID  = aleAssetItems.locationID
61000000 <= aleAssetItems.locationID             then ConqStations.stationID = aleAssetItems.locationID
                                              default mapDenormalize.itemID  = aleAssetItems.locationID

Also location PR-8CA III - Blood Raiders Logistic Support returns in corporate assets as locationId=66014946, but 66014946 - 6000001 = 60014945 = 1DH-SX III - Moon 1 - Blood Raiders Logistic Support

66014940 <= aleAssetItems.locationID <= 66014952 then staStations.stationID  = aleAssetItems.locationid - 6000000