These forums have been archived and are now read-only.

The new forums are live and can be found at https://forums.eveonline.com/

EVE Information Portal

 
  • Topic is locked indefinitely.
 

Dev blog: The Price of Change

First post First post
Author
Previous Topic Next Topic
Steve Ronuken
Fuzzwork Enterprises
Vote Steve Ronuken for CSM
#781 - 2014-07-03 11:17:49 UTC
Yes, the 25%/30% ME reduction was a bug (which is now stomped)

The reduction from multiple arrays isn't a material reduction. It's a build cost reduction. The ISK cost for installing jobs.


There is a 2% material reduction from using a POS array. You'll see this more when you build, say, 100 items, as the reduction is applied after materials are multiplied up by the number of runs. However, you can't reduce any materials below 1 per run. That's intentional.

Woo! CSM XI!

Fuzzwork Enterprises

Twitter: @fuzzysteve on Twitter
MailDeadDrop
Archon Industries
#782 - 2014-07-03 13:51:16 UTC
Steve Ronuken wrote:
Yes, the 25%/30% ME reduction was a bug (which is now stomped)

The reduction from multiple arrays isn't a material reduction. It's a build cost reduction. The ISK cost for installing jobs.

May I direct your attention to the laughably ineffective "build cost reduction" which one gets from multiple arrays. These numbers make T2 BPO ROIs look good...

MDD
Sigras
Conglomo
#783 - 2014-07-03 21:21:08 UTC
the ROI on POS modules does seem a bit poor...

its probably a bit out of scope now, but a while ago i posted a suggestion that allows corps to grow the number of arrays organically as they can now; it also fixes the online/offline problem...

Give all POS arrays a 10% reduction to job cost then make the job 1% more expensive per job in that array.

the obvious FOO strategy is one array per job of that type you want to run, but this runs into CPU issues and requires more shuffling around of materials, so you have tradeoffs.

the other idea i had was to give each type of array a "job cost reducer" module with a long-ish online time to prevent online/offline shenanigans

the added advantage to this approach is that you can make it cost appropriate so the ROI isnt insane and youre not messing with assembly array's online timers...

thoughts?
Tzar Sinak
Mythic Heights
#784 - 2014-07-04 19:11:19 UTC
Please forgive me if I missed this but does standings with an NPC corp impact manufacturing in an NPC station in anyway?

Hydrostatic Podcast First class listening of all things EVE

Check out the Eve-Prosper show for your market updates!
Elisabeth Jane
Doomheim
#785 - 2014-07-05 01:08:21 UTC
Has anyone compared their BPO between TQ and SISI and what the ME change does to the material required?

I did

TQ: Orca ME 8
SISI: Orca ME 9

The new (ME 9) will cost ~ 70,729,000 more ISK to build

I also have an example of the Rorqual

From: Dev blog: Coming in Crius

EVE Post: Orca
https://forums.eveonline.com/default.aspx?g=posts&m=4772683#post4772683

EVE Post Rorqual
https://forums.eveonline.com/default.aspx?g=posts&m=4773267#post4773267
Jess Technite
Almost Absolute
#786 - 2014-07-14 15:51:00 UTC
As a developer of applications I find that the system cost index it's not useful for all of us that scratch with 0's and 1's. On the other side:

"For manufacturing, we took a snapshot a while back and the highest system had a fraction of 0.0253 (i.e., 2.5%), or 0.15 after you square-root it"

I found that those numbers, either that 0.0253 or 2,5% or 0.15 (personally i prefer that 0.0253), are more useful for us. Would be possible two things?
- to change that blue bar for numbers if you want it
- allow the possibility to export that data

That would make easier our job.
CCP Greyscale
C C P
C C P Alliance
#787 - 2014-07-14 16:05:08 UTC
CCP Greyscale wrote:
Valterra Craven wrote:
Noting this here...

CCP Greyscale wrote:

I'm making a note to recheck the blog feedback threads tomorrow afternoon, so please post any questions/concerns you have about things that aren't the CSV I posted earlier in those threads, make it clear in the first sentence that you're reposting there because I've asked you to, and I'll prioritize answering those questions tomorrow if they aren't terrible. Deal? :)



And thus brings me to my post:

I'm wondering why the fee structure to install jobs is based off the market price of an item instead of the build cost of an item. In other words, wouldn't it be simpler to base the build fee based off the base build cost of the item?

In other words, figure out the base build cost of the item based on current market prices for the inputs that are required.

