It may be a system you do not like but it is far from stupid and I resent the implication that I am stupid because I find merit in this new mechanic.
Well maybe you should learn not to take people's subjective opinions as being a personal attack tailored just for you...I say it IS stupid and how you feel about it doesn't concern me one bit.
So... the actual cargo existing boxes, including the new model ones with higher hp, have nothing to do with the cc and ce system ? see i was thinking the new cargo box models with the higher hp and the cc and the ce were all part and parcel of 1 package and worked together. The way things are explained in this forum about this (SYSTEM) is not too clever at all... They throw in this new container system and I see new cargo box models came with it yet the cargo box are technically redundant to this system I figured the new model boxes had to be used with the CC CE. It would be nice if some basic explanations could be thrown in game along with the new items. I want a update page flash up on the loading splash screen. Anything to provide the public with more knowledge of what is going on please, considering I am a daily forum user and daily egs player, I have had to come here several times now in order to fully understand what is going on just with storage boxes. Now for the positives, I like the new system ! I like being able to design cargo box shapes, that's pretty cool, I have some awesome ideas for that already. I saw how the volume increases with the extensions, this system shows promise ! I was also under an impression for some reason, the old cargo boxes will be completely removed. Now that I understand it more, I am not going to whine any further about the subject. Just know this has frustrated me today lol. Please addendum the OP if you are so inclined. 1. EGS now has 3 container types 2. regular cargo boxes are as normal and in no way used with controllers or extenders. 3. we also added some stronger versions of regular cargo boxes (could do with rename to strongbox) 4. we added a controller, this is the new modular cargo box. 5. we added a extender, attach this to controller, this makes your controller have a larger volume capacity. Personally things like the term "controller" used to describe just a storage box is another thing that confused the hell out of me and completely threw me from even realising the controller was a storage box. Controller drives a train in my country, england, where the english language was invented Or is a device used to play games on a console. You should rename this to "Modular Container" as the title speaks for itself and **** I probably never would have had to post here today... You have used the term controller as to indicate it is the main box in the loop of extensions, the term "MASTER CONTAINER" may have been more appropriate. The cargo extension should be renamed to " Modular Container extension" so players don't presume it is an extension for a regular cargo box.. The new model cargo boxes with more hp which have nothing to do with the cc and ce, should be renamed to strongbox small/large. I hope you see the potential confusion here like I did Keep up the good work guys, I am still rooting for ya !
One major issue the logistics system (along with control panel) should handle, is looting POIs as the Armory. Have roughly 96 of the new cargo boxes with 500 health (that takes 5 hits with Multitool T2) or the version with some ammo boxes. I loot faster by "manually" select each and F them than using F4 or CP.
Logistics stuff is a must for a survival game, I was expecting this so I am ok with it. I also believe any problems about the system will be solved in time. But the execution of the logistics is a little bit of void right now. I mean, how this stuff work? Are they use short range cargo teleporters? Or is it drones that move stuff? The same problem also exist with constructors. When they build a template, you just spawn it like it is magic. A swarm of small drones actually building the template would be more convincing. Drones that move and build stuff dont even have to be complicated, for carrier drone put a box under it and sen it from A to B, for constructor drone give it a laser and make it "work" on the blueprint like some other games do. Or add cargo teleporters. Those are my suggestions.
I'm getting rather annoyed with how the "independent tracking" works. It's often helpful, but... Sometimes I want to keep the same view with F4, and sometimes I wish it would use the previous box I accessed with F, or I want it to return to being the player inventory on the left by default (even if I switched it away from that last time). It would be much better if it had the behavior I suggested a while back with the connected inventory replacing your personal inventory (on the left) when interacting with something on the right side with F. Also: Shift-transfer of fuel and O2 in the logistics view is broken. Yes, we can use the Fill buttons in the control panel, but... at the very least, inserting biofuel manually is annoying...
Hi There! I know this has probably already been suggested. If so, please accept my apologies. I would like to suggest either of the following alterations to the Armor Locker. #1 Have the Armor Locker accessible via F4, simply to access the internal inventory and manage suits of armor and boosters. Maybe it could be implemented as a T2 Armor Locker. #2 Have the Armor Locker essentially become an Armor Locker Container Controller. The Armor Locker retains it's own small inventory, but now can have container extenders attached. The newly created Armor Locker Volume would be available through F4. Additionally, this volume would be available for common, let's say T2 armor lockers to access. This would give teams the volume as a common equipment pool and the individuals space for a little special gear. I hope these make sense. Thank you!
You can access it via the control panel. Would be nice to have it in the logistics menu too if it's not already.
New Cargo System didn't go far enough. And how to fix a -huge- issue. -- Just back to Empyrion from A8.0. -Haven't- read any threads; want to get this down while it's clear(ish) -- Think this is the right thread since this would all be managed via the GUI. -- Huge issue is if a CC or CE is destroyed, all 'downstream' Cargo Extensions immediately dump their contents out. That is simply not rational or acceptable. Even if addressed by only dropping cargo equal in volume to the _destroyed_ CC/CEs, you'll still lose access to downstream CEs until repaired. There's a better option. Going further: Fully Virtualize Storage. ---------------------- All Cargo Extensions in a BA/CV/SV/HV are simply lumped in to a single 'Available Cargo Space'. That space is then divided up into virtual containers as desired via partitioning & Priorities. (Sounds like & is basically how computer hard drives are handled) (though soft & hard use quotas would be nice, they might be confusing...) Cargo Controllers become simply 'access points'; point to the "Ammo CC", hit F and 'see' how your Ammo is doing. But how -much- it can hold is configurable via the Cargo GUI, -not- by how many Cargo Extensions are directly, 'physically' connected to the Ammo CC. (I'm guessing the specific "Harvest" & "Ammo" label/tags are for backward compatibility, otherwise I'd suggest removing them) Doing away with 'physical' connectivity fixes the "Huge Issue"; there wouldn't be any 'downstream CE's.' If any CEs are destroyed their volume is removed from the 'Available Cargo Space' and then, based on Priorities, the lost volume is removed from the lowest Priority partition. For a combat ship where you expect to lose a few CEs you could make a "Dangerously Exposed" partition, set it to the size of the exposed CEs and set it to the lowest priority. If/When CEs are destroyed, cargo in "Dangerously Exposed" will be the first to go. **Yet since this is all virtualized now, -all- the cargo space not destroyed (and all partitions) is still accessible. -Keep- the 'old', standalone Cargo Containers. They are useful. _Allow_ them to be added into the single 'Available Cargo Space' used for Partitions & Priorities. Add a "Visible in GUI?" check box. Reason: builders. The new models are great! Would allow really nice looking cargo bays -without- having to individually manage boxes. On Building: this change would allow placing Cargo Extension blocks anywhere the builder wants, while building. No need to fiddle with maintaining 'no-touchy!' gaps or unbroken string of physical connections. Planning for damage is still rewarded. Put 3 CEs with your Core, encase in Combat Steel, set 1/2 the space of 3 CEs to "Ammo, Priority 2" & the other 1/2 to "Vital, Priority 1" (extra fuel, Meds, etc). -- EDIT: forgot to mention; another advantage would be that since the mass of the cargo appears to be calc'd as the center of a box described only by it's corners, then that calculation could be done one time at the 'Available Cargo Space' layer, rather than for each Ammo/Harvest/Container-Controller. Which would also make "designing" to handle all the mass, or Center of Gravity, quite a bit easier. Really hope the above makes sense. Once it clicked that I was actually thinking along the lines of hard drives, virtual disks, RAID etc. the lightbulb lit up.
I have one wish right now. That there was a way to change whether mass and volume was enforced after starting a game. I was over an hour into my survival game before I finally had more than 500 SU. That is when I realized that I had not turned on the setting when creating the new game. And I was even prepared with a large cargo box that I had attached on a wreckage. After playing for a little bit longer, I ended up leaving the game and starting a new one. There was no way to turn on the system in the middle of the game that I could find, and I actually wanted to have it there. Self-enforcement was very difficult and I was slipping frequently.
I just wanted to point out a regular flaw I see in these discussions: " (a) makes the game radically different from the one we bought" --- You did not buy a game. You bought the ability to view the software's development process, and to provide direct feedback to the developers of said software. Feedback which they can take or toss. Only the developers know what the actual final game is going to be, both in final look, and final mechanics. It will be a Finalized Game when they exit Early Access with a Full Release. Also, neither Beta, nor Release Candidates count as a game. --- Claiming you bought a game, and demanding 'what you bought' shows you simply do not understand what Early Access/Alpha Software means. --Brian
You do realize all games on the PC are 'software' by base definition, right? You also realize that Steams "Early Access" is buying software that is under development, right? If not... please do some research, and stop attacking members of the forum for pointing out how unreasonable you are. In the meantime... welcome to our ignore lists.
I had totally left this discussion until someone came in and decided to educate us on EA and told several big whoppers. You can try to cover for that but the truth is the EA section on the store page says game in the title. Saying that it is not a game is at best an untruth and at worse a bad attempt to moderate people and tell them to like it or shut up. I do not agree with someone who is not a mod or a dev telling others to sit down and shut up. We are all aware of EA and we are all painfully tired of any criticism being pounded with the EA hammer. The devs asked for feedback-good or bad--if you have a problem with the feedback then start your own company where you can control the forums. If you have a problem with the way a person gives feedback, maybe composing lies and telling them to shut up is not the way to go.
Besides reading this thread and poking around elsewhere (using Search, etc.) I'm still wondering if it's the intention or not of the devs to decrease the PU requirements of CE's? For SV's and HV's they are now in line with the old containers (1 PU) but for BA's and CV's those still draw 10 PU (both CC's and CE's) which means for 16 kSU volume it costs 20x as much in power than going with the equivalent SU capacity using traditional cargo boxes. I like my CC's and CE's but my solar base has reached the point where I'll have to start downsizing them (trading them out for the old style boxes) in order to make PU headroom for other things. I could also deconstruct (for an initial PU cost) a good portion of my collection of Combat Steel and Hardened Steel blocks into Steel Plates and Sathium ingots and save storage that way but I'd rather not (it would also mean some time and power to reconstruct these blocks for the next CV build). While I'm on the subject of power it would be nice if the PU draw of CE's was added to the Control Panel. It's a bit annoying to have a consumption of 403 PU but only have 170 show up in the device list (the two CC's are listed but not their respective children CE's). Oh, and Elevator blocks are also invisible (each draws one PU). So yeah, TLDR are we going to see CE's for bases and CV's get their PU requirements decreased any time soon?
I would very much like to have a nice concise report (page?) showing the power draw of various devices on the base. I imagine that with the introduction of CPU, a report on that would also be nice. Currently it is fairly irritating to have to hunt through devices to find what is drawing power in a large base or ship.
The UI for logistics has gotten a bit better than it was when A9 first came out, so I thought I would review it again, and bring up some points for improvement. There are several shapes missing for cargo extension blocks. Referring to the picture in https://empyriononline.com/threads/suggestions-for-new-full-block-shapes.46691/ the shape I really need is D7. I was surprised it was not there. Ideally, you'd go through the list again and add any block that is "big enough" to hold cargo (half block or more). As others have stated, container extensions use too much energy. It is an empty box. Please bring it down to a minimum value. If you want to make people expend energy for cargo, then make the cargo controller use more energy when it is full (e.g. 1 PU per 5000 VU or something like that). But please do not charge us power for EMPTY cargo space. Balance problem: Cargo extension blocks (for SV/HV) are stronger than steel blocks, but are made of only steel. It seems odd to be able to make a ship stronger by putting cargo blocks on the outside. Consider making an armored cargo extension block that includes sathium, and lowering the value of the existing cargo extension block to be more fragile. Currently, cargo controllers cannot be adjacent to one another, or to a cargo extension block that is already adjacent to a cargo controller. Please rework this so that you can have any number of cargo controllers adjacent to one another; in that case the cargo controllers should act as an access point for the same cargo storage. If they are separated by at least one block, then they act as separate storage areas. It is very useful for a larger container to be able to be accessed from multiple sides when you're standing next to it. With the old 2x1 cargo boxes, you can access them from every side, why can't you access the new ones from more than one place? When you load up an HV with cargo, the cargo controller is currently the center of mass for all of the cargo (it behaves like all the cargo is in the extension). Instead, it should behave like the cargo is evenly distributed between the containers. In my experience if you place the cargo controller off to one side it makes the whole HV lean over even if the cargo extensions are evenly distributed. (However, this may be due to that odd bug someone else reported where weight is 2X on one side, compared to the other.) It would be nice if cargo extensions weren't always solid textureable blocks, but had preset models. The new "cargo pallet" designs are cool but I was disappointed I could not use them as cargo extension blocks. What if all cargo blocks simply had a checkbox you could enable, which would make them function as extension blocks while still keeping their appearance? That way you can make stacks of boxes or pallets but have them function as one block (if adjacent to a cargo controller). Lack of automation, and lack of multiple inputs/outputs for constructors, make the new cargo storage system a disorganized mess. If the new way of doing things is going to be to have one gigantic cargo box, can you give us better tools to organize stuff inside that box? Maybe sections or tabs inside of it, where we can designate what kind of items go into each area. Better would be to support multiple inputs, so people can sort materials (e.g. this box has iron ore, this box has stone dust, etc.) and the constructor can pull from all of them.
Agreed. CEs should not consume either power or CPU, as they're useless without a CC. And CCs should only consume power (aside from a very little bit of idle power) and CPU when transferring material, in proportion to the mass being transferred and the transfer distance. That sounds like a bug, as cargo mass is supposed to be evenly distributed between all CEs in an array.
I only recently noticed there's a known issue that putting mass inside of other types of containers (fridges, ammo boxes) does not weigh down the vessel. That may have been why the mass was off-center, because I had those on the other side of my HV and had equal weight in them as a test. But if they were counting as 0, that would explain it.
Oh boy is this correct. Never expect people to read the forum. Expect them to find something diffrent on a release. Then do a rage quit when they dont understand it. An update page is good community management. The moderators here will love an in game update page. Even a link to the forum would be good. This one of the few things space engineers got right when things started to go down in the community. Now on with the real topic. Logistics seems to be working just fine for me. Even with volume testing mode on. Existing base designs fully functional. I guess this was just too big a change for people. A basic sort would would be a huge improvement. I suspect this is point that people are sticking on. Big containers always get messy without a sort button. The only real problem I have is power seems unbalanced. Also agree with that thought. I would not go for a scale based on mass transferred and transfer distance. Too much code right now but a good concept. I would just lower the base power for now and revisit this in a later sprint.
Once I had gotten over the initial confusion on requiring a specific controller for extensions, and that the original containers were treated separately, I quite like the new system. I do welcome the ability to create structural storage for when the build envelope is restricted. Some additional shapes in line with the current "Regular" blocks would be nice. There do seem to be a few usability problems however. With the original containers, they can be accessed from all sides, but the extended system only allows access via the single block controller. This may be some considerable distance, or not immediately accessible from the player location, and leaves only the control panel (if faction available) for access. Perhaps we need some "Access" blocks in addition to the controllers, or simply allow access to the container from all connected extensions? A simple example: A 1x1x2 original container can traverse a 2 block thick wall or bulkhead and be accessible from both sides of the divide. The new system only allows access from one side. For more complex arrangements, it can mean a long trip or a search through the devices simply to open the inventory. A further observation is that it is difficult to visualise how the extensions are connected to the controller, or indeed which controller any given extension is connected. If the connected extensions could be highlighted (as a debug option maybe?) then builds that use complex layouts would be easier to manage. Examples of this are not being able to place an extension because it would bridge two separate controller/storage groups, or not being able to place a controller because it would connect to another group. Feedback is given for the controller placement, but it can be difficult to identify the offending block(s). No feedback is given for an extension block at all, and they simply refuse to be placed. This problem is made worse if the extension blocks have been re-textured making them difficult to distinguish from regular blocks.
