MKMoose

@Teh Pizza Lady A quick note: I'm reading through your post, and it seems absolutely correct in what it describes, but almost entirely unrelated to the preceding discussion. You're making me question if I've maybe just been misinterpreting something, but I do not find that likely. Surface blocks are the loose nuggets. This is not the same as "surface deposits", i.e. proper ore deposits that happen to spawn with nuggets above them. The way I've been seeing it, this discussion is about whether the prospecting pick's readings are correlated with surface deposit frequency, and only by proxy with loose ore chunks which are the primary way of finding those deposits.

The ore generation page was fleshed out in 2020 and through 2022, and I think it's safe to say that it didn't see any significant changes because the game didn't see significant ore generation changes. About the same goes for the mining page, while the prospecting guide was created in 2024. I've read that thing several times over to make sure I'm not missing anything. I know what's on this page, and it does not support your case. I genuinely don't know where you find relevant evidence there. I would say that it exactly contradicts what you're saying, mostly because of this part: Knowing that galena only spawns as this "shallow" deposit, and knowing its generation parameters, I believe there is absolutely no reason to assume any separation between galena deposits that spawn or don't spawn loose ore on the surface beyond that fact itself, which is purely caused by the deposit generating sufficiently close to the surface. If there is any separation, then I am unable to find any information about it.

This is the main page I'm referring to, which explains the generation mechanics and details the generation parameters of all deposits: https://wiki.vintagestory.at/Ore_Deposits. Granted, "highly accurate and frequently updated" is somewhat relative, for the standards of the wiki. Some pages seriously lag behind the game's development and miss important details, but there seems to be a bunch of pages about core systems which are generally maintained quite well. And there are also two other, related pages that I've found quite reliable and useful: https://wiki.vintagestory.at/Mining - a general description of the system, https://wiki.vintagestory.at/Guide:Prospecting - a guide to prospecting that I used when I was starting out.

Take your time. I can wait. You've stated it multiple times already, and yet my testing and available information suggests otherwise. You can do a simple test yourself. Load into a new world, go into creative mode, grab a prospecting pick, and start looking for sedimentary rocks. Anytime you find a large area of sedimentary material, take a few samples nearby and check if there are readings for galena. Then run the command .debug find looseores-galena-{rock}-free (replacing {rock} with the appropriate type, e.g. .debug find looseores-galena-limestone-free if you're above a patch of limestone) and see how many nuggets it finds. I've found very strong correlation this way - the better readings I get, the more nuggets it tends to find. There are some areas which give no galena readings, and the command consequently doesn't yield anything. Sometimes I get no reading initially but it finds just two or three nuggets, then I fly to their locations, and sure enough, there's always a galena reading at the nugget's location. I'm trying to explain to you that there is only one type of galena deposits, backed up by a highly accurate and frequently updated wiki page and based on the actual definitions for ore generators, and with a few other minor points. I can consistently see strong correlation between loose ore and readings in my experimentation. And you're completely ignoring almost all arguments I'm making, or making excuses for why they're supposed to be less reliable than your "experience". You're clinging to a rule which is only accurate for two specific types of deposits which are implemented in a more complicated way, which I acknowledged as the exception.

You can mostly deduce this from what I was explaining above, but the short of it is that yes, lead spawns at any world height in the allowed rock types, and generates nuggets on the surface if it happens to generate high enough. It's not a bad assumption, though I think the devs' reasoning has more to do with the overarching progression of the game. The thing with copper specifically is that the surface deposits allow to easily find sufficient amounts of it when the player is starting out and hasn't touched prospecting yet, whereas the deep deposits actually start spawning relatively deep comparing to many other ores (Y = ~72 and lower, while the sea level is at Y = 110), and mostly serve to create a second layer of complexity that the player can use to find much more copper than on the surface (a single deep deposit will easily have as much copper as 4 surface deposits). Yeah, I did mention that in passing as well. One thing I can do based on the game files is list out all the deposits that are not registered by the prospecting pick's density search: surface copper, surface cassiterite, halite salt beds, quartz, olivine, saltpeter, sylvite. Interestingly, it does detect lapis lazuli, contrary to what the in-game tooltip suggests (I know in part because I have readings for it in my 1.21.5 world). I am not certain about gems and child deposits, as they behave in some less predictable ways. Well, except that the key point I've been trying to hammer home here (though may have distracted myself a bit) is that prospecting allows to locate areas where loose galena chunks can generate in the first place. Mining for galena doesn't tend to be efficient, but just prospecting every couple hundred blocks can tell you whether you should search nearby for surface nuggets or just move elsewhere.

Fair enough, I may have focused a bit too much on the technical side of it, rather than practical. Do keep in mind, though, that the claim that started this was a different one, which I argue was verifiably false in the context of galena (though it would be generally correct if the conversation was concerned with copper or cassiterite): Surface deposits (indicated by surface nuggets) do not show up on the Density Search mode on the pro-pick. I do somewhat agree that "prospecting for deep deposits is a waste of time", because of how thin the sedimentary layers can sometimes be (your estimate for a thick layer ending at Y ~= 50, a bit below half of world height, seems very generous to me). And of course there's the time and resource expenditure necessary for mining. However, in some cases, primarily when struggling to find surface bits in spite of prospecting pick readings (not unlike the OP experienced), mining for galena may be very useful. I'd like to share my own experimental data (not plentiful, and not insignificant) that I've gathered by digging vertical shafts and using node search (and some sideways digging to actually get to the deposits). The characteristics of the area were as follows: area size: ~250 blocks diameter, peak galena reading: 1.07 permille (very poor), average closer to 0.5 permille (very poor), peak borax reading: 0.73 permille (very poor), average around 0.5 permille (very poor), sedimentary layer thickness: ~20-25, terrain: mostly flat, some parts at sea level, with small hills (has to be very close to sea level to allow borax to create surface nuggets). With that, here's what I found within 16 mining shafts spaced a couple dozen blocks apart, only digging in the sedimentary layer: 8 galena deposits with no surface bits (I managed to find 4 deposits with surface bits in the same area), 6 borax deposits with no surface bits (I managed to find 3 deposits with surface bits; its generation is similar to galena but doesn't follow the surface, so nuggets only appear very close to sea level), 1 sulfur deposit (it was "minuscule" in a part of the area and I couldn't find higher readings anywhere; it generates almost the same as borax but doesn't appear high enough to create surface nuggets), 1 surface copper deposit with no surface bits (there was one deposit with surface bits, I'll also mention that copper deposits only generate 33% of surface nuggets according to the files). Was I lucky? Maybe. I could probably do some more rigorous testing if there's demand for it, though that may be pretty time-consuming. This is what I would conclude based on what I know and what I've found: searching for loose galena chunks on the surface does tend to be more reliable than mining in the general case, and it can certainly be cheaper and faster, prospecting can be useful to find areas which have higher frequency of surface nuggets, which can be especially valuable if found while searching for something else, deeper lead deposits can be useful, though it's primarily relevant when in need of exceptionally high amounts of lead or when struggling to find anything on the surface, lead (similar to borax, sulfur and a few other deposits) tends to have very low density readings, and anything above "minuscule" is generally pretty good, mining for galena is only practical in a thick layer of sedimentary rocks, at minimum ~15 blocks, ideally ~30+ blocks thick (though it's generally not practical to deliberately look for such areas - you get what you get, and if it's thick enough you can try mining).

