MKMoose

Them's got hands now, but for what? Except messing with a beginner who doesn't know that they can fight back, raccoons are equally as trivial to kill as they used to be, if not easier since they may come back right up to the player after the first hit instead of running away. Unlike foxes which have now been buffed considerably (though while seeking they are still slower than the player's sprint, just like black bears), raccoons aren't even a significant threat mainly because they are barely faster than the Seraph's walking speed (well, technically, they are about as fast as foxes used to be). I would expect wildlife to be much more skittish and defensive, not more aggressive. Granted, at least the animals affected in this RC are now ever so slightly less anemic when fleeing as well, not just when seeking.

Aye, I remember making a similar point in a different place entirely. I was actually asked in the Discord whether I would be fine with this post being used as the basis for a mod, though whether anything will come out of it I can't say. It would naturally be quite interesting to see how the mechanics work out in practice - there's nothing quite like having an actual working example to verify whether what I've thought up actually makes sense. The mythical 5% shatter chance on first quenching strikes again, it seems. It's not communicated in the tooltip, but that's what it does in the code, and I don't remember whether the devs confirmed what the intention was. As for the shattering bug, I might have just glossed over a mention of the watering can. To hopefully clarify what I mean a bit: handbook inconsistency => the handbook states that a piece can only be tempered at most as many times as it has been quenched, but there is simply no such limit in the game, debuffs of tempering outweigh its benefits => due to the way it is balanced, the effects of tempering are minimal or even purely detrimental (especially on a piece which has already been quenched a few times due to the reduction to power acting on the cumulative effect of previous quenchings and the reduction to shatter chance acting on the subsequent ones); the math for it is a bit complex and would require proper optimization to find optimal sequences (people have messed with it in this thread), but either way the actual material savings you can get from it are very minuscule, and are also counterweighed by the time and fuel costs - a newer player would probably be better off if tempering just didn't exist in the current balance, costs and risks of quenching for durability outweigh its benefits => the first quenching for durability gives 1.2 / 1 * 0.95 - 1 = 14% more expected durability per unit of metal, the second one gives 1.3(6) / 1.2 * 0.9 - 1 = 2.5% more expected durability per unit of metal, then after that it's net negative (especially if you also consider clay, fuel and time costs); tempering trades time and fuel for lower shatter chance but the difference is again minuscule - a player who looks at the math will just realize that it's practically not worth it past the first iteration, but someone will inevitably try going for higher durability and realize too late that they're wasting time and resources. As for quenching for power giving sometimes absurd results, I do agree that most players will not really be reaching them, but consider this: the damage increase from copper to tin bronze for a falx is 4.5 / 3.75 - 1 = 20%, the default damage increase from tin bronze to iron for a falx is 5 / 4.5 - 1 = ~11%, even a very achievable 25.48% damage buff (quenched three times with no tempering, on average making one piece out of ~1.4 ingots), from tin bronze to quenched iron makes for a (5 * 1.2548) / 4.5 - 1 = ~39% damage increase, from iron to meteoric iron or steel (which deal the same damage), it's just 5.25 / 5 = 5%. One of these is not like the other, so to speak. While I overall do agree that going past 3, maybe 4 quenchings is neither practical nor particularly impactful for the average player, even the 25% buff causes a really drastic jump over bronze, and a very significant balance shift relative to 1.21. Keep in mind as well that the damage bonus currently doesn't work on spears when thrown, and can't be applied at all to arrows, which significantly shifts late-game balance in favor of melee weapons (and that is also on top of sharpening currently only being possible on swords and falxes). Is all of that intentional? Maybe. Quenching gets counterbalanced somewhat by the changes to the forge. It kind of annoys me that we just don't really have any official information on what the long-term goals are here, but that jump over bronze (combined with a durability increase) is really kind of questionable balance-wise, especially given that it currently only affects melee weapons. The system ultimately isn't as terrible as I might sometimes make it come off as, and the least that I can give to you that it will most likely work fairly well for a more casual player. Frankly, linking this suggestion in the RC post and on the Discord (at least three times if you also count when it was brought up by other people without me asking) has got me a number of reactions from people who aren't normally active on these forums, and there's always a chance that a few of these reactions are knee-jerk over the RNG more than supportive of the suggestion, so I prefer to take that number with a grain of salt when compared to posts which get the majority of interactions from people more active in the forums. Still, the amount of positive feedback was genuinely kind of shocking.

Generally you will need to cool the piece in air for tempering. On a technical level, the game requires that there is sufficient delay between the piece reaching the tempering temperature and cooling to the settled state, which may mean (I haven't verified it to be certain) that you would be able to wait until that time passes and then cool in water the rest of the way through, but either way you won't be able to cool quickly in water right away. In the real process, slow cooling is required to more effectively relieve internal stresses in the metal and form a finer microstructure through carbon attoms diffusing more evenly throughout - cooling quickly introduces internal stresses and uneven grain (just like it does when quenching, but in that case it's considered a side effect of a desirable process), causing the piece to become more brittle. Tempering or annealing can be done in a furnace so that it's even slower than in air, often done overnight in a medieval or home forge, or sometimes taking up to a few dozen hours in some highly specialized processes.

The advice mentioned by other people here is solid, but I do want to mention as well that cassiterite (the tin ore you're looking for) is one of the two ores alongside native copper which spawn in a slightly different way than other ores. There are two different deposit types for native copper and cassiterite (all other ores only have one deposit type, barring some caveats): surface deposits - they only appear a couple blocks under the surface and are best found by digging a few blocks down under loose surface ore chunks, as you have likely been doing, since there is always a deposit under them; those specific deposits are entirely separate from the prospecting system; they are there to get you started with some easily-accessible resources and are not intended as your main source of those metals, at least not in the case of tin, deep deposits - they only form deeper underground (several dozen blocks deep, broadly speaking), and the most consistent method to find them is prospecting (caving is also an option, but it can also be highly dangerous if you're playing on standard settings); finding a few deep deposits this way will provide you with practically all the copper and tin you're ever gonna need outside perhaps of some particularly large projects.

I don't know if it was confirmed by a dev, but it's almost certainly a bug, and I think it started in rc.1. It's part of one of the two major bugs I was mentioning, because you might also notice that the damage buff is actually double that of the power increase from quenching, while it's supposed to be 1:1. The other major bug is that shattering appraently just doesn't happen at all, though I haven't tested that one personally.

A bit of a problem here is that, arguably, the stated vision is not even fulfilled in the current state of the mechanic. The developer behind the mechanic seems to be Tyron, based on this message in the Discord: To which my response at the time was: Whether my suggestion could make a better system, I cannot predict with certainty, but the core issue for me has been from the start that the current system has a bunch of problems and doesn't achieve its own stated goals, which I've tried to achieve better in a more realistic design. To be honest, I've specifically kind of avoided getting too far into details, and even still had to write the more approachable handbook-style guide at request (which I should have probably done much earlier, to be honest). I don't really have any numbers on hand, because I think that balancing them at the design stage is largely a fool's errand. There's simply too many moving pieces, different ways to apply absolute or relative modifiers, implement limits, weigh benefits with costs and time investment. I've analyzed a couple options and even had some mock numbers somewhere which had a few problems that I was considering how to solve, but any number being balanced is heavily dependent on a set of other numbers. As things stand, I don't even really know much about what the devs' intention is for quenching, which makes it difficult to propose anything more specific than I've already done. The handbook guide is still inconsistent with in-game behavior, and there are at least two major bugs with the system. In terms of balance, tempering (at least after one or two iterations) and durability quenching (except arguably the first iteration) apply risks and debuffs that outweigh the benefits, while power quenching can get to borderline absurd numbers after a few iterations, even if at steeply rising cost.

Personally, I've very quickly learned to only eat pies when I can eat an entire slice with no leftover, and I've been unaffected by the issue ever since. That said, I think an even better way to solve this (though significantly more complex code-wise) would be to allow to have a stack of multiple full slices and a partial slice in one slot. The same could apply to liquid containers with different amounts of liquid in them.

I've personally always found that water should be moveable and obtainable, but not easily duplicated, i.e. there should be some natural sources (oceans, underground aquifers, rain) which don't deplete when drawn from, while regular surface sources should be finite. Either way, to your questions. Though I play with moveable water sources, I can say that terrace farms are by far the most efficient type of farm in terms of the amount of farmland blocks per water block, because a single water source would be able to supply infinite farmland if it wasn't limited by world height. It's just much more flexible to let the water flow just the way you want instead of having to build around existing water sources, and terraces can also be very aesthetic in certain cases if you build them in such a way that the water is hidden under the next layer. It can take quite a lot of work to pull off without moveable sources. Covering a lake is the best way to achieve a large, flat farm that doesn't require watering or rely on rain. You can also build a farm around a lake, not necessarily into it, if you don't have the soil or time in the early game or if you prefer the aesthetics of it. Even just a single isolated block of water can supply: 8x 75% moisture tiles (~97% growth speed), 16x 50% moisture tiles (~82% growth speed), 24x 25% moisture tiles (~58% growth speed). And you can increase these numbers if you create channels for the water to flow through to cover a larger area. Naturally, the effective farmland count per water source will be much lower for a larger lake due to overlap, though the total for the entire lake can be very high regardless. Especially if you're willing to accept the lower growth rates, it means that you could just create a ring around a large lake, maybe with a couple extra channels, and be set for the entire game. Watering and rain increase the moisture of a farmland block to 100%, which results in a 110% growth rate (~13.4% higher than a regular 75% moisture block), which means that watering the farmland or settling in a rainy area can be useful in almost any context, not just with moveable water sources disabled. After watering or rain, farmland moisture should decrease to zero over four days (haven't verified it experimentally yet), so you can water it every ~3 days if you're fine with slightly slower growth or daily if not more often if you want slightly faster growth. It takes a bit of maintenance, but especially in a rainy area it is absolutely a viable choice to just skip irrigation altogether.

Am I correct to say that the water is ~80 blocks deep at that reading? Mining underwater and at this kind of depth is certainly a choice, but if you need bronze then it may take a long time to find a better spot than this, because, for many ores, deposits are much more common underwater than on land. If you can dive there safely, then I say go for it.

And yet it is completely untrue that multiple discs can spawn at the same depth close-by for any reason other than pure chance. I've been entirely unsuccessful at replicating what you're claiming in my many hours experimenting with the ore generation and prospecting system, and I can guarantee that you will be unsuccessful at replicating it as well as long as you use an actually robust testing method. Deposit depth is randomized in DiscGeneratorBase.beforeGenDeposit() independently for every deposit using a shared random generator, meaning that the only thing other than chance which could cause multiple deposits to spawn at the same level would be a bug.

It seems to be intentional. Currently, huge boars can only be found in the wild. The huge gray boar is just an elder eurasian wild pig (gray boar). The new species are the red river hog and the warthog, both of which prefer warm climates.

Lignite, bituminous coal, anthracite, malachite, galena, sulfur, borax, lapis lazuli, halite, limonite, rhodochrosite, fluorite, graphite, ketnite, phosphorite. For different ores to various extents - it doesn't matter much for lignite, for example, but can have a pretty extreme effect on galena, sulfur or borax, among other things. Ore depth is randomized independently for every deposit. There is nothing that I know of besides pure chance which could make multiple close-by deposits generate at the same depth.

You might or might not want to consult the FAQ, where Tyron has listed six arguments.

Contrary to seemingly popular opinion, the permille values can actually provide notably more information than the descriptors and allow you to find very nearly exact ore map values, but the catch is that to really use it you would need to be familiar with the prospecting and ore generation mechanics at a deeper level than most people would consider practical. It is not something that I would ask anyone to learn, because the descriptors are sufficient for almost all practical cases. Regarding the question, permille values are roughly correct with a few caveats and they do tell you how much ore is expected in the vicinity, with an especially big caveat for cassiterite. Cassiterite's permille value is currently bugged even more than for other ores, and its actual density is more than 10 times higher than shown - your 0.07‰ reading is actually more like 0.7‰ or more (I'd have to calculate again to tell you the exact value). You might also see it referred to as "ppt" or "parts per thousand", so for example on a 2‰ reading you can expect to find roughly 2 blocks of ore per 1000 rocks, on average. If you wanted to mine a large area for massive quantities of a specific resource, you could use this to estimate how much you'd have to mine for the desired return, but it's not as important if your goal is to find just a single deposit or a few of them. That said, the descriptors themselves can also be misleading, mainly because some ores cannot normally reach the highest reading values. Limonite, for example, will never reach a reading higher than ~0.5 => ~7‰ ("high") outside of certain edge cases (e.g. underwater mining), and a roughly 3‰ reading can be easily considered a highly valuable limonite spot due to how rare it is, despite it being technically "poor". Granted, besides pigment it has nothing going for it over hematite and magnetite anyways, but it serves as a good example. Regarding your readings, they are pretty normal, though you've been getting a lot of low ones and not many green dots. You might want to consider spacing out your reading locations a bit further apart to cover a larger area, not unlike others have suggested. I usually take readings in a roughly 100-block grid, sometimes up to 300-400 in especially empty areas - it's good enough resolution that it's rare to miss any significant hotspots, and past that it really doesn't matter whether you hit the exact local peak or a slightly lower reading a few dozen blocks away. For all three of these specific ores (cassiterite, sphalerite, bismuthinite), looking for at least "decent" readings is perfectly fine, especially for your purpose of just finding a bit for a jump to iron. For higher quantities, I would recommend "high" or better. It can go all the way up to "ultra high", but you shouldn't treat that as the goal. You can find these three ores almost anywhere, as the only notable limitations are that cassiterite primarily spawns near the middle between surface and mantle, and bismuthinite doesn't form in sedimentary rocks.

Small update as of rc.6: many bugs related to berry bushes have been fixed over rc.5 and rc.6, including the "young" state which was previously getting skipped being now functional, so the bushes are now much closer to functioning fully as intended and you might want to play around with them again if you've experienced bugs with them in earlier versions, as I anticipated, two specific bugfixes have now extended the time from planting a cutting to bush maturation from 2 months to 6 months on average, the medium fertility soil requirement seems to have been removed (berries planted in low fertility will start off "struggling" and require fertilizer much earlier than in medium fertility, while bushes planted in barren soil won't produce fruit at all without fertilizer). FYI, Pizza said in the Discord recently that they can't be made properly seasonal yet due to them being one of the primary foraging foods. While I don't think it would be a major issue due to the growing season generally starting around June or even earlier (especially in warmer climates) for species like strawberry or blueberry, that was the unofficial dev stance, so we might have to see more foraging foods added before berries get a single harvest window.

