Suggestion: Remove harvest controllers and ammo controllers. Instead, you should be able to access a given cargo controller and select any (or all) weapons, drills, or harvesters currently attached to the BA/CV/SV/HV so that a particular cargo controller (and it's expansions) can directly feed selected weapon systems with the proper ammo in its storage, or selected drills/harvesters can feed the cargo controller's storage with ores/wood. If you want separate harvest and ammo storage, you can still do that if you set up a separate cargo controller for ammo and for harvesting and select only the drills/harvesters or weapon relevant to each storage system.
An issue is that the food processor actually should have the ability of 2 input devices. Some items do not need to be stored in a fridge, but are still needed for recipes. Probably most devices could have that option. Even without mass/volume it becomes an issue that have to move stuff around since too few slots for some devices. Or need several devices set up towards different storage devices. BTW not the only suggestion having only 1 type of cargo controller, maybe even have fridge option.
Keep in mind that making everything more abstracted with a checkbox to switch between fridge and non-fridge "modes" does have an immersion cost. It doesn't bother me that much (it's just a checkbox in a standardized device vs. building a separate device), but it does go further down the same path that has been hurting player perception of the game insofar as "real" cargo interaction has been made into a virtual menu system. So I'm in favor of multiple input selection for constructors and food processors, but on the fence re: merging e.g. fridge functionality with other cargo container blocks. It's like a more mild version of merging the Large Constructor and Food Processor into an Omniprocessor. Removes some flavor.
Been thinking about this a little more. Instead of adding weapons/harvesters/drills to cargo controllers, you can assign cargo controllers to "inputs" or "outputs" of weapons/harvesters/drills. The method below follows the way logistics currently work for constructors. For example, when you place a new weapon system on a BA/HV/SV/CV you could open the weapon, and (similar to how an unattached constructor works now with input and output selections) you would see an "input" selection (only), and you would just select the proper cargo controller to feed it ammo. For newly placed harvesters/drills/multi-turrets, when you open them, you would see an "output" selection and you would select the appropriate cargo controller. It would be nice if when you look at the list of components in your BA/CV/HV/SV, components that haven't yet been assigned inputs and/or outputs would show up "red" or have some indicator that they are unconnected.
This seems like the simplest way, and yeah a warning of some kind that you need to set an input/output would be really nice.
@CitizenK3N That most devices that collect or need items could have input/output for connecting to the storage system are already suggested, but more the merrier
I don't know how often this has been brought up I admittedly only skimmed the thread. Here are my thoughts on my experiences with the logistics system UI. 1)Some sort of slot increase in container controllers doesn't have to be an infinite scrolling list, just bigger since in between looting and salvaging POI's the container controller I use for my constructors tend to run out of slots before they run out of volume. I don't know if connecting a deconstructor to my source material box is a workaround or not since I am not sure to what degree items are broken down and if there are any situations that less is returned that what went into making the item ( Ie, if a single electronic is broken down, is the half of a silicon ingot lost) 2) the ability for the logistics system to actually remember the last container I used on both sides when f4 is used and the last container I used on the left when I open a container with f. I believe that this will cut down on the amount of "drop-down simulator 2019" that the avg player experiences, especially when looting POI's one container at a time like you have to if the setting to allow POI's to regenerate is set to true. 3) I think all containers should have an ability to connect your toolbar by default even if it is within 1-5m of the container you want to link with. I have came across situations where I wanted to pull x item out of an alien container and then immediately put it in my blueprint factory only to find that it is too bulky/big for me to pick up and I don't always have a ship in range with enough volume to temporarily transfer the block to. Being able to stand right next to the container and have some sort of adhoc link (red background maybe) long enough to put it in the factory would be a Quality of Life Improvement. If I find any more cents while I am sleeping I will make sure to spend them here.
Be wary about "Quality of Life" improvements, sometimes they can turn into "Lack of Immersion" downgrades. I'm not saying this is the case in everything, nor the example above but I have seen it happen so many times in so many games.
I can't use the connected toolbar with the personal drone. Is that a bug or is that intended? If intended this will make the drone useless for building.
I have the same problem. I can not use T to switch, when drone enabled ... It works when double tapping though ... I don't know, but it sure FEELS like a bug ...
Q: Why on Earth would the large "Container Controller (Ore and Wood)" for the CV be set to unlock at level 20?! Please, consider changing this. This is especially confusing because: The small "Container Controller (Ore and Wood)" for the HV is set to unlock at level 3! That's quite the difference! Why does the equivalent for the CV unlock 17 levels higher? Does scaling up the size for a CV really require that much of a technological breakthrough? The name for the small "Container Controller (Ore and Wood)" for the HV makes sense, because an HV can have a Harvest Module to actually harvest trees for wood. However, the name for the large "Container Controller (Ore and Wood)" for the CV makes little sense because there is no Harvest Module for a CV, so they will never harvest Wood. Moreover, no Turret for the CV - not even a Tool Turret (Multiturret or Drill Turret) - is able to be used on a planet's surface. (BTW: I think that's quite ridiculous, but that's another subject.) The reason I bring this up now is because I was updating an old Starter CV (i.e., a blueprint with an Unlock Level of 10) to use the new Modular Container system, like a good player. And when I looked at my end result I was quite alarmed and confused because the Unlock Level suddenly jumped from Level 10 to Level 20! I'm doing this because, since the introduction of the new Logistics system, the game clearly discourages the use of regular old containers. The old Ammo Box for BA/CV only holds 2000 volume, yet weighs 1200 kg! Compare this to the Container Controller (Ammo), which weighs just 500 kg and has a whopping 8000 volume, even without a CEU. And while I would prefer to use the old Harvest Box as it still has a very low (or nonexistent) Unlock Level, I can't: While the Harvest Box is phased out - it is no longer available from the ItemMenu in Creative - a blueprint having one does not prevent it from being built in Survival. The problem is that one has to use a Multi Tool to steal one from an old blueprint as we can't get them from the ItemMenu. Worse, the Harvest Box (for the CV, mind you) only has a pathetic volume of 250, which isn't enough to do anything. This, despite the fact that the Harvest Box (for CV) is the same size as the Ammo Box or Cargo Box 1, 3 or 5, all of which have a respectable Volume of 8000. Strangely, the game actually encourages the continued use of Cargo Boxes for general storage, instead of the new CCU's and CEU's - at least when it comes to CV's. (The situation for SV's and HV's clearly favors the use of CCU's and CEU's, instead of Cargo Boxes.) I say this for several reasons, including: With the small CEU's for SV's and HV's, the Volume is a fixed amount, regardless of the shape or size it is placed as. This encourages blueprints to use CEU's in a variety of shapes to make interesting and beautiful designs. In contrast, the Volume for large CEU's for CV's and BA's is highly dependent on the shape they are placed has. For example, if a CEU is placed as a "Corner" or "Ramp Bottom C", it will add far less volume than, say, a "Cube", "Corner Long A" or "Corner Long B". This encourages players to always use the default "Cube" shape, which leads to players either hiding CEU's inside a CV or BA or leads to very block, cubic-shaped blueprints. Currently, Cargo Boxes (for CV/BA) weigh far less than the equivalent CCU and/or CEU, despite holding the same Volume for the same space. A single CCU or CEU takes up the space of 1 block and has a Volume of 8000, as does Cargo Boxes 0, 2 and 4. And Cargo Boxes 1, 3 and 5 have a Volume of 16000 while taking up the same space as two CCU's (or one CCU and one CEU). However, a single CCU weighs a whopping 500 kg, while a CEU weighs 250 kg. In contrast, a Cargo Box 0, 1, 3 or 5 weighs just 300kg, despite holding as much as two CCU's or one CCU and one CEU. Cargo Boxes 2 and 4 weigh even less, at a mere 150 kg, despite having as much volume as a single 500 kg CCU.
I'm sure the devs thought it made sense given that L20 is the first time you can unlock harvesting equipment for a CV . . . . . doesn't change the ridiculousness, mind you. I think it makes sense for non-full blocks to store less. It would be nice, however, if the rest of the blocks' stats scaled accordingly as well. Balance issues strike again, basically. I'd still like to see the original cargo boxes become alternate forms for CCs (and have the spacing rule removed for CCs).
Making CV mining a high level thing doesn't seem too unreasonable to me given the large amount of ore that asteroids have, but right now they could make the unlock level 1 for all it matters because finding the asteroids is the problem. You have to fly around at random, don't get a "ding" when you run across one, and there's nothing to help you keep track of where you already searched (other than manually setting waypoints). So it's like trying to find ore on a planet with not only no detector and an always-dark map, but with no alert "ding" when you get close to a deposit. So right now asteroid prospecting is an extremely boring problem with no good strategy solution. There are ways to address this without making it too easy, like: have a scanner that has to be activated manually and takes 10-20 seconds to scan, then gives you some vague information. Or make people deploy probes that triangulate ore asteroids within some range (like the probes only give you a distance if within range and that's it, so you need at least 2 to get a vague idea and 3 or 4 widely spaced to get a precise location).
It does make sense. But the problem is exactly as you state: CEU stats do not scale accordingly. Mass and hitpoints is fixed, regardless of shape or Volume. My biggest gripe with the scaling of CEU volume is the fact that the energy requirement is a fixed 1 PU, regardless of the block shape or Volume. It wouldn't even bother me much except for the fact that the energy draw is definitely a non-trivial amount. If the power draw was trivial (such as 0.1 PU or zero), then I would have no objection. Well, it also bothers me that the CEU's for SV's/HV's are treated quite differently from CV's/BA's. I'm pretty sure that the devs could remove the spacing rule. However, for that to happen, they would have to introduce new rules in place of this. Currently, the spacing is necessary because it allows the game to determine which CCU is connected to which set of CEU's. Without spacing, there would need to be a different mechanism to indicate which CEUs a given CCU is connected to - assuming that a connected Modular Container system can not have more than one CCU per connected set. Actually, I have no problem with CV mining being a high level thing. Keep it that way. My issue is with making the Container Controller (Ore & Wood) a high level thing. There are a few good reasons to install one (or a Harvest Box) in a Starter CV, long before the player has unlocked Tool Turrets or found the resources and motivation to install a Drill Turret. It's always nice to have extra container storage, regardless. And having it pre-installed in a blueprint means one less thing that the player has to install and reorganize in the Devices tab of the Control Panel. The player doesn't have to scratch their head in figuring out where in the ship to install it, either. Yep. Finding them is a real pain, for the reasons you state. I just assumed that this is something the devs will get around to addressing... eventually. A CV ore detector device would be awesome. And, yes, a way to keep track of where we searched in space would be super useful. And that does beg the question: Why can't fog-of-war be treated similarly in space the way it is on planets and moons?
The spacing is needed for CEs, yes, but it's not clear to me why CCs also have it. It seems like the spacing rule could be relaxed for CCs without any consequences.
For the very same reason theee is no cv-cv docking. There can be only 1 master, which is the CC. Even with this enabled, you could place CE only on the opposite side. As soon you want to poace CC alongside, they'd want to merge, which would redult in 2 cc for '1' ce-arangement.
I don't see why it would work that way; since each CC starts its own separate storage array and there can only be one CC per array, I don't see why having two CCs next to each other would cause any problems. They should just ignore each other, really. Obviously, with the current system, CEs can't be shared across multiple storage arrays, so CEs couldn't be placed such that they caused CEs from different arrays to touch.
I think this is the part @geostar1024 was questioning in particular. CCs have no reason to care about adjacent CCs; they can only attach to CEs. So there's no need to have a restriction against them (the CCs) being adjacent, as long as CEs aren't allowed to go next to CEs that are claimed by a different CC. Aside: Goshdarned acronym soup... o_o It would be so much simpler if they didn't need a root node (though in that case there would be an ironclad justification for not being able to isolate adjacent containers).
