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: Researching, the Future

First post First post First post
Author
tx eight
The Dry Stout Society
#1041 - 2014-05-16 20:37:08 UTC
Valterra Craven wrote:


Irrelevant. Invention has a floor build price. T2 BPOs can undercut that by a significant margin. This means you always have a market for your product and you always get the first sales. T2 BPOs should die.


Irrelevant. If the market turnover is significatly above 24/week, you can stuff your T2 BPO wherever you like, whatever you do with it will make a bit of difference on the market. But you will not like that bit.

Valterra Craven
#1042 - 2014-05-16 20:39:01 UTC
Apelacja wrote:
Valterra Craven wrote:
Malcanis wrote:
Harvey James wrote:
T2 BPO's need to die a painful death


Restricting copying to POS labs would strongly promote that goal, no?


They should also be restricted to building only from POS as well....



loled.. That would create new profession in eve T2 BPO hunting


Thats the point :)
mynnna
State War Academy
Caldari State
#1043 - 2014-05-16 20:40:34 UTC
CCP Greyscale wrote:
I'm updating my big-ass spreadsheet to link T1 and T2 typeIDs so I can run the math on making copy time 80% of build time in all cases and then setting invention time to "(build time / 2) - copy time"; while I'm working on it, does anyone think this is going to make their head explode?

Another thing to think about - if we mess with the invention math so we can kick max run counts up without breaking a bunch of things (including making sure we scale job time correctly against output runs), does the potentially large increase in practical invention throughput risk breaking the market? If you could put in 24 hours' worth of invention in one go, are we going to see a destructive glut of T2 BPC supply?

I'm coming in late on this but, no, I don't think the market will break. Change dramatically yes, but not break. There are a LOT of modules that are, even invented and built at ME -4, going for nearly double their cost, and it's specifically because inventing them has so much downtime due to the short duration of invention jobs in general. This would address that a bit. People's profit margins would surely drop, but the market would adjust as it always does.

Member of the Goonswarm Economic Warfare Cabal

tx eight
The Dry Stout Society
#1044 - 2014-05-16 20:54:49 UTC  |  Edited by: tx eight
mynnna wrote:

I'm coming in late on this but, no, I don't think the market will break. Change dramatically yes, but not break. There are a LOT of modules that are, even invented and built at ME -4, going for nearly double their cost.


edit: ... here I was wrong, but the second part still stands ...


Also I entirely don't get all that assurance in that market "won't break" or "won't do this thing" or "will do this thing".
It is most certainly impossible to even get a vague notion of what the market will be,
given any one (of the daily changing) set of rules, much less to "predict" where certain parts of it will go.

Not to mention "predictions" of market as a whole.

They are fundamentally impossible.
Matthew
BloodStar Technologies
#1045 - 2014-05-16 21:00:23 UTC
CCP Greyscale wrote:
I'm updating my big-ass spreadsheet to link T1 and T2 typeIDs so I can run the math on making copy time 80% of build time in all cases and then setting invention time to "(build time / 2) - copy time"; while I'm working on it, does anyone think this is going to make their head explode?


SQL against SDE wrote:
WITH CTE_InitialCalc AS
(
SELECT invTypes.typeName,
invBlueprintTypes.productionTime,
invBlueprintTypes.researchCopyTime,
invBlueprintTypes.maxProductionLimit,
CAST(invBlueprintTypes.researchCopyTime AS FLOAT) / (invBlueprintTypes.maxProductionLimit*0.5) AS CurrentCopyTimePerRun,
invBlueprintTypes.productionTime * CAST(0.8 AS FLOAT) AS NewCopyTimePerRun
FROM dbo.invBlueprintTypes
INNER JOIN dbo.invTypes
ON dbo.invBlueprintTypes.blueprintTypeID = dbo.invTypes.typeID
)

SELECT typeName,
productionTime,
researchCopyTime,
maxProductionLimit,
CurrentCopyTimePerRun,
NewCopyTimePerRun,
NewCopyTimePerRun / CurrentCopyTimePerRun AS CopyTimeChangeRatio
FROM CTE_InitialCalc
ORDER BY CopyTimeChangeRatio DESC;


Assuming no bonuses etc.

The stuff with really high change ratios are mostly stuff for which BPOs aren't available anyway (Ascendancy inplants, T3 subsystems, various faction/storyline modules, R.A.M Hybrid Technology etc.

The biggest increase ratios for things where BPOs actually exist seem to be for the Mobile Scan Inhibitor, Mobile Micro Jump Unit and the Freight Containers, which would see copy times per run being 40x what they currently are (e.g. Enormous freight container currently has researchCopyTime=6000, maxProductionLimit=1000, implying copy time per run of 12 seconds). productionTime is 600, so revised copy time would be 480 seconds per run. Max-run copy goes from 3.3hours to 5.5 days.

Worst hit of things that can be invented are drones, Warfare Links, and all varieties of Tech1 ammo below XL, which see copy times increase by 30x (from 12.8 seconds per run to 384 seconds). Max run copy time on drones goes from 5.3 hours to 6.7 days. For the Warfare Links it goes from 6.6 hours to 8.3 days.