Your experience is your own and perfectly valid, but your conclusions don't align with the way that the deposits are actually generated. Do note that you are entirely correct about surface copper deposits (or maybe aside from a minute detail or two), it's just that this doesn't carry over to galena. If I may ask, I would greatly appreciate if you @ or quote me when you are replying to me. I also want to clarify that the reason for my "wolf bait" reaction to your earlier post was that I felt like it didn't address anything that I said and instead went off to explaining basics that I fully understand, but let's put that aside, as I would prefer to try to actually explain how the ore generation works here. It's JSON, not C#. My bad for saying it's code, as it technically isn't. JSON is a file format used to store data in a human-readable way, which is useful here as it allows devs and modders to define various elements of the game in a way which is easy to read, interpret and modify, even for someone less familiar with it. Let me try to break it down in a way which should be as understandable as I can make it, to justify this conclusion that I placed below the code block earlier: First, focusing on this part: { code: "galena", triesPerChunk: 40, withOreMap: true, handbookPageCode: "item-nugget-galena", generator: "disc-followsurface", attributes: { ... }, ... } I've replaced less important parts with ellipses. The set of outermost {curly brackets} indicates that this entire code block is a single object (it happens to be the only such object for galena), which contains a bunch of name: value pairs. The first such pair is code: "galena" , indicating that this object defines galena deposits (the game knows to interpret this as a deposit generator and not something else because it's coded to expect it in this folder). We then have a bunch of other parameters, and one of particular interest is withOreMap: true . This lets the game know to generate a density map for this ore, and this is also how the game knows to detect this ore when using density mode with the prospecting pick. From the generator: "disc-followsurface" we can also infer that the game will generate the ores based on the Y level of the surface (as opposed to sea level), which will be relevant in a moment. Then, we reach attributes: { ... } , and the value here is another set of name: value pairs bundled into a single object using the curly brackets again. The main parameters of interest are these: attributes: { ... placeblock: { code: "ore-*-galena-{rock}", ... }, surfaceBlock: { code: "looseores-galena-{rock}-free" }, ... yPosRel: { dist: "uniform", avg: 0.5, var: 0.5 }, ... }, Of these, placeblock: { code: "ore-*-galena-{rock}", ... } defines the main galena ore that should be spawned by referencing its code (there's some added complexity to account for various ore richness and host rock types), while surfaceBlock: {code: "looseores-galena-{rock}-free" } is responsible for telling the game what kind of block it should generate on the surface near the deposit (the surface chunks). Then, yPosRel: {dist: "uniform", avg: 0.5, var: 0.5 } determines the height at which the deposits can spawn. Y level of 0 refers to the bottom surface of the world, while Y = 1 in this case is equal to the surface level (because earlier we set the generator to follow surface). Since the distribution here is uniform and has the average value of 0.5 and variance of 0.5, we can conclude that the deposits are spawned with equal probability at any height between 0 and 1, that is anywhere between the bottom of the world and the surface (as long as it spawns within an allowed rock type). Now, you might be wondering, how is surface copper different from this? The answer is that for copper we have two objects, enclosed into a list using outermost [square brackets]. Each of these two objects define their own deposits, and you should be able to easily distinguish which generator does what based on their codes and a few of their parameters (I skipped over the less critical stuff, as before): [ { code: "surfacecopper", // Surface copper deposits <--- note: this is a comment, the game ignores it ... generator: "disc-followsurface", attributes: { ... placeblock: { code: "ore-*-nativecopper-{rock}", ... }, surfaceBlock: { code: "looseores-nativecopper-{rock}-free" }, ... yPosRel: { dist: "uniform", avg: 0.965, var: 0.03 }, ... } }, { code: "nativecopper", // Deep native copper deposits ... withOreMap: true, ... generator: "disc-followsurface", attributes: { ... placeblock: { code: "ore-*-nativecopper-{rock}", ... }, ... yPosRel: { dist: "uniform", avg: 0.3, var: 0.3 }, ... } } ] I'll also point out that internally there is no technical separation between "surface", "shallow" or "deep" deposits - they're just classified in this way on the wiki based on some shared characteristics. Or actually, surface copper and surface cassiterite are the most distinct ones, as they are named as surface deposits in their definitions (like the code: "surfacecopper" above), and they are pretty unique in that the heights at which they generate are always very close to 1 (the surface), though they still rely on the same underlying system and just use slightly different parameters. Feel free to ask about anything unclear or point out any mistakes.

