Showing posts with label Industry. Show all posts
Showing posts with label Industry. Show all posts

Tuesday, April 29, 2014

Don't Panic, Manufacturers

CCP has apparently decided to focus the summer release on industry.  Certainly this is an area of the game that needs work, so that is good.  I do think it's brave in the sense that few players do industry, and so they probably won't get the income bounce they normally get for new releases.  No one is going to resubscribe to look at a pretty UI that they don't use.  I expect there to be at least a few new gee-whiz features unrelated to industry to try to draw resubscribers back.

In any case, I have seen quite a lot of complaining about it from industrialists, even to the point of threatening to unsubscribe.  I find this ludicrous, at this point anyway.  And here is why.  The basis of much of the complaining is that people want to do their industry in highsec, and they believe they are being "forced" out to null.  But so far as we know, this is not true.  What is true is that industry "slots" are going away; instead there will be surcharges at busy stations.  The surcharges are from 0-14%: "Expect costs ranging from 0% to 14% of the base item being produced for the most extreme case."  (emphasis theirs).

People seem to be looking at the high end 14%, the "most extreme case", thinking that's general, and panicking.  But this is crazy.  We know from the quote above that 0% will be a thing.  What we don't know yet is where the #jobs N where will draw the line between 0% and 1%.  And then also (though less interesting), other lines from 1 to 2%, and on up.  But in any case, I think it is pretty safe to assume that N is going to be, at least, a small integer.  (If it's not, then I must revise this opinion.  Expect me to revisit the subject when it is announced.)

The current behavior is 50 slots and then a queue; it seems reasonable to me to scale the 0 to 14% over that range, so that there are perhaps 5 jobs per 1% of surcharge.  So I am going to make a wild guess that the crowdedness cost will be 0% for zero to four jobs, 1% for five to nine, etc., capped at 14.  Where exactly these percentages are does not matter that much; what matters is only just that there are, say, four jobs per station at 0%, nine jobs per station at 1%, and then (less so) for more crowdedness.  I take it as given that more than a few percent of surcharge is not sustainable for most industry, whereas zero percent definitely is, and 1% is probably.  2% maybe.

You didn't choose me.
So the question here is: are there currently enough empty slots in highsec such that after the summer release, we can still do all the industry there, and competitively?  And I think the answer is pretty clearly "yes".  There are completely unused stations, right now, even in the Forge.  I went and looked: the nearest one to Jita -- with zero jobs -- is in Obe.  Obe is eight jumps from Jita.  OK, that's lowsec.  So, how about the nearest highsec station in the Forge, with zero jobs installed  It's in Uchosi, 10 jumps out.  There are many stations with only one to four jobs.

I feel confident that The Forge does the most industry in New Eden, due to the presence of Jita.  Remember the dev blog posting Insights into 2013 Production and Destruction.  See the picture, and notice all the tiny circles that are blue and green.  There are more of them than there are large or even medium blue and green circles.
Production.  

There are currently a lot of empty slots out there; probably more empty ones than filled.  Enough for everyone, especially after a substantial amount of the competition moves to POSes or to null.

So, don't panic manufacturers.  There will be plenty of room for profit.  What we are seeing here is not the evil Nullsec Cartel taking your profit for themselves.  We are seeing a leveling of the playing field, so that manufacturing can be done in nullsec and reasonably compete with highsec.  You are losing your massive cost advantage, but you are not being made uncompetitive.