XL and Orbital ammo gets 20x copy time. Tech 1 modules seem to go up 6x (e.g. Mega Pulse Laser I goes from 80 seconds per run to 480 seconds, max-run copy jumps from 6.6 hours to 1.6 days.

The only things that get shorter copying time per run from this would be T1 ships (x0.6 to x0.2, with bigger reductions on the larger sized ships), T2 BPO (x0.6 to x0.12, again bigger reductions on the larger items), capitals (x0.2), starbase arrays (x0.1 to x0.06) and capital components (x0.04).

This does achieve the aim of significantly reducing the copy time of the large items with expensive BPOs, encouraging the "build from copy" economy that was one of the stated aims. However, it does the exact opposite to the smaller BPOs. Putting invention to one side for a moment, I would think this would be a significant negative to the nomadic/wormhole play-style (taking some BPC and a few starbase arrays with you and manufacturing your own supplies in-situ).


I've put invention to one side for a moment to request clarification about the invention duration calculation you are proposing. In the invention duration calculation, are you taking the build time and copy times from the T1 blueprint being used as the input, or the T2 blueprint that would be the output? If you are taking the T1 input, then the formula doesn't seem to make sense, as with your definition of CopyTimePerRun as 0.8*productionTime, it would become

researchTechTime = (0.5*productionTime) - (0.8*productionTime) = -0.3*productionTime

i.e. it would always result in a negative time. So I assume that I'm misinterpreting what you are proposing in some way?
CCP Greyscale
C C P
C C P Alliance
#1046 - 2014-05-16 21:03:04 UTC
ShesAForumAlt wrote:
CCP Greyscale wrote:
I'm updating my big-ass spreadsheet to link T1 and T2 typeIDs so I can run the math on making copy time 80% of build time in all cases and then setting invention time to "(build time / 2) - copy time"; while I'm working on it, does anyone think this is going to make their head explode?


So I must be derping. I'm seeing from this that:

Copy Time = 0.8*Build Time
Build from Copy Time = 1.8 Build Time (1 Build Time + 0.8 Build Time)

Invention Time = 0.5 * Build time - 0.8 Build Time = - 0.3 Build Time?

Unless its supposed to mean:

Copy Time = 0.8 * Build Time * (1/Max Runs)
Build From Copy Time = (1 + 0.8*(1/Max Runs)) * Build Time

Invention Time = 0.5 Build Time - (0.8 * Build Time * 1/Max Runs) = (0.5 - 0.8 * 1/Max Runs) * Build Time

Someone mind correcting my derp here?


The math is not to scale :P

(ie, I'm talking in generalities, not specific numbers.)
ISD Ezwal
ISD Community Communications Liaisons
ISD Alliance
#1047 - 2014-05-16 21:03:57 UTC  |  Edited by: ISD Ezwal
Edward Olmops wrote:
TL;DR: THIS is a good post.
Bit lengthy though. The forum always truncates my text when I try to quote it in full length. ...
The reason it is truncated is that the maximum post length for us mere mortals (yes, including ISD) is 6000 characters. Developers are not hampered by such trivial details and can cram much more characters in their posts.
Surprisingly enough such lengthy Dev posts do not need a TL:DR imo, because they are nearly always worthwhile to read in full. A good example being the post you quoted.


Yes I know, this post is totally off topic but I couldn't resist answering this one. I will report my own post now....Oops

ISD Ezwal Community Communication Liaisons (CCLs)

CCP Greyscale
C C P
C C P Alliance
#1048 - 2014-05-16 21:06:07 UTC
Matthew wrote:
CCP Greyscale wrote:
I'm updating my big-ass spreadsheet to link T1 and T2 typeIDs so I can run the math on making copy time 80% of build time in all cases and then setting invention time to "(build time / 2) - copy time"; while I'm working on it, does anyone think this is going to make their head explode?


SQL against SDE wrote:
WITH CTE_InitialCalc AS
(
SELECT invTypes.typeName,
invBlueprintTypes.productionTime,
invBlueprintTypes.researchCopyTime,
invBlueprintTypes.maxProductionLimit,
CAST(invBlueprintTypes.researchCopyTime AS FLOAT) / (invBlueprintTypes.maxProductionLimit*0.5) AS CurrentCopyTimePerRun,
invBlueprintTypes.productionTime * CAST(0.8 AS FLOAT) AS NewCopyTimePerRun
FROM dbo.invBlueprintTypes
INNER JOIN dbo.invTypes
ON dbo.invBlueprintTypes.blueprintTypeID = dbo.invTypes.typeID
)

SELECT typeName,
productionTime,
researchCopyTime,
maxProductionLimit,
CurrentCopyTimePerRun,
NewCopyTimePerRun,
NewCopyTimePerRun / CurrentCopyTimePerRun AS CopyTimeChangeRatio
FROM CTE_InitialCalc
ORDER BY CopyTimeChangeRatio DESC;


Assuming no bonuses etc.

The stuff with really high change ratios are mostly stuff for which BPOs aren't available anyway (Ascendancy inplants, T3 subsystems, various faction/storyline modules, R.A.M Hybrid Technology etc.

The biggest increase ratios for things where BPOs actually exist seem to be for the Mobile Scan Inhibitor, Mobile Micro Jump Unit and the Freight Containers, which would see copy times per run being 40x what they currently are (e.g. Enormous freight container currently has researchCopyTime=6000, maxProductionLimit=1000, implying copy time per run of 12 seconds). productionTime is 600, so revised copy time would be 480 seconds per run. Max-run copy goes from 3.3hours to 5.5 days.

Worst hit of things that can be invented are drones, Warfare Links, and all varieties of Tech1 ammo below XL, which see copy times increase by 30x (from 12.8 seconds per run to 384 seconds). Max run copy time on drones goes from 5.3 hours to 6.7 days. For the Warfare Links it goes from 6.6 hours to 8.3 days.

XL and Orbital ammo gets 20x copy time. Tech 1 modules seem to go up 6x (e.g. Mega Pulse Laser I goes from 80 seconds per run to 480 seconds, max-run copy jumps from 6.6 hours to 1.6 days.

The only things that get shorter copying time per run from this would be T1 ships (x0.6 to x0.2, with bigger reductions on the larger sized ships), T2 BPO (x0.6 to x0.12, again bigger reductions on the larger items), capitals (x0.2), starbase arrays (x0.1 to x0.06) and capital components (x0.04).

This does achieve the aim of significantly reducing the copy time of the large items with expensive BPOs, encouraging the "build from copy" economy that was one of the stated aims. However, it does the exact opposite to the smaller BPOs. Putting invention to one side for a moment, I would think this would be a significant negative to the nomadic/wormhole play-style (taking some BPC and a few starbase arrays with you and manufacturing your own supplies in-situ).


I've put invention to one side for a moment to request clarification about the invention duration calculation you are proposing. In the invention duration calculation, are you taking the build time and copy times from the T1 blueprint being used as the input, or the T2 blueprint that would be the output? If you are taking the T1 input, then the formula doesn't seem to make sense, as with your definition of CopyTimePerRun as 0.8*productionTime, it would become

researchTechTime = (0.5*productionTime) - (0.8*productionTime) = -0.3*productionTime

i.e. it would always result in a negative time. So I assume that I'm misinterpreting what you are proposing in some way?


I will look over this in more detail tomorrow or Monday, depending on when I next sit down with my spreadsheet. Wanted to say thanks for the effort in the meantime though!

Regarding the last bit, yeah, it's based on the T2 output, which is the only thing that makes sense when we're trying to align build, copy and invent time, but I did exactly what you do there at first and it took me about a minute to realise why the whole column was negative :)

[edit] I get 12000 characters to play with, and I still run into the limit sometimes :P
CCP Punkturis
C C P
C C P Alliance
#1049 - 2014-05-16 22:33:33 UTC
CCP Greyscale wrote:
Patri Andari wrote:
CCP Greyscale wrote:
[quote=Shoogie]So much has changed in the last couple pages.

stuff & stuff




This is a good post, thank you.

stuff & stuff



Read on if you dare:

Did you just really single out one post as a "good post" and then respond?

There are sooo many reasons why this is just horrible form. Let me point out a few:

1. No one has ever proclaimed the criteria a post requires to get a response, yet this "good post" rises to the top and is responded to fortwith. I would love to see an enumerated guide on how to get a response from the devs.

2. Why have so many other posts which bring up even more important circumstance gone ignored?

3. Is it required that one post in a way that rubs a dev the right way to be considered a 'good post'? If so, how do you like to be rubbed?



Yeah ok, this is a reasonable question.

Preface: I am British (as evinced by the fact that I spell my name the way the Queen intended when she invented the English language), so all my expressions of emotion are compressed around the midpoint. To translate into eg American, exchange "good" for "excellent".

1. Here's the general guide, in approximate order of importance from my personal perspective
- Be calm and reasonable. Angry posts are harder to process, both because the actually worthwhile bits tend to be broken up by the angry bits, and just because it takes additional effort to filter out the negative vibes while you're trying to extract the useful information.
- "Show your working". The single most useful thing you can do in a post is to explain, in as much detail as possible, why. Simply stating things you believe to be true is somewhat unhelpful, as it's incumbent upon us as developers to be able to explain why we are making changes, and also to filter out things that players are saying because they are true from things that players are saying that they mistakenly believe to be true from things that players are saying that they know are false but hope will sway development decisions anyway. For both of these reasons, an explanation of why you are saying what you are saying is the biggest thing you can do (in combination with the previous point) to get a developer to make changes based on what you're saying. A lot of people seem to be under the misapprehension that simply stating their opinion should be enough for developers to change their mind; this isn't viable for a number of reasons, but the most obvious one is that any given thread will generally have multiple players stating mutually contradictory opinions. We have to be able to pick between them somehow, right?
- Be specific. I love players who actually present numbers rather than just saying "that is too big", because it makes it very clear what they're actually hoping to see, and gives context for what they find reasonable.
- Consider the whole picture. It's very easy to express an opinion about things that affect you directly. It's much rarer for people to consider how the changes they're suggesting affect other players, particularly those of different playstyles or levels of experience. As developers, we have to consider everyone, and that often involves tradeoffs. Your common-or-garden post says "this is what *I* want", and we have to then synthesize all those different points and figure out how to balance competing interests. Showing at least an awareness of this, and better still actually accounting for it in your working, is a good way to make a post more useful to a developer.
- Have a good, short opening paragraph. If your post starts off badly, I will jump through it quickly looking for anything that sticks out, because I have lots of posts to read and other work to do. If you catch my attention with your opening, I will read it carefully. Note here that I'm not saying it has to make an effort to be catching or provocative, just that a clear, well-written paragraph which meets all the other points in this list suggests that it's a post that's probably worth reading slowly.
- Be novel. Posts bringing up things that haven't previously been mentioned in the thread are generally more useful than posts repeating the same thing that's been mentioned twenty times. I want to properly clarify this: I'm *not* saying not to repeat points, or even that doing so isn't useful. Seeing the same thing brought up multiple times is a good indicator that there is a broad concern about a particular thing. It's not as powerful as a single post laying out succinctly and convincingly why a particular thing is problematic, but it's still useful information!
- Be nice to read. If you can be gently witty, or format and punctuate your post so it's easy to read, that will always score bonus points.

2. Nothing in this thread has been outright ignored. With fifty pages I'm happy to hold up my hand and say that some posts I skim-read because, as above, I have other work to do too, but I have read every post for some definition of "read". I have not replied to every post raising an important point, for a variety of reasons:
- In many cases a reply doesn't really add anything to the discussion
- In some cases that you are considering important posts, I probably simply didn't find the points they were making particularly compelling. YMMV, obviously :)
- I can't reply to everything, both because it would take forever and because it would destroy the rhythm of the thread.
- What a developer does and doesn't reply to tends to, over time, influence the character of the forum. I am less likely to respond to a post which makes good points in a bad way, because while good points are good, bad presentation is bad. Conversely, people making really good posts I will go out of my way to reply to, because I would like to see more posts like that.

3. This is kind of repeating the first question, at...

♥ EVE Brogrammer ♥ Team Five 0 ♥ @CCP_Punkturis

Aliventi
Rattini Tribe
Minmatar Fleet Alliance
#1050 - 2014-05-16 22:36:02 UTC  |  Edited by: Aliventi
CCP Greyscale wrote:
Querns wrote:
CCP Greyscale wrote:
Querns wrote:

Don't forget to exclude T2 BPOs from this copy time adjustment. :)


I'm going to come around to T2 BPO copy issues eventually :) We'd like T2 BPOs to be copying ideally, but not if it's only viable for balance reasons in a gallente outpost.

Actually, thinking on this, there is a KISS solution here -- make the copy bonus from pos and outposts simply not apply to T2 BPOs.


That is a thing I am considering :)

Don't do this. Choices and consequences. If you are copying your T2 BPO in a POS for the time bonus, POS gets blown up, you should lose your T2 BPO to whomever blew it up. Same for you copying it in a conquerable outpost. Let the POS/Outpost games begin!

Edit:: Y'all took a well deserved additional 6 weeks to get this all figured out. Why not find a good way to remove T2 BPOs from the game, while still compensating the owner properly. instead of playing around trying to figure out how to balance them with all these changes? At Fanfest you said you were going to do it anyway. Why not save some time and do it now?
Gilbaron
The Scope
Gallente Federation
#1051 - 2014-05-16 22:43:21 UTC  |  Edited by: Gilbaron
Reasons why Invention is inconvenient:

1. clickfest
2. clickfest
3. clickfest
4. optimisation. in order to make a lot of money from invention you need to optimize a lot of things. copying, invention and building all run on different timers and quite a lof of thinking is required to reduce downtime on your slots (character wise).

the interface changes you have planned will drastically reduce the amount of clicking necessary to start an invention job. that is very very convenient and will probably increase the amount of people that are willing to actually get involved with invention. it will also potentially change their behaviour, especially the use of meta items (expected price drop because of the refining changes for quite a few of them combined with easy usage) that change by itself will increase supply without increasing demand and therefore decrease prices

most modules run on 30 minute invention timers. change that to 20 hours and you will make a LOT of people VERY happy. But be careful not to increase the amount of BPCs that can be produced with that kind of job by the same factor.

time x40
bpcs x6

that should put invention in a situation where you can expect that an relatively active and dedicated inventor is able to produce the same amount of T2 BPCs per day (1x ~20hrs job vs 6x 30 minutes). at the same time, all those who don't like restarting jobs every 30 minutes will be able to produce more. that is significant for the market but probably won't cause a massive crash. as a side effect, some people may move from ships to modules which is good for the ships market.

please keep in mind that ~20 hour timers are awesome (start jobs at the end of a play session so that they are ready at the beginning of the next)

tl;dr

increased invention times ? yes please
massively increased supply of T2 BPCs ? nope
Aryth
GoonWaffe
Goonswarm Federation
#1052 - 2014-05-16 23:06:54 UTC
Gilbaron wrote:
Reasons why Invention is inconvenient:

1. clickfest
2. clickfest
3. clickfest
4. optimisation. in order to make a lot of money from invention you need to optimize a lot of things. copying, invention and building all run on different timers and quite a lof of thinking is required to reduce downtime on your slots (character wise).

the interface changes you have planned will drastically reduce the amount of clicking necessary to start an invention job. that is very very convenient and will probably increase the amount of people that are willing to actually get involved with invention. it will also potentially change their behaviour, especially the use of meta items (expected price drop because of the refining changes for quite a few of them combined with easy usage) that change by itself will increase supply without increasing demand and therefore decrease prices

most modules run on 30 minute invention timers. change that to 20 hours and you will make a LOT of people VERY happy. But be careful not to increase the amount of BPCs that can be produced with that kind of job by the same factor.

time x40
bpcs x6

that should put invention in a situation where you can expect an active inventor to produce the same amount of T2 BPCs per day. at the same time, all those who don't like restarting jobs every 30 minutes will be able to produce more. that is significant for the market but probably won't cause a massive crash. some people may move from ships to modules which is good for the ships market.

please keep in mind that ~20 hour timers are awesome (start jobs at the end of a play session so that they are ready at the beginning of the next)

tl;dr

increased invention times ? yes please
massively increased supply of T2 BPCs ? nope


This is a good example of what I mean by fixing queueing. This is one way there are others obviously.

Leader of the Goonswarm Economic Warfare Cabal.

Creator of Burn Jita

Vile Rat: You're the greatest sociopath that has ever played eve.

Matthew
BloodStar Technologies
#1053 - 2014-05-17 00:23:28 UTC
CCP Greyscale wrote:

Regarding the last bit, yeah, it's based on the T2 output, which is the only thing that makes sense when we're trying to align build, copy and invent time, but I did exactly what you do there at first and it took me about a minute to realise why the whole column was negative :)


