Designing vessels for the new logistics system ( weight and volume )

I design my own hv's , sv's and cv's but the new logistics system really changes how you handle inventory in your ships.
What guidelines are recommended for this new logistics system when it comes to handling inventory, production and the associated storage containers ?

 

What i have learned is that you should keep the amount of ce/cu to a bare minimum due to the insane powerdraw. If one can get away using the old containers, that is surely preferable.

On the other hand.. ce have more hitpoints than many buildingblocks, so if i build a cargohauler i dont use exterior blocks to save weight. Just stay out of enemyfire if you do.

Also having one cu/ce unit to link to when looting (with wifi) is great

And name your cargo so its easy to quicly find the correct cargo when using F4 menu

 

The worst part is that while placing extensions, especially on HV they cant touch the other group, is there a way around this, or am i missing something entirely? Seems like we should be able to thow a bunch of containers in there and than decide what they are for.

 

I try to place CC's in the center, any mass/weight is calculated towards them. Extensions is more for volume.
Often you can separate two sections by some planning, placing a fridge or another device or block. The shape do not count towards connected or not, so can create hallways by using half blocks or angled ones. They do not connect if "touching" in a diagonal position (edge/corner against edge/corner) only. You will not be able to place any CC or extension so they "bridge" two sections, so you get notice with the "red" placing markings.

Now I do not play with weight & volume in my SP's, but try to plan a bit if to be mandatory. The F4 logistic system is a separate function in the game.

A nice thing with linking storage to a Constructor (and such), that those are at top in "F4" lists.
The lists are also sorted by A-Z, so can use that to get the order you want (01 box K | 02 box F).
I mostly link CC Ore/Harvest to Constructors in vessels.
Sadly Control Panel's Devices lacks some easy sorting and rearranging (and more).

EDIT: Apparently there are some bugs/issues with Ore and Ammo CC's, regarding weight/mass (build 2281/2282).

 

Im using the volume system and i have the hang of placement now. I like the way the logistics system works. However, im not sure about the wireless thing. I mean how does that even work? I guess its like teleporter but it should way up the tech ladder if thats the case. I would just rather it require physical contact.

 

If you have teleport tech as this futuristic fantasy galaxy have, then you would have tried to use it for a storage system. Sadly the devs decided to add weight and volume and now probably use quite a bit time make it work, instead of embrace the teleport tech.

The transfer from the personal drone (F5) is done by "teleport", putting things in the BluePrint Factory and then spawn something, and so on.
Also already had the "registry", where you could connect to some of yours bases and vessels Control Panel (if close enough), but not use devices or access.

BTW there are several that have Let's Plays and similar on YouTube (and Twitch). Can watch there what they build and the performance. See the media section in the forum, I also have posted several links there to streamers.

 

Many UTubers will talk about a lot of other things besides just the topic of their UTube video so you have to waste time going through the video to find what your after which I find frustrating.
I appreciate the UTubers who get straight to the point of their video.

I wanted to start this thread about this very topic because it so dramatically changes how we play this game and not enough players know how it works.
I've seen a few players rage quite because they don't know how the new logistics system works and think it has broken the game.
This game needs more players.......not less.

Are there limits to how high your capacity can go by adding container extensions ?

 

Or youtubes about config/command line text you put in to get something to work, drawn out, with obnoxious music .... seriously, do we need a video of that? Now how do I copy/paste those command lines ! idiots. Thankfully there is a downvote button.

 

