MKMoose

4 hours ago, vewvew said:

The only argument going for it, is they wouldn't earn 100% from it [...]

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

On 3/30/2026 at 3:18 AM, Telios said:

The highest results I've found so far in order are 0.07‰ cassiterite, 0.50-0.59‰ sphalerite, and 2.06‰ bismuthinite. Hilariously enough I've found a 4.02‰ hemitite reading nearby. Are the readings for bronze alloy component materials usually that low?

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

On 3/20/2026 at 6:42 PM, LadyWYT said:

I'd prefer [a single harvest window per year] too, but I don't think the game is quite developed enough to go adding that feature yet. 

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.

8 hours ago, williams_482 said:

One of the intentional changes in this update did increase crop nutrient consumption, which will effectively reduce growth speed. So you can now expect them to grow slower than in 1.21 still, although not quite as slowly as in the previous 1.22 RCs. 

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.

6 hours ago, LadyWYT said:

I think it's supposed to take about two in-game years for a berry bush to deteriorate from bountiful to barren if the player takes zero care of the bush.

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.

5 hours ago, Chrondeath said:

How many harvests are there within two years....? 

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:

Quote

Fixed: Farmland would not recover while growing, instead recovering when the crop was ripe

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.

On 3/22/2026 at 3:13 PM, LadyWYT said:

Basically I'm struggling to picture how a system like this works in actual gameplay, so something like a handbook entry-style explanation or simplified walkthrough of how the process could unfold in regular gameplay is mostly what I'm looking for. All of the data above is useful for explaining how the process works in real life, but I'm just not sure how it's supposed to really plug into the actual gameplay, is all.

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.

11 hours ago, LadyWYT said:

While I do like the detailed writeup, I'm also going to bug you for a simpler explanation.

A simpler explanation of the detailed process, or a more simplified process, just to be clear?

11 hours ago, LadyWYT said:

The one modification I would make to the current system, I think, is rather than have work items shatter and vanish into thin air, they should just shatter into nuggets that can be smelted back down(which means that there needs to be a way to smelt steel nuggets back into ingots, but anyway). Doing so would allow the player to fail making the item, but still allow them to keep the material so that they can try again.

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.

11 hours ago, LadyWYT said:

Overall the main issue I run into with the writeup presented here, is similar to the one that Tyron seems to have expressed. It's pushing more into the "realism for the sake of realism" territory, rather than staying in the realm of "fun gameplay that is also realistic". Basically what kills the idea for me is there's so much information to process here that it becomes very hard to visualize trying to play something like this in the game itself, alongside all the other gameplay loops, and having fun without getting too frustrated. Or I suppose in other words, I'm not sure how all of the above information could fit into a single handbook entry that can easily be understood with a quick reading or two.

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.

11 hours ago, LadyWYT said:

I do want to note that this is already somewhat possible to do in the current game. I wouldn't recommend removing the temperature readout though, aside from an optional "hardcore" setting, since that could potentially cause some issues with colorblindness. 

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.

6 hours ago, LadyWYT said:

Basically, a change like this is likely to cut early game food supply by over half, and will probably be a little too punishing on newer players. There would need to be a few more food options, I think, to help give them a fighting chance and keep things balanced.

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 10%. 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. 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.

6 hours ago, LadyWYT said:

In some ways that's more realistic, however, I think this kind of change would overall be a detriment to gameplay balance. The seasonal harvest part is fine, and something I would eventually expect the game to implement. The lower satiety is the biggest problem, since berries are an important early game food source. Enough newer players seem to struggle to keep themselves fed that I'm not sure it's a good idea to make it an even harder task, at least in that manner. When paired with seasonal harvests, it's going to be especially brutal, given that the game starts in May and berries haven't necessarily brought forth yields yet.

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?

6 hours ago, LadyWYT said:

As for the labor-intensive part...this is why it's ultimately better for the player to create their own berry patch at home, rather than rely on wild foraging to avoid dealing with the annual maintenance. Even with all the wild patches marked, harvesting them can easily take a handful of days since the player has to cover a wide territory(which exposes them to hostile wildlife and other threats) and wild bushes don't necessarily ripen at the same time. Having cultivated bushes at base saves a lot of time, since they all tend to ripen at once and all the player has to do is take a couple seconds to step outside and check them, and spend a few minutes harvesting if the berries are ripe. Adding a little bonemeal/other fertilizer once per year also only costs a minute or two, depending on the size of the berry patch, and is a cost that diminishes with time. 

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.