Thanks, though I still can't work out any scenario where taking the difference between half the build time and the copy time would work.

If I take both the copy time and build time from the T2 blueprint, then if we modify the copy times of the T2 blueprints using the 0.8*productionTime change, then we end up back at the problem that invention time ends up always being -0.3*productionTime.

If I use the current T2 production and copy durations, the only blueprints that would have a positive invention time would be jump freighters (for everything else, the current copy time per run is significantly greater than the build time).

If we are trying to align the build, copy and invent times within the properties of the T2 blueprint, then wouldn't it be easier to say that productionTime is the "master" variable, and define both researchCopyTime and researchTechTime in relation to productionTime. e.g. say that researchCopyTime = 0.8*productionTime to meet the "copying faster than producing" goal. Then say that researchTechTime (defined per run of T2 BPC output) is some fraction <0.8 of T2 productionTime, to take into account that invention is not 100% successful.

I did also see what happens if you take the productionTime from the T2 blueprint and the new copy time from the T1 blueprint - which would be an attempt to do an end-to-end balancing of lab time used. But you still end up with jump freighters siege/triage/capital tractor, and the ever-popular perpetual motion unit, with negative invention times, and the Deep Core Mining Laser having a time of zero. You also end up with lots of strangeness around how the max-runs conversions work. Trying to do this would also significantly constrain what you could do with the times across the T1 and T2 blueprints, so while such an end-to-end balancing sounds nice in theory, I'm not sure it's going to be practical.

