Made sense from an intuitive gameplay perspective, since its the most common way of doing things in every other game. With that being said, I think it would be amazing if the creative side of the game, and the survival side were completely separate, but merged when it came time to build or modify something. Imagine, you are looting a poi. Health vials, food, ammo, etc all went in to your inventory with weight limits. Once the multi tool comes out though, everything salvaged goes in to a separate "creative" inventory with no limits to weight or volume. Whenever it's time to build, everything comes from that stock of items sort of like how it's accessed now in creative menu...but obviously with limited stock to what you've gathered. Constructors, food processors, and the players themselves would access this when it comes time to craft or build. This would fix so many itemisation issues we currently have...with just too much crap floating around that needs to be managed. You have to suspend the urge for complete realism though, to get proper fun gameplay. You can have your survival mode part of the game, while still giving people the creative freedom necessary for making amazing ships. We would obviously have to ditch the idea of weight inside cargo boxes adding weight to spacecraft. I hardly think this is necessary anyway. From the fun gameplay perspective, weight would only be factored by how armored each block was that is added to the ship. This would also make sense to all normal people coming to play this game for the first time.
I cant help to think that with the Volume/Weight and the forthcoming CPU implementations its intent was to move away from a jack-of-all-trades ship and promote specialized ships/needs. Prior to A9, you could build a ship that was a mobile base, yet still be viable for any combat engagement. Having weight/volume adds the ability to impose a penalty for thinking this way. If you want to be agile in combat, do not carry everything you own. You do not need a full construction suite of ability in a combat vessel. Even though I typically play MP (PVE) on our own private server. I do welcome the need to specialize vehicles for needs. If you want to move massive cargo, create a hauler. If you want an exploration ship, you have to balance your elements that you include on the ship. Logistics (Automazation) Time will tell as how this will flow on the next phase of its deployment. --izz
With my inital medling with it I would probably suggest changeing the hard cap on a players inventory to a soft cap where over 500 the player would slow down loss stamina etc. Basically a bit out of most RPGs encombered system. This would allow new players the leway to partily ignore the system early game and deal with the consequences while permoting learning and advancing into the game at later stages. While I fully realize the numbers are place holders it would let new players or new game stage players build a base or do simple things without letting people walk around with everything they have.
@Izzin , the idea behind the change seems reasonable, but then managing a fleet of highly specialized vessels will be the next big problem. In SP you don't have buddies, so for a single POI with a deposit nearby that would be: SV bombing run on turrets, return trip, armored HV with a medbay to assault the POI directly, return trip, mining HV to dig out the nearby deposit, return trip, SV/HV freighter to bring back the loot, return trip. In comparison to A8 - too many return trips without means to calling in and sending back an unmanned V or drone, and we may stuck here for some time as there is no clear roadmap from devs.
If the idea is to promote specialized vehicles, there's a much simpler and less performance wrecking solution. You give each ship component a value. A core can only hold up to a specific total value. So if an hv/sv wanted to have a lot of guns, and each gun cost 10 for example, and the total value an hv core could hold was 100, then you would factor the cost of each gun, the cost of each fuel and oxygen tank, and the cost of harvesting equipment....and you might find you don't have much if any available points left to add storage. This kind of system makes all kinds of specialized vehicles an option, and completely removes that "Jack of all trades" ship. Added bonus is that it's much easier to add in and balance, than any kind of weight/volume system littered with a bunch of arbitrary values.
This "penalty" always existed, as per "volume" limitations there was a limit imposed by available container slots, and containers and all devices had mass. They only "extended" the impacts of mass and volume to inventory items. I see no need for "penalties" for players thinking in any way in a game, unless it concerns "exploits". A warship is a "moving base" actually, so I don't understand what would be wrong with this. The mass of the ship exceeds its contents by a very large margin, so the evident "remedy" to any mass/volume "problem" (if there is one to start with) should then logically apply to the ships : physics and flight mechanics. It goes without saying that making physics realistic might prove harder to achieve than making an items management system based on virtual interactions not rendered in-game. The ability to be able to sustain long travel times in space (food, O2, fuel) and to survive combats does not require players to dismantle entire bases all over any given planet. But removing that... choice by ways of hampering material manipulation and forcing it through a convoluted management system will not change this, and players will simply have to spend more time to get to the same end results.
whats annoying me a little , is f4 key , if the devs can organize the storage to be at tab button it will look much better , we need a quick things to do at quick button that to reach in the same hand that we play on , and please make the game system remembers what containers i have opened last time , no need to click at drop down menu everytime , shift click also should work at all king of containers ui , and have programed rotation , hotbar to left container slots , left container slots to right container slots , and please make the container - constructor got refreshed everytime if the container ui is open , and be sure that constructor is working at background
I don't see any debunking going on here. I see complaints over the implementation of the logistics interface and essential missing logistics features, and issues over the current mass and volume values, to be sure. Which is why I've never argued that there should be intensive visualizations or physical objects running back and forth between the player and storage containers, only that those are perfectly valid explanations for how the remote transfer system works. Well, it's an abstraction of how it would work IRL, which, as you know, I find to be the best starting place when trying to design a self-consistent system. Sure, there are ways to design such a system using the player's inventory, but they don't scale; one could also use a global inventory (as Avorion does), but then there's the question of what object(s) get all that mass. With this system, it's very straightforward: objects with definite masses and volumes are localized to storage containers, and then (presumably) the signal logic system is used to check containers for items, transfer items between containers based on conditions, and set/remove constructor recipes based on conditions. That right there is basically all you need. Future systems can add additional conditions, but the basic model won't have to change. This is what I see as the logic behind making it so that all materials don't have to pass through the player's inventory. It may or may not be how the devs thought about it, but what they've implemented is a logical way to lay the groundwork for automation. Not the only logical way, perhaps, but logical nonetheless. Easier/simpler ways? Potentially. Consistent and scalable ways? Maybe not. One of the nicest aspects of the logistics system is that it's parallelizable if programmed correctly: inventories can be treated completely independently, and so long as storage controllers process inventory manipulation requests in order (and send errors if a request can't be fulfilled), every single storage array could technically be run in its own thread. Now, I don't know if that's how the devs have programmed things at present, but the architecture is scalable if they want it to be. In any case, my argument remains that the fundamental problem with the logistics system as it stands is one of interface and implementation, rather than the architecture of the system itself.
Ah, but whether or not that's true depends on mass and volume values for all items and blocks/devices. If the mass and stored volume of blocks and devices were set by their recipes, ships would be a lot less massive, and full cargo containers (under the assumption that items can be compressed to solid density) could be quite massive. Depending on the energy density of fuel, fuel could be an important part of a ship's mass too. There's nothing preventing you from designing a ship capable of salvaging entire planetary bases when cargo has mass and volume. It'd be a big ship, probably, and might not be much good for combat, of course, but still definitely doable. One could also imagine designing and building a small fleet of NPC ships to do the job (assuming we eventually get fleet management capabilities; StarMade has implemented the beginnings of such a system, so it definitely seems doable).
The fact that you "don't see debunking" regarding the specific topic of "making sense" (in a video game) is far from proving that "debunking" has not occured repeatedly against that over-used argument. You wrote this : " With the new system, there's certainly room to flesh out the remote access feature by adding visualizations (drones, nanobot clouds, etc), energy costs, time delays based on the distance, etc." You are not "arguing" for these features to get in the game: you are simply replacing what many other players already used as "explanation" for "magic tech" with your own. We already discussed this ad nauseam for the teleport and multitool, among other things. Playing with words ? A self-consistent system is one that is intuitive and logic. Usually. You are just trying to make me run in circles on the same arguments. I refer you to our previous discussion regarding the "sane and intelligent system designer" that is the player pawn, living in the future where really cool things can be achieved simply, because... "video game" and blabla. Do I need to go through all this again ? I tend to disagree a lot, for complicated reasons. But here is the summary : if I design a game where players can build stuff with stuff they pick up, I guess I will try to make that as simple as possible, unless there is a requirement to do otherwise. Where do you see such requirement ? "Consistency" ? Running me in circles ? More of the same "consistency" argument. Circles. But yes, there are other ways to "make believe" there is encumberance and manipulation limits, that are consistent with the "whole game" as perceived by the player, and... back to the same again (intelligent player in future and blablabla). I think it is intrusive. Players should be able to avoid it completely if they want to, and carry tons of stuff in their slot-limited backpack. Stacks never needed to go up to 999 in the first place.
damn, I checked it so and it is very sad, I’m afraid of what size the HV is needed now to not be able to mine ore and become an easy target for one volley of guns, probably have to increase its HV at least twice to 500-600 tons , and it will be just a more or less safe digger! WTF?!
Another way to tackle this issue would be turning the player armors into exoskeletons. The heavier the armor, the more weight you can carry. Heavier armors already impose penalties on mobility, so the player would not to be penalized twice when carrying a heavier load. An improved NPC system could solve this issue. Using a very recent example, in X4 you do exactly that: you build your fleet and let npcs take care of it. The same thing with traders, stations, etc. Maybe let you have a simple RTS experience when you open the map, like move, attack, patrol, etc. Then add some NPC requirements (like food, water, private rooms) and you have your reason to have a sprawling base, endless farms, a massive fleet. =D
And I felt I had to clarify, as you seemed to be implying that I've been proposing features that unnecessarily decrease performance. In the abstract, I'd argue that the logistics system is intuitive (stuff goes in boxes and every entity, player included, can use stuff directly from any box). But it's hard to see that when the current in-game interface for it is not intuitive. The need to support a robust automation system. The reason I keep bringing up the principle of consistency is because it's what makes a constructed world and its component systems integrate properly, and allows suspension of disbelief most easily. Players moving through a consistent world should very rarely have stop and go "huh, that's weird, this doesn't make sense at all" when interacting with an element of the world. Well, those players can simply keep mass and volume disabled. As for logistics, I honestly don't know what to tell you except to give the devs more time to fix the interface. As for stack sizes, even without mass and volume, you still need quite a range of stack sizes. Consider the difference between a bullet and a large steel block, for instance: should they have the same stack size?
First I think you know I am not shy of addressing a topic directly, so I would surely do my best to avoid "seeming to be implying" something as trivial as what you mention. Which is not a sin anyway... My point was to show that when proposing a solution, you "tunnel vision" into its minute details while staying silent about performance issues. All items discussed in that manner can be seen as insignificant performance-wise, but in the reality of the game they add up. In French we say "vouloir à la fois le beurre et l'argent du beurre", which means that things can't be had both ways. This is a rhetorical characteristic of many players defending X feature, not just you of course : everything is nice and neat, and will not impact performance significantly. The game already has performance issues so I think I do not need to elaborate on the effects of unrestricted addition of cosmetics and frills just for the sake of it. I hardly see how this system can be seen as "intuitive" if players can not even interact directly with materials, having to use an intermediary "medium" to allow them what they could do before much simpler. I (and others) have used analogies with the multi-tool acting as the "medium" already, transferring stuff in the "backpack". This whole system only postpones the "suspension of disbelief" one unnecessary step further, without solving the "inconsistency" at all. Read carefully : even when the "system" has been established, how in the hell is the player able ot take any 75 tons object and put it into place ? And here you propose "your" explanation (nano-drones or whatever), which is no different than what you would probably say if the logistics was non-existent (previous versions). This is either bad faith, or you just don't understand what "suspension of disbelief" means. Forcing the player into the "logistics" system to put a block in place was never "needed" in the first place : you invoked "consistency" and now you use "needed", and I point to you that "consistency" doesn't work, as per the "magic strength" of the player still exists, but has been hidden one step (click) further. See my previous paragraph up here. So here again, this is circular reasoning. You bring nothing new, you only reiterate the "need" because "consistency" while voluntarily avoiding to see it changes nothing to "the magic player abilities". This is very interesting, in light of what I wrote above. I'm starting to lean increasingly into believeing you are just playing the bad faith card to try to drown the fish into walls of texts. They had nothing to "fix" in the first place. If logistics had been tied to a network of conveyors and robot lifts & similar things, players would be totally free to use the system OR simply continue to build with the (still existent) "magic player strength". And clearly, "suspension of disbelief was not well served by the UI, as players would naturally expect "animations" and "conveyors" instead of a windows-based system. We already had the control panel, and it never prevented player from interacting with a cooking table or a constructor. Now you maintain that "suspension of disbelief" is better served with an abstract. This is bad faith again. That is not a problem, and it would have been way easier to make smart choices right there from the start, instead of making arbitrary stacks that enhanced the feeling of "nonsense" concerning the inventory capacity. Slot-based systems exist in other games and have been proposed, and do a very good job at simulating "inventory limits" without forcing the player to use a set of windows to "connect" to a remote container to put an object in front of him. That should go without saying, but it seems you don't understand this.
Ummm.... The player has twice the capacity as a large BA cargo block? *** edit *** I received a much larger capacity after I removed them replaced the cargo blocks with new ones. Any chance we will get a command like we did in alpha 4 that replaced the legacy blocks automatically? *** Another edit *** Ok, I found this in the release notes. (guess it helps if I read them). Not as easy as it was when Alpha 4 released, but I will get on it. Is there a way we could turn this into a batch command?
I think we agree that performance is important, and that features that consume extra cycles need to be justified based on what they contribute to the game. The logistics system itself will form the basis for automation, so I feel like that justifies whatever performance cost it has; visualizations of how the logistics system moves material around, not so much (though, it might be nice to have that as an eye-candy option for players who have CPU cycles to burn). It's true that I've invoked the same explanation for transferring materials before and after the logistics change. Maybe the problem is that we draw lines at different locations for what we consider requiring suspension of disbelief. The player being able to carry huge amounts of materials is more immersion-breaking than an unseen method of moving material between inventories (maybe the reverse is true for you). To put it another way, I prefer to need fewer magical explanations for a world. Before logistics, we needed there to be magical inventories, and a magical way of streaming materials from the player's inventory into place. With logistics (and consistent mass and volume), just the magical way of streaming materials remains. To me, this means that the world is better grounded and less suspension of disbelief is needed. As I argued above, the logistics system removes at least one magical ability (massless inventories with nearly arbitrary volume). So, to claim that it changes nothing with regard to the amount of magic required in-game seems incorrect. I'll continue to point out that a good portion of what we're discussing here are interface problems. Is it annoying and convoluted to not be able to directly interact with the inventory that a constructor connects to? Yep, I completely agree. But that's not the fault of the system itself; that's the fault of the devs for not having figured out concurrent inventory access. Is it annoying and convoluted to have to laboriously connect to a container and drag blocks into a virtual toolbar just in order to place a single block? Yep, I completely agree. But, again, that's not the fault of the system; it's the concurrent inventory access issue again, with a side-helping of the toolbars being separate inventories rather than simple links. For the latter case, here's how the system could work with the right interface: you are automatically connected to all structures (which ideally would include terrain-placeable containers) in range, and you can pick blocks (with something like the creative menu) to put in your toolbar. Items in the toolbar are links rather than physical items (and the displayed count is the sum of all of that item type across all the structures you're in range of), and when you place a block, it's pulled from one of the nearby structures you're connected to. So, effectively, while you're in range of a structure with storage, you can place blocks almost as if you were in creative mode (with the obvious restriction that you'd actually have to have those blocks on-hand in storage somewhere). You'll notice that throughout all of this, you never had to look at the logistics interface. Yes, I'm familiar with how to go about balancing stack sizes; that's what previous version the script that I wrote to consistently set item mass and volume did (more precisely, it computed stack sizes based on the volume of a slot in a CV/BA container). But since the player (and SV/HV containers) had to use the same slot size, it was next to useless at simulating inventory limits for the player (let alone be a viable way of dealing with inventory mass for players).
But who actually asks for a "hardcore survival mode"? The games name by the way is "galactic survival" not "galactic hardcore survival". All picking aside, i hope that shows how the game needs way more options to chose from when starting a game. Way more than 3 static very limited options to chose from. I actually would like to see the option to set the game up with either a (realistic) cargo weight system, or a (slot based) graphical based volume system, or a weight and volume (kilograms/liters) based system for the hand full of hardcore players out there. Giving options is good. The freedom mode takes away to much from the survival aspect, all systems in place distract to much from the survival aspect keeping the players busy with a lot of busy work and unnecessary tasks to fiddle around with while actually restricting the build part of the game. I must admit that i only took a small peak at 9.0 for now and will test it further. But i don't see anything right now which would make me lose sceptisism.
Survival mode is where all the mechanics get balanced, so they all need to be activated. Whether or not that's considered hardcore is a matter of opinion. What's the difference between the first and last options? In my opinion, Freedom Mode should be the highly-configurable mode. As the name implies, it should give you the freedom to enable whatever combination of game mechanics you want, leaving the rest disabled. Meanwhile, Survival Mode should probably just let you choose the difficulty and that's it (all game mechanics are enabled). Creative Mode, of course, remains as it is. So, I think the devs currently have it backwards in terms of which mode has all the configuration options. The benefit of this approach is that then workshop builds could be specifically tagged as being appropriate for Survival Mode, since Survival Mode would have a single configuration.
Well congrats, did you die of a lack of food within 30m of searching? - we dont always spawn/land near resources, or get lucky in that regard. Last time i played, i landed near a lake, and had to fend off not-so-passive alien insects, that could suddenly insta-kill myself or later my base... So that was my point. All the prefabs havent been updated since 7.x.x, i made the mistake of spawning a few, much to my regret. whats the point of driving around also on a ship that provides you NO protection from the surroundings. All the weapon wielding NPC's are capable of insta-killing most of the time now... at worst 1-3 shots, which its hard to get out of the extreme range. And to note, NO prefab before specifically Tier1(and no other till Tier2a), contains a Storage Container, and Tier2a is the only before Tier3 contain a Constructor... - NONE of them have sensors... If your referring to workshop BP's, that's just silly, that's the community. This is a discussion about what we expect from Eleon Game Studios in relation to Volume/Mass. The community should not have to maintain prefab blueprints, they have take responsibility for by adding them at this point. Thats just silly, not to mention, if you rely on the community /how/ do new players know which or even if they should use them. When i pointed out the 300+ ingot count i was referring to HV_PREFAB_TIER2a - As thats the first REAL starter HV provided. the others are more a joke after 6.x.x as they provide neither protection or storage. Also, idk how you can carry 100 units of ore, 30u of ore was 480u of mass, it was one of my irritations on 9.0.0 release. i havent played since. (i cant stand the logistics interface, so i dont want to even try. Its a regression, as a forced UI change. It should be encouraged for middle/late game, and not forced for ALL interactions. Its too clunky, takes to long to use effectively and takes away from the streamlined interface thats expected.)
