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

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

Science & Industry

 
  • Topic is locked indefinitely.
12Next page
 

Items to compress individual minerals
Author
Previous Topic Next Topic
Haffsol
#1 - 2014-01-25 16:31:37 UTC
As regards compressing minerals people generally tends to look for the best mix-up or ratio towards cap building or just according to which item has the highest compressing ratio of all.

I have my BPOs already for that but now I was wondering if there are items one can use to compress just the mineral he needs the most. For instance I found that sentry drones looks like a good way to carry around pyerite, with small leftovers of "useless" mega and zyd, which in null aren't missing but are also easy to haul back to highsec. But sentries offer a total compression ratio of only 3.8 ish. To make a comparision, the 425mm rails have a compression ratio of 31.

Anything better to compress pyerite? And what about trit, mex and nocx and only one of them at a time?
Steve Ronuken
Fuzzwork Enterprises
Vote Steve Ronuken for CSM
#2 - 2014-01-25 18:00:11 UTC
Haffsol
#3 - 2014-01-25 18:40:21 UTC
Too bad I can give you only 1 like, that link is saving me so much time and effort figuring stuff out in my never ending spreadsheet

:highfives:
Loraine Gess
Confedeferate Union of Tax Legalists
#4 - 2014-01-27 13:35:10 UTC
Haffsol wrote:
Too bad I can give you only 1 like, that link is saving me so much time and effort figuring stuff out in my never ending spreadsheet

:highfives:





Battleclinic also has a page which gets its info by calculating from database. However it includes items that cannot be manufactured (and the usual caveat about extra materials).
Haffsol
#5 - 2014-01-28 15:17:57 UTC
Nice one, didn't know about that one either

:thumbup:
Qalix
Long Jump.
#6 - 2014-01-28 20:16:38 UTC
Steve Ronuken wrote:
http://www.fuzzwork.co.uk/compression/

Will you be updating your sig Steve? maybe with a 10?
Steve Ronuken
Fuzzwork Enterprises
Vote Steve Ronuken for CSM
#7 - 2014-01-29 01:03:59 UTC
Qalix wrote:
Steve Ronuken wrote:
http://www.fuzzwork.co.uk/compression/

Will you be updating your sig Steve? maybe with a 10?



Well, I'll see if I get onto CSM 9 first Blink

That election hasn't happened yet.

Woo! CSM XI!

Fuzzwork Enterprises

Twitter: @fuzzysteve on Twitter
Victoria Sin
Doomheim
#8 - 2014-01-29 09:39:15 UTC
You know I was thinking about how dumb this whole thing is only this morning. I have a Rorqual that's a specialised industrial ship for mineral compression. That helps me get minerals from null to high sec. But if I want them to go the other way I have to build tens of thousands of units of certain modules. Personally I think the Orca should get mineral compression ability so this kind of game-play wouldn't be needed.



Dedaf
United Brothers Of Eve
#9 - 2014-01-29 12:29:31 UTC
I have just recently build my own compression sheet, and found that it verymuch depend on which mineral you decide on to compress first.
by just adding compression of one or 2 other T1 Items it can sometime mean a difference in 4 hauls where every needed mineral is compressed and down to just 1 haul if you move just a bit of mineral without compressing it.

You can try my tool here

Want to know what is best to mine or build at which cost? then try out Dedaf's Industrial Tool http://dedafsindustrialtool.blogspot.dk/
Haffsol
#10 - 2014-01-29 14:39:40 UTC  |  Edited by: Haffsol
Dedaf, I tried your tool before but it really doesn't like OpenOffice and I really don't like Microsoft Office :)

In any case a complete tool for compression is prolly the only one really missing in the universe of the community tools, where your ss, fuzzwork and IPH are no doubt the most impressive and complete ones.

From what I've been trying to do with my poor capabilities on googledoc, such a tool should be able to check:
- volume of the minerals required to build a certain item
- amount and percentage of the mineral of interest towards the total volume
- cost to produce the item (not buy/sell orders) AND which percentage of the cost is due to the mineral of interest
- volume of the produced item

now you can combine these information and have the actual outputs you're looking for, such as:
- COMPRESSION RATE both of the item itself (total mineral volume/item volume) AND of the mineral of interest
- some numbers to play with, like how many you need to move a certain amount of the mineral of interest, the cargo required, or viceversa how many you can squeeze if you have a fixed amount of cargobay available, how many are required to build an X amount of Y item assuming you have all the minerals already but the one you're searching for.....
- eventually BPO cost and research time to bring a certain amount of them to the optimal ME/PE level

This should be the minimum to understand if an item is what you're looking for or not, filling just 2-3 fields with "easy" requests.