I feel like somewhere in here there's an absolutely amazing way to turn RPG-like levelling into something much more interesting and immersive. The exact mechanics are a bit up in the air, but the general idea of player progression by slightly tweaking the class identity sounds very enticing. I think it would be fine enough to keep them limited to buffs in most cases, though, especially in the case of the clockmaker's proposed upgrades due to how niche they tend to be. I think Tyron has expressed interest in allowing some traits to be gained during gameplay, so I think something like this is absolutely on the table for the future.

If you mean the fix to the number of growth stages when calculating growth times and nutrient consumption being one higher than it should be, then that seems to have been effectively reverted now by adjusting the base nutrient consumption and growth time defined for individual crops to 1 - 1 / growthStages of the 1.21 values.

It's much slower than that. Roughly two years are from the starting state in medium fertility (50%) to struggling (30%). From bountiful to barren it takes something like 20 years, if you fertilize a bush initially and then forget about it. There's a reason I've been saying the fertilizer requirement is practically irrelevant. Two per year should be the maximum in temperate climates, at least when not using a greenhouse.

As of rc.5, seemingly all changes to crops besides halved grain yield and increased wild grain frequency seem to have been rolled back. The changelog only mentions one fix: However, it seems that the nutrient consumption and growth time of all plants has been multiplied by 1 - 1 / growthStages, returning the effective consumption and growth time to 1.21 values. Unless maybe one other bugfix still changes things relative to 1.21, but either way most changes are no longer a thing right now.

