MKMoose

It's 5% for every snow layer (up to 35% at the maximum of 7 layers), as far as I can tell from the JSON definition for snow. I'm not aware of player temperature having any impact.

Well, if you want to verify this, then it would probably be best to check what actually gets added to the placeBlockByInBlockId dictionary, because that's what eventually gets used down the line when calculating readings (I can't check myself now, though I should probably figure out how to do it eventually). Other than that you've laid everything out very neatly. Okay, I stupidly didn't realize that the code was up on GitHub, as I didn't initially expect that I would have to look for vssurvivalmod, so now I can actually show what I meant. This line is the only place in DiscDepositGenerator where blocks are added to placeBlockByInBlockId: public override void Init() { ... if (InBlock != null) { Block[] blocks = Api.World.SearchBlocks(InBlock.Code); ... foreach (var block in blocks) { ... ResolvedDepositBlock depositBlocks = placeBlockByInBlockId[block.BlockId] = PlaceBlock.Resolve(variant.fromFile, Api, block, key, value); ... } } ... } And the blocks to be added are taken from the InBlock JSON property, which corresponds to the rock types that the ore can spawn in, defined here: [ { code: "galena", ... attributes: { inblock: { code: "rock-*", name: "rock", allowedVariants: ["claystone", "sandstone", "shale", "chalk", "limestone", "chert", "conglomerate"] }, ... }, ... } ] As a reminder to keep everything cohesive, the main point I'm explaining here was this: And all that ultimately was related to the question of whether density readings are useful when searching for surface nuggets that indicate surface deposits. I appreciate your effort here either way, as you've helped me understand the system much better, and indirectly cleared up a different misconception I had about what the readings actually represent.

While I like the idea of crafting maps, I've never liked Minecraft's way of doing it. I'm not sure how it could be implemented to be sufficiently simple and intuitive for Vintage Story's exploration style, because having to bring a dozen maps with yourself when on a trip could get very inconvenient very fast. The coverage of Minecraft's maps being completely dependent on where they are activated has always frustrated me. There's a lot of ways to arguably improve upon a more realistic implementation, like by abstracting it away to some extent to avoid constantly taking up inventory slots, by reducing resource consumption to avoid imposing tedious maintenance, and it kind of devolves back into leaving the system as is, because it's just simple and convenient. It could certainly be immersive to have more realistic maps, and I would appreciate any middleground between full map and no map whatsoever, but I'm just not sure it would fit the standard game experience well enough to justify the effort. There's also the potential issue that if this system gets added, then many new items could be rendered useless (besides decorative uses) when playing with the map active at all times or completely disabled, which may then have to be addressed in item tooltips or the handbook in some way to avoid confusion. While I typically find myself disliking the "it would be better as a mod" response, in this specific context it seems more appropriate than usual, unless there are other good reasons for craftable maps. This part seems very good. The concern about the table losing all functionality when not using realistic maps even gets circumvented with waypoint sharing, and it could even allow sharing prospecting data (which technically are just a bit different waypoints, but still). It may be necessary to do something to avoid the need to clean up dozens if not hundreds of unnecessary waypoints each time after exchanging them, though, while still ideally allowing to transfer specific waypoints. I don't know what specific implementation you have in mind, but just in case I'll mention that automatic systems automatically make me stop paying attention to the surroundings. Reducing friction when marking the 76th trader and 134th copper deposit would be great, but the player should still be required to actually notice what gets marked. It could be done just by making automatic waypoint range very short, or perhaps better by having the player get close enough to things and right-click the important blocks (fruit trees, surface nuggets etc.) with a map in hand, or something in that vein. If that's roughly what you had in mind then I get you, just wanted to be sure because it's a very important point that I've seen people neglect in other contexts and then be surprised that exploration has become boring, after they take away most of the mental stimulation from it.

I just noticed, small correction on that part: it's 7 blocks average radius, while 14 blocks is the diameter.

Right, I kind of missed that, thank you. Although, keep in mind that if you ever find yourself wondering "can bees spawn here?", you'd generally prefer not to risk the chance and be in a common or very common area.

Prospecting data (specifically density search) is not concerned with what ores actually end up generating. The game generates a random distribution for each ore type that can be detected by the prospecting pick's density search, and this distribution is used both when randomly generating the ore and when the prospecting pick gives you a reading. That is, the density readings inform you about the actual chance that the game uses to generate the deposits, but whether that ore has actually generated under the reading is a separate matter. Caves generate first, then ore deposit generation replaces rock with ore blocks. Air is treated as a different block, so it doesn't get replaced. Either way, the end result is as you're assuming - if a cave happens to pass through a deposit, it effectively removes a bunch of the ore blocks. I've recently found a cassiterite deposit with exactly one ore block in a cave, which was quite amusing. Your case seems pretty unlucky, since deep copper deposits (I'm assuming you're talking about a deep and not surface deposit) tend to be much larger than cassiterite deposits: ~14 blocks average radius, and can generate up to 3 blocks thick. It is nonetheless entirely possible for a cave to remove most of it, provided the cave is large enough.

Well, if you want to verify this, then it would probably be best to check what actually gets added to the placeBlockByInBlockId dictionary, because that's what eventually gets used down the line when calculating readings (I can't check myself now, though I should probably figure out how to do it eventually). Other than that you've laid everything out very neatly.

