That's a good point. Correct me if I'm wrong, but it seems that with the BA constructor you need containers (input/output) to build containers, and this process have to be kickstarted with another source of containers. There shouldn't be a catch-22 like that. Solution: give the constructor a small backup inventory (input/output source "Constructor <self>") or let it draw from player inventory directly so that it can rebuild the infrastructure by itself. The later would be an incentive for new players to look into the logistics - don't want to stand here all day while it works? Use the dedicated input/output.
I understand your point, but do I feel this is about making the logistics feature, more workable than it currently is, given the large number of complaints about complexity. Which in conjunction with the other suggestions around UI etc is needed to turn the current feature set into a more agreeable trade off for players. There have got to be some more "wins" on the player usability side from this feature set, to maintain the balance.
That's the saddest Arguments since Logistic was announced... Think once again...Building a Base from a HV...Place Starter Block lay out some Floor...put a Container on the Floor and fill it with stuff for Building...while you are building the HV-Constructor transfers built stuff directly to the Container...if something runs out you have to refill the cargobox from where your Constructor is drawing material. To @Ranger_Ric point...You click eventually one more time than earlier...imagine producing ammo.. old version - all mats into the C, production, TAKE IT OUT - transfer it manually OR by CP to its destination... new version - One Box that has all the Mats - production - oh, it lands directly in my chosen Ammo Box, if chosen correctly before started production - Big Deal!
I actually agree that the Advance constructors should also have an in built cargo box/container. This would still need to be access via the drop down menus, so would be compatible with the new logistics system (it could be the default in and out box). The real upside to this is that it would allow all of the current scenario and workshop builds still function and permit the use of the logistics system (a win win scenario).
There it is! That's a HUD element needed to unify the inventory/toolbar player/logistics mode switching. It should probably always be active, showing the player or container fill progress depending on which is the selected toolbar/inventory.
This is a good point for @Ranger_Ric to consider, in line with what I was referencing for long-term efficiency, yes. It doesn't change his point about new (or perhaps especially some experienced) players likely seeing the Portable->Large transition as less convenient due to the lack of internal inventory and shared UI. You really have to use the system for a while and transfer lots of stuff before it clicks for some people: Bypassing the player's inventory entirely saves a transfer every single time you move stuff around. @Hummel-o-War Neat, simple feature request- In the Constructor / Food processor / Etc. UI, you could add a dropdown for all other devices of that same type, for quickly switching between them and assigning parallel jobs! Edit: Wait, how would this avoid locking the control panel? ...How do the input/output cargo container dropdowns avoid locking the control panel? Hmmmm...
I agree with this, this as been along requested feature in the game & I know for a fact that a lot of people have been requesting this to be added. The point of buying a game in Alpha is we the user help shape its development. Alright sometimes you may not agree with the way the game is going. For example: I’m not too happy with the logistics system as it stands. I think it’s too complicated & I vented about it as you can see from some of my previous posts. But you’ve got to remember that features of the game are still growing & so is the game. So when you buy the game in Alpha. You not only do the buy the game, but also the bugs and responsibility to report your feelings on any features, which in turn helps to shape the game itself. In a weird way Empyrion isn’t only the child of Eleon Studios, but it’s a child of everyone who makes comments and suggestions on these forums. "Even if sometimes we get a little annoyed."
The forum poll could be influenced/manipulated by fake forum accounts. I just look the real customers, steam reviews (each review tied to a serial number) and the game isnt going well with the addition of clunky and unnecessary logistic. There Will be a real disaster with volume.
What about(and that has probably been suggested befor) a new DropVessel Type of Ship. A ship that gets bonuses for going down/up(making specialized Thrusters for that) Both SV ans HV can dock to it ; how about that?
What most people don't understand is, that this system, is extremly Important for the Automation Feature(if it comes, but then again why wouldn't it, since we've semi Logistics in the Game). The most optimal Outcome(IMO) would be, we can program a Constructor for something specific, like say produceing only Steel Blocks on repeat, taking mats from an Centralized Raw Resources/Ingot Container and pushing the finished Product into a Output Container in your Hanagar, where you can just load it onto your Construction Ship. Another thing that goes hand in hand with this, is the ability to read the Contents of a specific Container and being able to output a Signal based on the readings. This would allow us to have completly Automated Factorys producing all the Stuff we need for Building while you chill out/plan out your next Building/Ship. But thats gonna be a long way and i can't wait to be there EDIT: Geostar1024 allready said something like this:
@geostar1024 "64-item-type limit and becoming scrollable and sortable" Yes...just ran into this 64 slot-item wall. It seems superfluous to have such addable volume in a cargo storage system if your restricted to 64 slots; with my constructor set up with an in/out container controller and container extenstions when I hit 64 full slots I have a choice of manually moving things around or … spending many resources to daisy chain CCs and constructors, which is not practical in early game play. If I need to convert one type of material into another type/item and then have the results deposited into the same input container for the constructor then input and output need to be the same container. Otherwise it's all manual switching around from container to container, which is easier now but kind of defeats the idea of doing things with less clicks. Volume with the use of the container extention is not a problem; but when output of the constructor hits 64 slots everything stops. If 64 slots are to be the norm then I'm hoping for the possibility of an overflow feature - where a ship or base has X amount of storage and when the designated CC slots are full it outputs to the next CC listed in the control panel, or some such. Hopefully reducing/eliminating this bottle neck is in the works.
Ideally, we'd have a system for chaining constructors together and buffering intermediates, so you could have 3 boxes and 2 constructors with the first one programmed to keep the intermediate box stocked...but now we're getting into automation again. Granted, early game you would want to control crafting very carefully, but at that point you're far less likely to fill the slot count anyway--so a single-box loop-back system is fine.
I do like this idea. It would be nice if we had more types of ships. Example, Carrier, Battleships, Cruiser, Destroyer, etc. Opps, perhaps I’m thinking about another game!
A proper docking system would be a much better solution; we don't need more ship types (arguably, we need fewer, as SVs and HVs really should be merged). A larger selection of thrusters would take care of the rest.
I think the main reason that I like the new logistics system is that it compliments how I had ended up playing before. I rarely accessed containers directly, and tucked constructors away in the basement. I accessed almost everything through the Control Panel. The logistic system makes that so much easier . . . mostly. Unless I missed a trick, there still isn't any way to access constructors/food processors/etc other than 1) direct interaction or 2) via the Control Panel -> Devices. To make the logistics system more comprehensive and consistent (and as another step toward automation), there needs to be an easy way to access these devices. Another option would be to make a consolidated production screen. Why do you need to know which machine is making which item? As you add different devices, more recipes are added to the consolidated view; and there's no reason you couldn't still assign input/output containers to each device (potentially allowing you to control what machine does what if you are so inclined). So long as the interface is easy to filter, it would simplify production and work well alongside the logistics.
I have heared alot of times, that CV's being able to land on Planets was this Workaround for the SV not being able to dock onto HV's/Other SV's. But i agree with you on the Merging Part, there is no logical or rational Explenation why i can't just slab a few more thrusters onto my HV and take off. The only limitation i could think off, is from a Coding/programming Perspectiv(and since i'm not a programmer/coder i can only really speculate). In most Discussions about Vehicles in Empyrion it usually turns out that basically no one(or near to no one) useses HV's after the first Base has been placed, and even then only as an Mining Vehicle(or sometimes as Tanks, but then again, you're better off with an SV bc of its Mobility). I like customizable Stuff, so having certain blocks in the game, that could designate a Base or Vehicle to excell at something, would add more meaning imo. With this, you could keep the base types the same(or even reduce them like with your merge) but have more meaning behind the Stuff you build. I like customizing my Vehicles/Bases beyond just asthetics(but this is getting off Topic, kinda). Maby specializing your Core to excell at defence, or productivity, being able to automatically push certain Items onto docked Ships or pull certain Items from them, that kind of thing. EDIT: Don't know(althought i kinda know, maby) what game you mean, i only played Empyrion and SE. But like i wrote up there, the base type could be the same, but you could further enhance it.
You have a point; for the average new player filling the slots would probably not happen often, but my little veteran got carried away lol... To temp fix the problem I paralleled two constructors from one input container and have the second constructor send a final product to a different output container. Still have to manually move some materials around by hand, but not as much as before. Even at that it's still as many or more clicks/menus than the old style. I'll just have to be patient while the Devs work this stuff out.
Mass and volume definitely will change that, at least. I'd rather see the specialization happen entirely through the blocks that are placed on a structure. For example, what's the difference between a CV and BA? Well, the CV has thrusters and a warp drive. In any case, I guess we're kind of drifting offtopic here . . . .
Well i would really like to texture the CE's, that would help with the Visuals a bit better. Maby you need to design your base a little bit differently(even thought with the new Logistic Window, you just have to press F4 and then get to the right Container). On Navigating the UI, how about when you open a dropdown box, you could simply use the Scroll Wheel on your mouse and once you have the right container, left click anywhere and it would switch to that container. This would help with the navigation. Like i said, the Logistic System is implemented with an automatic Off-/Onload System in mind...that is currently missing.