I've got a rough mockup of what a handbook entry for this could look like. To start off, a couple notes: I've tried to keep the style similar to the in-game handbook, without the kind of formatting that I would typically use in larger text blocks like that (which, to be honest, the handbook could greatly benefit from in a few places), the total length of this mockup is roughly double that of the current handbook entry for quenching and tempering, caused in large part by there just being more individual mechanics to cover, I'm not exactly certain on the exact level of complexity the system should have - I decided to include a couple mechanics I've initially noted to be optional, mainly to lean into making temperature management more in-depth, but this is ultimately just a mockup; I've also slightly relaxed some constraints which I felt weren't doing much, there's a few underlined words which would likely link to an appropriate handbook page or search, and more information could be found in those separate pages, having appropriate tooltips at many stages of the process would help a lot to inform the player what they've just done, what they're about to do, and what they can do, without having to go back to the handbook too many times. You'll also notice that I've elected to use "annealing" for normalization, with no functional changes, and I've also switched it out in the main post. It seems to be a more historically appropriate term, even if it might be slightly misleading nowadays. As a side note, the roadmap actually says "quenching, tempering, annealing", so including annealing as well seems pretty neat. Heat treatment of ferrous metals After forging a tool or weapon from a ferrous metal (iron, meteoric iron or steel), heat treatments can be performed to improve its qualities by controlled heating and cooling. All heat treatment processes start with bringing the metal up to a certain temperature range, which is shown in the tooltip of the worked item for each process. Once the item is heated past the minimum temperature, it should be kept in the desired range for several in-game minutes, which ensures that the metal temperature is uniform and the treatment is more effective. Finally, the workpiece has to be cooled down, depending on the type of treatment either slowly by allowing the item to cool in air, or rapidly by submerging it in a barrel of a quenchant liquid, for example water. In many cases, annealing alone is sufficient to obtain a high-quality tool. A more advanced process requires performing annealing, quenching and tempering in that order. Annealing Annealing is used to improve the durability of tools and weapons. It is also useful later as a way of reducing the risks of quenching. The temperature that the item has to reach for annealing is indicated by the metal turning to a red color. After soaking in that temperature, the item has to be cooled slowly in air. Annealing can be performed repeatedly, but the relative durability increase provided by subsequent iterations will diminish quickly. In order for repeated annealing to have the appropriate effect, the workpiece has to be kept close to the minimum required temperature, as heating it up excessively will remove the effects of prior heat treatments. Quenching Quenching can be used to greatly improve the power of tools and weapons, at the cost of making them brittle, which severely reduces their durability, and at the risk of breaking them. In order to amend the durability penalty, the next process of tempering will be necessary afterwards, while the risk of shattering the item can be controlled with several factors during quenching. This process can be especially valuable for weapons, but for some tools power value may provide little to no benefit. Quenching is a risky process which creates great internal stresses in the metal, which can sometimes cause the workpiece to shatter. An item which has been annealed will have its risk of breaking reduced, and repeated annealing will reduce that risk further. Similar to annealing, the workpiece needs to be red-hot for quenching, though the temperature should be slightly higher. Quenching from the optimal temperature range will produce slightly improved effects, but excessively high temperatures will increase the risk of shattering as well. The last step for quenching requires the metal to be cooled quickly by using Shift + RMB on a barrel of quenchant liquid like water, while holding the workpiece using tongs. The effects and risks of quenching can optionally be affected by certain other factors as well, including choice of different quenching medium like oil or brine instead of water, or covering the workpiece in fire clay. After an item has been quenched, you need to make sure not to heat it up too high above the tempering temperature, as doing so will reverse the effects of prior heat treatments. This means that a quenched item can only be tempered, unless you wish retry annealing and quenching if the first attempt was unsatisfactory. Tempering For a tool which has been quenched, tempering can be used to restore the durability back up and achieve a more satisfactory balance between durability and power. It will have no effect on unquenched tools, or on tools which have been heated back up too high after quenching. This process requires much lower temperatures than annealing and tempering, and similar to annealing it requires the workpiece to be cooled slowly in air. After tempering, the durability of the item will be increased back up, but the power will decrease slightly. More durability will be recovered when tempering at higher temperatures, while tempering at lower temperatures may be more useful when trying to preserve as much power as possible. Tempering can be repeated, albeit with diminishing returns, and durability can even be brought up to on par with an annealed item this way.