Anyway, query I used to get the numbers to play with (T1 copy times and max-runs, T2 production, copy times and max-runs, invention time):


SDE Invention Query wrote:

WITH CTE_InitialCalc AS
(
SELECT invMetaTypes.typeID,
invMetaTypes.parentTypeID,
T2ProductType.typeName AS T2ProductTypeName,
T2BlueprintType.typeName AS T2BlueprintTypeName,
T1ProductType.typeName AS T1ProductTypeName,
T1BlueprintType.typeName AS T1BlueprintTypeName,
CAST(T1BlueprintDetails.researchCopyTime AS FLOAT) / (T1BlueprintDetails.maxProductionLimit*0.5) AS T1CurrentCopyTimePerRun,
T1BlueprintDetails.productionTime * CAST(0.8 AS FLOAT) AS T1NewCopyTimePerRun,
T2BlueprintDetails.productionTime AS T2productionTime,
CAST(T2BlueprintDetails.researchCopyTime AS FLOAT) / (T2BlueprintDetails.maxProductionLimit*0.5) AS T2CurrentCopyTimePerRun,
T2BlueprintDetails.productionTime * CAST(0.8 AS FLOAT) AS T2NewCopyTimePerRun,
T1BlueprintDetails.researchTechTime AS CurrentInventionTime,
T1BlueprintDetails.maxProductionLimit AS T1MaxRuns,
T2BlueprintDetails.maxProductionLimit AS T2MaxRuns
FROM dbo.invMetaTypes
INNER JOIN dbo.invTypes AS T2ProductType
ON invMetaTypes.typeID = T2ProductType.typeID
INNER JOIN dbo.invBlueprintTypes AS T2BlueprintDetails
ON invMetaTypes.typeID = T2BlueprintDetails.productTypeID
INNER JOIN dbo.invTypes AS T2BlueprintType
ON T2BlueprintDetails.blueprintTypeID = T2BlueprintType.typeID
INNER JOIN dbo.invTypes AS T1ProductType
ON invMetaTypes.parentTypeID = T1ProductType.typeID
INNER JOIN dbo.invBlueprintTypes AS T1BlueprintDetails
ON dbo.invMetaTypes.parentTypeID = T1BlueprintDetails.productTypeID
INNER JOIN dbo.invTypes AS T1BlueprintType
ON T1BlueprintDetails.blueprintTypeID = T1BlueprintType.typeID
WHERE invMetaTypes.metaGroupID=2
)

