EVE Information Portal

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.

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.

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?

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....

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...

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

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):

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.

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.

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.