There are the various non-device building blocks: concrete, steel, carbon, armored concrete etc. All of these have a large selection of different shapes you can use. The hit points of the block vary with the shape, and generally follow the logic that within a specific block material the amount of hit points the shapes have is relative to how much the shape fills a "full cube". Makes sense. Except all the shapes have the same resource cost. A constructor takes the specified amount of input items and outputs "one block". You then place that block and your inventory gets deducted by one block. Your selection of the block shape has no effect on that. They are all equal to "1 block". Yet they have different hit points. Which is a problem because now there's really no functional incentive to use anything but full cubes. You'd only do it for cosmetic reasons and doing that will penalize you. That seems counter-productive... Now, obviously, it's easier to code it like this. It would also be a hassle if the player had to select the shape before constructing it. I want to build "100 blocks". Not "13 of this shape, 7 of this shape, 11 of these etc." So, here's an idea that allows you to have it both ways, and still make it easy to handle technically in the game: Instead of having the output amount of the constructor template for a block to be "1 block", make it "x units" where that x is the hit point amount of the full cube. Then, when you place a block, your inventory gets deducted by the amount of hit points the selected shape has. Simple and effective. The resource cost now automatically follows the "amount of stuff" in the different shapes. That's it. For example, instead of having "1 cement makes 1 concrete block", you'd have "1 cement makes 800 units of concrete" (because a full cube concrete block has 800 hit points). Placing a full cube concrete block would then consume 800 "concrete units". Placing a half-cube concrete block would consume 400 "concrete units". That allows you to either have 1 full cube or 2 half-cubes for the same resource amount. When salvaging or retrieving blocks, just do it in reverse by giving the player the amount of hit points in units. The amount can, of course, be deducted by an appropriate percentage depending on the chosen multi-tool mode and whether the player is the owner of the grid or not. Actually, this system would even allow to take into the account possible damage in the blocks as you could use the current damaged hit-point amount.
Here is the major issue with what you propose, stack size and tiny amount of blocks that can be carried now. Stack sizes above 50,000 can start to cause major issues in the game. I think it is actually around 65,000 is the absolute max you can go. So let's say we can safely use 65k max stack size (that can still cause issues). Your full blocks consume 800 units from the stack, each. 65k divided by 800 = 81.25 blocks. With your suggestion the absolute MAX blocks we can carry would be 81.25 blocks per stack of inventory space. The devs would likely choose 50k as the max stack for safety reasons, so 50k/800= 62.5 blocks per stack would likely be the safe choice by the devs. So unless they can change the max int number, which would have major implications across the entire game, I just don't see this idea ever working out how you have proposed it. I know I sure as heck won't want to build ever again if I can only carry 60-80 blocks per stack of inventory space/virtual toolbar slot....... I, and many others, would never play again. Building ANYTHING would be an exercise in frustration, tedium, etc.
Isn't that just a scaling issue? I mean there's nothing specific in the number "800" so if there's an integer limit then we could just define the "building unit" as "hit points divided by 10". Full concrete block would then be 80 units which would give you 50k/80 = 625 blocks. Actually, even more since you would spend less for the other shapes. What's the highest armor block hit point value? Is it 2000 hp? That would be 200 units so 50k/200 = 250 full blocks per stack. Is it too small? We could also divide by 20 instead of 10. Just needs to be *enough* accuracy there in the resource cost calculation for the shapes that they give a meaningful difference for some good value of "meaningful". If it's really too small, then I think even just a distinction of 1/4 vs. 1/2 vs. 3/4 vs 1/1 in the shapes would be "useful enough". Hit points divided by 100?