SELECT typeID,
parentTypeID,
T2ProductTypeName,
T2BlueprintTypeName,
T1ProductTypeName,
T1BlueprintTypeName,
T1MaxRuns,
T1CurrentCopyTimePerRun,
T1NewCopyTimePerRun,
T2productionTime,
T2CurrentCopyTimePerRun,
T2NewCopyTimePerRun,
T2MaxRuns,
CurrentInventionTime
FROM CTE_InitialCalc;
Sabriz Adoudel
Move along there is nothing here
#1054 - 2014-05-17 00:27:05 UTC
CCP Greyscale wrote:
I'm updating my big-ass spreadsheet to link T1 and T2 typeIDs so I can run the math on making copy time 80% of build time in all cases and then setting invention time to "(build time / 2) - copy time"; while I'm working on it, does anyone think this is going to make their head explode?

Another thing to think about - if we mess with the invention math so we can kick max run counts up without breaking a bunch of things (including making sure we scale job time correctly against output runs), does the potentially large increase in practical invention throughput risk breaking the market? If you could put in 24 hours' worth of invention in one go, are we going to see a destructive glut of T2 BPC supply?


Only addressing the invention aspect.

There are two things that limit T2 BPC supply presently. One is player available research jobs, the other is player tolerance for doing many hundreds of manual inputs.