For instance looking at the Steve's link, I initially jumped on the chair when I saw the Ultraviolet XL crystals had a compression rate for pyerite of 940, so I opened another tool to check the complete building requirements and saw that pyerite was about 90% of the total volume. I thought that was freaking awesome and I was going to buy a gazillion BPOs of those crystals, then I checked the cost to build the amount I needed to move my sh!t and saw that while pyerite is 90% of the total volume unfortunately megacyte is about 90% of the cost.
TL;DR: to be able to continually move (say) 50M of pyerite I had to invest about 14 Billions isk in megacyte.

Scratched it from the list and kept on checking the next ones.....
Loraine Gess
Confedeferate Union of Tax Legalists
#11 - 2014-01-29 15:20:06 UTC
Haffsol wrote:
Dedaf, I tried your tool before but it really doesn't like OpenOffice and I really don't like Microsoft Office :)

In any case a complete tool for compression is prolly the only one really missing in the universe of the community tools, where your ss, fuzzwork and IPH are no doubt the most impressive and complete ones.

From what I've been trying to do with my poor capabilities on googledoc, such a tool should be able to check:
- volume of the minerals required to build a certain item
- amount and percentage of the mineral of interest towards the total volume
- cost to produce the item (not buy/sell orders) AND which percentage of the cost is due to the mineral of interest
- volume of the produced item

now you can combine these information and have the actual outputs you're looking for, such as:
- COMPRESSION RATE both of the item itself (total mineral volume/item volume) AND of the mineral of interest
- some numbers to play with, like how many you need to move a certain amount of the mineral of interest, the cargo required, or viceversa how many you can squeeze if you have a fixed amount of cargobay available, how many are required to build an X amount of Y item assuming you have all the minerals already but the one you're searching for.....
- eventually BPO cost and research time to bring a certain amount of them to the optimal ME/PE level

This should be the minimum to understand if an item is what you're looking for or not, filling just 2-3 fields with "easy" requests.

For instance looking at the Steve's link, I initially jumped on the chair when I saw the Ultraviolet XL crystals had a compression rate for pyerite of 940, so I opened another tool to check the complete building requirements and saw that pyerite was about 90% of the total volume. I thought that was freaking awesome and I was going to buy a gazillion BPOs of those crystals, then I checked the cost to build the amount I needed to move my sh!t and saw that while pyerite is 90% of the total volume unfortunately megacyte is about 90% of the cost.
TL;DR: to be able to continually move (say) 50M of pyerite I had to invest about 14 Billions isk in megacyte.

Scratched it from the list and kept on checking the next ones.....



My corporation has been constructing a spreadsheet to optimize compression loads. Unfortunately it requires some very high-level math work as you need to get generally 8 different mineral amounts as close to the desired load as possible while minimizing volume. If you want to try and factor production time you're going to need to set a rate for how important that is compared to volume, and if you want to work within certain cargo caps you introduce a whole different layer of ****. If we complete such a tool, you can bet it's not going to be public access. Not terribly surprising no one else has made one public either.
stg slate
State War Academy
Caldari State
#12 - 2014-01-29 17:47:23 UTC
As a side note if you figure out a way to mathematically solve this issue, and by that i mean you find a way to mathematically calculate the best items to make to carry the optimal ISK-worth of minerals in a certain volume then you've solved a great classical NP-complete problem :P
Zhilia Mann
Tide Way Out Productions
#13 - 2014-01-29 17:56:47 UTC
Steve Ronuken wrote:
http://www.fuzzwork.co.uk/compression/


Hadn't played with that before. I approve. But you misspelled pyerite :P.
Loraine Gess
Confedeferate Union of Tax Legalists
#14 - 2014-01-29 21:45:19 UTC
stg slate wrote:
As a side note if you figure out a way to mathematically solve this issue, and by that i mean you find a way to mathematically calculate the best items to make to carry the optimal ISK-worth of minerals in a certain volume then you've solved a great classical NP-complete problem :P




From what I was told (I am not educated in this field beyond a college statistics course), it appears that we can select an optimum solution or solutions by setting a range for our final result and simply calculating every single possible combination of makeup modules. This may still require some manual picking after finding the remaining possible combinations, though the point of this endeavour was always to minimize later workload and make it very easy to source original minerals for a full capital build.



Alternatively I may just decide to have an insane fit and hand calculate some optimum solutions for every combination of cap BPO and component BPO ME.
Steve Ronuken
Fuzzwork Enterprises
Vote Steve Ronuken for CSM
#15 - 2014-01-29 22:36:10 UTC
Zhilia Mann wrote:
Steve Ronuken wrote:
http://www.fuzzwork.co.uk/compression/


Hadn't played with that before. I approve. But you misspelled pyerite :P.


oops?

Woo! CSM XI!

Fuzzwork Enterprises

Twitter: @fuzzysteve on Twitter
Pinky Hops
Caldari Provisions
Caldari State
#16 - 2014-01-29 23:06:00 UTC  |  Edited by: Pinky Hops
stg slate wrote:
As a side note if you figure out a way to mathematically solve this issue, and by that i mean you find a way to mathematically calculate the best items to make to carry the optimal ISK-worth of minerals in a certain volume then you've solved a great classical NP-complete problem :P


