The correct answer is : the data is cached on the ESI per request, not per API.
So when API1 request the mining ledger for player 1, it is created and cached.
when API2 request the mining ledger for player 1, let’s say 1 min later, the exact same data is returned . The cache prevents the returned data from being modified for the cache duration.
1hour later, one API request the mining ledger for player I. The cache is expired, so the ESI requests the monolith for the data, caches the data, and returns the new ledger for that exact time.
except the fleet history, that needs to be sent by the client !
The structure that is currently there for personal mining ledger, is a date, a system, an item name, and an amount.
Adding time, fleet ID, could very well add the necessary data we need to have accurate mining histories.
I would assume that a Fleet ID of 0 means no fleet. A time stamp for each cycle completion could be ignored when you compress the data, but be useful to check when a user was in a fleet and when a user was not. The cached data would then be parsed putting everything into personal ledger, and putting anything with a Fleet ID into that fleet’s mining ledger. Probably wouldn’t even need the time stamp for this, but anyway.
Lemme get a copy of my JSON mining ledger data real fast and edit it into this post.
CCP would need to be the ones who modify the game to add a fleet ID to the table. You can see from the snipplet of my mining ledger, that it has date, quantity, system, type. No fleet or time.
With at least fleet ID, it could easily be parsed to make a fleet ledger.
Personally I don’t know how the game parses the data into cache before it gets requested by the API requesting it or before it gets put into the personal ledger. If it can distinguish what cycle was in a fleet when it completed and what cycle wasn’t, then great. If not, then I don’t know how much overhead that might add to the server.
If loot histories were made server side, it wouldn’t be as bad because then they would likely add fleet history to the API so it can be requested. They would just need to find a way to prevent fleet history tampering with the use of jetcans. If CCP reads this, I would suggest ignoring loot history from player launched jetcans. Tagging jetcans dropped by a wreck or other incidents with natural can ID while player launched cans with an artificial can ID so that loot history ignores these cans.
Not just overhead. You need to rework the complete mining ledger.
The mining ledger only gives you the TOTAL amount mined, for a day, for an asteroid type. So there is not ONE notion of fleet/time for a day. It just makes no sense, and anyhow would be data redundancy with the fleet path.
But what’s more, your whole idea is bound to be worthless.
What would you use that fleet ledger for ?
So if someone does keep the ore you still pay him ?
If I’m boosting in orca and people are in fleet but outside of boost range (eg in a different system) I sill ask them to give me a part of their ore ?
Which I already told you here
But you rather be toxic than realize your idea has fatal issues.
Does the mining ledger currently count what’s picked up from cans? My boosting alt has no mining history despite people dumping copious amounts of ore in the hold (something like 12 million Veldspar just from today).