For ship invention, the former is the limiting factor. For ammunition, the latter is limiting. For modules, it is a bit of both.

Taking a few examples:

Taranis BPC:
Input per successful invention(rounding to a 1 in 3 chance)
3 single run Atron BPC (IIRC that is about six research hours)
3 Incognito Symmetry
12 datacores (random aside, Android keyboard thought I meant Spartacus there...)
75 research hours (station slot)
3.15 uses of the science interface (one per invent attempt, one per twenty Atron BPCs created)
Then 16 production line hours to build them.

Limiting factor here is research time.


Example 2: Spike L
Input per successful invention
2 Plutonium L max run BPC (5 research hours in a public slot)
2 Incognito Symmetry
2.1 uses of the science interface
4 datacores
2.5 research hours
Then 270 production line hours to build them.

- Here, for all but the most OCD players, clicks see the limiting factor for invention and production line hours limit the overall process.


Modules are in between but in my experience production time is limiting, with player click tolerance close behind.



If you allow the production of 200 run Damage Control II BPCs by inventing on a 6000 run DC I BPC, you will absolutely crash the tech ii market in the short to medium term. Instead of requiring frequent player input for efficient production, you'd end up with something more like the old datacore research system - check your jobs once per week or month and otherwise sit back and get free stuff from them.

I support the New Order and CODE. alliance. www.minerbumping.com

Matthew
BloodStar Technologies
#1055 - 2014-05-17 00:27:06 UTC
CCP Greyscale wrote:

Another thing to think about - if we mess with the invention math so we can kick max run counts up without breaking a bunch of things (including making sure we scale job time correctly against output runs), does the potentially large increase in practical invention throughput risk breaking the market? If you could put in 24 hours' worth of invention in one go, are we going to see a destructive glut of T2 BPC supply?


I don't know enough about the T2 BPC market to comment on that, but there is one effect of making much larger invention jobs that I've not seen mentioned - the impact it has on the convergence of the success probability. If you put through a given number of attempted runs as several smaller jobs, you are likely to get some succeed and some fail, and begin to converge on your underlying probability of success. If you put it all through as one large invention job, you'd either succeed or fail as a single block. Therefore, for a given quantity of attempted output, the larger jobs would be noticeably riskier than the smaller ones, and you would have to achieve a higher throughput before your results would begin to reasonably approximate your underlying probability of success.

I did a quick-and-dirty monte carlo of the scenario with a 40% success chance and either doing 200 invention jobs that would yield a 10-run BPC, or 20 invention jobs that would yield a 100-run BPC (so both should tend towards yielding 800 runs overall). Running 5000 trials of each confirms that the mean of these 5000 trials is very close to 800 from both methods, but the standard deviation is significantly different, at around 70 for the shorter jobs, compared to around 220 for the longer jobs. So while placing the longer jobs is much less work, the outcome is also less reliable.