@Maelstrom Very well. Let's check out the code, then. This is the entire file that determines the generation of galena deposits, located in assets/survival/worldgen/deposits/metalore/galena.json: [ { code: "galena", triesPerChunk: 40, withOreMap: true, handbookPageCode: "item-nugget-galena", generator: "disc-followsurface", attributes: { inblock: { code: "rock-*", name: "rock", allowedVariants: ["claystone", "sandstone", "shale", "chalk", "limestone", "chert", "conglomerate"] }, placeblock: { code: "ore-*-galena-{rock}", name: "grade", allowedVariantsByInBlock: { "rock-claystone": ["poor", "medium", "rich"], "rock-sandstone": ["poor", "medium", "rich"], "rock-shale": ["poor", "medium", "rich", "bountiful"], "rock-chalk": ["poor", "medium"], "rock-limestone": ["poor", "medium"], "rock-chert": ["poor", "medium", "rich", "bountiful"], "rock-conglomerate": ["poor", "medium"] } }, surfaceBlock: {code: "looseores-galena-{rock}-free" }, radius: { dist: "gaussian", avg: 4, var: 4 }, yPosRel: {dist: "uniform", avg: 0.5, var: 0.5 }, gradeDistribution: "RandomPlusDepthBonus", thickness: { dist: "uniform", avg: 1, var: 0 } }, childDeposits: [ { code: "silver", triesPerChunk: 4, withOreMap: true, handbookPageCode: "item-nugget-nativesilver", generator: "childdeposit-pointcloud", attributes: { randomTries: { avg: 10 }, placeblock: { code: "ore-*-galena_nativesilver-{rock}", name: "grade", allowedVariants: ["poor", "medium"] }, radius: { dist: "gaussian", avg: 2, var: 2 }, thickness: { dist: "invexp", avg: 1.2, var: 3 } } } ], } ] There is one generator for galena, which creates deposits: at any depth below the surface (within allowed rock types), with surface blocks (nuggets), with an ore map, which allows these deposits to be detected by the prospecting pick. This affirms the strong correlation that I observed between readings and loose ore on the surface, as well as exactly confirms the information available on the wiki page that I linked.

Not necessarily. They provide small positive reinforcement as reward for progression, helping to create a sense of accomplishment and motivate the player to reach the next goals in sight, especially for players with a more completionist mindset. Easier achievements can motivate a beginner to keep playing until they can attempt the more difficult ones, if nothing else. Additionally, achievements can inform the player about next steps in progression and content they haven't seen yet, or remind about mechanics that they may not know or remember. Nothing against a little bit of fun, though. I'm torn between one name and two triggers. "I didn't hear no bell!" - eat a funeral bell and live to tell the tale. "I didn't hear no bell!" - allow a bell to summon 10 monsters.

Where did you get that from? I don't think it's stated anywhere in the game, the wiki doesn't seem to mention it, and everything that I've found on Reddit or wherever else has absolutely zero evidence and often contradicts other information. Additionally, you may want to consult the prospecting pick's description in the tooltip, which mentions a few specific deposits but not surface deposits as a whole: I think that list actually also includes olivine and surface cassiterite, but not galena. According to the wiki, galena only generates as shallow deposits, which may or may not actually be near the surface and be indicated by the presence of loose nuggets (I don't know if that's the same as your "surface deposit"). The primary distinguishing factor is that most shallow deposits only appear in sedimentary rock, while deep deposits primarily generate in metamorphic and igneous layers. If what you're saying is true, then either the wiki is missing a separate generator for deep galena (which would be odd considering that the shallow one already can generate at any height in all rock types that galena can generate in) or the game would have to somehow split "surface deposits" off of shallow deposits when generating the density map (which would be even worse). The same applies to borax and maybe some other stuff. Personally, I've seen close correlation between readings for shallow deposits and frequency of nuggets on the surface for both galena and borax.

Galena is a shallow ore, spawning in all types of sedimentary rock only, and it spawns nuggets if it's close enough on the surface. It will likely have very low propick readings, as the highest I've seen personally was just over 1 permille, still classed as "very poor". I've mostly found galena by chance when exploring, through surface nuggets. Once you get a reading with relatively high lead concentrations (in practice I think anything above "minuscule" should suffice), you can try running around looking for nuggets before commiting to mining - with some luck in a good area you may be able to find a dozen deposits in a two hundred block radius or so this way (I did just that near the 1 permille reading). If you decide to mine for it, like when you get a good reading but can't find nuggets, just keep in mind that it's in sedimentary rocks only, and you should be good. It has really high spawn rates and should be easy to find once you're looking in a relatively good area with a decent layer of sedimentary material. As a reminder, it's chalk, chert, claystone, conglomerate, limestone, sandstone and slate. You can also find them by searching for galena in the handbook and taking a look at the different chunks or ore blocks that show up.

Honestly, I think it's less that people really prefer open spaces, and more that they specifically dislike the current implementation of shrubs. I'm no stranger to getting frustrated when I have to constantly jump over bushes, break leaf blocks or move around obstructions, and I think that's a shared sentiment for many people. The bottom line is arguably that branchy leaf blocks shouldn't be solid, and instead they should just reduce movement speed. We even have a working implementation for the required functionality in cobwebs. It's kind of odd to have to walk over bushes or to bonk the head on a branch when jumping up a step. There's this cool thing that I think I've first heard mentioned in one of Factorio's dev blogs. People tend to like thick foliage, but it is predictably really annoying to move through, and it results in a lot of frustration when there is no way to go around it or to move through it more efficiently. What you do, then, is allow people to solve the problem. Give them a bit of agency and engagement, instead of just making them put up with an inconvenience. One might say that it's possible to solve the problem by running around the whole forest, but that isn't really fun, and neither is cutting down a whole bunch of trees and shrubbery to make a path. So what you do is create animal paths through the forests, making it more engaging to move through by following a more open trail, and easier to open it up for a road or something of the sort. Just random narrow paths (~3-8 blocks wide) that block trees and other larger vegetation from generating would look great and I think they could work wonders for traversal. The same can apply to nearly any biome that has a fair amount of anything beyond grasses and sedges, but its importance increases drastically for more lush areas like forests. And once you have a good way to reduce player frustration and split out annoying areas into more manageable subsections, then by all means, go ham with filling out the whole lower foliage layer with all the plants you can find, and you'll have my full support. As a side note, another thing that could be nice would be a machete to clear out shrubs near-instantaneously, and generally as a tool for cutting down plants, especially bamboo. If necessary, it could come at the tradeoff of reduced or completely removed drops from some plants. And the machete could go really well with a bunch of bushes and shrubbery (especially tropical ones) that regrow after getting cut down (likely similar in implementation to cattails) which could be cut down near-instantaneously with a machete, but would take much longer to remove roots (and might only drop them for replanting if dug with a shovel).

