Thorfinn

Yeah, I would (well, actually, I do) hold off on the bigger trees until I have better tools. The taller pines are OK, but the massive oaks or walnuts (or redwoods) are just too much, unless maybe you remove all the leaves first. I've often thought that maybe it should not count the leafy blocks, only the branchy ones, and sometimes that it should only count the branchy ones that actually drop something, but as is, if you aren't defoliating before chopping, a stone axe isn't a great option. Unless you are building something like a hunting lodge, you should be able to get through on 8-10 stacks of logs until you have better tooling. That's only a little over one stack of flint axe heads. And I would definitely agree with @LadyWYT that filling a large charcoal pit while having to individually split every log with 3 clicks would be tedious to the extreme. There are people who think it's too tedious as it is.

I feel a bit of an idiot now. Must have been a bad batch of heroin or something. But that's why I usually want to think on things for a bit. There's almost always an easier way than just barreling through. You don't have to patch those blocks at the time they are defined. Just add the combustibleProps lto each later. I suspect you could assign them all the same burn values with wildcards like thatch and agedthatch, but I would think you would want to make the reflect the actual amount of thatch that each recipe called for in creating it, so the sloped thatch block would burn for half the time that the thatch roof tip would.

Interesting thought, @Kevin Eric Snell. All it would take is adding the following code to each code block: combustibleProps: { burnTemperature: 700, burnDuration: 24, and set whatever values you think it should have. But it's a little more involved. Each type of roofing block uses variantgroups for materials. e.g., variantgroups: [ { code: "material", states: ["copper", "slate", "thatch", "agedthatch", "blackclay", "brownclay", "creamclay", "fireclay", "grayclay", "orangeclay", "redclay", "tanclay", "bamboo", "sod", "acacia", "aged", "baldcypress", "birch", "ebony", "kapok", "larch", "maple", "oak", "pine", "purpleheart", "redwood", "walnut"] }, Adding that to this block would make fireclay and slate shingles burn, too. I'd have to think on it a bit, but offhand, I think you will probably have to break things out by desired combustibleProps, and then repeat with 13 other files. Easiest would be to use the knife and take the loss. Next easiest would probably to make recipes to convert thatch blocks to a new thatchblock similar to a hay bale. I take that back. Easiest would probably be toss them into a cave and just walk away.

Maybe just switch the text when paused to "Resume Game"?

Are you playing 1.19.8, or the 1.20 RC? In the new version, red clay can spawn anywhere that the climate is acceptable (0.27 rainfall (probably uncommon and up), and at least -10C), while blue clay is the same, but only at or a few handfuls of blocks above sea level. Interestingly, bauxite finally has a reason to exist, apart from the small number you need for refractory bricks. Something I hadn't noticed until I just read the JSON is

Dunno. The last couple starts that were under water, with default Wilderness settings, no mods, I was standing on muddy gravel. There were no planks that I could see on the surface, Not having coordinates, though, I'm not sure origin would have been in water, since the shorelines were pretty close. Maybe salt water? Defaults have no oceans, to the best of my knowledge, and the times I've seen the wood slabs were about the time I was puttering with Landcover.

Right. All you need for a paint is a more or less translucent binder system that entrains your pigments. Dye is another thing. That said, charcoal dust is very hard to remove from fibers. I'm sure you could use charcoal to stain cloth, but it would be more of a temporary pigment than a dye.

Welcome to the forums, @StarFeather! Are you seeking out the passes and valleys? I ask because they are pretty common in default mapgen. What usually causes the problems is if you really, really want to head in some particular direction. In the pic you posted, if your destination were across the lake and up over the mountain, instead of just following the road around the bend in the "wrong" direction, that would not be a whole lot of fun. That's really the reason I advise avoiding the map as much as possible. There's usually an easy road through, though it might require a roundabout path. In the case of your graphic, just go the far side of the mountains dead ahead, and you often have a clear path. If not, often the range right beyond that.

Welcome to the forums, @Svetlin Totev! It's true that clay doesn't appear in low rainfall areas, like deserts and gravel biomes. The rest of us know that, so don't waste time looking where it doesn't spawn. Your view is valuable. How would you recommend that information be conveyed? Should it be "Just go ahead and start a new world" anytime one does not complete the tutorial in a certain amount of time? Should it suggest you seek out lowlands with lots of rainfall? What would keep it from being not a great experience?

Welcome to the forums, @Ratnaraj_ Yeah, this bugs me too. Not a huge deal, though. Click on Movable once and Bob's your uncle. Until you have to start a new game, they will go to where you left them. I think it would be cool to have a tiled setting, as my storage tends to be... um... disjoint? Uninspired? Chaotic, maybe? Let's see just how many things I have to open to find where something is stored... Yep, another peeve. The only real reason I have info tips on. Even so, I've eaten scads of honeycomb while holding it over a bucket. Fortunately no one is watching. I can't imagine how silly that would look. Bobbing for honeycomb, I'd guess. Huh. Now that you mention it... No idea why I didn't notice it before. Maybe because I just <ESC> to close all? That's my story and I'm stickin' to it. In my ideal world, R-Click wouldn't close the storage block, though. Again, that somewhat cryptic storage method, combined with a somewhat... inconsistent memory. Does take a bit to understand what it's showing you.

Don't know. Looks to be an Apple product of some sort. Welcome to the forums, @Oofishy

Looks like none of the numbers, either the ones I've seen posted, nor my extrapolations, seem to be very close. Took 3 hours 10 minutes to fill in a 10k x 10k map. Started flying at 4x. Had to keep slowing down flying speed as the file grew, so at the end was flying 2x with pauses to let the thing catch up. Made sure it was all revealed, then flew around a bunch more to make sure the file size didn't suddenly change. A tiny amount of change as I went. Such a small amount that it might have been animal spawns and deaths. Maybe some lightning fires. Saw a few of those. But the answer for this map, anyway, is 3.71 gigs. Extrapolating should work, but player constructions might do weirdness. I don't know how chiseled blocks are stored, for example. But I'd expect a fully explored 100k x 100k to be somewhere around 100 times that size, or south of 400 gigs.

Right. As you expand the view radius, it generates the new chunks, and expands the vcdbs. Which is the same thing you are trying to do. Technically, you could probably just multiply the size of a single chunk by the number of chunks in a 10k x 10k map (looks like its 313x313 chunks or 97,969 chunks), so as a first guess, it would be 97,969 * the size of a single chunk, which I think you already measured, right? A first approximation would be 108k. That sounds a lot lean. Someone reported his map increased by 2 gigs when he traveled 14k, and at a guess, 1024 viewDistance, which would only be a little over a quarter of an entire 10k x 10k. Assuming the report was correct, a 10k square should be closer to 3 gigs. All I have on this machine is a small test world (that I don't remember what I was testing) with 10 minutes of playtime that is 250k. I haven't opened it up, but I guarantee you I haven't fully explored a 25k by 10k region. Only reason I suggested starting with 32 and recording the difference in size as you increase viewDistance is to get some kind of idea how much overhead there is. I'm not saying there is any overhead, I don't have any idea. But if, for example the file size of viewDistance 160 is exactly 81 times the size of a viewDistance 32, and you have at least 31 blocks of vertical difference in some of those chunks, you also know it is also storing air blocks. And you have not had to run around revealing the whole map.

My favorite bit: Not that I've minded the pre or RCs one bit, as evidenced by the fact I have separate installs for each of them so if I run into something, I can see, "Was that always like that?" [EDIT] Oh, that's just great. Used to be we could tell salt water from fresh by whether it would transfer. Now we have to look at the description when selected? That is totally unacceptable! (Yes, I'm kidding.)

I was way more wrong than right. Never have played with small view distances. Anyway, it starts out with just 1 chunk revealed. 64 view distance reveals the 8 around that, for a total of 9. 96, the 16 around that, for a total of 25. Continue up to the 5th concentric ring, 160 view distance, the last that your map remains a square, 9x9 or 81 chunks. The next, 192, adds 9 more on each side, for a total of 81+36=117. A more useful way to look at it is that it creates an 11x11 square missing one chunk from each corner, or 121-4=117. The next is 13^2 but missing the outer 3 chunks on each corner, 169-3*4=157, the next 15^2 less 6 chunks per corner, 225-6*4=201, etc. Note the number of chunks missing from each corner are the triangular numbers, 1,3,6,10,15, etc., that is, the nth triangular number is the sum of the the natural numbers 1 to n. The last view distance is 1536, or 97 chunks per side, less 4x the 43rd triangular number, which if I didn't blow something along the way, is 946. So, again, assuming I didn't make a rookie mistake somewhere along the line, there are 97^2-946*4=5625 chunks in a full view distance. Well, 2d chunks. Multiply that by however many chunks to the top of the landform, or possibly all the way up to worldheight, 9 chunks high by default. Should be able to tell pretty quickly if it stores air blocks in the database. [EDIT] Oops. Speaking of rookie mistakes, the side of the full square is viewDistance/16-1. So the largest viewDistance would have a side of 95, meaning 95^2-946*4=5241 2d chunks. Again, with the proviso of no more rookie mistakes.

Sorry. I didn't take it out of context. I was making a joke. You weren't here, but as recently as yesterday, people were mad at me for having the opinion that one day's travel isn't all that far. I've had a similar discussion about sticks, BTW. About how important it is in early game to use the layer of sticks so that you don't end up with 9 full stacks of sticks in inventory. Yes, it's a pain to have to break them as opposed to decrafting them like hay, but it beats the heck out of running out of sticks. But going to disagree about adding it to the base game. That was a design choice, and, while I don't want to head off into the weeds again, at least so soon, a choice that was not too bad in terms of game balance. For example, any ratio of planks to sticks in excess of unity is going to mess up the recipe for ladders, though I wouldn't expect one relatively new to the game to know that. The same is true for firewood to sticks -- anything greater than 2:3 is going to be a problem. I'd advise one use those mods until you, too, realize that sticks are not as badly balanced as you once thought. What might be a better answer is changing the pit kiln to only require 4 kindling. I'm guessing there was a reason 8 was selected, but I haven't given it much thought. Whatever one finds annoying about the game at any moment, with a little more playtime, you will probably see there's a reason for the choice made. I'm hard pressed to think of more than a handful of things that I've not come to that conclusion. (Mushroom harvest speed, I'm looking at you.)

Welcome to the forums, @Kyzer! Oh, no, you are not going to drag me into a discussion about whether it's "ridiculously hard" to collect enough sticks. Not this soon. [EDIT] BTW, there are several mods that do that, and at least a couple that give you all the drops from lumberjacking as if you had used the shears first. Talk your group into adding either or both.

I play permadeath, so have no saved worlds. And I've never made a smaller than default world. Probably played in them, but never cared to ask. I think by far the easiest way to investigate is to set your view distance to minimum and start a new game and don't move from spawn. It won't take long to generate. Figure out how many chunks are revealed. If it's like the larger view distances, the map will be a diamond with chopped off vertices in cardinal directions, that you can resolve into 2 squares with s of viewdistance, plus 4 rectangles of viewdistance x (?). It would not surprise me if the width is twice the step+1, so at viewdistance=512 it's 9 chunks wide (or whatever), at the next, its 11. So for your first mapsize, I'd expect something like 2 * viewdistance ^ 2 + viewdistance * 3 * 4. (The last multipliers are 3 is rectangle width, 4 is number of rectangles.) The width of the rectangles are by far the things I'm least confident about. It may turn out the smallest viewdistance is actually a true diamond, and if so, the squares will actually be (viewdistance-1) on a side. Then bump it to the next view distance and record its size, and repeat. Once you are satisfied you know the model for the number of chunks, predict what you will get next, because I suspect counting blocks at 1532 view distance is going to be a bit tedious. Like @Streetwind says, I think the size on the drive is volume based, and is going to depend on how many mountains there are. It looks to me as if air blocks are free. There are nearly 3x as many blocks in a column that goes to worldheight than there are of a column that goes only to sea level. It's going to end up being approximate, so the greater the viewdistance, the better the full world size estimate will be. Ah. So that's why worldheight of 320.

Dana Tweaks does/did that. According to the author, the stove's graphics are hardcoded, so no matter what fuel you use, it looks like firewood. If that doesn't bother you, that's an option.

One of the positive aspects of the design here is that the chapter content is 100% locked behind a person's interest in role-playing and exploring options. It's not forced on you. It's there if you want it. I know people who just look at things like trader dialog and lore as pointless EULAs to click through, then wonder why they can't find anything interesting to do. I also know many who could not care less about the lore and story -- they are looking the game as a builder, and having a blast. The game caters to almost any type of player.

Yes, @Adnyeus it's more or less the same as Step 3. Use mapgen 6 if you want less hilly, 7 if you want rugged. There is also a command to replace a larger area. Be aware that while the landform may well be regenerated if you are using the right mapgen, the rock layers and mineral resources will be different. Or at least they useta was. Please do a backup first, though. Regenerate until you get something that fits.

Mods hook into the engine at load. This makes it possible for different modlists to reuse hotkeys, For example you can use "Z" for zoom if you are using the Zoom mod, or for stack to container if you are using Xandu's Inventory Tweaks So long as you don't play a game with both mods, neither has to be fiddled with.

If money were what the devs were looking for, they'd just release it on Steam. So far, Tyron has just left it at, "Thanks, but no thanks." For now, anyway. In part, that might be what they want to avoid -- the demographic you see posting on pretty much every game on Steam. You know the kind, "I know you don't think it's broken, but fix it now!"

Satiety or nutrition? I'd think I'd have noticed the satiety since pie has become my standard food starting in late May to early June, but evidently not. You aren't triggering the bug from taking hunger damage? Don't know that affects food, but it wouldn't surprise me, either. I have run into the case that if my food level is very low, pie (and porridge) doesn't seem to be as filling as it should be, but, of course, I forget to look at the numbers next time it comes up.

That's a good idea, and another possible solution the current unpleasantness. If Mohammed won't go to the mountain, then the mountain must come to Mohammed. Now all that's necessary is guessing the names of the next story locations.