Only solution that comes immediately to mind would be to do the success/fail test per run, or per batch of runs, depending on how you are scaling the requirements (e.g. if you do a double-sized job, it rolls for success twice, and you either end up with nothing, a normal-sized BPC, or a double-sized BPC). That would give you lots of inconsistently-sized BPC though which might be a pain to manage production from.
Sabriz Adoudel
Move along there is nothing here
#1056 - 2014-05-17 00:40:11 UTC
Matthew wrote:
CCP Greyscale wrote:

Another thing to think about - if we mess with the invention math so we can kick max run counts up without breaking a bunch of things (including making sure we scale job time correctly against output runs), does the potentially large increase in practical invention throughput risk breaking the market? If you could put in 24 hours' worth of invention in one go, are we going to see a destructive glut of T2 BPC supply?


I don't know enough about the T2 BPC market to comment on that, but there is one effect of making much larger invention jobs that I've not seen mentioned - the impact it has on the convergence of the success probability. If you put through a given number of attempted runs as several smaller jobs, you are likely to get some succeed and some fail, and begin to converge on your underlying probability of success. If you put it all through as one large invention job, you'd either succeed or fail as a single block. Therefore, for a given quantity of attempted output, the larger jobs would be noticeably riskier than the smaller ones, and you would have to achieve a higher throughput before your results would begin to reasonably approximate your underlying probability of success.

I did a quick-and-dirty monte carlo of the scenario with a 40% success chance and either doing 200 invention jobs that would yield a 10-run BPC, or 20 invention jobs that would yield a 100-run BPC (so both should tend towards yielding 800 runs overall). Running 5000 trials of each confirms that the mean of these 5000 trials is very close to 800 from both methods, but the standard deviation is significantly different, at around 70 for the shorter jobs, compared to around 220 for the longer jobs. So while placing the longer jobs is much less work, the outcome is also less reliable.

Only solution that comes immediately to mind would be to do the success/fail test per run, or per batch of runs, depending on how you are scaling the requirements (e.g. if you do a double-sized job, it rolls for success twice, and you either end up with nothing, a normal-sized BPC, or a double-sized BPC). That would give you lots of inconsistently-sized BPC though which might be a pain to manage production from.



The economy doesn't care about the blip on the radar that is your personal lucky or unlucky steak.

If I invent Kronos hulls and have an extreme lucky streak (say 42 successes from 100 attempts), the additional 15 BPCs above the mean do not impact the market much. And that is on a low volume BPC and a result that is 3 to 4 standard deviations above the mean (I.e. a one in 2000 chance)

It's an open question whether adding more streakiness to invention will lead to more memorable and unpleasant game experiences (players remember every time their results fall well below the mean and an increased standard deviation will lead to more memorable unlucky streaks) but these will smooth out over the game as a whole.


In numbers: if the standard deviation quadrupled due to input BPCs being 16 times the max runs, from 5 percent of personal production to 20, but there are 1600 players inventing the item gamewide, the gamewide standard deviation will increase from 0.125 percent of overall production to 0.5. Less of an impact than an extended downtime causing some players to miss their scheduled logon for job turnover.


I support the New Order and CODE. alliance. www.minerbumping.com

Matthew
BloodStar Technologies
#1057 - 2014-05-17 00:50:38 UTC  |  Edited by: Matthew
One of the main complications at the moment about adjusting Max Runs on either T1 or T2 blueprints is the dependency between them that invention causes. I'm wondering if it would be possible to break that dependency, and treat runs from the T1 BPC more like any other job input.

For example, at the moment a Miner I has max-runs of 300, and the Miner II max-runs of 100. Inventing from a max-run T1 BPC would therefore give you a 10-run T2 BPC (ignoring decryptors). Messing with the max-runs of the blueprints would change the size of the job and/or the conversion ratio.

If we could move the BPC consumption more towards being a normal input requirement rather than being defined by the max-runs of the two blueprints, then we could say that each run of T2 BPC output requires 30 T1 BPC runs. You could then offer flexibility in how long an invention job you want to place. e.g. you could start with a 300-run T1 BPC, put it into an invention job and request a 1-run T2 BPC out. You would then get back your T1 BPC with it's runs reduced to 270, and the T2 BPC if the invention was a success.

There may need to be some sort of batch size imposed to sort out the problem of the low numbers of datacores, meta items etc used in invention - that would need looking at further.

This would give greater flexibility to change the max runs of both T1 and T2 blueprints without directly changing the conversion ratio within invention, as well as letting people pick longer or shorter jobs as appropriate.
Gamer4liff
Deep Core Mining Inc.
Caldari State
#1058 - 2014-05-17 00:58:15 UTC  |  Edited by: Gamer4liff
Aliventi wrote:

Edit:: Y'all took a well deserved additional 6 weeks to get this all figured out. Why not find a good way to remove T2 BPOs from the game, while still compensating the owner properly. instead of playing around trying to figure out how to balance them with all these changes? At Fanfest you said you were going to do it anyway. Why not save some time and do it now?