44 minutes ago, williams_482 said:

How long does it take fallow farmland to recover nutrients? If it's only ~3 months to recover 50 points then this works fine. 

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.

38 minutes ago, williams_482 said:

That must be a bug, because it defeats the point of crop rotation. 

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.

38 minutes ago, williams_482 said:

Rotating through three crops and then leaving all of your fields to fallow at the same time and starting an entirely new farm just feels bad, especially if it's expensive Terra Preta fields that you're leaving barren.

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.

4 hours ago, Erik said:

Quenching and tempering processes replicate the basic idea of what they are in real life

• Quenching being fast cooling from higher specific temperature range
• Tempering being slow cooling from lower specific temperature range
• Only the element of soaking the metal at specific temperatures is lost

[...]

While not entirely realistic, it still realistically depicts the basic process of quenching and tempering. I don't think we need to go further, especially if it would harm gameplay.

The realistic process is roughly:

1. Normalize (once or more, may be skipped), to reduce risks of quenching and improve toughness.
2. Quench (only once; if unsatisfactory then go back to 1. and retry), to maximize hardness at the cost of making the metal brittle.
3. 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.

4 hours ago, Erik said:

Tedious process: This is in my opinion mostly a balancing issue. There should be an incentive to reward additional effort, but currently the risk reduction of tempering appears to high. Making tempering less effective or maybe just increasing the base shatter chance could "shorten" the process significantly.

[...]

Hyperoptimization: Same solution as 1.

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.

4 hours ago, Erik said:

Quenching for durability: Here I also disagree to see this as a problem. If it were a problem, the solution would just be to remove quenching for durability. Quenching for durability is still risk vs reward, though tempering should probably have a drawback (like when quenching for power), to reduce tedium.

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?

4 hours ago, Erik said:

It presents a working risk vs reward vs effort mechanic instead of player skill expression

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.

16 minutes ago, williams_482 said:

Is that all nutrients, or just the current crop nutrients?

All nutrients - recovery is completely paused while a crop is growing. I'm frankly unsure whether it's an intentional change, but that's what it is right now, and it's arguably better from a design perspective, even if not ideal.

Once the crop ripens, recovery resumes again, though at a much slower rate for the nutrient preferred by the crop.

On 3/18/2026 at 4:00 PM, williams_482 said:

The bug which was fixed was a "fencepost problem" with nutrient consumption as crops grew. Flax, for example, has nine growth stages and is supposed to consume 50 K nutrient. Previously it was consuming 50 / 9 = ~5.5 K per growth stage. This is wrong because although there are nine stages, there are only eight transitions between stages because crops start at stage one, so flax should have been consuming 50 / 8 = ~6.3 K per growth stage.

The changelog mentions two changes separately:

Quote

• Fixed: Crop growth was 10% faster and consumed 10% less nutrients than intended
• Fixed: Farmland crops consumed slightly less soil nutrients than intended

I don't really know what is what here, but there seems to have been another change as well: farmland no longer recovers nutrients while crops are growing on it. It used to be that farmland would stop recovering nutrients when it had a ripe crop on it, apparently. Now this was changed to where farmland seems to only recover nutrients when empty or when it has a ripe crop on it. Both before and after the update nutrient recovery is significantly slower for the nutrient preferred by the currently planted crop.

On 3/18/2026 at 1:35 AM, Calmest_of_lakes said:

Is it my imagination (probably the case,) or was medium fertility farmland OR flax nerfed? I used to be able to get 1, maybe 2 flax crop harvests per year back in 1.21, but now, my flax stops maturing after reaching stage 8/9. It's been a solid week of being stuck on stage 8/9, and it's too late to harvest, being in the negative temperture range in october where I set up my home. Is this a bug, a deliberate change, or me being silly? Do I need potash in order to grow flax, now?

Based on a quick test, flax planted in medium fertility soil used to take ~2.5 months and leave the farmland at ~15 K (~35 K net uptake) at the time it finishes growing, whereas now it seems to take ~3.5 months and leave the soil at 0 K (50 uptake).

I do generally like the change for the most part, or at least the general direction, because it used to be quite easy to outright ignore the nutrient levels and still have almost zero issues with farming, whereas now fertilizing, crop rotation and better soils are much more useful. That said, especially combined with the yield reduction for grains, this is a very significant nerf that will in all likelihood just cause people to build even larger farms than they used to make. If they want to address farming being nearly free food, then the current plant-and-forget cycle should also be changed in some way, instead of just making everything slower and less efficient. Few methods would achieve this nearly as effectively as requiring more care and maintenance for optimal growth.