Aka amount of trit times 5.5isk or whatever it is at the time, etc. and once you do all the math to get a base build cost in terms of isk, use that to determine how much the install job would be. While I understand you guys want the build costs to be high for the push pull mechanic, I'm still really concerned about the grave affects these new prices are going to have on the already rampant inflation we face today.

I know you've stated that you aren't really worried about infinite feedback loops in terms of item price affecting build price, but I don't know that you guys have really done a great job of explaining why you aren't worried about it.

I would think my idea would be less prone to market manipulation just based off the sheer volume of the goods involved in mineral/ comp trade. I would also think it would be less prone to an items price being artificially high due to speculation from future/possible changes due to patches. (AKA Ishtar receiving that buff in the t2 rebalance and then their price skyrocketing). I know that prices don't stay high for what some people would say is long term (aka past 6 month) period, but I would think that these price spikes would last sufficiently long to affect the build fee calculations in rather negative way. But on the other hand if you base it on the build cost of the comps, while these are still subject to price spikes, they tend to last far shorter than the item you are creating does. (Look at how short the trit spike lasted after that major cap battle)


Probably the biggest problem with trying to base build costs off component prices is that some items are built with components that move in very low volumes, making them more susceptible to manipulation. They're not a huge deal, given that such components are low-volume because the thing they're building is also low-volume and thus manipulating it is unlikely to be particularly profitable, but the risk is still there.

We're not super-committed to basing off product price, it's just a little more transparent and solves a few issues like the above. We're not expecting this to result in a "death spiral" because a) assuming costs are passed on to consumers as-is, the increases quickly tail off into irrelevance, and b) it's can't go into a death-spiral because hugely increased prices would kill demand and bring things back under control. In order for prices to continue to rise, people would need to continue to pay ever-higher prices, which they won't do.

If it becomes problematic we're open to changing it, but we don't expect any trouble in this area.


Update on this (which I should've posted last week, but forgot about): after a lot of further consideration and discussion, we've decided that the arguments here about certainty are stronger than I was giving them credit for, and that the downsides to input-driven pricing are sufficiently small that it is worth the (fairly straightforward) work of switching over to that model. We will therefore be pricing jobs based on the combined values of the inputs, rather than the value of the outputs. Thanks for all the feedback on this issue :)
Jess Technite
Almost Absolute
#788 - 2014-07-14 16:40:09 UTC
And by the way, the possibility to export (also) the teams data.
Ydnari
Estrale Frontiers
#789 - 2014-07-14 18:16:47 UTC
CCP Greyscale wrote:
[quote=CCP Greyscale]Update on this (which I should've posted last week, but forgot about): after a lot of further consideration and discussion, we've decided that the arguments here about certainty are stronger than I was giving them credit for, and that the downsides to input-driven pricing are sufficiently small that it is worth the (fairly straightforward) work of switching over to that model. We will therefore be pricing jobs based on the combined values of the inputs, rather than the value of the outputs. Thanks for all the feedback on this issue :)


Doesn't that just shift the problem down one step? Jump freighter T2 components are a prime example here; the install cost of building the components would then be based on composites, but instead the jump freighter hull install costs are based on the problematic component prices.

--
CCP Greyscale
C C P
C C P Alliance
#790 - 2014-07-14 18:33:10 UTC
Ydnari wrote:
CCP Greyscale wrote:
[quote=CCP Greyscale]Update on this (which I should've posted last week, but forgot about): after a lot of further consideration and discussion, we've decided that the arguments here about certainty are stronger than I was giving them credit for, and that the downsides to input-driven pricing are sufficiently small that it is worth the (fairly straightforward) work of switching over to that model. We will therefore be pricing jobs based on the combined values of the inputs, rather than the value of the outputs. Thanks for all the feedback on this issue :)


Doesn't that just shift the problem down one step? Jump freighter T2 components are a prime example here; the install cost of building the components would then be based on composites, but instead the jump freighter hull install costs are based on the problematic component prices.


I don't believe so. The concern surrounds feedback loops, which I don't think are present here.
Jinn Aideron
#791 - 2014-07-14 19:16:13 UTC  |  Edited by: Jinn Aideron
CCP Greyscale wrote:
... We will therefore be pricing jobs based on the combined values of the inputs, rather than the value of the outputs.
Glad you guys came to realize this. Was a major dampener on Crius anticipation having to wait for all prices to reach their long-term mathematical price feed-back equilibrium. Which, given the long averages in the loop, might have taken a very long time.

Cheers. :)

