EVE Information Portal

One, that's a big "if". One that would probably involve null sec sovereignty rule changes, which are surely a ways off.

Two, because of #1 (above), nobody knows the answer.

MDD

it's because outposts were hacked in and presumably the code is atrocious, and it's just not technically possible without redoing the old code

Systems with a lot of industrial activity will be rather more expensive than systems with little activity. Systems with a lot of facilities will be somewhat cheaper. A system like Nonni will wind up finding a balance between the two - probably at the point where additional players basing there derive no benefit. That point will depend on the specialities of teams resident in that system compared to what that industrialist is interested in building, but there will come a point where the 'push' overwhelms the 'pull' for any given player.

And yeah, gankers and wardeccers might start camping those systems. They might even follow teams whose specialities are lucrative. That's Eve.

Insane that the price of the output is taken as a factor in the cost of producing said output. There is no reason to pay more for an activity unless someone else is willing to pay more for the same workforce supply. What the end product is should have no impact at all. The employers are demand, and the workers are supply...and that is it basically.

What it is now, is more like a regulated profit margin, communist style.

They could not use a flat fee. Any cost sufficient to spread out battle ship producers would kill ammo production. The easy way to scale is by the price of the item being produced.

I'm a bit confused how Invention will work with this system... will i have to pay 3 times to invent and produce something? one to copy one to invent one to produce? That sounds like as an inverter I'm going to get bent over and ***** sideways. Please someone correct me if I'm understanding this wrong.

As someone else already intimated, in that situation I'd just plan for 2-day duration jobs and alternate the "daily bonus".



I agree that this isn't FW levels of exploitable, but then very few things are.

The trouble with any sort of "debounce" timer is that if you set it too short, it's still easy to game with even a modicum of planning. I'm concerned that if you set it long enough to push out the exploitative scenarios, it will add a lot of ramp-up time for starbases, and restrict the legitimate uses of the flexibility a starbase offers.




I argued against this sort of solution in my original post, due to it embedding the lots-of-small-arrays model of starbases. But the more I think about it, the more I'm inclined to think that this is the most workable option.

Given the current limitations in the starbase code around associating different arrays within the same starbase, the only truly workable approach is to ensure the mechanics only rely on a job->array mapping, not a job->starbase mapping. That's the only way the current starbase code can ensure that the arrays that support a job stay online for the duration of the job. Anything else could be gamed to a greater or lesser extent.


Any future starbase re-write will presumably still need to support some sort of modular system for industry, so that people can build pure copy-houses, pure manufacturing houses, and hybrids in between, so it would still need to solve these problems. However, such a re-write would be able to build in the necessary inter-module associations from the start. The system above would be relatively easy to transition to such an arrangement, with a design something like:

• The Core Module (control tower equivalent) would host all the jobs and storage (fixing the main annoyance of the multi-array model in the current system)
• Individual modules are then added to enable particular types of jobs, of which only one would be needed (e.g. you would add a single "Copy Module" to enable copying with relevant bonuses and an expansion of the central storage space).
• A "worker housing" module of which a number could be added to increase the number of inherent workers (replacing the multiple arrays in the current system).

This would allow fitting requirements to be balanced in a more fine-grain manner between enabling a type of activity in the first place, and expanding the number of workers available. Other modules could also be added to give additional storage space, improved bonuses to ME/TE/Team use etc, to provide more flexibility in tuning the starbase to your requirements (e.g. do I want to build something that can push through large volumes of anything and everything at normal cost, or do I want to build something that can manufacture one specific thing very fast or very efficiently).

The current system of occupying specific arrays would transition to utilisation of the specific worker crews granted by the worker housing modules. While this could just be a direct replication of the behaviour with the individual arrays, the re-write could offer more flexibility within the same principles. For example, the workers could be treated as a pool accessed by the Core Module, with restrictions on being able to deactivate the housing modules if that would take the Core Module below the number of workers currently in use. This would also allow flexibility to be able to choose on install whether to use one of your private worker crews, or pay the premium for a system-wide crew, allowing more intelligent decisions about which jobs are worth using your discounted workers on (you could do that to some extent in the proposal above for the current starbase system by choosing to overload one array and keeping the other one free, but the re-write would allow this to be a more formal choice).

If you then added the ability to see which of your jobs were utilising the inherent workers, and the ability to manually "offline" specific jobs to free up the inherent worker allowance if you needed to take some housing offline. You could then either restrict it so that you could only online the job again if an inherent worker allowance became free, or if you were willing to store the state of all the pricing variables at the start of the job, you could add an option to pay the difference in order to resume it using a system-wide crew.

Such a system might also be useful in Outposts, especially if usage of the inherent workers was tied into access permissions (e.g. only the supercap/strategic build division can use the inherent workers, everyone else gets to use the public crews).

Appreciate that this sort of thing would be well down the line, but wanted to demonstrate how the fairly basic fix within the current code could be extended into a fuller system later.

Maybe he meant socialist. That's a 'thing' now in America, right?

As far as I can tell, yes, this is exactly what will happen. The backwater corners of EVE that had vertical/small/solo industrial corps are about to get even quieter than they were, because those corps are going to have to move. The new system promotes clusters and I've already started searching for places where I think a cluster might form that will be small enough for me to participate. I need affordable office rent because I'm a lousy industrialist who won't be able to compete in any cluster particularly close to Jita/Amarr.

i'm not an industrialist. i' build small amounts of stuff from time to time mostly ships and mods, but man, atl those new changes and extra calculations had sent my head spinning. like really i found this confusing: this is becoming a game into itself now, where you need to check the time of the year, the phase of the moon, the outside temperature, the lvl of the sea, and IF all that multiplied with 3 and divided by 9 give a round number, then yes, you can build in the system...

i understand, that some ppl like this, but really...

also, every single change that was posted will come with a price increase; every single one; add to this the nerfing to reprocessing and the isotopes price increase(jump drive nerf) and we are looking at an increase in prices all over the market.
not to mention that remembering CCP "united inventory" fiasco, i think we will a nasty concoction in the making here