Frankly I don't think there is a good way to remove T2 BPOs. I would expect more additive solutions like the aforementioned boosts to invention ME bringing invention up. The ultimate additive solution would be to let inventors earn new T2 BPOs in a limited way that doesn't render invention irrelevant, finally allowing the current generation of players to earn what some consider to be the ultimate solo manufacturing content without having to pay out the nose.

That would be my ideal solution anyway. I suppose what I'm getting at is that the existence of BPOs is not inherently the problem, the problem is the existence of the BPOs without any way for players to acquire them from the environment. It is my hope that CCP has or will consider some kind of solution fixing this aspect and appropriately balancing the BPOs with invention instead of acquiescing to the rabid clamoring for their outright removal.

In reality we'll probably see a research/invention revamp in the future that both makes invention less annoying, and puts it on even more equal footing with BPO production, continual changes, adjustments to BPOs, gradually bringing the value down, I doubt we'll ever see full removal though. It's not like the mere existence of BPOs is some horrible public blight standing in between inventors and incredible profitability.

Yeesh though, the inventors clamoring to kill BPOs to get into the ~promised lands~ of BPO-dominated markets are going to be sorely disappointed if BPOs ever do get straight up removed. The reason the markets are BPO-dominated, from what I've seen, is because of a severe lack of demand.

E: Perhaps the ultimate solution is to balance T2 BPO production with Inventing so well that the literal only advantage of BPOs is not having to invent. :v The BPOs would be the reward for the long-term inventor's pain and suffering.

A comprehensive proposal for balancing T2 Production: here

Matthew
BloodStar Technologies
#1059 - 2014-05-17 01:07:38 UTC
Sabriz Adoudel wrote:

The economy doesn't care about the blip on the radar that is your personal lucky or unlucky steak.

If I invent Kronos hulls and have an extreme lucky streak (say 42 successes from 100 attempts), the additional 15 BPCs above the mean do not impact the market much. And that is on a low volume BPC and a result that is 3 to 4 standard deviations above the mean (I.e. a one in 2000 chance)

It's an open question whether adding more streakiness to invention will lead to more memorable and unpleasant game experiences (players remember every time their results fall well below the mean and an increased standard deviation will lead to more memorable unlucky streaks) but these will smooth out over the game as a whole.


Of course the economy as a whole doesn't care - that much is evident by the very consistent outcome of the mean of the 5000 trials.

However, people don't make decisions about what and when to invent based on what happens to the probabilities at a whole-economy scale, they make those decisions based on what is likely to happen at the scale that they intend to produce. While having streaks of good and bad luck is indeed memorable, I would argue that there is a threshold below which this is a manageable and entertaining challenge for the individual, but beyond which it becomes frustrating and will generally discourage participation.

Invention is currently one of the industrial activities with the highest number of unique characters participating. My worry would be that if we move that threshold too much, it will have a discouraging effect on the smaller participants and new entrants and we may lose that wide participation.

Where that line is, or should be, located is no doubt a subject that can be hotly debated, but it is something that should be debated if we are looking at changes that would move that threshold.
Zappity
New Eden Tank Testing Services
#1060 - 2014-05-17 04:56:41 UTC
Sabriz Adoudel wrote:
Only addressing the invention aspect.

There are two things that limit T2 BPC supply presently. One is player available research jobs, the other is player tolerance for doing many hundreds of manual inputs.

For ship invention, the former is the limiting factor. For ammunition, the latter is limiting. For modules, it is a bit of both.

Taking a few examples:

Taranis BPC:
Input per successful invention(rounding to a 1 in 3 chance)
3 single run Atron BPC (IIRC that is about six research hours)
3 Incognito Symmetry
12 datacores (random aside, Android keyboard thought I meant Spartacus there...)
75 research hours (station slot)
3.15 uses of the science interface (one per invent attempt, one per twenty Atron BPCs created)
Then 16 production line hours to build them.

Limiting factor here is research time.


Example 2: Spike L
Input per successful invention
2 Plutonium L max run BPC (5 research hours in a public slot)
2 Incognito Symmetry
2.1 uses of the science interface
4 datacores
2.5 research hours
Then 270 production line hours to build them.

- Here, for all but the most OCD players, clicks see the limiting factor for invention and production line hours limit the overall process.


Modules are in between but in my experience production time is limiting, with player click tolerance close behind.



If you allow the production of 200 run Damage Control II BPCs by inventing on a 6000 run DC I BPC, you will absolutely crash the tech ii market in the short to medium term. Instead of requiring frequent player input for efficient production, you'd end up with something more like the old datacore research system - check your jobs once per week or month and otherwise sit back and get free stuff from them.

Yes, a good post. I think a lot of people tend to underestimate the effect of effort and clicks on T2 price calculations. Effort needs to be removed because the current clicks really are just stupid. But the price of modules and ammo will crash when it happens. Does that matter? I'm ambivalent.

Zappity's Adventures for a taste of lowsec and nullsec.