Stealth deletes are bad.
Valterra Craven
#792 - 2014-07-14 22:48:28 UTC  |  Edited by: Valterra Craven
CCP Greyscale wrote:
CCP Greyscale wrote:
Valterra Craven wrote:
Noting this here...

CCP Greyscale wrote:

I'm making a note to recheck the blog feedback threads tomorrow afternoon, so please post any questions/concerns you have about things that aren't the CSV I posted earlier in those threads, make it clear in the first sentence that you're reposting there because I've asked you to, and I'll prioritize answering those questions tomorrow if they aren't terrible. Deal? :)



And thus brings me to my post:

I'm wondering why the fee structure to install jobs is based off the market price of an item instead of the build cost of an item. In other words, wouldn't it be simpler to base the build fee based off the base build cost of the item?

In other words, figure out the base build cost of the item based on current market prices for the inputs that are required.

Aka amount of trit times 5.5isk or whatever it is at the time, etc. and once you do all the math to get a base build cost in terms of isk, use that to determine how much the install job would be. While I understand you guys want the build costs to be high for the push pull mechanic, I'm still really concerned about the grave affects these new prices are going to have on the already rampant inflation we face today.

I know you've stated that you aren't really worried about infinite feedback loops in terms of item price affecting build price, but I don't know that you guys have really done a great job of explaining why you aren't worried about it.

I would think my idea would be less prone to market manipulation just based off the sheer volume of the goods involved in mineral/ comp trade. I would also think it would be less prone to an items price being artificially high due to speculation from future/possible changes due to patches. (AKA Ishtar receiving that buff in the t2 rebalance and then their price skyrocketing). I know that prices don't stay high for what some people would say is long term (aka past 6 month) period, but I would think that these price spikes would last sufficiently long to affect the build fee calculations in rather negative way. But on the other hand if you base it on the build cost of the comps, while these are still subject to price spikes, they tend to last far shorter than the item you are creating does. (Look at how short the trit spike lasted after that major cap battle)


Probably the biggest problem with trying to base build costs off component prices is that some items are built with components that move in very low volumes, making them more susceptible to manipulation. They're not a huge deal, given that such components are low-volume because the thing they're building is also low-volume and thus manipulating it is unlikely to be particularly profitable, but the risk is still there.

We're not super-committed to basing off product price, it's just a little more transparent and solves a few issues like the above. We're not expecting this to result in a "death spiral" because a) assuming costs are passed on to consumers as-is, the increases quickly tail off into irrelevance, and b) it's can't go into a death-spiral because hugely increased prices would kill demand and bring things back under control. In order for prices to continue to rise, people would need to continue to pay ever-higher prices, which they won't do.

If it becomes problematic we're open to changing it, but we don't expect any trouble in this area.


Update on this (which I should've posted last week, but forgot about): after a lot of further consideration and discussion, we've decided that the arguments here about certainty are stronger than I was giving them credit for, and that the downsides to input-driven pricing are sufficiently small that it is worth the (fairly straightforward) work of switching over to that model. We will therefore be pricing jobs based on the combined values of the inputs, rather than the value of the outputs. Thanks for all the feedback on this issue :)


Holy crap! I'm in utter shock that I've had important feedback listened to and changes been made to implementation because of it. First my ideas on changing pos lab bonus and now this?! Whatever you and CCP Yit (I shortened cuse well I wanted to) are drinking could you please pass it to Rise and Fozie :P
Gilbaron
The Scope
Gallente Federation
#793 - 2014-07-15 11:27:25 UTC
i really don't like this change, components often have weird prices, especially cap components and even more, T2 cap components.

for minerals and PI stuff it's okay, but some other stuff is rarely ever traded on the market and therefore, has weird prices.
CCP Greyscale
C C P
C C P Alliance
#794 - 2014-07-15 15:13:34 UTC
Gilbaron wrote:
i really don't like this change, components often have weird prices, especially cap components and even more, T2 cap components.

for minerals and PI stuff it's okay, but some other stuff is rarely ever traded on the market and therefore, has weird prices.


Our position on this is that a) we're not using straight market prices to prevent manipulation so their trading volume isn't that relevant, and b) it doesn't really matter what prices *are* so long as they're reasonably stable and within the right order of magnitude, because we're only doing this so that "bigger items cost more to build" and there's zero balance need for the prices to be "accurate" by any particular metric.
Gilbaron
The Scope
Gallente Federation
#795 - 2014-07-15 15:43:09 UTC  |  Edited by: Gilbaron
Yeah, but what's the price for a capital doomsday mount? Or the t2 cap components. The trade volume is pretty close to zero.