I have to disagree. It can look good in some places, but a lot of the time it results in a more busy yet uniform look that I'm not a fan of. I think there are two main things I would love to see improved about the current foliage, that would let me more properly enjoy high-foliage worlds: higher trees in forests - at ~20-30 m total, with branches/leaves starting at ~5-15 m (free-standing trees can be shorter but wider) they would look arguably much better and give more space to the shrub layer, greater shrub variety, and better design - blocks of tree leaves are just weird; I know they're supposed to represent smaller trees but it ain't very good, and there's plenty of bushes, shrubs and dwarf tree species that I think would benefit the game's visuals greatly. The biggest offender for me is the temperate or cold gravel deserts or whatever that is, because nothing even close to that abomination exists in the real world as far as I know. The everpresent birch leaves in those biomes seem like they represent dwarf birch, but they typically don't grow beyond 1 m. The almost complete lack of mosses, grasses, bushes and sedges honestly baffles me. And last thing, why are there trees on gravel? Where to they get their nutrients from? Trees are already an issue here very frequently, because when trying to ride through a forest you'll have your head in the leaves half the time. The above points have the potential to address issues with travelling through forests, and additionally I think most shrubs should slow down the player and not stop them entirely. I'm not saying movement should be fully smooth and convenient, but I think it should be less annoying, and there's a lot of fine-tuning that can be done depending on the indended level of movement obstruction. My apologies if I'm kinda just complaining, but given how fundamental to the game world generation is, I think VS could use some improvements in that regard.

I think you mean currently there is only one direction the axles spin in. Toggles are clearly direction dependent. I don't want to put words into anyone's mouth, but the point seems to be that reversing the rotation doesn't actually change anything. The quern, the helve and the pulverizer work perfectly fine regardless of which way the input spins, even if one direction causes something to look wrong. This seems like a pretty good reason not to bother with a reverser until it gets a functional purpose. Restricting machines to one specific direction is probably a bad idea, as there would inevitably be a whole lot of questions asking why a setup doesn't work. A reverser is a perfect fit for something that actually changes function when spinning the other way, and I can't really think of anything that fits the bill. Maybe something that can move in two directions, like an elevator? Would be pretty cool thematically, though might lack significant use cases for how complex it would be.

It’s not a single component, it still requires a transmission to work. But I get that. To elaborate a bit on this, I'll mention that I would have nothing strictly against the idea, and implementing it in a way similar to the clutch and not as a completely standalone component is probably the best suggestion for a reverser that I've seen so far. The reason why I'm saying it seems "a bit too convenient" is mainly that the devs seem to prefer to push players to create more complex machinery for more advanced functionality (as evidenced by small gears only ever connecting in pairs, though that might also be to simplify implementation), so simplifying a large contraption down to a single added component seems like a pretty drastic jump. Now that I think about it, though, reversing doesn't have much of a functional purpose, because most if not all machines can be powered in either direction. Since reversing is already possible (albeit it requires a bit of space), and doesn't seem to serve an important gameplay function, it has much lower priority than new functional components. However, the fact that it wouldn't heavily impact balance while removing the need for a niche but unnecessarily large construction does work strongly in its favor.

It would be possible to do it much more efficiently than in the devlog, since the large gear is completely unnecessary. I would prefer a more distinct name to avoid confusion. Either way, a single-component reverser seems almost a bit too convenient and I wouldn't necessarily put my hopes up. I've seen another suggestion which would allow to reverse directions a bit easier by allowing the clutch to alternate between two gear trains instead of only being an on/off switch. From this discord message:

While this may be a concern in some cases, most of the time bark would only be either a suboptimal early-game alternative to another resource (e.g. rope, clothing, food) or an exclusive source for a special item (e.g. cork), plus it may have decorative uses. As long as it isn't allowed to fully substitute a resource which is normally unlocked later, I think the risk is minimal. I'll also mention that realistically, many uses of wood absolutely require debarking first (or bark just gets removed as part of processing), especially for anything that is meant to last a long time. For fuel, I think an appropriate solution may be to simply reduce the burn duration of debarked logs by an amount corresponding to bark's burn time or slightly more. And by a quarter of that for debarked firewood if we do make this distinction, and we might ever so slightly reduce its charcoal yield while at it.

Bear pelt with head. Combined in the crafting grid with a knife produces a bear pelt and a bear pelt head. I'd say just right-click a log with an axe (and perhaps a hammer in offhand) to debark it. A double-output recipe is possible, but it could also be removed altogether, as I think it benefits the game when things are moved out of the UI and into the world. Personally, after cotton I would turn to wool, silk, jute and hemp. Barkcloth is an interesting but rather niche choice, and it was historically replaced by other textiles. I'm not sure if it would actually have the desirable properties of linen and similar cloth. It's also worth mentioning that it is primarily produced from one specific family of trees generally native to Asia, most significant of which is paper mulberry but breadfruit and fig have been used as well. It does work in favor of the suggestion that bark has a large variety of uses besides clothing, which makes it more likely that it gets added to the game eventially. Of these uses I can list out a few I've looked into recently, and it's frankly a pretty short list compared to what you might find elsewhere: a bunch of uses in construction, for roofing, canoes, shoes, bags and other useful items (primarily birch, but some cases are more generic and could be made from barkcloth as well), rope (important historically in northern Europe, often from one specific species but a lot of different ones could be used), birch bark tar (an early adhesive used for hafting, I think), food (pine bark is a staple for the Sami people, apparently, and they're mentioned a few times in item descriptions), cork (from cork oak, primarily for sealing bottles, though an oil-soaked rag could serve the same purpose), mulch (for farming, as fertilizer if nothing else but can also have some special uses), cinnamon (from a few specific trees, would be nice if we ever get any spices added to the cooking system), aspirin (from willow, kind of an odd fit for the current state of the game but willow extract might be a cool thing to add along with herbalism). Alongside all these other ideas, barkcloth could add a lot of functional purpose to different trees, and in this way it could greatly enhance the variety of the early and mid game depending on starting climate. It would also create further incentives for exploration and promote planting a larger variety of trees beyond purely aesthetic reasons. Honestly, this is starting to look like a separate suggestion in the making. But either way, if we do end up with bark at some point, then I like the idea of barkcloth as one of its uses. Barkcloth doesn't use looms from what I've read, I think it's just strips of inner bark beaten into thin sheets. The long-term goal seems to be to introduce a proper weaving system, so it's not clear how the balance of all that is gonna look in the future. Realistically, barkcloth should be cheap and easily available (at least in the right climate), but less useful for late-game recipes, and I think that would fit the game's progression quite well.

