Honestly, i think its stupid to build 5 different CV's just to do basic needs. need Saithum for that Advanced Constructor? well need a CV and 30 Pentax. gosh the resource cost alone is insane.... Again, Grind, grind....grind.........grind... Gosh thats beyond boring, if i wanted a Work Simulator, id go to work IRL and get paid in usable Currency... We play videogames to get AWAY from reality and enjoy functionality and diversity of reality outside of our own. Because life is complicated, and repetitive.... So why such repetitivity in a VIDEO GAME... Should rename this SPACE SURVIVAL WORK SIMULATOR! in that regard lol Back to the point, Specialised ships in PVP is useful, but in PVE its super super super nonsense. - I think we should be able to do both, logically. IE: I usually play with Jrandall's "Nomad-ST" and later Trig's "(CV)-Industry"[and my heavier variety of this ship], They provide a good all-around ship for general use. Which is quite detrimental for long-term PVE play. - Honestly, i doubt at this rate they will be useful in the future of this Weight Debate because there "Too Big"... PVP/FPS isnt the only focus of this game... and a Work Simulator shouldn't be either.
I provided a Scientific and Factual explanation to each point... Its impossible to say "Space Sim from 2402" and "2000 bags of Concrete Stopped my Hover Craft dead" without thinking there is something wrong with game mechanics.... Im all for mass if done right, and its not... This is a Total Bethesda level mistake. The game /WAS/ Balanced before, it depended on your play style in how it affected you. If all your worried about is PvP easy, add mass LIMITS to ships and item count LIMITS to players... problem solved. But for PVE, which is all i play(and from what i see Online, what most play), for the fun experience of a Creative Space Survival Game. This is all just pipedreams, right now. Again, it is alpha, but none of us expect a game-breaking "Update" that wasnt finished with the testing phase before being implemented. Any other software industry doesnt usually do this. - I mean is 9.0.x supposed to be stable? because i cant find one new implementation thats fleshed out in a function way (and i just tried 9.0.2 hoping some undocumented change fixed some of its VERY broken problems) 2 problems, 1: its 2402, WHY ARE WE TALKING ABOUT PHYSICALLY MOVING OBJECTS THAT WEIGH OVER A TON... Everything is ENERGY... your body is a stack of celluar data that with proper understanding and development of technology, can be broken down into atoms, stored with a index of data, and stored as ENERGY... And we are still talking about moving objects around through the sky like invisible drones are moving it??? 2: Why are we even talking wifi... Wifi as a implementation is broken as it is. 100m is a joke in reality today, in 2402 it would be equivilant to smoke signals today (something used less than 170 years ago as actual form of communication). we are talking nearly 400 years into the future, and were still using a broken IEEE standard that was only adopted due to consumer complaints and a security nightmare... What about Subspace? ultra-lowband compressed data streams capable of carrying vastly compressed data over vastly long distances in a instant. That makes more sense.... but then again, store that data in a Pentax powered backpack with Constructor and this mass issue is gone again (see my point... makes no sense) Its not a Object Simulator, Its a Space Simulator. How do you plan on simulating a Artillery Cannon in the available physical space. This isnt Diablo, the storage system would be full with just CV/BA blocks alone due to there physical space. I often modify my builds in-survival. because, it makes no sense to make a new ship every few hours when a new problem arises or /no one updates there BP's for releases as its too time consuming/ Let me ask you something, IRL now, or IRL in 2402, because i imagine in 2402 AI enabled automation would render even this conversation useless. Im all for automation, but when i put something in my "BackPack" what im doing is saying "I want to decide what to do with it; or im in a rush." now, where Logistics is useful is when its a planned action of automation. "I want all drilled items, at this X/Y loc, to go in cargo-box2" Thats what is "Logistical" about it. its a planned action. sometimes, being logistic doesnt make any sense. "i need to pick up as much pentax as fast as possible, before i have to get ready for work in 30m.; Ooop, i cant, i have to re-set up logistics window every time i pick up one." Again, what are you talking about, all data storage IRL for the game is done in memory registers. even if they optimised how to store data it all gets set to a group of memory registers and then forwarded to external storage (IE; the save file) If your talking in game, that's automation... When you do a action, and script a result, it /automatically/ performs a set action. Which we had already. i walk up to a constructor, put in the required basic mats, and queue up the build requirements, then the objects i wish to build, in order to speed up multiple-object building (IE: steel plates for ammunition). As soon as i do the 4 actions required for that, that took me 30s, i walk over to my food processor, which already has all the components i need stored and queued up 200 cans of Canned Vegetables, to carry on my long journey... I have a input, a scripted process, and a expected result. - Now to do all that i have to pick inputs sources (and fight to make sure my items from my inventory made it there without disappearing...) and outputs(which easily overflow if were talking about food). Not to mention, we can only use one constructor or food processor at a time? i mean, if you want me to waste time for some reason, this is not worth it. A game progression in a Creative Environment is not mapped by time spent doing a single task... its mapped by the amount of unique experiences that occur. --- Sorry for getting a bit off topic and onto logistics again. it just came up again.
Umm... WE EACH PLAY IN OUR OWN WAY... otherwise there would be no reason to leave the planet, just give you a survival constructor, on a arid planet with no O2, and say "Have Fun"... ITS A GAME, not reality. You want to play Rust, go play rust. This is about Creative Choice... Otherwise there would be no reason to build ANYTHING in survival. you would just be carrying stuff, and shoving it in containers to build BP's and shooting things... whats the point in that. You could "beat" that game in 11m, just buy building a HV BP, and being done. This game has shown us since 4.x (AS THE OFFICIAL TRAILER SAYS), its all about the Creative Freedom. Where is creative "Freedom" in your idea of Survival. Its a strict set of reality breaking ideas. Also ill repeat this one last time. 2402, not 2018, not 1952, not 1838. There is no pulleys, no drones magically lifting your stuff. Its being transported instantly from one point to another. If it wasnt, not only would taking a 70ton Turret take HOURS, it would be impossible to keep in place during flight... breaking CV's all together... Its a game, Have Fun, Mine Things, Shoot things, Have some restrictions to make it more challenging. But dont suggest that we want to all play hardcore all the time.
My statement that you quoted in no way implied that everyone should be forced to play with all mechanics activated. Further down in that post, I laid out how I'd like to see the various game modes develop. Based on that, I'd argue that if you didn't want the full hardcore survival experience, you'd choose Freedom Mode, and disable the game mechanics you didn't want to play with, thereby obtaining the gameplay that you would find enjoyable (which could even include disabling blueprints, if you so chose). Also, moving massive objects quickly is largely a matter of having enough energy available and being able to channel that energy at a high rate in a useful manner. With the right equipment (say a swarm of drones with powerful thrusters or a swarm of nanobots that disassemble the item and reassemble it somewhere else), moving a 70-ton artillery piece quickly is a straightforward process. Due to performance constraints, rendering the actual method of transportation is probably out of the question at present, so all we have in the meantime are a series of possible techofluff explanations for how it might be happening. You can rightly object that there's no energy being expended (right now, at least), and even if there were, it would be orders of magnitude too small to actually do the job as quickly as it's apparently being done. And you'd be right; however, the devs have evidently chosen not to pursue even remotely realistic power values for any high power equipment (thrusters, constructors, energy weapons, warp drives, etc.); little to no energy being spent for moving material around between inventories falls into that same category.
I'm certainly not going to defend the devs' release schedule. They were warned by the CA testers that none of this was ready for experimental, let alone a full release. If it'd been me, there wouldn't have been an experimental release until at least the new year, given the magnitude of the changes, and the numerous things that need to be done correctly for all of this to succeed. Sure, you could convert matter to pure energy for transport; it'd certainly allow for instantaneous transfers over distances much shorter than a light-second. The only problem would be that the beam of (presumably) photons that you'd be sending would contain about 90 PJ (21 megaton equivalent) per kilogram of mass. At that point, that's not just a matter transfer technology, that's a weapon of mass destruction. Now, if instead you mean some kind of Star Trek-like transporter technology wherein an object is scanned for its pattern (probably down to the quantum level) and then said pattern is what's actually transferred, well, that doesn't actually solve the mass transfer problem; you'll still need to somehow get all of the appropriate particles to the destination in order to reassemble the object. I agree that the devs' choice of "wifi" as the terminology for the remote access/transfer portion of the logistics system was not a great one. Better would have been to simply refer to it as a network and avoid specifying anything about the underlying protocol. As far as storing large blocks is concerned, I've always thought it reasonable that blocks and devices could be made to fold or collapse given how little matter is actually in them. We already have IRL examples of structures that can be cleverly folded flat for storage (deployable solar panels on spacecraft and the humble cardboard box), so it's not much of a stretch to apply that to more complex objects (especially with 25th century technology as you keep mentioning). Let objects be collapsed to solid density, and suddenly they don't take up nearly so much space; a 1 ton CV/BA steel block collapses nicely to ~128 L for example. As far as modifying builds in survival is concerned, yes, I do that too. However, I remain hopeful that at some point we will get a physical factory block that has the ability to modify an existing ship according to a new blueprint (basically, it would do a diff of the two designs and perform the work needed to transform one into the other, consuming appropriate resources in the process). Depending on advances in AI, potentially. And I agree that the logistics interface leaves much to be desired (one of the main reasons there shouldn't been a release so quickly), and that it forces new patterns to be learned to accomplish tasks that used to be simpler. A properly designed and implemented interface would generally stay out of your way, in my opinion; unfortunately that's not yet possible due to a variety of deficiencies in the implementation of both the logistics system itself (the mess that is toolbars and the concurrent access issue both come to mind) and its interface. That wasn't my point, though. The issue isn't where physically data resides on a player's computer, but how it's accessed by various in-game objects. One of the big problems right now with the logistics system is that any time an entity wants to interact with an inventory, it locks access to that inventory until it's finished using it, which blocks all other entities from interacting with it during that time. The better architecture that I proposed was that each inventory basically has a queue that entities can submit requests of various kinds to, and the inventory controller notifies each entity after its respective transaction has been completed; in the meantime, the inventory remains viewable by all. This would take care of the concurrent access problem which currently plagues the system and is responsible for, among other things, the lock icons in the constructor interface (and the inability to manipulate items in inventories from the constructor), and the fact that two players can't look at the same container at the same time. The logistics system currently lacks the signal logic tie-ins that would enable proper automation (setting input and output containers, and the recipe to build in constructors, for example). The system also lacks the ability to use multiple storage arrays (up to, and including all the storage on a structure) as a single input or output. So, once again, the logistics system is lacking important features and shouldn't have been released yet.
I'm worrying about how my SP mid-game playstyle would now look like: Let's say that weight may be rebalanced in some way (which probably shouldn't strictly follow current recipe since something like Laser rifle would be incredibly heavy and CV's thruster would have much less than 1/10 of its former weight) and my CV becomes 15-25k tons of weight. She requires all metal types existing in the game, and around 3-4k each too. To build her, I'll still need a mean of transporting 10k tons of metals from other planets while also have to be space and combat worthy at the same time (for POI's drops like CV thruster XL and many fodder that will save me from waiting 24hr until the ship is completed). Being a mid-game player from A8, first I'd probably look for a way to make a SV cargo ship, but even a dedicated one that can load itself to 1k tons, not excluding its own weight, would need a minimum downward thrust of 20MN for 2g planets, translated into 58 thruster jet S (the best thrust per dimension) just for one side. Not to mention its combat prowess is also virtually zero. Keep investing on SV might be a poor choice. That leads to the second choice of building a freighter CV with combat SV/HV aboard. Freighter that can load herself to 13k tons would need 260MN downward thrust on 2g planet, which equals 13 thrusters M (or 2 thrusters L, if rare metal from POI fodders is adequate). Seems morally acceptable that I don't need to turn my design into a swiss cheese. This freighter would probably weight like 5k tons (even less with some rebalancing), so a bit less painful to build than intended CV. But the whole concept of specializing vessels also means that before completing the freighter, I have to bust POIs/survey the area with combat HV/SV → return home → bring cargo variant of those HV/SV to the POI/deposit → transported and secured at the base (may even have to repeat this multiple time just for one POI) → rinse & repeat for other POIs → put in a factory and build a freighter. (I've seen someone wrote like this before but seems to can't find and quote it.) After that, it's still the same whole process, adding another option to move an entire CV to the POI/deposit and planets with rare metals. Roughly speaking; It'd become less exploring, more truck driving and more grinding for logistic vessels and fuel (to have a reasonable mean of building competent CV compared to A8. New players may find sticking to few familiar places longer acceptable?) On the bright side, though, freighter type ship may see more popularity in the workshop and allow creators to have new projects to work with. Saying more would be pure rant, but I simply have to stop playing after feeling too uncomfortable to design or update any blueprint for survival game since volumn/weight are bound to be polished/balanced (which hasn't been done properly prior to release and might even break several pre-A9 workshop blueprints). And I have to refuse to edit it in post, especially in survival mode with weird inertia in drone control. The weight/volumn limit can be a welcome change, and I do like the idea that ship types like oilers and combat support ships may become more relevant. The increased tediousness should, however, have its remedy planned. Players shouldn't be confused whether they're playing Empyrion or truck simulator by assuming the role of the driver by themselves every time. Maybe they can assign their unmanned logistic vessel to follow them to the site or call it remotely and transport goods back to the base by itself on the route the player has planned? Fleet system? I'm very looking forward to seeing how would automation turns out. Hopefully, it'll only be a definite break for myself to step back and keep observing the direction Empyrion would go.
Well i actually don't think it is bad to have options regardless of the mode you play. I actually don't see a single problem in having a survival mode were you can choose what systems and to what extent you actually want to play with. Makes things more user friendly and the game more accessible to a wider audience.
No, I died twice to suffocation before I got lvl3+constructor, but food was relatively easy to get and always spoils before I have chance to eat it all( That must have been one very unfortunate landing. What planet? If it was Temperate, then lake is good source of food by itself (and it really should have been covered by tutorial), if it was Arid, then it likely intended since arid isn't meant to be easy, and I think you should have died of heat before hunger. Either way 'day' amount of food takes only couple points of volume unless you are running all time and without using jetpack. Well, I do agree that prefabs need an update, but: 1. I meant it more as an example, that it is possible to make cheap&usable HV in 2 trips. Enclosed cabin is as cheap as closed one. And there are such vehicles in workshop. 2. Prefabs are more of an example at this point (and modifiability is far more important for them, not all of them easy to modify unfortuantely). 3. I actually spawned tier 0 prefab HV and just added 3 1x2 containers instead of truss block, vehicle worked fine as temporary ore transport. Lacking environment protection is indeed an issue (now that I think about it, I really should have spawned something like Wisp-ST this time around, temperature is harsh), but tier0 HV still wins over bike and worked fine for me to get a better start on resources. And you don't need much of environment protection on Temperate planet, prefabs not working as well for Arid is probably unintended benefit - build/find your own vessels). Also I ended up keeping close to water and jumping into water each time I overheat. And why that is important for first HV? Personaly mine was meant for ore/wood transportation, there were no enemies near deposites highlighted by tutorial (aka near tutorial's wreck) And how does that matters? It is a sandbox game! If you don't like something, change it. P.S. I added containers, sensor isn't that expensive as well (and I don't remember survival constructor providing HV one, so I added none), neither I had sufficient level for constructor (on Hard levels are a problem), I was level 4 when i spawned it. 1. They fixed volume of ores somewhat, now inventory can fit more ores (in 9.0.0 it was barely 30 units, now it is 100) 2. All volumes are placeholders 3. They seems to be fixing F interaction to be more like in A8 (at least player's inventory now opens at left)
I mean, I guess that makes sense. In which case, we don't really need Freedom Mode if Survival Mode is going to be completely configurable (unless Freedom Mode is intended as a convenient shortcut to a more forgiving set of game settings).
You have very good points regarding the consequences, and I agree with you. That said, currently we are used to simply hoard resources and build a massive CV right away. Since a CV is THE vessel of the game, it certainly should be quite the undertaking to build a huge (not starter CV) one, no? Also, I recall Hummel saying something about a "shipyard" being considered, so the Logistics system when paired with Automation would neatly deal with the "weight problem" regarding the larger builds. That being said, and repeating myself even, Weight should be shelved for a later date. It should be implemented ONLY alongside with other systems, like this shipyard concept and the complete overhaul of the game. Weight NEEDS to happen, but now is simply not the right time for it! Now, to the general public: calm down and think rationally; we are used to simply play Survival as it were Creative with the possibility of dying - and with almost ZERO consequences. Doing big projects SHOULD be costly, in terms of time, logistics, materials and everything! Not only that, but since you can build any tipe of vessel in a freeform manner, devs simply have no way of manually defining these vessel's stats. So either they take the No Man's Sky approach and make every vessel class behave the same, or they simply use rules to dynamically govern a vessels behavior. In this case, the "rules" are simple Physics, and Weight should be part of those rules. No way around that, this is non-negotiable. Now, to WHAT extent weight plays a role, that's just numbers and consequently trivial to deal with. Still unhappy? Creative mode is always there.
Could you explain why and how the design team envisions the mass and volume of item limitations are going to work together with the new additional resource "CPU capacity" to improve the game? (this later seems to be getting almost no play but it is potentially very important). I'm assuming that implementing it for its own sake is not the reason its being implemented. I have a few areas that I hope implementing volume/mass and cpu constraints effect. The most obvious is End game: these additional limitations ought to drive diversity of ships. ie - it shouldn't be possible to have a nimble/fast moving extremely armored and armed ship that can fire virtually infinite salvos... . What other areas to you/the designers see this as improving the game? I'm asking because right now it feels like its a mess (and your opening post acknowledges this) so in thinking about it/how its implemented it would be helpful to understand the vision.
I remember back in Alpha 2 having to manually create components to make objects in a constructor. Then automation in constructors was implemented. There were a lot of bugs at first like duplicate materials, missing items, etc. Eventually the bugs got ironed out and nobody even talks about it anymore. I expect the same will be with volume/mass/CPU and continued automation. When we are looking at the initial implementations we tend to miss what the potential will be. Anyone remember the first implementation of the Control Panel? It has come a long way and added a lot of beneficial features. Features that now nobody even talks about. Give it time before complaining that this is unnecessary or unwanted. To the talk about the physics simulation and having mass be an issue for carrying objects around: Shut it already. Items that are too bulky/heavy should not be carried without assistance. This was true in the 1800s, now and will still be true in the 25th century. If the tech level imagined is capable of transferring matter into energy and reconstituting it elsewhere and is readily available after getting out of your escape pod then there wouldn't be a point to playing this game realistically. The point of this game first and foremost is survival and adventure. Secondarily (for some primarily) it is also a sandbox game with incredible minecraft-like design capability in terms of vehicles and bases. Tertiary (but still important) it is a simulation game (Flight Sim and Life Sim). Physics plays a big role in each of those types. Trying to say it shouldn't be there because gameplay/technology level is silly. It should be there and will be there and what it is now is nowhere near what it will end up being in a few version iterations. What I think the direction of this is heading toward is a variability in the second aspect of the game (sandbox) which will ultimately lead to a much larger variability in play style. In every singly playthrough from Alpha 2 to Alpha 8 I primarily used the same sequence of play: Try not to die while getting stuff, make a crappy HV, get stuff, make a crappy SV, go to space, get stuff, make a crappy/semi-crappy base, get stuff, make midgrade SV, assault POIs, get stuff, make a CV capable of carrying new and better HV and SV, go to other planets, Assault more POIs (don't bother building base, CV is just as good and mobile), get stuff, build "endgame" SV and "POI assault" HV, assault more POI's, get bored, play MP or play a different game. Now, I must consider logistics. Now I must consider distance between resources. Now I must consider multiple bases and different types of vehicles for different types of missions. Now I must consider leaving things behind in POI's because it will not be worth it to try to haul it out (assuming I cant just feed it to my ever-present blueprint factory). I like it. For the first time in a while I'm excited to see what Eleon comes up with and play the game in a very new and different way. One that requires a lot more thought and has potential to reward those that pay attention to these details.
Quite frankly, not liking the limitations of weight and SU at all. The combination of the two is clunky, painfully labor intensive to make even the most rudimentary bases, and turns a mining expedition into a multi trip effort for even small nodes, making single player survival painfully tedious, unfun, and dangerous with the frequent attacks by spider packs and randomly aggro "peaceful" creatures such as inexplicably angry pangolins and alien insects. But the BIGGEST hurdle is that it makes the start of a new game even MORE of a hassle. With all the things you have to carry you have no room to keep even a fraction of the ores you pick up mining random rocks, crushed stone included. It makes the early game even longer. Intolerably so. There are a lot of interesting features that have been added to make the game more interesting since I started playing. Enemies being able to shoot higher than eye level. POI's with various security measures as death traps. NPC vessels that shoot back at you if you want to subdue/loot them. Increased variety of wildlife. Factions in the NPCs. Armor. There are features I've learned to tolerate- barely, in some cases- that I don't particularly like, such as HV weapons being deactivated while docked since you guys wanted to impose a block limit on weapons. This... I'm hoping you guys permanently make this optional during game creation because this is too much realism. I don't want to require multiplayer to be able to leave the starter planet inside of six months play time. I don't want to have to stretch a four hour labor to get into orbit to over a hundred, since I'm going through steel and copper like water replacing ammo used each trip from my base to anything more distant than a kilometer- which, on the large planets, is virtually everything. My opinion of this is that it's a BAD addition to the game. But there are people who like dwarf fortress, so I guess there's people who like this too. If you don't make this optional, you're going to lose a huge chunk of not only your current playerbase, but an even larger chunk of your future buyers, because if absolute realism was fun nobody would play video games.
Honestly, I feel like "Freedom Mode" is just creative atm, with some planetary interaction. Beyond that, makes no sense. there is literally no "options" at this point and all it does is the same thing as creative, with NPC's & world generation. While i get what your trying to say, they way it was done before makes more sense. You choose SP, MP or CM, you choose your Scenario, You choose your Difficulty, then your Starting Location. - Then away you go. Works the same in MP, you still choose a server based on what fits what you want to play. So why so much "Hardmode" "Freedom Mode" "Creative Mode" "Multiplayer" - I mean its not designed specifically for all the options. Litterally difficulty settings only effect things like NPC spawn rate, Ore Availability, O2/Food/Rad rate. it would make sense to just add Mass & Volume to this list as it literally is a "Difficulty Option". Because it plays no other role, other then to increase difficulty and provide another challenge. (And make you endlessly grind your life away with 1000 trips for simple things) I personally don't see the benefit to the system, so i would gladly play survival like A8, with it off. But, thats my point. i dont want a mode Specifically for a difficulty setting. That's just silly.
After playing with it a while, and reading others' comments, I have come to mostly agree. I think having mass affect handling of vehicles is OK. Cargo mass gives you a reason to build bigger ships with more thrusters. This, by itself, is a change I can live with. I think it would be OK to limit player inventory by mass. Previously, it was by slots. Now, it is by volume, which I do not like. I would prefer there was a limit on how much mass I can carry, and possibly I can exceed it, at the cost of walking slower and not being able to jump or run. (Basically, an over-encumbrance penalty.) I think volume is unrealistic and unnecessary. I said some of this in the experimental thread already, but will restate it: Players do not actually have a volume limit, they have a weight limit. Your items aren't all in a pack, or box. You're carrying some of them in your hand, others are strapped to your belt. How can you model the maximum "volume" that you can carry, when items aren't even in a container? Your "backpack" is just a proxy for how to recover your stuff. It is not all in a backpack, your armor and weapons are in your hand. Volume limits for ships will require huge redesigns to make them much larger to haul anything. You can argue this is "more realistic" but is it? In reality I don't have to pack stuff into boxes to transport it. I can leave it on the floor of the hangar, leaned up against the wall, laying in a walkway, stacked onto a passenger seat. There's tons of open space we could be placing stuff into. But we aren't allowed to actually lay items around this space. Volume limits for bases are pointless. In any base on the ground you can put a staircase or elevator down, and then add as many cargo extensions as you want, below ground. There's no real limit on storage size, and these extensions don't even need to be accessible, only the controller does. Thus, mass/volume limits for bases are largely irrelevant. Volume is a hard limit, whereas mass is more of a soft limit - the more mass you have the more it slows you down. Thus implementing mass does not take away freedom in the same way as volume does. If you're going to implement volume in the name of "realism" then there's a few more things to consider: The player should have more "containers" you can fill with stuff - backpack, pockets, pouches, belt, etc. Can you get drones to carry more stuff? Can the motorcycle carry stuff? Can I lay items down on the floor or ground and leave them there? For example can I put a big pile of ore on the floor of a hangar? Can certain items be disassembled/folded to smaller size? Can I get a little wagon or cart I can drag behind me to carry more stuff? Or maybe push carts? Can we get ropes to tie stuff onto the outside of an HV or ship? Can we get a trailer hitch so we can link/unlink vehicles, sort of like a trailer or train? Can we get movable cargo boxes that we can pick up and move around? Maybe a forklift to move them around? If you implement only mass restrictions then most of these would't matter because it is really volume restrictions that make them useful.
Yes, you could pack stuff into devices that appear to be smaller than a block. That actually wouldn't be all that difficult to implement at a simplistic level: just give most items an appropriate VolumeCapacity and a visual overlay of piles of stuff when there's something in the inventory. For empty hallways, you could do something similar with a cargo block that would be normally transparent until you added something to its inventory and then piles of stuff would appear. Make these latter "containers" free to place, and make all of these makeshift containers inaccessible via the logistics system, and then you really could haphazardly pile stuff in every available nook and cranny of your ship. What you'd quickly find, though, is that finding and unloading stuff would be a nightmare without direct access to the logistics system (you could still use the logistics system by walking up to each makeshift storage block and opening it, but you'd have to do it for every single one of them). You might find that the hassle of managing dozens (or hundreds, even) of containers without a direct logistics connection might be more trouble than it's worth (on the other hand, perhaps not).
Something I'd like to point out that's going to need addressed as part of the whole volume/mass implementation is docked vessel mass transfer/connection. As it stands now, when docking a HV or SV to a CV, the mass of the HV/SV isn't transferred to the CV. This can sorta be exploited / taken advantage of by building 'cargobox' HV's and putting stuff with the highest mass in those, and just keeping the HV docked. (and while you're at it if the docking system could be improved to allow HV <-> SV docking you could please A LOT of people) Also I really like these ideas: (i'm currently building a HV Train locomotive to pull a string of these cargobox hv's and some form of flexible connection would be awesome)
Yep, we need a proper docking system that consistently handles the properties of a chain of docked entities. I wonder how well flexible stretchable connections would work between grids. It'd be pretty nifty to have, certainly (though some care would have to be taken; these connections would definitely need a maximum strength rating as well as a nonzero unstretched length, otherwise we'd get some weird physics. . .)
I suspect that it may have an important part in true differentiation of logistic ships and combat ships. Continued from my thought process for my mid-game logistics where I want an effective mean of transporting materials equivalent in weight to the contemporary missile cruiser, those logistic ships able to carry weight a couple folds beyond their own weight (even more for dedicated SV) would still have more than enough thrust to spare for more armor, more weaponry, or effective maneuverability at empty load. In other words, logistic ships can also be very combat worthy in itself due to their massive thrust. (Ofc, if loading mass isn't included in maneuverability calculation, this issue would be no more.) So CPU limit may have its role in this. It'll remain to be seen, however, how could CPU limits armoring in particular or necessitate the allocation of resource to either logistic worth or combat prowess. Too extreme of thrust limit will leads to logistic ships who also needs to spare CPU for their CC/CE rendered worthless right away. Too extreme of weapon limit also means too little of both armor and maneuverability, to the point of imbalance. Too extreme liimit of both will severely hamper creativity in vessel designs, and so on. CPU limit implementation must be done very carefully. Currently, only the core provides 7500 CPU, which is very restrictive considering my own design of size class 5 CV (only 120m in length) and not even fully decked or truly armored (only 2 combat steel)/maneuverable (not really distinguishable for a destroyer type warship) has CPU 0f 20k, far exceeding the limit. And it won't even be appeal enough for PvP scenario. without proper calibration, even a half good CV won't even pass the CPU limit. To add this up, a certain limit called "Size class limit (on different server)" already has my hand full trying to create a combat worthy CV that has an acceptable interior/exterior look, facility, and still within most server's limit for accessibility. Less true for SV/HV to me, however, limited by their weak engines to be built big anyway. If an creator can still combine features for combat, logistics, and aesthetics after all other limits like volume and weight then their skill is quite impressive already. Do they need more burden when it comes to designing? Does such creativity needs to be hard-limited?
Yes, technically you could refit a cargo ship into a combat ship by adding armor plating and weapons (both of which will reduce the max acceleration of the ship when fully loaded). And yes, a combat ship could serve as a cargo ship in a pinch (though with greatly reduced ammo capacity). CPU is very unlikely to be hard-limited; I expect that the devs simply haven't yet introduced the device(s) that will increase the CPU available to a ship.
