Mass currently has no effect on the player yet (might change when volume/mass is properly added/integrated)
So... just PSA since I made a stupid mistake, remember to remove the # in front of the line. Otherwise it's just a comment. /smackforehead. >.<
Where? In the gamesoption.yaml? I have been trying to enable it, but it doesn't work for me. It worked in the first week of the EXP phase thought. Regardless i actually came from SE to Empyrion, beacause of Empyrions simplistic approach to ship building and Inventory handling. It was something that i wanted from SE, but that it couldn't deliver. So im not quite sure about the Volume restrictions and the added weight that will(probably) affect ships. Althought im all for Options! And this surely adds some more depth to the gameplay, escpecially to storing and transporting items.
Did you edit the scenario file? Or your savegame? If the scenario it only impacts a NEW game. If you wish to enable it in an existing game you instead need to browse to your Empyrion -Galactic survival\saves\games\gamename\ and edit the gameoptions.yaml there.
I skip consider the logistic system in 0.9, since that could be there regardless of mass/volume. As long as mass/volume is an option, I do not really care. If it got forced and no way to mod/yaml it to an option, then I might not play it anymore, along stop watching EGS content on YouTube/Twitch and similar. For me it just adds grinding, wasting time transporting stuff. An option in SP is to use "im"-H, or nomad style dump most in BluePrint Factory (ifn not that too become a grinding element). The game itself is in a fictional universe, almost nothing are "realistic" , it just have a faint resemblance of "IRL" physics and workings and looks. Also mass/volume does not follow the logic of existing technology in this sci-fi game, TELEPORT you know (and warp). You are able to create portals and travel between them, and have spawn pads too. Then that tech can be used for storage too, like a delayed transfer (in-between states) or one or more storage buildings somewhere. How else does the wireless works, or transfer to the F5 Personal drone. Or put stuff in the BluePrint Factory. Then mass+volume should not count much as stored cargo, maybe only the need for energy relative to the weight or item classification. How mass/volume will inflict issues during larger battles on MP servers (PvP), are probably not tested properly. That calculations of mass/volume when damages and changes occur, might create lag and similar issues (even if optimized). Now dev time have to go towards mass/volume balancing and functionality, prolonging main release and maybe even not get some other functionality that can make the game even more enjoyable. A lot of "good" (in my opinion) suggestions that have not been implemented yet. Since not finished yet either, then have to wait and see the end result. I have many other games I can use my time on, but for time being it is the one I play most.
I Changed #weightvolumeenabled false #blah To weightvolumeenabled true #blah But yeah, probably need to edit the game file. Too bad I didn't know that... would've saved me a couple hours in game time, and a couple more trying to figure it out! I like volume, but it needs to be visually apparent in the GUI, not a number to track. In the gui, Larger volume devices use more contiguous squares. Like DayZ or old school XCom (I think?) Make CV/BA device volume their actual size in blocks x3 for devices. Large constructor takes 2×2×3=12 gui squares. RCS takes 1x1x3 for instance. HV/SV devices use their size in blocks of GUI squares. Small items (herbs, etc..) use stacks of x number of items in 1 gui square. Larger items (motorbike) use 2 squares, so forth. For construction blocks: they get special treatment because the entire block is made up of a single material. Because of this, we use a peice of lore. Miniturization technologies have allowed the block's material to be stored in single small container (one gui square). Because devices are too complex, they cannot be stored this way. With this method, balance amounts to the storage capacity of containers, the stacking limits for small items, and the stacking limits of miniaturized blocks. Optionally, the weight can be distributed throughout the craft based on the location of containers, and the mass of the items they contain.
Sadly i tried that and when create a new SP Survival Game. Just as i clicked on the survival Option in the select screen, it threw an Quit and Mail error, so i restored the config back to its original state again. Will try to change it in one of my 9.0 saves. Thanks for the reply.
100% Interesting compromise on the blocks vs. devices. I think I prefer the idea of having an indicator bar for each item type (or stack, if stack sizes are kept in spite of enabling volume limitations), displaying its % share of the used volume of the container, but your solution has a certain mechanical charm. The main issue is that taking up more grid squares only matches volume utilization if you assume there is a single item in that location. For example: A 1x3 item would appear to take up more space than a 1x1 stack of 10 items. To make your suggestion work visually there would have to be no stacks at all, with each item taking up its own grid space in real terms. This could work, but the drawback would be a loss of summary counts and convenient transfers. "How many hull blocks are there here? I see 2 thrusters, but the rest is a sea of blocks..." Multiple inventory views (selection tabs that display the same items differently) with this being an option could be nifty though.
Wow.. well I don't have any idea why that would happen . Maybe some other error was introduced during the edit? I think there's a default file in the same folder. Maybe try a copy - rename of that and see if it works, then make the edit again? Great idea! You could even drag and drop into the summary view, and if there was a volume problem, go the graphical display to rearrange them. It could be compatible with the current split view mechanism. Just a checkbox to switch the mode on each side. However it's done, there will need to be some consideration of build blocks. No way that it's reasonable that anything smaller than a warehouse would contain 999 units of space! Lol
Just thought of a slight modification that will make this even better. Instead of making the % bar scaled so that 100% == the Filled% of the inventory, it will have even more appropriate scaling if the % is set so that 100% = the largest thing in the container, and all other bars are scaled with it. However, even with that much improved dynamic range, the issue of comparability between inventories remains, which I hadn't considered. Going so far as to remove stack sizes (and any kind of item merging at all) and using pure visual size akin to @7HzHetrodyne's suggestion would be the best way to make the two inventories easily compared, but if both inventories get so large they extend off the screen, it's probably unreasonable to have perfect visual comparison of their per-item sizing and a certain amount of mental modeling will be required.
I got it working now, seems to me that the spaces infront of the EnableVolumeWeight: true also need to be removed. Thank you very much for your help.
You know, after my post I thought about that too. I wonder if each side could operate with a zoom. The objects there are drag and drop. Basically, the same controls as the map. Also add a search, and an intellegent sort function. Couple that with an alternate tab that has the items listed with scaled bars. Double click those to locate the object on the visual display. Each item's info can be totaled for that container (mass, vol, whatever) and a tooltip can show the per-item details like it does now. Its shaping up to be a workable solution I think. It adds volume as an interesting mechanic that's doesn't have such a spreadsheet feel. And it's a unique aspect to the game, whereas now it's just another number to design against, like energy or fuel. I think its important for volume to add something fun to do with a players time aside from adding another roadblock.
Now you've done it... I may never be able to see volume as anything other than extra "status bar management" now.
That was exactly my point. It adds nothing enjoyable to the game, just another factor players need to consider, which makes everything more of a chore, while adding nothing of interest. This is exactly the opposite way from creating more options and open up ways for different playstyles. Not just that development of other things get delayed because of it. You add a interesting point, that CPU power gets even more stressed, which is something i always dislike in this game. Now there is even more reason to keep visibility/weapon range in space this rediculusly short. Additionally, with the introduction of Volume and Weight big CVs become more and more unplayable imo. Heck, why don't they remove CVs alltogether and replace them with semi-moveable BAs, that would at least clarify things and people would know what to expect in the future of this game. What about taking the opposite route and creating a game mechanic to merge big structures so they are handled as one single element, which would allow to increase the possible view/weapon range and leave resources for other things like crew mechanic for instance or other things that could be added to the game? I know this won't happen. It's a shame that with every new update, this game gets more and more uninteresting (to me), generic and unoriginal.
Pre 0.9 you could role-play and set rules for yourself (/server) to emulate mass/volume, mass blocks are still there. Mass/volume for cargo in devices creates more restrictions on how to play than without, if forced. You probably get forced early on to get a storage system, prolonging looting and resource gathering and exploration. Without it you can choose to do storage system or not, roam around nomad style or whatever before settle down and/or build a large CV. Wait, there are also NCP factions and might have to avoid certain areas too, at the start. Giving that with mass/volume you might have to build a base close to crash area, then a vessel (HV), before starting exploring and so on. Since now have become game elements, then probably will stay. Time will show what types of game play this will give. Visual nice vessels (and bases) can still be built, do not need to fill them with storage systems (and/or movement devices) that might be needed in a survival game play. Larger builds often have more than enough space to fit such though.
Something interesting about volume I've found in my hard mode games with volume is that the motor bike has become absolutely indispensable. Setting up base now consists of 2 or 3 survival constuctors, and a lot more meal / o2 management. Making the early starter HV isn't so beneficial right at the start as it used to be. I don't even tap into mines as early because it's just as easy to roam around and crack rocks. Slowing down the early game is ok with me. The mid game might not be affected so much, since it's a point where you can't farm quite as fast as you use stuff up, but late game will slow, since now you will have to develop some system of getting mats into space. I might be ok with that too, but haven't gotten that far into it yet.
The most glaring issue I see brought up in comments lately is the issue of inventory slots. Right now, a max size modular cargo container has enough volume to hold 400,000 iron ingots (on exp), but due to inventory slots, can only hold 63,936, less than 1/6th, of its total capacity: If inventory slots can't be feasibly increased due to technical limits, then I propose increasing the stack size of common items to compensate. A stack size of 10,000 for ingots allows you to make use of the full volume of a modular cargo container: With this change, adding the ability to pick up a specific number of items from a stack would be a good quality of life change. For example, pressing shift+right click on a stack would pop up a box where you type in how many items you want to take. Even without that quality of life change, I think increasing stack sizes would be a step in the right direction towards making the volume system feel more usable and intuitive. The logistics and modular cargo systems are great but right now we're still being held back by inventory slots and stack sizes. One unintended change would be players who don't use the volume system will suddenly find themselves with much more cargo capacity than before. I'm not sure that would be a bad thing though, and server owners who choose to disable the volume system can always use a custom config to set the stack sizes back to how they were for balance. Along with this change, I would like to see the max size of modular cargo containers increased, assuming there's no technical reason for the limit of 320,000. If anyone wants to test using these stack size limits in the experimental branch, here's what I used: Spoiler Code: # How it works: # - rename to 'Config.ecf' to activate # - change original values of parameters as desired # - listed parameters will overwrite the game's internal original values # - parameters not listed (commented out / removed) will cause the game to continue using the internal ORIGINAL values VERSION: 3 { Item Id: 2246, Name: OreTemplate StackSize: 10000 } { Item Id: 2247, Name: ComponentsTemplate StackSize: 10000 }
