KoviBat Posted June 23 Report Posted June 23 Rooms are a bit finicky as they are now, being limited to an area of 15x15x15. While this is fine for very early builds, it becomes very annoying when trying to work with angles or curves, as you can quickly lose usable area to the grid. And how often do rooms actually incorporate that 15 blocks of height that they're able to have? So my (hopefully simple) proposal is to maintain the maximum volume a room can have (15^3), while expanding the borders on the space it can occupy. Maybe 30x30x30, or maybe even 45x45x45. I don't know how the room/hole detection system works, so I'm not really sure how this would affect performance, which is my main concern. I've tried using the custom room size mod and all that does is tank frames and increase freezing spikes, and I'd like to avoid that. Maybe some shortcuts could be having it so only one dimension can be expanded beyond 15 at a time per room, dropping it to a 15x15x30/15x15x45? There should still be an area of perimeter instead of just fully relying on volume regardless of shape, because a 1500m long 1x2 tunnel shouldn't count as one room. That will absolutely wreak hell on performance in some way just by nature of occupying multiple chunks that may or may not be loaded. I've attached an image to basically show my logic. You'll notice three sections of this circle. All of these sections are 1/8th of the circle. At the top is a room fortunate enough to be built parallel with the grid. At the bottom right, you'll see a room of equal size, but off the grid. And on the left is the size of the room you are actually able to build and have it be insulated. A lot of potential space is lost because of the orientation. With expanded borders, the rooms could occupy the same volume in spite of the grid system restrictions. So yeah. Pushing out the area barriers a little bit while retaining max volume should help expand what we can make just that little extra bit. I'm fine with cellars staying as they are. Not sure about how/if Greenhouses would be affected by this. It's not a huge deal, the game isn't completely unplayable without this change implemented. It's just one of those extra mile QOL things that would help out user experience a little. 3
LadyWYT Posted June 23 Report Posted June 23 4 hours ago, KoviBat said: Rooms are a bit finicky as they are now, being limited to an area of 15x15x15. While this is fine for very early builds, it becomes very annoying when trying to work with angles or curves, as you can quickly lose usable area to the grid. And how often do rooms actually incorporate that 15 blocks of height that they're able to have? So my (hopefully simple) proposal is to maintain the maximum volume a room can have (15^3), while expanding the borders on the space it can occupy. Maybe 30x30x30, or maybe even 45x45x45. To clarify--what you seem to be trying to say is calculate whether or not a space qualifies as insulated based on the interior volume, and not the exterior dimensions? That is, instead of having the maximum size be a 15x15x15 cube, one could have an 18x10x10 space instead, since it would still be in the maximum volume requirement. You're still going to run into problems with curves though based on how chiseled blocks operate. For a chiseled block to qualify as an insulating block, it basically can't be smaller than a slab. It might be possible to do "microcalculations" on the space, but that seems like it could run into lag issues rather quickly given how easy it is to make a complicated space while chiseling.
BurgerDaddy Posted June 23 Report Posted June 23 I think the performance hit would be huge. I have no idea what they’re doing internally for the room calculations but… 14x14x14 = 2,744 45x45x45 = 91,125 My guess is that the chosen room size was somewhat based on this.
KoviBat Posted June 23 Author Report Posted June 23 5 hours ago, LadyWYT said: To clarify--what you seem to be trying to say is calculate whether or not a space qualifies as insulated based on the interior volume, and not the exterior dimensions? That is, instead of having the maximum size be a 15x15x15 cube, one could have an 18x10x10 space instead, since it would still be in the maximum volume requirement. Yep, that's exactly it. The volume would still be equivalent to the current 15^3, but it could occupy more area than the 15x15x15 perimeter.
Kulze Posted June 24 Report Posted June 24 I mean, yeah, absolutely, would be great and nothing to even add to it. The issue is as was mentioned: Performance. The larger the check-function to determine if a room exists the worse it is performance-wise. The only solution I see there is to define room-areas in the game as a static when the game realized 'yes, this space is closed'. Only happening for any block which goes through a 'state change', hence when we set down/remove a block it calculates from there to see if there is a room available, as a low-priority task to not interfere with performance. The major downside? It could take very significant amounts of time to create a room this way, removal would be easy, because of a room isn't connected to another room when the block is removed it would automatically be able to tell 'this is the outside, delete the room'. But creation? We could see minutes of a place not being a viable interior space as the system simply hasn't finished computing if it actually is one... or if it's a open space, even if the system solely checks along boundaries instead of inside-blocks. This makes troubleshooting quite a lot harder and emergency creation of a space potentially non-functional when direly needed.
cjameshuff Posted June 25 Report Posted June 25 A couple thoughts about dealing with the performance: Require some special object to "bless" a space as a room. Maybe only do the check around firepits: every room (or every large room, the existing rules being used for small ones) requires a firepit to keep it warm. If the volume is limited to something less than the entire possible volume of the enclosing cube, if you have a starting point within the room, you can scan to the potential boundaries and stop processing if you reach that limit, without even having to do more complex processing to ensure chiseled blocks are valid boundary blocks. If the volume is within limits, the number of boundary blocks to check doesn't scale anywhere near as badly, especially since most rooms will have fairly simple shapes with reasonably low surface area for their volume.
Rainbow Fresh Posted June 25 Report Posted June 25 7 hours ago, Kulze said: I mean, yeah, absolutely, would be great and nothing to even add to it. The issue is as was mentioned: Performance. The larger the check-function to determine if a room exists the worse it is performance-wise. The only solution I see there is to define room-areas in the game as a static when the game realized 'yes, this space is closed'. Only happening for any block which goes through a 'state change', hence when we set down/remove a block it calculates from there to see if there is a room available, as a low-priority task to not interfere with performance. The major downside? It could take very significant amounts of time to create a room this way, removal would be easy, because of a room isn't connected to another room when the block is removed it would automatically be able to tell 'this is the outside, delete the room'. But creation? We could see minutes of a place not being a viable interior space as the system simply hasn't finished computing if it actually is one... or if it's a open space, even if the system solely checks along boundaries instead of inside-blocks. This makes troubleshooting quite a lot harder and emergency creation of a space potentially non-functional when direly needed. I would expect the game to already do that because, by all means, there is no need to constantly check the existence of a room around the player when a room is a static world area that only ever needs to be recalculated when something changes. And even if it is a low priority task, it shouldn't take that long. I already find myself in-game entering a room as is and the character menu "indoors" buff only appears after a couple seconds. Which means the game currently seems to be running a check every so often (probably because your PC would explode if it checked the entire area around you for rooms you might be in every single tick)
Kulze Posted June 25 Report Posted June 25 Well, that's the question though, is it? I would imagine that the check for the character position being the part which causes the delay of the 'indoor' buff, not the check for it to be a viable room itself. After all if that would happen then storage vessels would be in a rather shoddy position. What I think is that it proclaims the specific blocks as 'indoor' as a simple flag, checking whenever a block gets added/removed into the world, which is likely what causes the limitation as then in all cardinal directions + up/down it likely checks the maximum distance limit for existing blocks before going forward with the room-check itself, creating one if it fulfills all conditions ultimately. This only works 'so far' performance-wise, which is what I imagine causes the limit of room-sizes currently as otherwise the performance hit would probably be too high since I imagine it being a O(n²) operation performance wise. It's hence likely a 'instant' action for the room flag (so if you place a vessel inside it gets that flag applied immediately rather then having to re-check) while the player position is a irregular check which happens every few seconds so performance is saved. So to create a larger room with less limits it would need to be changed from a boundary check to a adjacent check system, which is substantially less resource friendly. It can definitely be done! But it's a complex system for sure which isn't lightweight as the current one seems to be. So I imagine it to be on a low priority if implemented, unless rooms get a vaster range of functionality which makes them more important to have outside of simple temperature management and spoilage, for which those sizes suffice. One way to make it needed would be a 'comfort' system similar to what games like Enshrouded or Valheim have, a buff directly tied to how much effort into varied interior decoration has been made.
Heegrim Posted June 29 Report Posted June 29 I think they should just overhaul the temperature system instead and calculate the inside temperature based on how many heat sources there are and how enclosed the space is. 1 hole in the wall shouldn’t completely negate the sheltered effect, especially if there is a campfire inside. Maybe raycast in every direction to see how many sides are sheltered, that way a cave can be used as shelter even if is not fully enclosed.
Slam Posted June 29 Report Posted June 29 On 6/23/2026 at 10:42 AM, LadyWYT said: You're still going to run into problems with curves though based on how chiseled blocks operate. For a chiseled block to qualify as an insulating block, it basically can't be smaller than a slab. It might be possible to do "microcalculations" on the space, but that seems like it could run into lag issues rather quickly given how easy it is to make a complicated space while chiseling. That would’ve been nice to know a long, long time ago… lol.
Recommended Posts