That said, there will be some manufacturers that will be better off moving to null, and some better off staying in highsec.  This will be a function of transportation cost.  Mynnna, though not doing much in his recent blog post to quench the alarm of his critics (here's my comment), did have some useful numbers there on the transportation costs faced by nullsec: "30k isotopes per round trip".  Isotopes cost between 700 and 1000 ISK right now, depending on type.  And CCP is going to increase fuel requirement for jumping by 50%.  So, using a lower end isotope price, we predict transport costs of about 30m ISK for a round trip for a jump freighter.  That is a few percent for anything but a very low value load.  (To be fair, we must factor in other costs: the capital cost of a jump freighter is one.  The effective cost of losses to gank is another.  Opportunity cost is also worth mentioning.  These are impossible to know.)  In any case, the point is that transport costs are significantly higher to and from nullsec than in highsec.  Also, there is a balance factor preventing too much industry from moving to null: fuel costs will rise with demand.  In highsec, you can autopilot a billion ISK in substantial safety with no fuel cost at all.

So, what we can see is that to the extent nullsec does have a cost advantage in manufacturing proper, industry should be done there first for the things with high value:volume, then decreasingly for things with lower value:volume.  The very largest yet low value things, for example T1 ship hulls, will be manufactured in highsec because of the transportation cost advantage.  Small, high value stuff, for example most T2 ship parts, will probably move to null.  Medium sized stuff will be where the breakeven point is, and might be done in both regions.

Thursday, March 6, 2014

Sorting Robots

Here's an function I'd like to have in EVE.  Call it a Sorting Robot.  Its intended function is to make it easier to assemble sets of stuff for manufacturing, which currently is quite annoying and fiddly.

A sorting robot would probably be implemented as an in-game item.  It does not have to be an item, but let us assume it is.  CCP seems to implement most functions as items (i.e., to organize your hangar you have to use a physical container to get the effect of a "folder").

A sorting robot is a special kind of container.    Indeed, it acts as a container: you can put stuff in it just like a freight container.  However, its intended use is to allow you to program it to automatically collect and package stuff.  To this end, it has a fairly extensive set of parameters you can set.  (A UI would have to be created for this.)  The parameters are:
  • a multiset of items (a multiset is a set where items can appear multiple times)
  • a "where to search" variable: top hangar only, only below the top hangar, the entire hangar
  • a "use market deliveries" flag
  • an "auto repeat" flag
  • a "mail notification" flag
  • a priority, perhaps 1 to 5
  • a destination (optional)
  • a name string (optional)

The "where to search" is fairly self-explanatory.  The sorting robot searches for and takes stuff only from the places you specify here.  In addition, it will take stuff out of your corp's "Market Delivieries" hangar if that flag is set.

The multiset is what the robot is attempting to find and package.  The set should allow any kind of item, and any number of each type.  So, for example, you might set the robot to assemble the exact minerals you need to build 10 Catalysts, which for my Jita alt are as follows:  Tritanium - 514870; Pyerite - 145200; Mexallon - 63620; etc.

The set of items may be inputted via drag and drop, then right-click on a desired item and set its amount.  However, since the intended function is to make assembling sets of stuff for manufacturing, the more common use is to program the robot using a blueprint.  This works as follows: at any time you can right-click on the robot and there should be an item "Program from Blueprints".  If you select it, it displays a list of "blueprints" and multiplicities that the robot is currently using.  (A "blueprint" here is not an actual blueprint, but a transcription of a blueprint's information.)  The UI should allow the user to change the multiplicity, and/or remove a blueprint entirely.  There should also be an "add blueprint" function.  When you select it, it displays the Assets interface and tells you to find the blueprint you want to add.  You find it and select "Add this blueprint" or whatever; then that material inputs for that particular blueprint (as it currently is, for the current character) are recorded and the blueprint added to the list of blueprints that the robot has.  Note that each "blueprint" that the robot has a record of is simply a multiset itself; if the character's skill changes, or the (actual) blueprint is improved, then robot's copy may be out of date.

Sorting robot operation uses the robot's contents, and works as follows.  If the robot has enough of a particular item already inside it (remember it is a container), it does not look for that item.  Otherwise, it looks where it has been told to look (that is, in "where to search").  If there are multiple sorting robots active in a hangar, they use their "priority" variable to determine the order in which they will search.

If the robot finds an item (or stack of items) it is looking for which is packaged, it moves the item inside itself.  If the item is not packaged, the robot attempts to package it and then move it.  (If it cannot be packaged, the robot does nothing and the item should not be moved.)

Once the robot has the full multiset of stuff inside it that it is looking for, it wraps the stuff up into a package similar to a courier package.  The package is placed in the top level hangar.  If the "mail notification" flag is set, mail is generated to the character to notify him or her of the new package.  If the optional destination has been set, it should be set on the package.  (This destination should be automatically used for destination if the package is sent using a courier contract.)  If the optional name string has been set, the package should be named that.  Otherwise the name should be that of the sorting robot.  For example, you might name a sorting robot "Minerals for 10 Catalysts"; that name would be replicated on each package that the robot creates.

Finally, according to the "auto repeat" flag, the robot either keeps shuts itself down (it must be restarted manually) or not.  If not, then it will automatically start attempting to make another package.