[Feature Request] Estimated result of moon extraction

[mjuopperi]

Feature Request

/corporation/{corporation_id}/mining/extractions/ returns time information on extractions but the estimated output is not available through the api.

Since extractions do not have an id them selves, the information should probably be returned through the same endpoint. Alternatively it could be /corporation/{corporation_id}/mining/extractions/{structure_id} to limit the response size.

Use case

Corporations who want to monitor their moon operations out of game or to share the data to others.

Authentication

Required same auth as the extraction list (esi-industry.read_corporation_mining.v1)

Example return

{
  "chunk_arrival_time": "2018-05-29T22:01:00Z",
  "extraction_start_time": "2018-05-23T21:30:25Z",
  "moon_id": 18923,
  "natural_decay_time": "2018-05-30T01:01:00Z",
  "structure_id": 92387429374,
  "expected_output": [
    {
      "type_id": 123,
      "quantity": 10000
    },
    {
      "type_id": 312,
      "quantity": 1000
    },
  ]
} 

Checklist

Check all boxes that apply to this issue:

• Feature request description is provided
• Use case exists
• Feature requires a new route
• Feature adds data to existing route
• Feature requires new auth scope
• Feature can reuse existing scope
• Feature does not require auth
• Meta feature, applies to all routes

[NathenSample]

Is there any update around this? As bartender believed that this had intentionally been omitted by GD decision.

If it was, oh boi am I going on a rant in this thread.

[ghost]

It seems I misremembered a discussion from quite some time ago, GD is fine with this.

[NathenSample]

As a reference for anyone attempting to retrieve and work with this information, until such time as this route is implemented, there a couple of potential work-arounds to infer this information. I'll provide a brief rundown here, but feel feel to grab me on slack if you have any issues.

Option One - Notification Endpoint.
If you have a character in the corp which owns the refineries, then you can utilize the notifications endpoint to gleam this information.

When a pull begins, you receive a notification.
When a pull finishes, you receive a notification.
When a pull auto-fractures, you receive a notification.

Each of these contain the estimated yield, and so can be used in your tool.

Option 2 - Extraction Endpoint + known mineral breakdown
This one is fairly simple, moons mine at a set rate of 10,000 m3 per hour - these minerals are distributed based upon the mineral composition shown in a scan of the moon.

I.e a moon with 0.5 veldspar and 0.5 Xenomite will produce 5,000 m3 veldspar and 5,000m3 Xenomite an hour.

Both of these methods come with caveats - But should work in a pinch until such time as the route is added.

[ErikKalkoken]

My current alternative approach is to calculate extractions from received moon mining notifications and ignoring the extraction endpoint. This gives you way more information about the extractions:

• current status of an extraction: started, canceled, ready, fractured
• which ores are being pulled (including volume and quality)
• who exactly performed actions like started, canceled or fractured an extraction

I would much prefer to get al that information from an extraction endpoint instead of having to reply on notifications. But until this feature update is implemented I am wondering if there is any benefit in using this endpoint at all?

[flyingferret]

has there been any updates on this request? Still amazed this endpoint is not availible.