To my knowledge, bees just require a warmish climate without too much rainfall in order to spawn, as well as a tree or something to spawn in. The flower type doesn't matter--the plant just needs to count as a flower in order for the bees to use it. It's not that bees only spawn when there are certain flowers or trees nearby; it's that plants, just like bees, have specific climate requirements to spawn. If a tree's or flower's requirements overlap strongly with bees, then finding those plants can be an indication that bees may spawn in the area as well, though this is only really reliable for temperature as it has less significant local variations. Bees require the following conditions: yearly average temperature: 5 - 35 deg. C (temperate climates are on the lower end of this range, so it's possible to find them on default spawn parameters but preferable to move south when searching), rainfall: 0.35 - 0.95 (either common or very common in the character panel), forest: 0.25 - 1 (basically anything resembling a forest is good enough). Notable tells that a location is somewhere in the correct temperature range (but not necessarily correct rainfall and forestation levels) include: crimson maple, walnut, redwood, cypress (both) - all of these trees never generate outside of the 5-35 temperature range, catmint, forget me not, wild daisy, and golden poppy - all of these flowers also never generate outside of that temperature range. Do keep in mind, though, that a place having none of these plants does not mean that bees can't spawn there. Many plants spawn in very narrow conditions, and they may appear in places where bees actually can't spawn, even though the temperature is correct. There is no clear, unambiguous indicator that bees can spawn in an area (unless maybe if you get a perfect combination of plants in a small area, but I don't even know if it's actually possible), and all the plants are little more than a rough indication that you are in the right climate. They don't have to be present for bees to spawn, and their absence doesn't prevent bees from spawning. And lastly, if you find yourself wanting to be absolutely sure whether bees can spawn in a place or not, the generation parameters (yearly average temperature, rainfall, forest, as well as other stuff which is irrelevant in this context) can be checked for your location using the command /wgen pos climate.

Correct that whether and where the ore is spawned does not matter. Not entirely correct that it's based on the heat map only, at least depending on how you define the heat map. It also has to account for whether the ore can actually generate in the rock types under the reading (e.g. if there are no sedimentary rocks in the block column at the reading location, then there will be no readings for ores which can only generate in sedimentary layers), and in the code that's a separate process alongside taking a value from the ore distribution. Now, to get back to this: Ore-bearing blocks include the rock types that the ore is allowed to spawn in. What this method does is find how many blocks in the column at the reading's location the deposit could spawn in, and in order to do that it checks each block in the column for: whether it is in the Y range that the ore can spawn in (no reason to evaluate blocks outside of that range), whether it is in the list of host blocks (doesn't make sense to give readings where there are no rocks that the ore can spawn in). Density search readings don't account for the presence of ore blocks at any point (unless maybe they get dumped together with ore-bearing rock types, but that would barely change anything either way). I do not see anything that would support this conclusion:

It really feels to me like we are saying the exact same thing, and yet somehow disagreeing. I'm not sure if the code that you've provided actually warrants this conclusion: I will have to get back to you later, in a couple hours or more, with a more proper explanation, but the short of it is that I don't see ore blocks being considered at any point when calculating readings.

@Teh Pizza Lady At least one of us is grossly misunderstanding the other. Allow me to first clarify one thing, so that we know that we're at least talking about the same thing: when I say "surface deposit" in this context, I mean a deposit of full ore blocks that happens to generate near the surface, close enough to spawn loose ore chunks on the surface above. With that, IF your point is that density readings for galena are irrelevant when searching for nuggets that indicate surface deposits, then this is for you: Try it and tell me what you find. I did it myself for about half an hour if not more, saw consistent, strong correlation between loose ore and density readings, and walked away with a conclusion that so far you have completely failed to undermine. And if your point is anything else, then you misunderstood something that I said. I cannot say what exactly or whether the blame should be on my phrasing or on something else.

This line only seems to determine whether the generator should create surface blocks for a specific deposit based on 1) whether a surface block is actually defined, and 2) the chance to generate these surface blocks (which by default is equal to 1, but can be modified in the JSON definition, like it is for surface copper deposits): { code: "surfacecopper", // Surface copper deposits ... attributes: { ... surfaceBlock: { code: "looseores-nativecopper-{rock}-free" }, surfaceBlockChance: 0.33, ... } }, I do not see any relation to whether the prospecting pick's readings can indicate the presence of the main deposit, especially after you've just laid out how density search produces its readings. If readings are produced only based on 1) the ore map and 2) the rock types in the block column at the reading's location, then what is it going to change that loose ore is generated on the surface? Allow the generator to ignore the ore map, effectively causing decorrelation between loose ore and readings? Certainly can't see that in your code snippet. Side note from the previous stuff, I want to mention that I think it does control it. From what I've seen, the withOreMap: true property in JSON definitions controls whether the propick can detect a deposit, though probably not through first-order causality. Every single deposit that does not have this property set to true cannot be detected by density search. To add to that, I think you may agree with this quick reasoning: we have deposits that don't use ore maps, presumably, this means that these deposits have uniform base chance to generate, regardless of location, if so, then the only thing that would affect density readings is rock types, so density search loses most of its utility, additionally, though causality could go either way, these deposits generate either practically anywhere (quartz, saltpeter) or only under very specific conditions which mostly remove the need for prospecting to find them (olivine, sylvite, surface copper and surface cassiterite), it makes sense to just disable readings for these deposits.

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