yes 320000 for the large block size 1container controller and 39 extensions. unfortunately, a max size container is exp[ensive as to energy (400 energy units) and very few items will utilise the entire volume before the secondary volume system kicks in (slots). This makes the system difficult to use and a disappointment to me as I see the new w/v system has great potential, currently unrealised.

 

So do you think energy consumption should be based off % volume filled? 0% volume having a baseline energy usage of course for the whole system to run.... then 100% volume be the cap energy used by all devices in the array?

 

That is exactly what i proposed in some suggestions thread a week or so ago.. would make a lot more sense imo

 

I could live with that. It is not that I expect the storage to be completely free, but I do not want to spend an inordinate amount of time farming energy to power my storage either.

 

Properly, energy (and CPU) should only be consumed when the storage system is doing something (i.e. transferring material). The best implementation would be a per-unit-mass and per-unit-distance energy charge, the latter of which would encourage designers to locate storage close to consumers (for even more fun, per-unit-distance energy charge could be nonlinear, so that locating an ammo box close to a turret would use substantially less power in operation than if the turret had to draw on an ammo box on the far side of a structure). When idle, the only power draw should be a trickle to maintain a connection to the core for purposes of access control.

 

Energy should not be a limiting factor on raw storage space. Transferring, sorting, and processing cargo? Sure. But just storing stuff? Nah. Weight and size should be the limiting factors on cargo capacity. With the current power draw, it makes it hard to fully use the modular cargo system and logistics to its full potential.

 

Well, I think Eleons argument was that things are actually stored in a compressed state that requires power to maintain that compressed state of storage.

But, even with trying to rationalize that, it doesn't make sense when the power goes out... your cargo doesnt "explode" in mass expansion.

So I believe the best course of action is as you and geo state.... draw power when things are being transported around too and from destinations/sources. I do like the idea of distance factoring in. Would help reduce this "place a turret 100 blocks out, and hide my ammo buried deep inside my base" syndrome without any drawbacks to doing such.

 

Regarding everyone's concern about the Energy problems with ContainerControllers and Extenders,

We tweaked it down abit

Will be included in the next HotFix

 

But, ultimately, that's not really addressing the underlying issue, which is that containers need active and idle power states. For containers, ideally the energy consumed should be proportional to the items transferred and the distance they were transferred.

Now, one issue to consider is a finite transfer speed; without it, extreme power spikes would be possible when transferring large numbers of massive items. Dealing with this (or not) gives a number of possible approaches:

• Simplistic: CE has active power and zero idle, and CC has both active power and idle (total active and idle power for a container are the sum of the components). Container is activated for a few seconds whenever its inventory is changed.
• Improved: everything from Simplistic, except that either the active power or the activation time is multiplied by some factor related to the mass being moved and the distance it's being moved. May required a maximum power to be defined to avoid potentially massive power consumption spikes.
  
• Realistic: everything from Simplistic, as well as a finite mass transfer rate for CCs; along with a per-unit-mass and per-unit-distance energy charge, this gives the maximum active power for a CC. A storage array remains active while items are being transferred.

 

So long as there actually is NOT a real 'delay in transfer'... as trying to maintain that, with people clicking and moving items back and forth will drive people to seriously rage hard on top of what they do now.

So any delay or power consumption time-frame, could also be circumvented by immediately shutting power off after moving a ton of stuff, to cut the 'time power is on' or something. Sounds like a headache.

And burst sucking power only when an item is transferred... isn't going to consume enough power to even be noticed. As it seems one only loses fuel over sustained power consumption.

 

Well, that is why I stuck that in the "Realistic" option . For small amounts of low-mass items, you likely wouldn't notice it; it could even be disabled entirely for transfers involving the player's inventory since the maximum mass transferred would be small anyway (which would probably take care of a lot of the potential rage). However, it would make sense that transferring tons of iron ore from your HV to your BA would take a few seconds. The main advantages of this approach is that it would provide a natural cap on the power consumption of a container as well as introduce some interesting logistics puzzles in cases where extremely high throughput is needed.

Yep, if the duration is appreciable but item transfer is instantaneous, the system is definitely gameable.

Well, so, that's a good question: what's the minimum active time for the system to register energy usage? Alternatively, if the existing power system can handle energy deductions directly rather than requiring a power draw for a finite time then there's no problem, and the energy consumption calculation is simple. Part of the problem for us in assessing this is that we can't see the stored energy in high enough resolution to see how small momentary power draws change it.