Thorfinn

Oh, to get from point A to point B, you first have to go halfway. Then you have to go from the midpoint to point B. Then from 3/4 of the way to point B. Since the distance can always be split in half (mathematically) it will take an infinite number of steps, and therefore, can never reach point B. That's kind of what's going on here, but due to the number of digits, eventually it really is 0. And just like IRL, you can actually get to point B. Interesting. Not surprising, as that's good coding practice, but interesting. It strongly suggests that the intent is at some point to fine-tune movement of the various means of transport by tweaking just the constants relative to each other, or maybe even put access to it in world settings.

So what happens if/when it's discovered that doubled speed is too much, as in, unbalanced with the rest of the game, or causes other problems? What about when new hazards are introduced? Are you going to be OK with speed being adjusted? Is everyone else? Incidentally, that's kind of what @traugdor is investigating Is SpeedMultiplier at least derived from Walk Speed from worldconfig? If someone has a speed buff/debuff, is his sailing speed affected?

Oh, yeah, should have noticed. Subtracting ForwardSpeed in the parenthesis would set a limit, as it would drive the increment to 0*dt. Not quite the same thing as second order, but close enough. Closer to a Zeno's Paradox. You would have to do a lot of testing to see the difference.

I suspect the reason for not being included is that wind speed at sea level is not terribly impressive. Until late fall or winter, you can't count on being able to drive a quern at sea level with just a single set of sails. Might be fairly easily addressed -- I can see something like reducing the altitude penalty to windspeed by 1 for every block you are from shore, so at 50 distance from shore you are at the same windspeed as your windmill at 160. I don't think that would be that bad CPU-wise, though it would be more intensive than just the one-time calculation it needs to do for your windmill. [EDIT] If I were coding it, I think I'd put the penalty as an attribute of the rotor at the time it is placed. It will only ever change when you move the rotor. The boat's JSON is interesting in that it includes things like water resistance. Not sure how the physics there is done. IRL, it's a second -order differential equation. Does resistance increase as the square of the speed? Dunno.

Good way to do it. I add one more step -- something, anything to presumably make the pit non-spawnable except in storms. (Hmmm, is there anything at all I could craft with the 6 stones I just picked up?) If I hear drifters when running cross country, I want to know for sure that there is a cave nearby, and not just an old prospecting shaft with it's own unfortunate Fortunato.

Was your biome just too cold? From defaults you can end up with reeds or not, and heading east or west finds different climates where they may spawn.

What mention of dt there is in the code is consistent with it being the dt from calculus, but in this case, to allow it to be numerically calculated. Since you can't use the infinitely small dt of calc, you use the algebraic version, delta t, which would necessarily have to be adjusted by framerate.

Interesting. I figured it was more a proof of concept at this point. Simplifying the model makes a lot of sense. Until there is variable wind direction, there's not much point in writing code that uses it, if for no other reason that you can't really test the code. But it does not consider wind speed at all? I had thought there was a dreadful row about sailboat speed, but this morning, I see it was just a terrible nightmare. "[A]n undigested bit of beef, a blot of mustard, a crumb of cheese, a fragment of an underdone potato." But one dollop of unintended wisdom remains -- it's always easier to give than to take away. The Great Mining Speed Riot may well be the reason for things like a somewhat underwhelming glider and sailboat -- people will be happy to get improved versions, but will not tolerate them being nerfed. What comes as no surprise is that the SpeedMultiplier is already written into the code. Or is that walking speed?

Oh, right. It should be a mod, and ideally a player mod. That would make it possible to have several different implementations and you could choose the one whose characteristics you like. The vid someone ( @Brady_The?) posted of the boat going up the waterfall gives me a lot of confidence that the multi-block entities are capable of vertical control.

Welcome to the forums, @J Bush You can pull up the command handbook from in-game by typing .chb I believe what you want is something like /worldConfig creatureHostility aggressive

I think that's a good start, but would love it if it played into the steampunk genre with steam/Jonas -powered airships.

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.)