A simpler explanation of the detailed process, or a more simplified process, just to be clear? It's a seemingly pretty common suggestion, but I'm not sure what it's supposed to solve except reduce frustration when the workpiece shatters on a very low chance. Iron is extremely plentiful as it is if you know how to find it, and the added cost from shattered tool heads isn't very significant until you start going into extremes. Obtaining an ~37% power buff by quenching 5 times will get you to shatter on average ~1.3 tool heads, and that is roughly the maximum I would consider reasonable for the average player. By removing or heavily reducing the resource cost, you'd be essentially removing a balance lever from quenching with nothing to replace it and leaving time and tedium as almost the only factors keeping the player from outright absurd creations. I could also see it as a way of being more forgiving for a new player who only has a tiny quantity of iron, though a small problem then appears: resmelting the iron nuggets is done more optimally using a full bloomery with 120 nuggets, so smelting just 20 can be seen as a waste, and if the workpiece returns less than 20, then you wouldn't even be able to resmelt it into a new ingot. Granted, this could be addressed by allowing the bloomery to take multiple inputs, with some caveats. Okay, this I can work with much better. I'm impressed with how well you put this, honestly. I don't really have much to say at the moment other than that the basic process is really quite simple on the surface (as described in the "main suggestion" section) and several of the more complex effects are only required under the hood to force this specific order of operations in a controlled way and to achieve a specific balance between all the different parameters. I'll see if I can write something more clear and concise at some point. Normalization also offers an easy way out with a neat durability buff for anyone not finding themselves ready to take on the more complex process yet. If I had a nickel for every time someone told me that this was already possible, I would have two nickels. Keep in mind that as long as the temperature readout is perfectly accurate, then the color is mostly just for immersion. You might recall a similar argument from when I was saying that the temporal stability gear in the middle of the screen is too accurate and too reliable and ends up making the player pay too much attention to the UI and not the world, so any diegetic signs of unstable areas wouldn't really be useful anyways unless the gear is changed or removed. I haven't exactly checked how realistic the current colors are and how practical they would be in gameplay, but I think they would likely require some adjustments to allow actually telling the temperature with good accuracy in the range where it matters most without an excess of guesswork. That this would likely have to be an optional setting I did say myself, but nonetheless I think it would be a really cool one, especially suitable for Homo Sapiens. Even if not remove the temperature readout, I would like to see it rounded, at the very least to an integer. Optionally to larger steps like 10 C, and maybe even with some random error if we're feeling more adventurous, as a way to require a bit more deliberate temperature evaluation and not a single robotic comparison.