I have a hefty background in mathematics, and I can tell you that this sort of problem is solved all the time, just not for arbitrarily large sets P. The specific discipline that tackles this is called Operations Research.

You could formulate the problem quite easily as a linear programming problem, and optimize by either minimizing the ISK cost or the transport size or some combination of the two - but you would have to weight them.

I've heard implementing things like the simplex algorithm can be quite a pain in the arse, but there are many libraries for many programming languages that already have implementations built in.

edit: if nobody else bothers in the next few weeks, maybe i'll whip up something crude.
Loraine Gess
Confedeferate Union of Tax Legalists
#17 - 2014-01-29 23:55:10 UTC
Pinky Hops wrote:
stg slate wrote:
As a side note if you figure out a way to mathematically solve this issue, and by that i mean you find a way to mathematically calculate the best items to make to carry the optimal ISK-worth of minerals in a certain volume then you've solved a great classical NP-complete problem :P


I have a hefty background in mathematics, and I can tell you that this sort of problem is solved all the time, just not for arbitrarily large sets P. The specific discipline that tackles this is called Operations Research.

You could formulate the problem quite easily as a linear programming problem, and optimize by either minimizing the ISK cost or the transport size or some combination of the two - but you would have to weight them.

I've heard implementing things like the simplex algorithm can be quite a pain in the arse, but there are many libraries for many programming languages that already have implementations built in.

edit: if nobody else bothers in the next few weeks, maybe i'll whip up something crude.




I am willing to throw a spreadsheet at you if you can provide proof of concept or somethings else that is reasonably replicatable. There would have to be an agreement on publicity, though.
Pinky Hops
Caldari Provisions
Caldari State
#18 - 2014-01-30 14:18:21 UTC
Loraine Gess wrote:
I am willing to throw a spreadsheet at you if you can provide proof of concept or somethings else that is reasonably replicatable. There would have to be an agreement on publicity, though.


I thought about this.

However, I don't think this problem lends itself well to being solved within a spreadsheet. It would have to be a monumentally large spreadsheet, containing all the candidate compression items in the game. In addition, it would have to be able to communicate with an LP solver.

The problem would best be solved within an existing framework like IPH or Fuzzworks....Or alternatively, standalone (this was going to be my approach given nobody else bothers with the problem.)

I have a sneaking suspicion that the reason there is no super good tool like this within the existing frameworks is due to lack of time on the part of the people who maintain them - not because the problem is necessarily more difficult than the ones they have already solved.
Steve Ronuken
Fuzzwork Enterprises
Vote Steve Ronuken for CSM
#19 - 2014-01-30 15:53:36 UTC  |  Edited by: Steve Ronuken
Pinky Hops wrote:
Loraine Gess wrote:
I am willing to throw a spreadsheet at you if you can provide proof of concept or somethings else that is reasonably replicatable. There would have to be an agreement on publicity, though.


I thought about this.

However, I don't think this problem lends itself well to being solved within a spreadsheet. It would have to be a monumentally large spreadsheet, containing all the candidate compression items in the game. In addition, it would have to be able to communicate with an LP solver.

The problem would best be solved within an existing framework like IPH or Fuzzworks....Or alternatively, standalone (this was going to be my approach given nobody else bothers with the problem.)

I have a sneaking suspicion that the reason there is no super good tool like this within the existing frameworks is due to lack of time on the part of the people who maintain them - not because the problem is necessarily more difficult than the ones they have already solved.



In my case it's because I take a look at the potential math, then run away screaming. I'm unsure how to start solving the problem in a good way, other than 'try and compress the biggest first. then fit bits in.' Which isn't good.


(I take, at times, great satisfaction from the tears of people who wrote a tool and kept it private to enrich themselves. I won't make /everything/ available, but stuff like the blueprint calculator and lp store, certainly)

Woo! CSM XI!

Fuzzwork Enterprises

Twitter: @fuzzysteve on Twitter
Loraine Gess
Confedeferate Union of Tax Legalists
#20 - 2014-01-30 18:33:17 UTC
Pinky Hops wrote:
Loraine Gess wrote:
I am willing to throw a spreadsheet at you if you can provide proof of concept or somethings else that is reasonably replicatable. There would have to be an agreement on publicity, though.


I thought about this.

However, I don't think this problem lends itself well to being solved within a spreadsheet. It would have to be a monumentally large spreadsheet, containing all the candidate compression items in the game. In addition, it would have to be able to communicate with an LP solver.

The problem would best be solved within an existing framework like IPH or Fuzzworks....Or alternatively, standalone (this was going to be my approach given nobody else bothers with the problem.)

I have a sneaking suspicion that the reason there is no super good tool like this within the existing frameworks is due to lack of time on the part of the people who maintain them - not because the problem is necessarily more difficult than the ones they have already solved.




Honestly we thought about this problem and there are few very good compression choices. If we need to simplify as much as possible the number of candidates can be reduced to 4-6.
12Next page