Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Feature Request] Reprocessing Events #1231

Open
4 of 8 tasks
whaleberg opened this issue Aug 25, 2020 · 7 comments
Open
4 of 8 tasks

[Feature Request] Reprocessing Events #1231

whaleberg opened this issue Aug 25, 2020 · 7 comments

Comments

@whaleberg
Copy link

whaleberg commented Aug 25, 2020

Feature Request

An endpoint to track a characters reprocessing events. Something that lets you tell what items were reprocessed and what the result was.

I want to be able to track when my character has reprocessed items but I don't see any existing route for it. I buy a lot of modules and reprocess them for profit and currently it doesn't seem like there's a mechanism for tracking this. It's possible this exists already and I just missed it but I looked through whole swagger page I think.

Use case

Traders who buy and reprocess items and industrialists who reprocess ore. It would let you programmatically track when items have been removed due to reprocessing and where ores and reprocessed items came from.

Authentication

It would require authentication but it could probably share a scope with other industrial activity. I don't know which one is best. It seems like a type of manufacturing activity.

Example return

Ideally it would let you track what was reprocessed and what the results were, along with the cost, time, and location.

[ 
 {
    "time" : <date-time>,
    "location" : <location_id>
    "cost" : <double>
  "input" : [
     {
      "item": <item_id>,
      "quantity": <integer>,
     }
   ] ... 10 more items
   "output": [
      {
      "item"<item_id>,
      "quantity": <integer>
      }
   ]  ... 5 more outputs
  }
] .. more reprocessing events

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
@skiedude
Copy link

#664

Somewhat related. Has a reference to an SDE Table that might divulge reprocessing information that you potentially could plug into yourself to see what it was.

@Blacksmoke16
Copy link
Member

Blacksmoke16 commented Aug 25, 2020

I wouldn't plan on this happening soon (if ever). Your best bet for the moment would be to have some custom code that handles this. I.e. paste in list, fetch prices via ESI, etc.

@whaleberg
Copy link
Author

@skiedude I can see how we can use that to figure out what the results were given the inputs, but I can't figure out how to find out WHAT items were reprocessed and when. It's hard to reverse a pile of tritanium into a set of modules only knowing that there was a reprocessing fee in the log.

@whaleberg
Copy link
Author

@Blacksmoke16 What makes you say that? I'm not really in touch with the state of ESI and how hard it is to get stuff added. This seems like a weird hole in the API to me but admittedly maybe low priority.

@Blacksmoke16
Copy link
Member

@whaleberg See #1225 (comment).

@whaleberg
Copy link
Author

Ah. So changes are pretty much frozen for now? Thanks for the heads up!

@CarbonAlabel
Copy link
Member

To further add to the "not happening" verdict: ESI generally doesn't return information that isn't already exposed in-game, and can't return something that isn't even recorded.

This is not an ESI feature request, it's an entirely new game feature that's being asked for, and this isn't the best place to be making a case that having access to detailed reprocessing history would be beneficial to you as a player.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants