Huge discrepancies in industry tax application

Council Of Stellar Management Assembly Hall
1

Hello. This topic was first submitted as a bug report, but then a GM told me to make it a CSM post.

Hello there stefnia Freir, this is [REDACTED].

Thank you for contacting the EVE Online Player Experience Team.

I understand your concerns and this affects the industry players and the market pricing impacting the rest of the players too. Any feedback from our players is taken very seriously and we appreciate your contribution. I would encourage you to also consider posting your thoughts on the EVE Online forums.

I recommend that you consider highlighting your concerns to the CSM as well. They ensure that the voices of the EVE community are heard and you can either post on the CSM section of the forum or contact them directly.

The issue is :
Several blueprint have an Estimated Item Value (EIV) far away from the actual cost of the materials required to produce the item. Typically, some items have an adjusted value (the value that is used to compute the EIV) lower than 10% of the actual item market value.

This was not an issue as long as the taxes were low compared to the material price of the item, but with the recent changes, which made taxes like 8% of the mats costs, it means that the changes to industry taxes have none of the effect that could be hoped for regarding those items.
As such, this is unfair to the people who build other BP. Either make ALL BP subject to tax, or make none of them subject to taxes.

The data for those difference can be found here(google spreadsheet)

The first sheet, BP, lists the blueprints by decreasing EIV error. The EIV error is the ratio of the EIV over computed EIV using SO/average values, typically error = min( abs( log(EIAdjusted/EISO) ), abs( log(EIAdjusted/EI) ) ) . Out of 3620 BP

  • 211 have an EIV below 5% of the SO/average value (BOTH : using the lower). That’s the 5.83 centile
  • 334 have an EIV below 10%. That’s the 9.23 centile
  • the median multiplier is 1.85 (EIV is 54% of SO or average, whichever is the lower)

2nd sheet, mats, explained the issue : some mats have an adjusted value too low compared to the SO/average value.
Typically, the adjusted value (used for EIV) of Thruster Console is only 0.16% of the actual SO/average value. This means that the people who use that item in BP are taxed 720 times less than they are supposed to.

3rd sheet shows all the types that are used to build a BP, so more than the mats.
You can check that the Standup Satyr I has an adjusted value of 0 by searching its id in https://esi.evetech.net/latest/markets/prices/?datasource=tranquility (search type_id":47147 )
It shows that also other mats, added recently or not, are subject to that.

Since I don’t know how the adjusted are computed, I can’t tell what exactly is wrong. I can imagine several cases :

  1. Players abuse mechanism to reduce the taxes. Typically, that would mean selling a lot of items at a price of 0 in order to reduce their historical price. Not sure if possible. If that’s the case though, don’t use average exchange value. Use max instead, as it is more costly to manipulate. Better yet, use the median of the daily max - or even 6h-max if available - over the last year
  2. it’s a bug. Well, fix it ?
  3. it’s on purpose. Then it needs to be explained. “It’s not a bug, it’s a feature” is not an acceptable answer when you are not considering people like idiots. What is that feature supposed to achieve ? How comes is it not explicitly stated somewhere ? I guess it’s a remnant from when CCP wanted to have a “free market” where the prices are actually guided. Then it should go.
2 Likes
2

@Angry_Mustache

1 Like
3

I don’t use the EVE forums often, so here’s the delayed response.

Yes it’s an Issue, CCP is aware, but the fix has no determined timeline. The Developers only have limited throughput and a recalculation of EIV is a heavy dev time expenditure for indeterminate gameplay advantage. The thing about EIV distortions is that it is ultimately priced into the the end goods, so the distortion can at least be accounted for.

2 Likes
4

Sure it’s easy to account for when the tax is zero …

Why did CCP bother make a change on tax when those taxes are not applied correctly ?
You don’t try to improve the speed of your car when your road has potholes. Even when “removal of potholes is an indeterminate gameplay advantage”.

Also it’s not a small error.
As I wrote, 10% of the BP have less than 10% of the average price as adjusted.50% have less than 54%
It’s like the state decided to tax beef industry but not chicken industry …
I could understand if it was to promote new items, but that’s not even the case.

5

Why did CCP bother make a change on tax when those taxes are not applied correctly ?

because the goal of the tax change is to increase the Industry fee isk sink in order to counterbalance recent isk faucet additions. While distorted, the Industry fee is a functional isk sink.

I am very much in agreement that CCP needs to fix the badly out of date EIV’s, but when that gets done is dependent on CCP development priorities.

6

CCP basically doubled the tax %, maybe even more . They added raw ppc and multiplied the cost index by two on average.

Fixing the formula would have done the same thing. With the added benefit to not present it as an arbitrary tax, adding balance to the game, making the formula actually have its intended effect. The tax are supposed to make people produce in various places. Instead they build items with no tax in Jita. Proof : Jita is now 20% cost index, which implies 44% of the game’s production is made in that system

image
image342Ă—1135 72.8 KB

Why do you think people keep crafting in Jita ?

Yes, that is the issue : you don’t paint a wall while there are still holes in it. CCP should hire managers that know what dependencies (between changes) are.
This is a critical bug. The functionality does not work how it is supposed to work. Anything related to that function that is not fixing bug should have a lower priority than fixing it.
(Note : I consider that using EIV as base for tax instead of installation fee was a bug fix. It was a functional bug, because it made cost-reduction rigs useless )

7

And yes, I know that the 44% seems an exageration.

I added a sheet to look at cost indexes, and the sum of the top 10 systems already reaches 300% .

8

Can anyone enlight me what the EIV is even based at? Completed Sell/BuyOrder Average universe-wide? Or input materials average order value? Over what timeframe? 30days? 90days? 365days?

9

EIV of a BP is the sum of the adjusted value of the ingredients required to manufacture it.

If your BP requires 200 tritanium, and the adjusted of tritanium is 4, then the EIV of the BP is 800.

The issue being, that the "adjusted"algorithm used by CCP is critically failed. See “used items” sheet that I gave.

Then to have the base cost of a job, you take the EIV of the BP(when inventing, use the target BP EIV instead of source) , the activity multiplier( 100% for manufacturing, 2% for everything else), the runs multiplier (number of run for manuf/invent, total runs avail for copy, 1.67^target-1.67^now for ME/TE). Multiply the three.
Say if I copy the previous BP into 5Ă—10 BP (5 10-runs BP) then the base activity cost is 800(=EIV) Ă—2/100(=CP mult) Ă—50(=runs) = 3 200 isk

This base job cost is then taken into account to get the installation fee, using 1. index cost, 2. tax %, 3. surcharge, 4. alpha cost. (the four are additive)
Say if I run that copy job in a location with 4% index cost, 0.25% tax, 1.5% surcharge, 0.25% surcharge as I am an alpha, it means

  • index is 4% so 128
  • tax is 0.25% so 8 isk
  • surcharge is 1.5% so 48
  • alpha surcharge is 0.25% so 8
    => total job cost is the sum.

Each of those are rounded up to the isk, before being summed.

Now how “adjusted” is built is “secret formula” but CCP know that their “secret formula” is an “open failure” since people abuse it to use BP with no EIV in high-index systems.

My guess is there are hardcoded numbers in the adjusted that mess with it.
The adjusted is required otherwise people could abuse the “average” formula to move the average of each item to 0, which would generalize the issue at hand to ALL BP.

10

Yeah thats what I mean, do you have a formula for these “adjusted values” or are they simply artificially fixed numbers for each item, independent from actual market value?

11

I realized I answered the wrong question, and edited the last post .

12

Thank you. I was under the impression that they would somehow use a rolling 90d or even 365d average of all universe-wide completed sell/buy orders… (which should be pretty hard to manipulate, just to save some job installation fees).

13

No, it’s actually very easy :
Just go in a place without taxes or market, place a huge volume BO for a mat at 0.01 isk value, and every day you just sell yourself a part of that value. If the daily sale volume is the same as the sale volume in the game, it means the average price of that item is divided by 2. if it’s 9 times, then it’s divided by 10.

That’s why I wrote,

The rolling 360 days with weight is the “average” value, which is why I use it. I also consider the market SO price to have a manipulation-proof reading.

1 Like
14

You mean that one? So, the EIV would be based on the daily max-value orders that actually completed, median’ed over the last year? Yeah looks pretty manipulation-proof.

15

Nothing is manipulation proof. Unless it’s invariant. Which is why I believe there are constant values in the “adjusted” : CCP’s way to reduce manipulation. Yes it does not seem to work - or it’s working too god and makes the adjusted constant ^^

But yes, median (= 50th centile) or max(100%th centile) are much resilient to extreme alterations. Still not perfect. But a combination of the two would, I believe, improve the current state.

16

I think we want a function that

  • input is the whole market exchanges done over the last X years (date to the second, value, number)
  • output is the adjusted
  • ouptut is linear with the prices vector : if ALL the prices are doubled , the the adjusted is also doubled
  • output is constant with the volume vector : if all volume are doubled, adjusted remains the same.
  • the miminal cost to alter the output is maximized. If talking in term of relative difference, moving from an adjusted=0 to anything non 0 would be infinitely costly. Of course, what we actually want is that the cost of modification outweighs the benefit. Still to maximize the cost, we need to use the max of the sales somewhere.
17

EIV is a fixed value for an item that does not change. It was last revised in 2015 or something.

2 Likes
18

EIV is not a fixed value. I believe you mean “adjusted” ?

Well that answers the question of

So the answer is : yes.

Which also confirms

Also it explains why so many items have an adjusted of 0 : all the items added since (triglavian stuff…).

Next question is … how comes Enhanced Electro-Neural Signaller has an adjusted 55 times its SO value and 91 times its average ?
That makes building caps a lot more expensive without a reason. Did CCP recycle an id ?
edit : no, it was created in late 2021.

19

So here is my proposal :

  1. a job (DB job ? cron ?) triggers the update of the adjusted at random interval (months are the result of a 2 6-dices . So between 2 and 12 months, with avg 7.5 Ă— 30days = 225 days). Once the job is launched, it schedules itself for the next launch.
  2. When started, the job creates an entry in its execution table (adjust_prices_executions). This entry contains the date of execution, and the values used for the execution : delay to next execution, weight_factor (random D6).
  3. When launched, for each item : the job takes , over the last 350 days, the median of MAX unit sell value of the 6-hour time frames (only considers time frames with a sell), aggregating transactions from all regions. This is the med_value for that item.
    It then creates a new entry in a dedicated table (adjust_prices_lines) containing
    1. the id of the execution entry created when started (in adjust_prices_executions)
    2. the type_id
    3. the med_value computed previously,
    4. old_adjusted as the existing adjusted (null if absent),
    5. new_adjusted as the average of med_value and old_value, weighted towards med_value by weight_factor. So if weight_factor is 3, then new_adjusted is (med_value + old_adjustedĂ—3)/(3+1).
      If old_adjusted is null then it is med_value (no weighting ^^ ).
  4. The job performs sanity checks on those entries. Typically limit the variation of non-null, non-zero old_adjusted , or other things. If at least a sanity check fails, the checks(s) add a message in the line for which the check failed. For example, if the check fails because the adjusted has decreased by more than 75% (from 1000 to 100), then the job writes for that item line “C001 : adjusted from 1000 to 100 isk too low. selected 250”) and the new_adjusted is set to 250.
  5. The job then updates the adjusted price of each item from the new_adjusted value (update prices set adjusted = (select new_adjusted from adjust_prices_lines where id =adjust_prices_executions_id and type_id=prices.type_id) ) .
  6. the execution line is updated with the number of prices updates, the number of items for which at least a check failed, the total number of failed checks (those are respectively count and sum of the lines’ values), and the next job execution is scheduled.

Can you transmit that specification to the devs @Angry_Mustache ?

20

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.