Honestly, that's fine. I'm pretty much the opposite--if the lore is presented one way, and the game mechanics directly oppose it, then it's usually highly annoying since it's not really possible to get immersed in a world that doesn't even attempt to follow its own rules. I don't see this as the opposite. I dislike the classic ludonarrative dissonance as much as the next guy, though I see lore and realism as very similar in some regards. Both tend to get used to argue for mechanics in a way that doesn't focus on gameplay enjoyment (I seem to prefer realism, you've often made arguments through lore), and both greatly enhance immersion when used well. If the mechanic you're justifying with lore or realism is fun, then all's good, but the moment that this mechanic becomes detrimental to the enjoyment of the game I start questioning whether the original reasoning is still relevant. And keep in mind, changing the mechanic can perfectly retain its lore accuracy or even improve it. Okay, before I get into other things too far, I'm gonna focus on explaining better what I actually mean by integrating temporal mechanics into the weather system, as it admittedly comes with a lot of implied baggage that probably isn't as obvious as it is in my own head. When I say "the weather system", I mean a continuous simulation of (usually 2D) distributions for each of various parameters throughout the game world. In a purely realistic game this would just be different weather components, but there is nothing that prevents the system from being used for other things, like the temporal mechanics. They don't have to interact with weather at all, though it wouldn't be unreasonable to, for example, make dry areas more unstable on average. With that, temporal mechanics would simply be one component of the system that slowly evolves over time, mostly or entirely independent of weather. Dynamic hotspots or fronts of instability would intermittently move over the player's home, bringing with them negative stability and elevated rift activity, in extreme cases perhaps similar to temporal storms. Ideally, this would come with actual moving rifts, be it small cracks (similar to current rifts) or massive fissures (potentially dozens of blocks across), and other indications that can be seen across the landscape and used to gauge the current and upcoming temporal state of the area. And I will note that signs of surface instability were a big point in a different discussion, so I don't want to bring too much of it here, but more so just mention it because any attempt at reducing reliance on UI has to bring equivalent information into the game world. I'm not sure how underground stability is implemented currently, but I don't think anything would really change with it. In the simplest case, it would be decided by an equation that combines the player's elevation with the current surface stability, even as simple as a sum, e.g. current stability at the player's position is 0.2, they are 0.7 of world depth below the sea level, so stability at that depth is 0.2 - 0.7 = -0.5. As for the building argument, a dynamic system like this could make it so that all areas of the world are suitable for building, but would once in a few days to weeks face a period of instability. This would mean that even areas which are more unstable on average could still be habitable, but the player would just have to face a bit more instability and rifts instead of having a limit on how long they can stay there before storm-like effects kick in. As long as even the most unstable areas are balanced in a way that makes them still reasonably habitable, the complaint would be addressed. It would also have the other benefit of making instability into something that can actually catch a player off-guard anywhere on the surface, instead of it being completely irrelevant unless it happens to cover an important spot. Regarding the "not everywhere is habitable" point, I really don't feel like arguing much about it, because from a design perspective risks and consequences always have to be communicated, whereas surface instability offers random encounters, delayed punishment, no tells outside of UI, extremely limited learning opportunities, and no way to counteract it. It's objectively not a good mechanic, and lore-driven reasoning is the only saving grace that makes it tolerable. It's fine to make some areas unwelcoming and inhospitable, but then you'd do well to justify that to the player in a more satisfying way. Nobody is confused that, say, the polar regions are not conducive to creative building, because they clearly can see that it's the polar regions and they know what that means. But surface instability feels arbitrary and annoying. Temporal storms are somewhat separate from the weather system suggestion, because making them dependent on player location wouldn't play well on servers with sleeping disabled during storms. However, I think they can still be improved by slowly increasing instabilty and rift activity for a few hours before the storm properly starts and letting them fade out slowly instead of getting cut off immediately. This would arguably integrate them much better into the world, and it would also reduce reliance on chat messages. The player would be able to see the world change and would be attacked by a few weaker threats before having T4 rotbeasts spawned at their feet. Side note, there should be more proper difference between light, medium and heavy temporal storms. I'll mention, also, that given the player's low temporal stability having effects very similar to temporal storms, it wouldn't be unreasonable to just remove temporal storms as a distinct mechanic and instead make it so that occasional instability spikes are the cause of "storms" through lowering the player's stability. It would be much easier to integrate naturally into the weather system, though storms disabling sleeping would have to be worked around in some way or just ditched. I feel the opposite, really. The storms and rift activity feel as dangerous as the world makes them out to be, so it's rather easy to get immersed and take them seriously, rather than treat them like a quick-time loot event. It's also quite clearly something that does permeate the entire world, since it doesn't matter where you go, you'll end up needing to deal with temporal mechanics unless you turn them off entirely. I don't feel like what you say here addresses what you quoted in any meaningful way, and it seems largely related to other points. Just in case, though, I want to clarify what I meant under the "disjointed and tacked-on" umbrella: surface instability, although technically is a continuous value, mostly ends up boiling down to the positive/negative binary - this creates distinct regions of instability, and doesn't really feel like something that permeates the whole world to me, because it is irrelevant most of the time or practically in full effect on those less common occasions; it also doesn't help that it's static, which reinforces the barrier between stable and unstable areas, and it's completely invisible, which easily makes it seem arbitrarily tacked on, rift activity doesn't really matter for the most part, because what actually matters is rifts themselves which pop up wherever they want, and for many players a single rift is already too much to keep dealing with for several in-game hours - I've spent many nights in low and medium stability without any combat (at least once I've even had a high-activity night with no encounters, at least for a couple hours), and I've had to retreat back home during many nights in low and medium activity due to seemingly endless monster spawns that were impractical to fight, temporal storms are almost entirely self-contained and poorly integrated into the world - they start immediately with no warning aside from the chat messages and end just as suddenly, which makes them feel extremely artificial; there is no variation or in-between events - either it's a storm, or stability is completely normal and unchanging, different mechanics barely interact and aren't consistent with each other - one is static, one is completely random, one is cyclical, storms have no relation whatsoever to rift activity and rifts themselves, ambient instability has little to no effect on rifts; it often also feels like there's three separate monster spawning systems that follow different rules and only one of them relies on rifts. Just so you know, I do realize that I might be kind of splitting hairs with some of those criticisms, but given how integral temporal mechanics are to the game and how unique they are compared to some other games, they kind of deserve every level of scrutiny. And I'm also just trying to explain my line of thought in a sufficiently detailed way. Heavily disagree here, because that essentially turns the storms from disasters that need to be planned around, to quick-time loot gathering events. Likewise, if the unique resource in question does not come from enemies, then how does a player obtain it whilst being assaulted from every direction during a storm? Does the player need specific gear quality to obtain said resource? I will also note that this doesn't solve the complaint about hiding in one's base during early storms, when one lacks the proper equipment to fight through them. Rather, it's probably going to make such complaints worse, since there's actually something to miss out on. I'm gonna leave this one and the rest for myself to think through further (and to avoid making this post even longer), but I'll just mention that the loot gathering doesn't necessarily have to occur in the middle of a storm. It could be just before a storm, to have the player hurry while the world is changing but rotbeasts aren't appearing in droves yet, or it could be right after a storm, to let the player salvage the aftermath of it before everything fades back into how it was before the storm.