12 hours ago, LadyWYT said:

Overall, using bonemeal as an annual fertilizer doesn't seem entirely unrealistic, especially not from a gameplay standpoint.

I don't like this, and I think I'm gonna gloss over it for my own good. 

13 hours ago, LadyWYT said:

Needing to care a little for the bushes to keep them productive also makes them feel more like plants, and not so much leafy vending machines.

As much as I agree with this, I feel like berry bushes are quite literally the only food source currently in the game where this is unnecessary if not harmful from the perspective of game balance and pacing. I'd argue that berry bushes should be limited by low satiety (I personally see no significant issue with just nuking it down to 40), seasonal availability window (different for different species), and being very labor-intensive to collect (in part because of the low satiety).

They could actually take much more optional maintenance than they do now to make very good bushes, but then that would explicitly be a small high-effort garden that the player voluntarily chooses to maintain instead of a massive plantation. And that optional effort should go into alleviating some of the drawbacks of wild bushes like short availability window and labor-intensive harvesting, instead of just being a boost to yield which the player can nearly just as well get by simply planting more bushes.

12 hours ago, LadyWYT said:

I'd like to see pruning as well, but I think it's better suited as additional maintenance mechanic to help bushes become productive more quickly, or train them to acquire better traits over time(potentially even losing bad traits they may have started with). Trying to swap fertilizing for pruning now seems like it would not only remove that kind of potential depth, but would probably delay the 1.22 release since the code and art assets would need reworking to accommodate. Removing the maintenance requirement entirely just makes the bushes less interesting.

The new bushes require seemingly some of the most complex texture work that the game has seen so far with dozens of individual textures per bush, so I'm wondering whether they even manage to fit all the new fruit types into the update, let alone a second set of new textures that pruning would almost certainly require (unless they use some clever masking, but the results of that most likely wouldn't look as good, and would still have to be tailored for every bush individually).

I'm not quite sure where the idea of swapping fertilizer to pruning even comes from, though I can agree that just swapping it would be a pretty ill-advised idea. That said, removing the fertilizer requirement (just the requirement via the "barren" state, not the rest of the bush health system) would change almost nothing in the current balance. Well, at least as long as the arbitrary medium fertility soil requirement remains in place and bushes aren't adjusted to consume nutrients during initial growth.

Pruning as a way of getting new traits onto bushes does seem like an interesting idea from a gameplay perspective, though at which point would new traits be applied? It seems to me like a better way to implement creating new traits may be to just make cuttings occasionally gain or lose traits when planted. Granted, it may end up a bit annoying to have some outliers with additional or missing traits in the middle of a berry plantation.

31 minutes ago, SeaWarriorSon said:

Does it require a "large boar" to breed?

If not, do the children get a random variation from between the two parents?

From what I can find, huge eurasian pigs can interbreed with the regular ones (though not with the other species that spawn in warm climates).

The baby will always grow into a regular variant - the huge ones can only be found in the wild.

49 minutes ago, Blaiyze said:

When I first saw the fertilizer requirement, my initial knee jerk was "oh great, we have to fertilize ALL THE TIME?" and then I saw people who actually have tested it, and I think it's written more specifically in the update (my knee jerk just hopped over this part I think), that the fertilizing is literally once per year. Which honestly, that's nothing. Seriously, I don't see the big deal if it's one slap of bonemeal per year. If it were more tedious, with having to fertilize throughout the entire initial growth of the cutting, I could understand that being a frustration.

It's only once per year for bone meal, and about once every ~2 years for other types of fertilizer. That's in the first couple year, and it falls off over time. I actually don't know whether this change (nutrient consumption being reduced over time) was planned from the start, or added in as a quick solution to the initial heated reaction. In the current balance, fertilizing isn't even necessary for short-term worlds, up to ~2 years.

49 minutes ago, Blaiyze said:

I've always thought that berries were far too OP early game, but I think they were made that way partially for early game food security. The addition of fishing really bridges the gap. I also prefer the concept of berries ripening and having a single harvest window per year, which is on par with how berries work IRL and simply makes more sense. Especially considering berries became useless pretty quickly once farms were up and running and food stability had been achieved. This makes them more viable long term particularly with the variants. It makes foraging early game perhaps a touch more complex but means actually paying attention to/marking down those berry patches as you explore.

