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

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

Player Features and Ideas Discussion

 
  • Topic is locked indefinitely.
 

Stack Blueprint Copies RUNS(x)

Author
Previous Topic Next Topic
Boer'd
ROE'Dock
#1 - 2015-04-02 15:32:54 UTC
I realize this may sound a bit odd, but I think it would help simplify the INDUSTRY process and seems like it would be relatively easy to implement. So, here goes:

Problem: Having a large inventory of prints becomes very difficult to manage due to physical number of different prints. Plus, the manufacturing time is directly related to the max number of runs() associated with each individual print. For a print with a small limited number of runs(), the actual manufacturing time is sometimes very quick. For example, tech-II mining crystals typically finish in less than one hour which causes a LOT of extra effort simply to keep revisiting the INDUSTRY panel to submit next set.

Suggestion: Provide a special case of the STACK command that allows us to highlight a set of prints for a specific item [ same ME(), PE(), etc; however, there's no reason that runs() couldn't vary ]. Right click to see a drop down option to STACK PRINTS, this would result in accumulating the runs() for each selected print and result in one single print with a total runs() equal to the totals of the selected prints.

Advantages: Significantly reduce the number of prints we have to manage. Reduce the number of times we have to interface with the industry system. Allow us to consolidate manufacturing runs to manage the time to deliver so that one visit to manufacturing facility per day/week/xxx could be scheduled to handle multiple manufacturing slots. Dramatically reduce the impact of max items in cargo holds, station hangers, corporate hangers, cargo containers, etc. Should result in some modest performance improvements since inventory management will have fewer items to track.

I don't see any reason to assign a max runs() to prints consolidated with this special function since the submit manufacturing job function already has a check to ensure that number of runs() requested don't exceed the standard 30day cycle.

Reposted in this forum because original post was in wrong forum.
Serendipity Lost
Repo Industries
#2 - 2015-04-02 16:46:18 UTC
You sir are lazy. Complaining that managing large numbers of bpo/bpc is kind of funny.


Which pains you the most?
- the effort required moving them around?
- the 'time lost' because your production lines sit idle while you are at work/school?


-1 (you are lazy)
Michael Ignis Archangel
Deep Core Mining Inc.
Caldari State
#3 - 2015-04-02 17:44:25 UTC
Serendipity Lost wrote:
You sir are lazy. Complaining that managing large numbers of bpo/bpc is kind of funny.


Which pains you the most?
- the effort required moving them around?
- the 'time lost' because your production lines sit idle while you are at work/school?


-1 (you are lazy)


While you're not entirely off-point here, a sufficiently large group industry effort fairly often bumps against the 1,000-item-per-hangar limit. Having to dedicate canisters is a permissions nightmare (just... trust me here). So, fixing either the number of items or the permissions around cans has some legitimate use.
Ben Ishikela
#4 - 2015-04-02 18:00:52 UTC
Hey nice!
I was going to write nearly the same thing. I agree to that your suggestion improves the game.
There is also the Problem, that BPC&BPO are a Pain to trade in large numbers.
Also every BP is unique, which, i presume, requires lots of querries and serverload. so much that the item limits may be required.
So --if i may-- i like to add a suggestion (Although OPs suggestion is much faster and easier to do), that could potentially tackle the trade and the stacking problem.

Currently BPs have 3 attributes [runs,ME,TE]. (maybe also more, but that might not be important to get the idea). I will get rid of the uniqueness by split these attributes.

Here is how it goes:
.create two additional items for each itemtype for which a BP exist. These two are "itemname ME" and "itemname TE". These are added tradeable to the market. BPCs become tradeable.
.remove and reimburse all BPOs (take care of research effort while reimbursing)
.BPCs are now all single run and stack up. they do not differ from each other because they have zero attributes.
.BPCs are seeded by NPCs.
.For Production one selects RUNS, ME, TE. Then the industry window presents the requirements: Minerals as we know it, Plus number of BPC-, number of ME- and number of TE-items needed.
.....[+more details that would only add confusion at this point. any important? lets know]

examples:
.For production of two Vexors (at 5% ME and 12%TE) i need two "Vexor BPC", up to 5*2=10 "Vexor ME", 12*2=24 "Vexor TE" and some minerals.
.for inventing an ishtar i just need one "Vexor BPC" for each run plus Datacores and optional decryptors. no ME/TE required (they do not matter here as is currently).
.for successful inventing a vexor BPC i would get one "Ishtar BPC", two "Ishtar ME" and zero "Ishtar TE"
. vexor with an augmentation decryptor --> ten "ishtar BPC", zero "ishtar ME" and two "Ishtar TE"

Possible extensions:
.get ME from salvaging wrecks. (+more of them for better salvage skills or freshness of the wreck?) (+get a bpc?)
.control seed of BPCs. -> overly used ship gets more expensive. (example: too many ishtars? --> give out less "ishtar BPC"s! -> price rises -> effective as usual but less efficient -> no balance, but a little improvement (Nerfbat still better ofc).)
.ME/TE items can only be produced/researched from the original item. (example: i need an assembled vexor to research TE on it) (+risk of loosing that item in the process on failure?) (+also on T2 items?)