In several ways, the recent changes have already significantly nerfed berries as an early-game food source, while arguably making them better than they used to be in the late game. The expected yield from a ripe wild bush is reduced by ~6%. It used to be that (if I recall correctly) 1/3 (33%) of wild bushes would be ripe in newly generated chunks and 2/3 (~67%) of wild bushes would be ripe under natural conditions (except those eaten by animals), while now it's only 1/4 (25%) in newly generated chunks or 2/7 (~29%) in the longer term (ending up with a ~25-60% reduction in the total number of ripe wild bushes). Granted, there are now new species which increase that quantity back up somewhat, though as of now the effect is at best some 20%. If my math is right, then that's something like a 40% total reduction in the expected wild berry yield, while the time of year is right [as of 1.22.0-rc.7, with even more new species, the yields are again up a bit, though the difference isn't massive]. And that's combined with ripe bushes being potentially more difficult to notice, grown bushes taking more time to wake up after winter, cuttings taking their time to grow, traits making it much less practical to take every single bush home, and two harvests per year down from three being usually the maximum in temperate climates. Contrast that with cultivated bushes, which have 20% higher yield in the "healthy" state or 80% higher in the "bountiful" state and can be boosted further with the "heavy bearer" trait to respectively 38% or 107% higher than 1.21 bushes. Even considering two harvests and not three, that's still -20% or +20% (without the trait) and -8% or +38% (with the trait) total yearly yield for "healthy" and "bountiful" bushes respectively, relative to 1.21 bushes. Keep in mind that it consequently also takes significantly less total time to harvest a given amount from the bushes, especially if you happen to get the "densely clustered berries" trait. I would absolutely support adding new food sources, potentially tubers, roots, herbs, bird eggs, and other stuff of this kind, to bolster the early-game hunter-gatherer experience while berries aren't in season, and I've even suggested that somewhere before. That said, I don't think new food sources are necessary to achieve a satisfactory balance with berry bushes even if they are made strictly seasonal. Early berries fruit around June, which I think could even make for a very neat early-game experience. The player would at first have to struggle somewhat to feed themselves for a couple days, and once they are sufficiently familiarized with food scarcity and likely have learned about some wild plants and perhaps tried hunting, they would be granted a bit more breathing room for at most around five months to prepare for the real challenge that is winter. If taking food away from newer players is a concern with reduced satiety, then that's where the second part of my suggestion from a while back may fit right in: dense thickets of larger bushes like blueberry, raspberry or blackberry, and carpet-like large patches of small bushes like cranberry or cloudberry, numbering from a couple dozen to hundreds of bushes, or even many thousands in certain cases where they may cover the ground almost like grass (e.g. in the arctic tundra). Currants, strawberries and some other bushes can remain in smaller and more spread-out patches for the most part, and may be designed to be more optimal for cultivation in one way or another. What I take issue with in the way that berries and the overall food system are currently balanced is that they seem to neglect certain arguably obvious balance levers which could greatly increase the depth and variety of various food sources in the game. The moment we've finally got some sort of maintenance requirement as a new lever, it's smacked right onto the food source which needs it arguably the least, and made borderline irrelevant to compensate. If berries were made very bountiful but limited to a short avaliability window, then being labor-intensive to collect (clarification below) and quick to spoil would work perfectly to push the player to invest into other food sources, as well as into preservation methods, instead of making all balance revolve about food scarcity. They would be an amazing food source at the beginning of the game, especially during Year 0, but suboptimal long-term due to their inherent properties. Fruit trees would gain value in a very natural way, since they produce a lot of fruit that can be collected more quickly and doesn't spoil as fast. Berry bushes and fruit trees used to be very similar in most aspects except that trees would take longer to set up but their fruit would last longer. Instead of leaning into this distinction and introducing new differences, they've been made more similar in several ways, which to me is a wasted opportunity at best. Wouldn't it be more fitting to make berries explicitly into the early-game, accessible but inefficient food source, while making fruit trees require a bit more attention to maintain in good health but reward the player with even greater yields? By "labor-intensive to collect" I mean just the time it takes to collect berries off the bush once you're next to it. Could also be neatly increased by giving the larger bushes four hitboxes on the corners (more would probably be overkill, less would be difficult to arrange neatly), requiring the player to collect smaller portions of fruit bit-by-bit. Alternatively, multiple harvesting stages could work, though that would be comparatively pretty boring. I don't think the same would work well for fruit trees, to be clear, unless maybe just for the ones with smaller fruit, especially cherries and lychee. The issue with subsisting off wild bushes to me is that they're tedious to collect intentionally, but extremely easy to collect while traveling, which means that they're annoying most of the time but can completely trivialize long-distance travel. Just recently I've run ~2.5k blocks, consuming a full 1.5k satiety hunger bar along the way, and in that trip I collected ~8k satiety worth of berries that I stumbled upon, not even bothering with crops and mushrooms - one sample isn't indicative of much, of course, but +~400% satiety off a random trip filled almost entirely with running seems pretty crazy, especially since it's after nerfs. That's largely how I made a two-way trip to the tropics, by the way, ~100k blocks total yet without taking any food with me. Making berry patches larger but much more time-consuming to collect would mean that harvesting them midway through travel would require stopping for an extended period of time, whereas harvesting a patch near home may be roughly unaffected in terms reward per unit of time on average, but more convenient and intentional than having to run between many patches a few bushes each.

It is partially random, on average 3 months, 2 days and 4 hours, though the variance is low. Just to note, keep in mind that nutrient recovery (just like crop growth speed) is slowed down by 10% for every 1 C below 10 C, so nutrient recovery over winter is much slower, or entirely paused during the coldest months.

Hm, I neglected that part somehow. Yeah, it is a bit odd that crop rotation without a fallow period is non-functional, except the little bit that will recover between ripening and next planting. I don't feel like it's too bad if you time it neatly. Four fields, one nutrient each for three of them, the fourth one left fallow, and switch them around after each harvest. Some aspects could be tweaked depending on whether you even need any P crops, or some other factors. Kind of heavy-handed, but actually incentivizes a more proper crop rotation cycle now with three nutrients and a fallow period. It's not ideal, but in the previous balance you often didn't even need to use all three nutrients, and just alternating two of them was often entirely viable, so I feel like some sort of in-between option would be great.

The realistic process is roughly: Normalize (once or more, may be skipped), to reduce risks of quenching and improve toughness. Quench (only once; if unsatisfactory then go back to 1. and retry), to maximize hardness at the cost of making the metal brittle. Temper (once or more), to balance out a desired proportion between hardness and other properties. I can understand simplifications and minor discrepancies, but the order of operations in the current system isn't similar to the realistic process at all. Tempering is actually in this weird spot where the in-game implementation is somehow more similar to real-life normalization in certain regards, because it's done before quenching to reduce risks. Repetition may be greatly reduced by just tweaking the numbers, that much I can agree with. But making tempering less effective would make it almost completely useless. It's a matter of hyperoptimization in the best case scenario (quenching for low power or for durability), while for high-power tools tempering is strictly harmful in the current balance. The problem with quenching for durability is that it doesn't even offer a proper tradeoff like power does (because power exists on a completely separate balance axis). Shatter chance and durability increase are effectively the same effect but going different ways, and once the risk outweighs the benefits, it's just fundamentally not worth it. The first iteration gives you a 14% expected effective durability increase (controlled for resource loss). The second iteration falls down to a 2.5% expected effective durability increase, or ~4.8% if you temper in-between. Starting from the third iteration, it becomes an expected loss, and that's only considering material savings, while time, fuel and clay costs actually make it even less worthwhile. Even if you abuse the ability to temper indefinitely, which is currently possible though contradicts the handbook guide, it will quickly start costing you more time than it's worth in durability. Why even allow the player to waste time and resources on something like this? I argue that it doesn't, because it doesn't have any standard risk-reward mechanics. A proper risk-reward mechanic should generally always have at least one of the following: scarce opportunity - if the player is allowed to risk wasting a limited opportunity for a greater reward, then the risk feels more impactful; in the current system, the risk is taken very frequently, failure doesn't present any meaningful setback besides wasted time, and retrying is allowed instantly, tightened error margin - if the player is allowed to play in a way that leaves less room for error in mechanical execution in exchange for some benefits, then the inherent risk naturally creates tension and engagement, and it also serves as a method of self-regulating difficulty; in the current system, the "risk" is purely an uniteresting random chance. There's also a lot of other things that could be mentioned here, but scarce opportunity and tightened error margin are, in my experience, the most common and most essential parts of a good risk-reward mechanic.