Ciarara

No matter the size, generating a chunk is going to take more resources than loading one from a file, so at that point it's an issue of whether you want to prioritize keeping file size low or performance high. Personally, for a game like this, I think performance is the top priority, especially on a server. However, a config setting for that could be useful for some people in single player, as long as it isn't to costly to implement. Adding a check for a config flag adds to processing time, even a small amount. I don't think a once-per-chunk check on generation would be noticeable, but as @7embre pointed out, on large servers everything gets magnified. That also includes file sizes, of course, which could get absolutely insane with many people using translocators to explore, so some way to cull unmodified chunks that haven't been loaded in a long time from the save could be needed.

Oh, that's true. What I was thinking when I wrote that was to simply save empty chunks as null chunks, instead of saving data for every individual air block, but I forgot to write it out properly.

This is a feature I was really hoping for when I switched to this game, and I hope it gets implemented at some point in the future. Only having to load chunks in line of sight (and bordering chunks if close enough to a boundary) would theoretically improve performance a lot over loading the whole column, especially with increased world height. Loading of individual chunks would also be way faster. (edit: I think this is already the case, actually? see https://github.com/tyronx/occlusionculling) It would also probably save on world size (in terms of data) even without having to regenerate chunks, since most sub-surface chunks would never be loaded. I think only saving modified chunks that contain at least one non-air block is a potentially good idea as well, though, since chunk generation would also be much cheaper if the whole column didn't have to be generated at once. Edit: I read in another post that chunks in VS are already cubes, but terrain generation is still based on chunk columns (I'm unsure why, though). So what I'm actually interested in would be an alternative form of terrain generation to take advantage of the chunks being cubes, and allow for greater verticality