My take is that all or almost all lighting should be expendable even while kept in containers, though this change would probably only be suitable for Wilderness Survival and Homo Sapiens. Actual pre-industrial households and towns tended to be extremely dark at night, with work and social life generally limited to daylight. Rushlights and oil lamps (actual oil lamps using vegetable or seed oils, especially olive oil; what we have currently is more of a fat lamp) would then proabbly have to be added as cheap light sources accessible in the early to mid game, though they could serve as a perfectly fine addition on their own as well. Anything that reduces unnecessary UI interaction is a win in my book, though it may be more natural if this required a stick and grass (since when the torch burns out the fire consumes a lot of the stick as well), at which point we end up with a way to craft a torch on the ground, kind of like the current campfires. Place a stick on a wall or stick it into the ground (which by itself could serve other decorative or functional purposes), and then place grass or other materials on that stick to complete a torch. Regardless of specifics of implementation, I do like this idea. Torches that use resin or other stuff would have to still be very cheap or much better than the regular torch to be worth it, at which point it might be simpler to just default to oil lamps. It's not easy to beat something that only takes sticks and grass to keep replacing, while also remaining competitive with a piece of fat in a bowl that lasts forever. That said, generally a greater variety of lighting and reduced reliance on beeswax candles (which historically were a luxury) would arguably benefit the game greatly, with the one caveat that a new player shouldn't have to choose between multiple different but very similar items. I think it might be fine to limit ourselves to just one new type of torch which could be made interchangeably with resin, wax, and maybe something new as well (tar, bitumen, etc.). Some additional variety or flexibility may come with with substituting grass (which can currently be replaced with cattails and papyrus already) with twine or other materials like burlap. And that might come with renaming the current torch to a crude torch.

