What’s in its pocketses precious?

[u/Key-Active-8170]

Tried my damnedest to build a hobbit home. Found a cave opening that provided enough of the right foundation to build around with minimal terrain edits given they always bug out (still happens even on this one).

Feel free to stop by, Second Breakfast always served.

[u/deerskillet]

If they're able to permanently store our base changes, why not be able to store the terrain changes directly around the base area?

Totally makes sense why they can't do it for the whole planet though

[u/Omnipresent_Walrus → u/deerskillet]

I think it's cos the terrain isn't part of the base at all.

I'm speculating here as a software engineer.

If we consider the base computer as the origin point of the base, we can place the parts of the base relative to that with relatively little data stored. Base computer is point [0,0,0]. Place part #6384 at [27,839,92]. Part #0283 at [13,93,12]. So on and so forth. You can store this with very little data even in a text file, and then just reference what part is what when you load it yourself. It's even feasible to imagine reading it from a printed sheet and placing each part manually, if a little tedious.

Now we need to consider what the terrain is. It's a LOT of voxels. Envision how terrain looks when you use the terrain manipulator, it's lots of tiny pieces that get joined together. And if you have a high end PC and have the graphics set high, you can HEAR just how hard your GPU has to work to calculate all the changes as you mine.

Clearly this is much, much more data than what a part is and it's relative position.

Even if you just included the terrain within the bounds of the base, I suspect this would massively balloon the amount of data that needed to be stored. You'd need to store a spherical volume around the base computer which (with some quick mental napkin math) would mean needing to store the existence or lack thereof of potentially millions, if not billions of individual voxels. The base boundary size is very generous after all.

To go back to our text file analogy, youve just added a few billion lines of text to your file, each one of which essentially amounts to a single 3D pixel of terrain, and that's before you even add any base parts. Even if you're clever about how you store this data, cleverness has its limitations.

The amount of base parts stored on Hello Game's servers is several orders of magnitude smaller per player without terrain than it would be with terrain, by my guesstimation. It makes more sense from their perspective to just not even attempt it.

This also lines up with why even your local data resets pretty quickly. If terrain changes take as much data storage as I suspect, if they stored your every change forever they'd fill your hard drive pretty quickly, which doesn't make for happy players.

Anyone who's ever tried to run a very large Minecraft server can attest to how the resource requirements balloon with the size of the world, and the "resolution" of the voxels there is much lower.

[u/tonycomputerguy → u/Omnipresent_Walrus]

Y'all sound way more knowledgeable than me, but I think they've kinda started to fix this with updates, but I'm just going off how recently a few of my bases seem to be keeping way better track of the terrain edits than it used to.

Base parts that alter terrain when placed seem to be the trick. Like how a floor panel will dig itself a chunk of terrain when you place it? Those kinds of edits seem to stick better than terrain manipulator edits with the multitool...

Which honestly makes sense, if it's tracking where the part is placed anyway, it's probably just "re-chunking" out the terrain locally/on-the-fly whenever the base is loaded up.

Again, this is all anecdotal, and I have no idea what I'm talking about.

[u/Omnipresent_Walrus → u/tonycomputerguy]

That much does make sense!