It's something you can easily play with and cause weird things.

I think that's a bigger problem than basing the price on inaccurate end product prices. (or at least, it feels like)

That's something that will fix itself over time, component prices probably won't.
Retar Aveymone
GoonWaffe
Goonswarm Federation
#796 - 2014-07-15 16:12:45 UTC
If they're doing it right, for any manufactured product there should be a sanity check that the price is within some reasonable range of the base mineral cost.

The issue is that anything that's solely based on market prices at some point (not just current ones, but like a moving average of the last 90d with some outlier removal) is vulnerable where there simply is no legitimate market data, and the only real data is margin scams or the like. As long as there's "is this within 1/3rd to 3x the underlying build cost, if not set it to underlying build cost" sanity check then it should work well enough.

If not though, there will be some cap components/JF components that just make no goddamned sense and probably one of them will be several orders of magnitude off.
Valterra Craven
#797 - 2014-07-15 18:53:26 UTC
Gilbaron wrote:
Yeah, but what's the price for a capital doomsday mount? Or the t2 cap components. The trade volume is pretty close to zero.

It's something you can easily play with and cause weird things.

I think that's a bigger problem than basing the price on inaccurate end product prices. (or at least, it feels like)

That's something that will fix itself over time, component prices probably won't.


If there's no market movement on an item, then there wouldn't be profit to manipulating the items build price since no one is buying them anyway, and this doesn't have to do with insurance, so these cases really shouldn't matter.
Sabriz Adoudel
Move along there is nothing here
#798 - 2014-07-16 07:11:49 UTC  |  Edited by: Sabriz Adoudel
Valterra Craven wrote:


If there's no market movement on an item, then there wouldn't be profit to manipulating the items build price since no one is buying them anyway, and this doesn't have to do with insurance, so these cases really shouldn't matter.



Thing is that these components ARE being built, in significant numbers, but basically only by end users.

I am already thinking of mechanisms to manipulate the prices of Photon Microprocessors and Crystalline Carbonide Armor Platings, and those have significant trade volume.

In spite of that, I think I can see a way to dramatically reduce their cost contribution to the build costs of Kronos and Ishtar hulls universe-wide (if I continue to build those hulls post-Crius and if I desire to reduce the non-material costs of construction). I won't post it here in case it is considered an exploit (it probably won't be based on previous precedents).



Edit: It does, of course, depend upon the exact formuae used to determine prices. It may not be feasible if the formula is divorced heavily from the market.

I support the New Order and CODE. alliance. www.minerbumping.com
Valterra Craven
#799 - 2014-07-16 13:39:57 UTC
Sabriz Adoudel wrote:
Valterra Craven wrote:


If there's no market movement on an item, then there wouldn't be profit to manipulating the items build price since no one is buying them anyway, and this doesn't have to do with insurance, so these cases really shouldn't matter.



Thing is that these components ARE being built, in significant numbers, but basically only by end users.

I am already thinking of mechanisms to manipulate the prices of Photon Microprocessors and Crystalline Carbonide Armor Platings, and those have significant trade volume.

In spite of that, I think I can see a way to dramatically reduce their cost contribution to the build costs of Kronos and Ishtar hulls universe-wide (if I continue to build those hulls post-Crius and if I desire to reduce the non-material costs of construction). I won't post it here in case it is considered an exploit (it probably won't be based on previous precedents).



Edit: It does, of course, depend upon the exact formuae used to determine prices. It may not be feasible if the formula is divorced heavily from the market.


Again, what would be the point? You wouldn't be earning a profit off the manipulation, so at worst you'd likely be considered a griefer since you would be making something more expensive to produce for the whole game with no compensation.
Sienna Toth
Pulsar Phisics Shipyards
#800 - 2014-07-25 19:15:34 UTC
Well here we are post CRIUS deployment and everyone right about now should be seeing that what I saw coming a month ago is coming to pass. The markets are starting to crumble. No one can build because these CRIUS costs have jacked up the cost of manufacture to levels beyond the margins so people would be crazy to buy now for products they cant sell at a profit. This is sinking mineral and Goo prices. Less need for POS arrays allows Corps to consolidate POS towers and off line un needed towers saving another 400-500M per month. That's another 400-500M out of the Cube market per tower per month which should start to sink the ice and PI markets around 33-31 Aug.

Way to go team CRIUS !!!!