I'll probably never not be mildly annoyed to see lore reasons as justification for mechanics and disabling them as solution for players who don't like the mechanics. I've been thinking about integrating all three temporal mechanics (ambient stability, storms, rift activity) into the weather system, alongside potentially other changes that are too plentiful to describe in detail here but that I may eventually assemble into a standalone suggestion. I reckon that something like this could solve a bunch of fairly common complaints and criticisms, especially the one about temporal stability making areas unsuitable for building. It would also make surface instability a more integral part to the experience that everyone would have to face semi-regularly (not unlike the current storms), instead of it being almost entirely predicated on whether there happens to be instability near the player's home. I think the least that a rework of temporal mechanics could achieve would be to address how disjointed and tacked-on these mechanics can feel. They don't give the impression of something that permeates the entire world and exists as part of it, and instead they come and go in very obvious, binary ways. Either it's stable or it's unstable, either there is a rift which will continue spitting out monsters or there is no rift and it's safe, either the storm is ongoing at full force or there's no hint of it ever being there. And the temporal mechanics barely interact and aren't really cohesive with one another, with the most confusing case being that you can be in the middle of a storm with "calm" rift activity, which just feels wrong. I would lean towards the idea that temporal storms could offer a brief opportunity to obtain a rare resource. It probably shouldn't simply be loot from enemies - this may easily be detrimental to the health of the game if not implemented well - but there is a lot of other options as well, primarily revolving around snatching something that briefly crosses the boundary between worlds or in some way exploiting the altered state and properties of the world, even if only using Jonas tech. And by that I mean, do whatever doesn't conflict with the lore, but with that general goal in mind. The issue here is that while an important overarching goal of the design of temporal storms is undeniably that they should be an uncontrollable supernatural disaster, leaning too hard into this predictably results in storms largely being seen as a tedious disruption. Quite often I would straight up just alt-tab out of the game for a few minutes during a storm if I don't have anything important to do at the moment, and that's the dangerous and immersive storm for you. I think it is entirely possible to retain the supernatural feel of the storm while creating this one special occasion in the game where the player has a time window to, if they so desire, put in the extra effort to obtain a rare resource, likely while having to defend themselves from monsters. It could get people more excited or nervous about storms rather than just annoyed at the disruption. We do kind of have a bit of that with the highest tier rotbeasts, but as mentioned, combat should probably stand in the way of what the player is aiming towards, and not be something that the player actively seeks out. Even if it's combat, then it may be better to create something that the player has to put effort into beyond hitting the monster a few times. Maybe, and I'm mostly spitballing here, some sort of a neutral beast that wanders through the world and has to be hunted down, or an incorporeal monster that the player has to lure or trap and only then kill. There is, as usual, a balance to be maintaned here between different design goals, but I think it's unavoidable that something has to be done about the temporal mechanics eventually, as they create too many undesirable incentives and too many gameplay disruptions in their current state. It's not, but that is the price one pays for safety. In order to be completely safe from a temporal storm, the player needs to build a small bunker to hide in. A good game mechanic is designed in such a way that it encourages the player to interact with it or with other parts of the system. Nearly all temporal mechanics in the game, but temporal storms most offensively, do the exact opposite, at least in early to mid game - limit player agency and offer little to nothing in return - which reflects in the related complaints and suggestions. While there's plenty of mechanics which could be seen as time-wasters but are ultimately well-integrated into the game loop and easily justifiable for various reasons, storms are exceptional in how disruptive and restrictive they are, and temporal mechanics overall suffer from lack of almost any player interaction aside from combat or hiding. Quite literally the only thing that works in their favor is that they don't take up too much time in the long run, but then why are we adding annoying mechanics and making them rare and predictable to compensate? In practice you usually do need to return to the surface, unless you are confident that you can handle the combat (which plenty of people avoid, especially before they have good armor) or have an ample supply of temporal gears and some currently on hand (which generally also requires combat). Keep in mind that, especially if you're not experienced enough to know well what works and what doesn't, you'll often be inclined to take the simple, safe and cheap route, instead of risky combat or an expense of health and valuable temporal gears.

Maybe, but why would a player sink resources into crafting high fertility soil, when they can just craft terra preta, which is better? Likewise, if terra preta cannot be crafted, then how does one obtain it? Assuming the problem of soil not dropping itself when broken is directly removed or circumvented, then it would arguably be more natural to gradually upgrade soil tier-by-tier, i.e. remove direct crafting of terra preta and require the player to create it from high fertility soil. It would at least make for a smoother farming progression, though perhaps not fully realistic for terra preta specifically. But the idea for removing direct crafting of terra preta is more of a side note, it's not a crucial part of the overall suggestion. Dare I say, terra preta is already kind of not worth it, because a slightly larger area with medium fertility soil is almost free, at least outside of cold climates, and can provide identical average returns at almost no additonal effort (or may even end up better for players who don't check on the crops regularly). People do often craft terra preta eventually, but I feel like it has more to do with how easy it is to slowly accumulate the necessary resources as byproducts of regular gameplay, and less with it being a truly worthwhile improvement. If balanced well, terra preta could have reduced material cost but some added time expenditure and opportunity cost, ending up with a similar or even smaller perceived cost. That said, yeah, it's a valid concern, and as always there has to be a balance between effort and payoff. I think it could be interesting to add something beyond just faster growth rate to make high fertility soils (including terra preta, or specifically terra preta) more enticing, instead of this "might as well" thing that seems to often occur now.

It wouldn't be unreasonable to allow crafting high fertility soil using half the resources required for terra preta, or to remove direct crafting of terra preta and give some other recipe to high fertility soil. I also recall an idea that bounced around the forums to create higher-tier farmland by adding fertilizer to lower fertility soil and placing mulch on top, or something similar, which would increment soil fertility after a period of time. It would certainly feel much more engaging than just crafting it, alongside other benefits: implementing a more incremental and time-consuming process also has the potential to make the soil progression more gradual and satisfying, especially for cold starting climates, adding a waiting period for the soil to convert could introduce a nice early-game strategic decision to make, between improving soil quality and planting more crops, allowing to upgrade farmland in place would partially circumvent the problem of farmland not dropping itself when broken. Right now it often feels like farming on random dirt that cannot be improved in any way, then one day whipping up top-tier fertile soil out of a pile of compost and replacing the farmland overnight. It's a very sudden jump, especially if starting out on low fertility for lack of anything better. That works for all soils, though, no? And it only matches maximum potassium levels, but other nutrients are still worse than high fertility, so it's hardly a variant of it. Either way, it is quite useful and might point to some ideas for upgrading soil more properly.