Issues:
.For nullsec industrialists far away: we enable to Copy from BPCs for everyone. 1 BPC -> N+1 BPC
.All my effort put into research of BPO earlier ingame will be invane --> dont worry! researched BPOs can be exchanged when patching into 1000 "item TE"/ME. depending on the time that was needed to get them to the same lvl.
.BP/ME/TE can be used more flexible, one does not have to plan ahead so much -> if yes, why is this bad exactly?

Alternatives:
"itemname ME"/TE as implant. but industrialists usually dont die as much.


Please tell me if i would need to make another thread for this. But hey, i just bumped OP P

Ideas are like Seeds. I'd chop fullgrown trees to start a fire.
Quintessen
The Scope
Gallente Federation
#5 - 2015-04-02 18:30:32 UTC
Boer'd wrote:
I realize this may sound a bit odd, but I think it would help simplify the INDUSTRY process and seems like it would be relatively easy to implement. So, here goes:

Problem: Having a large inventory of prints becomes very difficult to manage due to physical number of different prints. Plus, the manufacturing time is directly related to the max number of runs() associated with each individual print. For a print with a small limited number of runs(), the actual manufacturing time is sometimes very quick. For example, tech-II mining crystals typically finish in less than one hour which causes a LOT of extra effort simply to keep revisiting the INDUSTRY panel to submit next set.

Suggestion: Provide a special case of the STACK command that allows us to highlight a set of prints for a specific item [ same ME(), PE(), etc; however, there's no reason that runs() couldn't vary ]. Right click to see a drop down option to STACK PRINTS, this would result in accumulating the runs() for each selected print and result in one single print with a total runs() equal to the totals of the selected prints.

Advantages: Significantly reduce the number of prints we have to manage. Reduce the number of times we have to interface with the industry system. Allow us to consolidate manufacturing runs to manage the time to deliver so that one visit to manufacturing facility per day/week/xxx could be scheduled to handle multiple manufacturing slots. Dramatically reduce the impact of max items in cargo holds, station hangers, corporate hangers, cargo containers, etc. Should result in some modest performance improvements since inventory management will have fewer items to track.

I don't see any reason to assign a max runs() to prints consolidated with this special function since the submit manufacturing job function already has a check to ensure that number of runs() requested don't exceed the standard 30day cycle.

Reposted in this forum because original post was in wrong forum.


I would go with combine and split. Once combined, I would also like to be able to split off runs as well.
Boer'd
ROE'Dock
#6 - 2015-04-02 20:25:43 UTC

Totally agree, ability to split would be super. I was just afraid to ask for to much and get rejected due to effort required.
Boer'd
ROE'Dock
#7 - 2015-04-02 20:31:52 UTC
[quote=Serendipity Lost]You sir are lazy. Complaining that managing large numbers of bpo/bpc is kind of funny.


I will agree that I'm lazy. BUT: the amount of time that is required to manage large numbers of bpc's just seems unnecessary to me. Especially when a relatively easy, reliable solution is available that offeres player relief plus performance improvements.
Quintessen
The Scope
Gallente Federation
#8 - 2015-04-02 21:09:06 UTC
Serendipity Lost wrote:
You sir are lazy. Complaining that managing large numbers of bpo/bpc is kind of funny.


Which pains you the most?
- the effort required moving them around?
- the 'time lost' because your production lines sit idle while you are at work/school?


-1 (you are lazy)


How about how my non-crappy computer starts to choke when scrolling through hundeds and hundreds of BPCs of the same exact freaking type, stats and count. A lot of industrialists still have large volumes from before the great industry changes. At this point, managing them is just difficult.
Tuttomenui II
Aliastra
Gallente Federation
#9 - 2015-04-02 23:30:06 UTC
What we need are folders. A type Cargo container that can be put in other cargo containers. That way you can organize within cargo containers.
Boer'd
ROE'Dock
#10 - 2015-04-03 14:14:23 UTC
Tuttomenui II wrote:
What we need are folders. A type Cargo container that can be put in other cargo containers. That way you can organize within cargo containers.


Agree, folders would help organize them, but wouldn't help with the drudgery of submitting a build job for tech-ii mining crystals every 30m because the invention process only produces prints with RUNS(10) that only take 00:36:06 to complete. Combining a couple dozen of those tiny run() prints into a quantity will results in a run that will last one full day.

Personally, I would prefer to not spend all day long simply returning every 36m to submit another batch of builds for exactly the same thing. Especially when a solution seems practical, efficient, safe, easy, xxx.
Quintessen
The Scope
Gallente Federation
#11 - 2015-04-03 17:20:03 UTC
Tuttomenui II wrote:
What we need are folders. A type Cargo container that can be put in other cargo containers. That way you can organize within cargo containers.


Folders are actually a really bad UI concept. Really trees more than a single level deep are bad. Usability studies have regularly shown that humans just don't do well with folder structures. The filtering system is actually a lot better at this. I just wish I could pin ones on a per-location basis.