They ripen usually twice per year now, which is a bit more better than up to three times (assuming temperate climate). I've been also arguing for only one seasonal harvest and some changes similar to what you're mentioning, and Pizza (one of the devs) has responded that the hope is to eventually make all plant life seasonal, even flowers. Naturally, that will take some time, but it is a pretty neat goal to aim for.

Berries being somewhat OP in the early game has actually been probably the single biggest argument in support of these changes. My opinion is that this wasn't really a problem in the first place and should have been addressed differently (cuttings and a seasonal growth cycle would have nerfed them plenty - no real need to tack on much beyond that in terms of balance), but it is undeniable that it has been solved one way or another with this rework.

32 minutes ago, LadyWYT said:

Having an actual use for that bonemeal is going to be so nice, and annual maintenance isn't a big deal. [...]

I'm also not convinced that switching the annual fertilizer requirement to an annual pruning requirement would actually solve very many of the complaints either(plus it would make bonemeal a lot less useful).

I've never understood this point. Surely, if the problem is "too many bones", then we could just add a whole range of interesting and historically accurate uses for them? Bone meal apparently hasn't been a recognized thing until the 17th century, whereas bone broth, bone glue and a whole host of products of bone carving have seen significant use since prehistoric times.

What actually has changed

A description and mini-guide to the changes. Most of this information you can roughly get from the handbook. Includes a couple potential objective issues, especially those which are unlikely to change in the foreseeable future.

1. Reworked visuals. Generally speaking: no longer a cube, more detailed, more realistic and more varied. Ripe fruit can be more difficult to notice, especially on struggling bushes. They can't be pruned anymore, but returning this functionality would likely require a lot of additional texture work on top of what the devs have already taken on with several new fruit types alongside the reworked ones.

2. New species. As of now, strawberry and beautyberry have been added. A whopping 8 more new fruit types are in game files but not obtainable yet, though I don't know whether all of them are going to be added in 1.22 and whether all of them are going to be implemented as fruiting bushes, and three may realistically fit better as fruit trees.

3. Cuttings. Bushes now drop a few pieces of plant debris when broken, only useful for rot. In order to propagate the bushes, cuttings have to be taken from them using a knife and planted in soil, and they take a few months until they grow into a proper bush. They grow in two stages, from cutting to a young bush, then from young to a mature bush. The exact time is currently 8.5 +/- 2.3 months until the first harvest (sum of cutting growth, bush maturation and the first fruiting cycle), though it may still change - either way it's long enough that it will be unlikely if not impossible to get any significant berry harvest in Year 0 before winter hits. A cutting can be taken from a bush only once per year. A cutting has to be planted within 15 days of obtaining it.

4. Adjusted growth cycle. I'll skip an exact description for now, but the most important practical differences include: extended growth time from empty to ripe bush (2 => 2.5 months), shortened growth window (they take longer to start growing again after the winter) and shortened ripe duration (4 => 1 month). Overall, it seems generally impractical in temperate climates to harvest berries more than twice per year. Different species have slightly different parameters. Also, as of rc.6, bushes require sunlight to grow.