But that's precisely the point! Sure the randomness shows up late in the process, but that's also exactly why it works! Most of the smithing and bloom processing in this game is extremely deterministic once you learn the steps. Heat ingot, select template, pound metal, get product. Tedious... Having one small moment of uncertainty ("Am I gonna have this bloom fail??") preserves the tension of a system that otherwise becomes braindead and fully rote memorization of the process. If the result were guaranteed every time, the entire bloom-to-ingot loop would lose one of the only points that still feels dynamic within the whole smithing process. But the resource loss IS trivial. The iron ore deposits underground are often huge, with each ore guaranteed to produce at least 3 nuggets (worth 5 units each). But it doesn't meaningfully slow progression, it just paces it. The game already has small friction points such as resin scarcity for mechanical setups, crop cycles and rotation, charcoal pit production variances. Defective blooms fall into the same category of momentary setback, not a punishment. Removing it would shave away one more piece of pacing that the game has to prevent players from just blasting their way through the iron age without a care in the world. Apologies for taking this long. Those are decent arguments, but I'm not sure what you're arguing for or against. I do agree that the metalworking mechanics could use a bit of uncertainty for better moment-to-moment engagement, and I take issue with the way that this uncertainty is currently implemented, not with it being there in the first place. The resource loss being mostly insignificant in the long run is also the reason why I specifically said that the defective blooms are among the least punishing random mechanics in the game, and instead focused on the more subjective aspect of why people find it annoying. And that was in response to you going off in the vein of "if remove this randomness, then why not other randomness as well", so I'm explaining why this randomness specifically is much more annoying than many other examples. This is where your argument really starts to get under my skin. Vintage Story borrows realism where it's fun, not where it becomes administratively heavy. I suppose if you're saying that realism should have an effect on the end product, then we should have variable ingot sizes, variable impurities and metal qualities, variable carbon levels, different bloom grades, and tools that require more or less metal to craft depending on quality and the size of the wielder. For that matter, we might as well add a height slider to the character creation process so that the player characters aren't all the same size, too! The game abstracts all of that because excessive granularity creates more complexity than it does benefits. Having a bloom missing a voxel doesn't do that. It doesn't create complexity, rather it encourages the player to make use of the helve hammer to extract a usable ingot from an otherwise failed part of an historically imperfect process as you yourself pointed out. Holding the bloom mechanic to a realism standard that the rest of the game and the metallurgic processes don't follow creates an inconsistency in the game. Removing the mechanic altogether deadens the impact of the thematic journey of loss and recovery that the game promotes throughout it's story and lore. I didn't phrase myself especially well here, but the bottom line is that the current defective bloom mechanics are less realistic than just always getting one ingot per bloom. It would be fine to just disregard the randomness in the amount of metal, because it's not a thing in all other parts of the game. If I was told about blooms sometimes having insufficient iron for an ingot before I learned about this mechanic, my immediate assumption would be that they could still be processed using the same methods as full blooms into a bunch of smaller pieces. That would be realistic, would retain a dose of uncertainty, and may even point to a new progression step associated with building a more advanced hearth for welding smaller pieces into ingots, among other potential uses. But instead we have blooms that have a small percentage of metal below an arbitrary threshold required for an ingot, which can't be processed in any way except using a bigger hammer that magically repairs them. But this is how progression works in the rest of the game. Querns are slow to operate; windmills solve it Panning for copper nuggets is slow; making tools solves it Pit kilns are slow; beehive kilns solve it Early-game friction (the loss of a bloom) gives way to late-game convenience (I can just repair it on the helve) and is a core part of the dynamics within the Vintage Story ecosystem of mechanics. It doesn't trivialize the mechanic, it integrates it naturally into the tech curve. If the helve could no longer repair defective blooms, then it's only use would be to hammer out plates from ingots... which if you know what you're doing, can actually be slower than doing it by hand. The helve would just be a useless bit of tech at that point. No use at all to the skilled player. Not every game mechanic needs to scale upwards. Some exist specifically to give weight to later-game progression (panning -> mining as an example). I'm sorry but I have no clue what you're getting at here. The examples of mechanized querns, panning getting replaced by mining and the pit kiln being replaced by the beehive kiln all have vastly different purposes in the game's progression. They are quite representative of a lot of the game's design, but the helve fixing defective blooms absolutely is not. My point here was primarily that if you're using realism and fun as an argument for the defective blooms, then realism and fun should persist throughout the game and not be thrown out the window once the player gets a helve. But now you've largely ditched all other arguments and focused on justifying the existence of bloom defects as a source of early-game friction, and I absolutely can agree with that line of thought in isolation, with a few caveats. But I never questioned that line of thought, so what were you arguing against? The reason why I don't think it's beneficial that the helve completely eliminates the problem of defective blooms (aside from it being unrealistic and the helve already offering several other incentives) is that complexity in game design tends to work best either as a progression ladder (see especially the ever-increasing complexity of metalworking processes) or as an opt-in challenge with additional rewards (see automation and the variety of tasks non-integral to progression like animal husbandry or cheesemaking). Defective blooms, as it stands, increase complexity of manual ironworking, which already is significantly more advanced than bronze processing, only to immediately be made irrelevant by the optional helve, which simplifies ironworking back down closer to bronze. So you have a feature which intentionally raises the barrier to entry, but can be trivially circumvented by a more experienced player, especially since the helve is actually a Bronze Age unlock. The defective blooms also cannot reinforce mastery, since the better player interacts with them much less often if at all. It is an annoying inconvenience which primarily affects beginners who don't have a good mechanical power setup, don't have a developed resource supply, and naturally start off small and put more value on individual ingots. Now, I can see the argument that this is largely intentional as a way of giving more value to the helve, but I believe this would be much better served by making the helve faster or more versatile, and not by making the manual process more annoying. Ideally, I'd argue that the helve should be more difficult to operate correctly (i.e. not entirely automatic), and when used skillfully it should allow significantly faster forging than it currently does. It could be a pretty big rework and may require a larger pass across the metalworking system, but it's something to consider. I don't really know if I'm making much sense at this point, but I hope this at least clarifies my previous points, because it didn't seem like they came through well enough.

One question that immediately comes to my mind is whether it's possible to fire wet pottery, and if so then what happens if you do (I know you addressed it, but it might have a big impact on the new or forgetful player). Dry and wet pottery would inevitably end up very similar in appearance, so they might be easy to confuse, which could be annoying for different reasons regardless of whether wet pottery can be fired. Ideally, they would have to be clearly described in the tooltip, in block info and in the handbook all at once. It's also important to make sure that it's explained sufficiently well that drying is 4x slower in containers, assuming we intend to include this part of the mechanic. I'd also somewhat agree with the counterpoint that it could delay early-game advancement quite a bit, which might be especially undesirable considering that pottery is the first significant progression milestone in the game and as of now it's entirely plausible even for a beginner to start small-scale firing on day 1 if they find clay nearby. It could also drive a new player to obsessively check on the drying process and to get discouraged when they have to wait so long only to have to wait again for firing. It may also be annoying to have to wait more than twice as long as now if the player needs an item quickly, say, a tool mold that they'd just realized they need for progression. But I think it would be quite fine, ultimately, as long as everything is neatly explained and the drying time is not too long (I think 20-24 hours is fine and doesn't stretch realism too much), since the player tends to have quite a lot to deal with either way, especially at the start of the game. It certainly works in its favor that the process would be realistic and mechanically very simple. It might also make for a subjectively greater payoff once the fired pottery starts coming in.