Rebalance storage cell sizes
yueh opened this issue ยท 11 comments
Goal
Allow each cell to fit a more specific niche and not just be a mindless upgrade besides the basic resource costs assuming technically infinite resources in most situations.
Different amount of types per type
Each cell could be changed to support a different amount of actual types, for example:
Item Storage Cell | Old types | New types |
---|---|---|
1k | 63 | 127 (or 255?) |
4k | 63 | 63 (or 127?) |
16k | 63 | 31 (or 63?) |
64k | 63 | 15 (or 31?) |
The alternative value really feels like way too many different types for the 1k cell, but 15 for the 64k might be a bit too limited.
On the other hand players will dedicate a single block for a drawer with a single item and here a drive could still hold 150 different items and in pretty large quantities.
Fluid Storage Cell | Old types | New types |
---|---|---|
1k | 5 | 31 |
4k | 5 | 15 |
16k | 5 | 7 |
64k | 5 | 3 |
Fluid cells are a bit more difficult as there aren't that many fluids around. One or two 1k cells are probably enough to store every existing fluid in most kitchen sink modpacks in a meaningful amount.
With a 1k cell currently storing 8131B of a single fluid. Technically that is around the same value as storing it as actual buckets in form of items. Which would also require a ton of iron. So maybe reducing it by half might be an idea to balance it a bit compared to item in terms of the total amount of different types and also volume.
This would allow players to choose them more specifically for certain use cases like a 1k cell for many different items but only a few each while the 64k one would be more for bulk storage of a few different items.
Technically the bytes per type should have a similar effect, but it is pretty much negligible.
Potentially remove the bytes per type
With this change in mind this property would be somewhat superfluous and might be removed and just use the amount of different item types to keep the behaviour of storing overall less items with more types in the same cell.
However it might be easier to just keep it for the actual calculation.
Other implications
Cell workbench
The GUI is currently limited to 63 slots, so it would either provide to many filters or to less when wanting to maintain a 1:1 mapping.
Hower this is in my opinion not necessary as fuzzy cards could still cover a wide range different stacks of a similar type like every enchanting book being a valid option with just defining one. Which would put more focus on these features as well as require a bit more planning than just dumping 127 different items into a huge UI.
In case of less than 63 storable types, it could either just disable any additional slot or just keep it. There might be some interesting use cases to allow filtered types in some sort of buffer system which then is constantly cycled.
The main issue I see is any attempt to limit types or size will just lead to players who want more chaining them with subnetworks. I don't mean to say we need to do away with subnetworks but the main issue is players can put infinite amounts of drives on the network and that just means stubborn players will just spam more of them and limiting total devices or messing with subnetworks will just annoy/punish the creative/technical players who like making interesting networks that go beyond the channel limits.
I mean I personally use 1ks for all my single items/small storage as it's less energy, lag, and faster to setup/craft and use 64ks for my bulk storage. I find it's the same issue as the people who build massive controllers instead of using the mods other functions to work around the channels limit feature and auto crafting stuff.
Then again I also slap a storage bus on EVERY drive I put down and have a subnet I can just dump all my formatted bulk drives and 1ks into and have them auto inserted and easier to manage. XD
Generally agreed with @XerShade. I don't think this is going to happen.
Variable cells are pretty much a no go.
Except if we would go a fully modular approach and say start with a 1k cell being able to store 7 or 15 types and then allow a limited amount of upgrades to add more types, capacity or filter slots. For example allow something like a cell which would be more comparable to a 128k or even 256k cell, but only allow 3 types to be stored, but completely unfiltered. Or the opposite way and having a small cell with 255 or 511 types, but only like a 3-4 items of each.
But that quickly turns into a PITA once you want to fill your 128 drives with 1280 custom cells. All crafted by hand with some tedious GUI. Or at least needing a few dozen different patterns to craft exactly the ones you would need.
Neverthless I do not see many arguments to convince me about this option.
Specialised cells for certain conditions also do not make much sense as the idea for AE2 is still to provide as few basic options as possible, while allowing the player to combine it to fit their needs. With the way tags and flattening works, it also would not be of much use. Each bee variant should be its own item id and would better fit into a redesigned 1k cell. So in the end it would just be a cell to store all wooden swords produced by some player's mob farm with every possible enchant and damage value.
Similar with tags, they are used much more broadly compared to the old ore dict, so we easily could encounter someone tagging everything as block/worldgen
because they need it for their quarry and allowing iron ore into a cell would now also match logs, flowers, dirt, stone, and what not. Similar with things like forge/ingots
matching all ingots and not just the copper ones you want to be stored here.
The goal here is to reward players for planning ahead and not just brute forcing their way with 64k cells. It should not be impossible to do it. Which is why 15 types for a 64k cell might feel a bit low currently.
But on the other hand that still means a single drive can store 150 types and about 2.6 million items. About 280 stacks of each type. Compared to say a diamond chest with 108 types and just 6912 items or 1 stack per type. And with suggested 1k cells it would be provide 1270 slots with about 41600 items or half a stack per type. I'd guess not many ME networks would even store 1k items or more. Really sounds pretty reasonable to me for now.
With just 1 type the overall storable amount would about double, that might also be something to revisit and maybe quadruple it to further reward planning ahead and setting up dedicated drives for bulk items.
I understand the idea behind this post now. It's about providing better functionality to 1k cells to not be completely overshadowed by their counterparts. I would agree if you don't want variable cells to bring for 1k 255 types and lower for the next tier. If you want for players to think more in detail about how they store their items maybe add more than a capacity bonus for higher-tier storage cells maybe even add something like RAM speed (something like the acceleration card for all processes meaning a 1k cell would deliver slower, items to an output).
My idea for storage types is the following. Let players choose the number of items that a cell can hold through a new block named storage allocator (very debatable name and idea). If you have problems with other blocks because a player would choose to have 64 types for example maybe add predetermined choices.
It would be convenient for players to choose at the beginning to have more than 63 types of items since there are a lot of junk items. In the future, you don't need to limit players that have a 64k disk to only use 15 types of items ( I am the type of player that would only use 64k cells even for junk items since I don't know when I will get a large amount of the said item).
would allow to setup a disk for unique items like damaged and enchanted items that don't share a slot and never stack higher than 1 item ... or bees from forestry
Pretty much this. But also not introducing a totally different mechanic players have to play around. Reward players who pay attention and plan ahead, but still allow them to mostly ignore and brute force it. Channels are already enough to deal with and there are still other mods players have to learn and we should not balance it around AE2 being the only mod.
Dedicating a single dense cable for drives full of 64k cells would still net around 4800 different types, which should be more than most players will ever need. And still not really big when going full out.
Similar also the intermediate ones shouldn't be completely obsolete. So 1k would be ideally for all the random items someone would never have more than a couple, 4k for a couple stacks each, 16k for the semi bulk stuff with a couple hundreds or maybe thousands, and 64k for the actual bulk storage (outside external storages).
And with suggested 1k cells it would be provide 1270 slots with about 41600 items or half a stack per type. I'd guess not many ME networks would even store 1k items or more. Really sounds pretty reasonable to me for now.
I like the numbers, sounded a bit lower in the first proposal
I think the best way to force player to think of how to use the storage cells properly is to make them more expansive in upgrading, also for ME Controller (players always make them in a 777 way, 68=5*12+8blocks)
For example:
4k=
Logic Processor + 1k + Logic Processor
Formation Core + Printed Silicon + Annihilation Core
1k + Pure Nether Quartz Crystal + 1k
16k=
Calculation Processor + 4k + Calculation Processor
Formation Core + Printed Engineering Circuit + Annihilation Core
4k + Pure Fluix Crystal + 4k
64k=
Fluix Pearl + 16k + Fluix Pearl
4k + Matter Ball + 4k
16k + Engineering Processor + 16k
You could also make it feel less wasteful to use 1k cells. If people could recoup their expense on cells, they might use more 1k cells while trying to progress. My idea is to make a machine block that would simply take a storage cell and 'uncraft' them back into a cell housing and storage component. (Storage Cell -> Component + Housing)
This would also give more use to Storage Housing as well since otherwise the only unique use of them is for view cells.
1k cells don't have to necessarily be more useful endgame if they are more useful early game. Just my food for thought.