5. Bush health and fertilizer usage. Bushes planted from a cutting now require fertilizer to maintain good health. A bush has four possible states, depending on its average nutrient level:
- 80-100% nutrients => “bountiful” - produces 50% more fruit,
- 30-80% nutrients => “healthy” - default state,
- 10-30% nutrients => “struggling” - produces 50% less fruit,
- 0-10% average nutrients => “barren” - doesn't produce any fruit at all.
This does not affect wild bushes - wild ones start off randomly either "struggling" or "healthy" and stay in that state indefninitely (and can't be fertilized). Bushes planted from cuttings start off from an amount of nutrients determined by the soil they are planted on (the same level as for farmland), and then they consume a portion of nutrients every time the fruit ripens (an equal amount of all three nutrients, more is consumed when the bush is more healthy). The nutrient consumption falls off slowly over time, becoming almost negligible after ~15 years and very nearly zero after ~25 years. The amount of fertilizer you need to use and how early you have to use it after planting depends on the soil you use (and it’s practically the only effect that soil ends up having on the bush). For low fertility soil, the bush will start off in the "struggling" state, so you're generally gonna prefer to fertilize it immediately or just plant in better soil. For medium fertility soil, you will generally want to add at least one piece of fertilizer after about two years from planting the bush, and then some more within the next couple years. Most players won’t generally need to use more than ~4 portions per bush in a typical multi-year playthrough, or a bit more up-front if trying to keep them "bountiful". In the extreme, ~10 portions in total (a bit more if only using bone meal) over up to ~10 years are required to bring a bush to the “bountiful” state immediately and maintain it indefinitely. Strawberries are an exception, since they have halved yield and halved nutrient uptake, so they almost don't have to be fertilized at all besides the initial cost of bringing them up to a higher health state. It is currently possible and arguably optimal to sustain the bushes only on one nutrient and not all three, which seems like an exploit but I don’t know when and how it will get patched, if at all.

6. Fertility requirement specifically (the “barren” state). A bush which falls below 10% average nutrient levels will enter the “barren” state, in which it no longer bears fruit and has to be fertilized to produce again. For medium fertility soil, if the bush doesn’t get fertilized initially, it will happen after ~8 years, I think, if I didn't miscalculate something, which is borderline irrelevant for the average player - it's entirely possible to just skip fertilization altogether, and you'll just be collecting half-yield bushes. Fertilizing the bush planted in medium fertility just a tiny bit makes it impossible for the nutrient levels to fall to “barren” - they will stay “struggling” or better forever. I’m separating it from bush health as a separate feature, if only because it was initially very controversial and I want to see separate sentiments for fertilization in general, and specifically the requirement to fertilize lest the bush stop producing fruit.

7. Medium soil fertility requirement. A cutting can only be planted on medium fertility soil and above. As of rc.6, this seems to have been removed. Keep in mind they will start off "struggling" in low fertility and require fertilizer more quickly, while on barren soil they won't produce any fruit at all unless fertilized.

8. Traits. Some bushes can have a few small effects applied to them, which can be either negative or positive. Increased/reduced yield, nutrient uptake, harvest speed, ripe duration. Those traits persist when bushes are propagated through cuttings, which means that you can find a really good bush with multiple good traits and propagate it out into a large farm. However, new traits cannot be created by propagating bushes - you have to find good wild bushes and propagate them. Cuttings with different traits don’t stack, which can take up a lot of inventory space quickly.

9. General balance as a food source. Mainly influenced by the adjusted growth cycle, as well as by a 20% drop rate increase relative to 1.21 (4.4 => 5.5 berries per healthy bush). Wild bushes are significantly less reliable than they used to be, especially for people who may struggle to notice them now, but purely numbers-wise as well. Cultivated bushes can be arguably better than they used to be, especially when considering traits, but require more time to properly set up and some fertilizer to keep them healthy. The initial growth time is long enough that it seems impractical if not impossible to get a sizable quantity of bushes fast enough to fruit within Year 0 at default world configuration. Remember that farming has received some nerfs in 1.22 as well, which makes this comparison a bit less straightforward.

I'll try to update this post at least until the stable release if anyone has any corrections or when new changes are released, though the poll itself will probably stay as is.

Motivation for this post

When discussing the rework, I’ve frequently seen perfectly fine changes being complained about with completely incorrect assumptions about their effects, and a couple times I've even seen literally nonexistent changes being complained about. I’ve also seen the rework uncritically praised with no apparent attempt to even consider criticism of it as potentially valid.

Of a few relatively popular videos I've looked at to gauge people's sentiment, every single one included only surface-level coverage, used flawed testing methods, neglected many details, and even included baseless conjecture or plainly incorrect information in one or two cases.

On the whole, player familiarity with the rework is low despite many reactions being heated, because many people predominantly react off of vibes, expectations, unverified interpretation of the changelog, and word of mouth. Many people supportive of the rework aren't even familiar with the details of what has been changed, and even fewer still actually know which parts are predominantly being criticized. Similarly, a lot of the people critical of the rework are grossly overreacting to the fertilization requirement and a couple other details without actually analyzing the gameplay impact of all the changes, which easily drives a feedback loop where two sides fuel each other's emotions and entrench themselves in opposing positions. Productive discussion has been quite rare to see, which is kind of both expected and disappointing.

A lot of that reaction could have been prevented by designing the rework differently to avoid hitting obvious triggers like the fertilizer requirement, or by communicating the changes more clearly in the changelog.

Personally, while my initial reactions to the rework were admittedly somewhat rushed, I generally argue knowing the code and full extent of the changes. The most positive broad take I can muster is as follows: the design direction is fine even if not what I would prefer, but the execution has some problems. Certain changes are quite universally welcomed, but there are certain components of the new system, intentional or not, which should still be revised or improved, if not removed. One of them (soil downgrading) has been rolled back in rc.3.

I’d be interested to know what people think of individual aspects of the rework.

On 3/13/2026 at 6:21 AM, Teh Pizza Lady said:

good suggestion, but I think it's a bit overly complicated it would be great for a forging mod for enthusiasts. I don't think I would enjoy this as a part of the base game, but I could be wrong.

I've edited the suggestion somewhat after a chat with Tyron over on Discord, and I've mentioned your concern as well in a new section of the post. Feel free to tell me if this is a satisfactory response, and whether you think that some specific mechanics go over the line especially far:

On 3/3/2026 at 8:38 PM, MKMoose said:

The exact level of complexity could be tweaked, but I think that the process should be ultimately quite easy to understand - while the under-the-hood mechanics may be very complex, it's not necessary to understand them in detail. A newer player can be eased into the system with normalization giving an easy durability buff, without having to bother with quenching, while those seeking a more complex challenge would be rewarded appropriately. A well-written handbook guide and descriptive tooltips at every stage of the process can also go a long way.

On 3/13/2026 at 7:09 PM, coolAlias said:

I like a lot of the OP's suggestions, but my preferred take on it would be we get to choose 1 option (e.g. durability OR power) with no stacking, so we just do whatever the process is once and we're done. Smithing, as much as I enjoy it, is already a very long and convoluted process.

I think Tyron has said that adding a config for something like this could be a suitable short-term solution. I don't think resorting to a config is a good idea, but sure, it could be nice for those who don't want excess complexity.

7 hours ago, LadyWYT said:

Based on what others had said though, and my own tinkering, bellows will be needed to forge bronze or better items since the base fuel temperatures just aren't going to be hot enough for efficient smithing. Brown coal, I'm guessing, should still be fine for copperwork, but players may want to consider refining it into coal coke when they have the opportunity.

Bismuth/tin/black bronze should be workable at 425/475/510 C, which is lower than copper's 542 C. All of them are workable quite fine even with brown coal and no bellows. The fuel type is only really a matter of convenience for working iron and steel as well as requirement to melt nickel, but keep in mind that converting coal to coke also greatly reduces its effective burn duration in all contexts.

1 hour ago, lumiera said:

1. How much fertilizer does a planted berry bush require in 1.22 per year?

Something like one piece every 2 years at first, a bit more if using bone meal. It falls off over time, eventually becoming completely negligible in long-term worlds.

1 hour ago, lumiera said:

4. What peak temperature does brown coal reach in the new forges in 1.22 without and with bellows?

It reaches 600 C normally (700 base value - 100 brown coal modifier = 600), and with bellows it's more than you will need (985.7 C, if I recall correctly), though you will need to use the bellows much more than with other fuel types.

Oh, it feels like young bushes should be functional now, if I'm reading the code correctly. It would be amazing, though if that is theb case, then I can't wait for people to notice that the growth time is three months longer, unless that was changed as well. So many things to check out and be excited about.

8 hours ago, Tyron said:

Tweak: No longer downgrade soil when berry bush cuttings grow

And I am so glad. Though I don't know how to feel about fertilization seemingly becoming almost irrelevant again.

3 hours ago, Calmest_of_lakes said:

What gives?

Great question. There is no answer, only guessing and conjecture.

3 hours ago, Calmest_of_lakes said:

How do I bring the berry bushes back to a healthy state? 

Fertilize it. Any fertilizer works. About one piece per year for the first four years will generally work well enough. Nutrient consumption falls off over time, so you won't have to keep fertilizing in long-term worlds. It's currently strictly optimal to only use one fertilizer type per bush, or two if you want to keep it in the "bountiful" state.

Update: with rc.3 now released, soil doesn't get downgraded, and it seems that medium fertility soil will get bushes to start off in the "healthy" state at 50% nutrients, greatly reducing the need to fertilize the bushes.

Does the issue appear at all times while below Y = 128, or does it flicker in and out in some way? While you're standing in or behind certain blocks like crops or fences, perhaps?

Either way, the most likely cause is probably the Immersive Mouse Mode. If disabling IMM doesn't fix it (or if you don't have it enabled in the first place), then you can see if the issue still persists after disabling occlusion culling altogether (possibly at some cost to performance). Might be a prime candidate for a bug report.