MKMoose

I don't know where you're getting the idea that it would only be collected during storms (granted, "unique" could mean "such that only one holder has it", but it's also "being the only one of its kind"). I even expressed a very similar concern in the next paragraph below the one you quoted: Whatever that resource may be, I'm calling it "unique" just because it would most likely be a supernatural item with rather fantastical applications, and I have nothing against allowing to collect small quantities of it in other ways. It would have to be very rare outside of storms, though, to avoid defeating the original purpose of the change. Maybe it could appear in a story location, maybe it could be purchased at a high price from a special NPC, whatever, really, it's beside the point. The point is to give the player a reason to brave the start of the storm (period of preparation and anticipation, encourages the player to come out of their hiding hole), then hurry back home with the loot (something of a thrilling survival test, like you've described with your dash towards the story location), and give an extra something to do during the storm when it's not possible to stay outside (actually process the resource). I was considering this as well for a different reason, but I don't think it would change much of anything. For most purposes it would just add a delay to rotbeast spawns, with little to no impact on how interesting or engaging the storms are. Having to run around to close the rifts would be a job and a half in itself, you'd inevitably miss a few, and you wouldn't get much done besides closing rifts. At that point I'd probably prefer to just sit in the house cooking or panning - at least I would actually get something done, instead of risking combat and draining my stability for zero benefit. Maybe it could work with a few tweaks, but I don't really see how it could improve storms in any way for the players who find them restrictive and tedious.

I'm not certain it makes much sense to discuss the whole stability mechanic by focusing on the very small part that is surface instability. Sure, there are also people who dislike the mechanic as a whole, but surface instability is separate in that it specifically has the problem of having nearly nothing beneficial for the game going for it. Both its gameplay purpose and the worldbuilding aspects are questionable, which cannot be said about the rest of the stability mechanic. To be frank, this is a matter of personal opinion. Enjoyment of mechanics is subjective, and in a large enough playerbase you will always find a diversity of opinions. That said, I think we can discuss a mechanic by analyzing the constraints it applies to the player, the incentives that it provides, the punishment and rewards that it offers in different circumstances, and everything else about their design, without getting bogged down in an opinionated back-and-forth that goes nowhere (though this is still nothing compared to something like the gapped ladder threads, to be fair). All the temporal mechanics are backed with reasonably strong arguments from the perspective of lore, worldbuilding and atmosphere, which increase the wiggle room for momentarily imposing limitations on the player and creating risk of punishment, and storms especially make liberal use of it. Some players don't mind it, like you, and some players find that it goes too far and becomes boring in spite of the intended effects. I will also note that the atmosphere and worldbuilding aren't really there for me as long as the storm begins in an instant and ends just as suddenly. All the temporal mechanics are risky from a design perspective, because they are universally hostile to the player and designed as obstacles without significant rewards, which is a combination that easily reduces player engagement. Underground instability is fine as part of the risk of mining or caving, which itself is necessary or at least useful to obtain a bunch of resources. Surface instability is annoying for reasons that I probably don't need to explain again. Now, temporal storms are exceptionally imposing and punishing, which might point to them offering some sort of a reward, and... it's just rotbeast loot, which, to add insult to injury, is pretty useless unless optimized for large quantities with a mob farm. What I would personally love to see are more upfront and everpresent temporal mechanics, with new and improved visual effects and sounds but removed direct tells in the UI and chat. Make them a big and interactive part of the world that the player actually has to keep in mind and deal with regularly (but without making them too threatening or imposing), with in-world ways to gauge stability and predict storms, and potentially limited means to exploit or counteract instability. I'm gonna twist this right around and say that it is indirectly an excellent argument for creating a short opportunity right as the storm starts to collect a unique resource. My thought was unironically some sort of nectar from a flower, because it could start growing as the storm is imminent and blossom right around the moment it hits, then wilt pretty quickly to remove the incentive to stay outside and keep collecting resources throughtout the entire storm's duration. This would make the player hurry before the storm to find a flower and collect the nectar quickly, then dash back home to process it into something in safety (possibly something that herbalism and brewing could help with, but it could also be used with Jonas parts somehow). Flowers appearing in random locations would make it much less cheeseable, and I'm thinking that they could even be deliberately made to only appear in chunks that are mostly unmodified by the player. There's plenty other options as well, if flowers sound a bit out there, but similar design constraints apply. One thing that is fun to look at on this topic is the importance of autonomy as described by self-determination theory. Offering extrinsic motivation (i.e. an opportunity to collect a resource) may reduce intrinsic motivation in players to busy themselves with their own tasks during the storm, however, the storm already greatly limits intrinsic motivation by reducing the options available to the player as they sit in a small hiding spot. I think that as long as the additional incentive offered by the storm is not excessively strong (that is, the unique resource isn't absolutely crucial in the game - that is a bit of a worry I have with potential new Jonas tech as well), then this extra option would go a long way to increase player engagement during storms.

I've looked through the code more thoroughly today, and I didn't find any spawn conditions (besides a collision check) being used during storms. In fact, it doesn't even test whether the player is in the way, so it could spawn something exactly on top of them. It's very rare simply because the game chooses a position randomly in a 15-block range and there's many more blocks to choose from as distance increases (e.g. a 5x5 area centered on the player is just 25 blocks, so the chance that something spawns within this area and not further away is less than 3%, assuming a completely flat area with no additional obstructions). Both light level and proximity to the player do impact spawning outside of storms. You can look it up or look into the code, but I can also describe it later if there's demand. Though it's admittedly a bit of a nitpick, I can say based on both personal experience and code that bowtorns can spawn in a room this size easily, almost as easily as drifters. Shivers are less common due to their horizontal hitbox size exceeding 0.8, which as far as I can tell causes the game to check for collisions in a 3x3 area (or at least 2x2, even if I misread something), and not 1x1 like for drifters and bowtorns. For bowtorns height is more of a limiting factor, but they still fit in 2.5 blocks, while the room in question looks like it's at least 4 blocks high not accounting for furniture. Both bowtorns and shivers are also less common on the whole.

Welcome to the forums! I'm not really aware of any specific strategies aimed at finding the more basic rock types other than traveling long distances and marking down whatever you might be interested in on the map for later reference. The TLDR is probably just that you have to travel around, preferably once you have an elk, and count on a bit of luck. There might be some tricks and obscure facts that I could find, but I know no method more reliable than exploration. Some people suggest using translocators to aid in this process, but in my experience finding and repairing them in the first place tends to take me more time and effort than just traveling the same distance. They're an option, either way. A typical recommendation might be to put the rock search on the back burner and just pay attention to rock types as you're traveling for other purposes, though I appreciate that it might not be the most enticing idea if you're looking for materials for the house. You can consider something that I do at least once in every long-term playthrough, though it can get tedious: travel to the tropics (~40k blocks south from the default spawn location, though you could turn back earlier once satisfied) to collect seeds for crops and trees that you don't have yet, which might just let you find rocks along the way. I'm not aware of of climate having any impact on this. It may be worth mentioning that geologic provinces which limit the rock types that can spawn in the area are very large, and so can be the actual patches of specific rock, so you'll be better off traveling long distances quickly instead of thoroughly analyzing a smaller area. You might also try moving along the edges between different rock types if you want, to try to maximize the variety of rocks that you see along a single path, though I'm not sure if it's worth the effort. In case you haven't done so already, looking into the four rock categories that the game uses (igneous, metamorphic, sedimentary, volcanic) will also help you search more effectively. As a sedimentary rock, shale (as well as chert, if something more red-brown is tolerable) will often be the topmost layer, and the most reliable way to find it is just exploration. However, when looking for some of the other dark rocks, the categories are a bit more impactful: slate - it is metamorphic and so tends to be rare (and makes for a nice black roof); often appears under sedimentary layers but may also happen to be the topmost layer, doesn't generally appear below basalt; it currently only generates as thin layers (at most 15 blocks thick), which may be noticeable as a black stripe on cliff faces, basalt - as the volcanic rock, it's perhaps the rarest strata in the game and it will always be the topmost layer (maybe barring some odd layering shenanigans); it can also be found throughout the world in deep caves near the mantle, which might be a fast but risky and expensive option that doesn't require traveling too far, though I can't really say how reliable it is.

A lot here depends on the exact implementation of the placeable bags. I would lean towards something that indirectly prevents the player from running freely with the inventory open (enhance immersion and improve IMM while at it), yet with little detriment to the time it takes to access the items in the bags. It may be still possible to open the bags freely while sitting (ideally also on an elk, on the sailboat, or other modes of transport where it makes sense). Side note: I absolutely hate minimaps (maps are mostly fine, just minimaps). They are a plague. A bandaid fix to poor design that should never be tolerated in anything that dares call itself a survival, an RPG, or anything of the sort, except maybe as an additional accessibilty option.

Can I just say that I've mentioned this idea both in this thread and in my first suggestion in these forums (which could use some rewriting, now that I look at it again)? I don't know if it's popular or not, but I think it would be a great change. Incomparably more immersive, largely solves a big issue with IMM, and it would arguably be beneficial to make the player stand in place when using the inventory to more naturally reduce the need for simultaneous inputs. Would probably take some getting used to for existing players, but I think it's worth it. I'm not certain how this could be implemented well, but I really felt the problem when leaving the first story location with 7 bracelets, 5 butterfly pins and a whole bunch of other clothing.

Double disagree -- the real challenge class is Commoner. Double that and give it to the next person. Commoner has no particular strengths, but they aren't a challenge class, kind of by definition. They are the baseline and a good starting point for the new or indecisive player. If need be, we could lean into that further by giving the commoner slightly reduced hunger rate or slightly improved cold resistance. I could get behind a diplomat as a new class, separate from the tailor, with the caveat that an excessive number of classes could be detrimental in the long term. It could fill a neat niche where few other classes could fit, focused on unconventional utility and interaction with NPCs. Could also be a vassal, a merchant, a guildsman, a courier, or anything of the sort, with potentially different traits that would make sense for each. The tailor is in a bit of a limbo until we get more developed weaving and sewing mechanics (if we ever get them, but at least weaving is on the roadmap). Before that, I feel like they really don't need much to be entirely viable, even if slightly suboptimal. Not that the suggestions are bad, bur I have to mention a few potential issues with the proposed changes: increased healing effectiveness goes against the tailor's reduced health; a recipe for better bandages at similar cost could be nice, though, increased trade value, when not implemented carefully, could make the tailor into the "can you run to the trader and buy/sell this for me" class; I wouldn't mind to see some clothes be made more profitable to craft and sell, though, upgrading armor could have quite large benefits, making the tailor into the server's armorer; relatively large systems also probably shouldn't be locked behind a class (tailor already has by far the most significant class-exclusive items).

The position of the sun currently depends on the latitude, and polar regions have realistic polar nights and days. If we were to do the same for longitude, then we would presumably choose the distance between poles (by default it's 100k blocks) or something close to it to indicate the "length of the equator", and travelling that length would change the time of day by 24 hours, landing back in the same time zone. While it's a fine suggestion for the sake of realism and it should be fairly simple to implement, there are two potential issues: if multiple people are in different time zones, then sleeping would be practically impossible in a satisfactory way as the night for one person would be the day for someone else, possibly making the feature more annoying than immersive in those cases, the impact of this change would likely be quite minimal, which makes it more difficult to justify it - at 100k blocks equator length, one time zone would be more than 4000 blocks wide, meaning multiple players would have to be at least some 10-20k blocks apart on the horizontal axis to notice a significant difference, making the feature practically irrelevant in singleplayer and unlikely to matter on small servers where people tend to stick together.

The short of it is that you were most likely just unlucky and there probably isn't anything you can really do about it. Prevailing wisdom suggests that temporal storms allow rotbeasts to spawn practically anywhere they please. According to the wiki, the only condition is that they have to physically fit in the space (and I think that checks out with the source code). I don't think you can fully prevent spawns without just cramming yourself into a space with at least one dimension smaller than the minimum required for spawning. I'm not sure whether the player counts as an obstruction as well. The required space, I think, is the collision box of the entity that the game is attmepting to spawn plus 0.1 in every direction except down (I can't look up the collision boxes for the rotbeasts at the moment, but if you're feeling adventurous then they should probably be in the JSON definitions, somewhere in %AppData%/VintageStory/assets).

I don't know how much you've looked into the actual halite generation, but there's a few things that you may want to know to make sure you're looking where salt can actually generate: halite rock cannot be detected by the prospecting pick's node search, whereas density search is only useful for salt domes and not the salt beds in deserts, salt domes can generate anywhere with a thick enough layer of sedimentary rock and they can be found using the prospecting pick's density search - if you want to find salt as soon as possible, you have to get a reasonable reading for halite (I don't think it's actually possible to find a "decent" reading, "poor" is actually good for halite) and mine horizontal tunnels at any depth below the lowest sedimentary layer in ~20 block intervals (or a bit more dense if you really need to, since the domes can have a diameter anywhere from 5 to 37 if I recall correctly); keep in mind that you can take density readings while deep underground to make sure that you're still in an area with a lot of halite - the reading accounts for the amount of sedimentary rock above you so you don't need to double-check it, dry lake salt beds should generate in dry, hot and flat areas (sandy deserts, specifically 0 to 0.3 rainfall and 15 to 40 average temperature), directly under the surface (just under sand/gravel), near the sea level (Y < 117, I think); I would actually need it confirmed that they can generate at all and I'm not certain about the exact generation requirements, though, as I have yet to see one myself.

See, I'm immediately pulling my hair out over this one (and a few other ones in here), because I feel like only a small part of it is unpopular. From what I've seen there's very few people who dislike temporal stability as a whole compared to the number of people who would yeet surface instability out the window the first chance they get. Dumping the two together ain't doing you favors. Also, though I can't claim to have seen them all, I actually don't recall any argument about stability customization that did not revolve around surface instability being inseparable from all other instability. There's no reason to put underground instability in the crossfire when it doesn't get nearly the same flack. Or in other words, focus on improving what doesn't work instead of panicking that the baby shouldn't be thrown out with the bathwater. Feel free to consider this my potentially unpopular opinion, which kind of gets more reinforced with each new game I pick up: long-time fans of various things tend to be too worried about it getting ruined with poorly thought out suggestions (which is largely but not entirely justified) to genuinely entertain the possibility of improving undercooked features that they've already grown accustomed to.

I feel like the large amounts of flax in recipes is a stand-in for the processing time that's presumably gonna be necessary once proper weaving is added. Currently, flax processing is practically instant, so some other way of time-gating linen isn't completely unreasonable. I love the contrast between these two. Also, I think that you should have to place down your bags to access the items inside. This is a cool idea. I'd say it should be a different item and not just a lantern with something else inside, but that's a minor detail.

Can I mention that the medieval world map still allows to find ruins very easily, at least the larger ones? Traders also aren't difficult to notice if you know what and where to look for (if they're not in a forest), and some clay patches (fire clay in bauxite, red clay in cold climates) can stand out against gravel (but not against soil). I would really love to have something in-between the current navigational aids (map and coordinates) and nothing at all. Something to allow me to mark down important spots and avoid getting lost without a lot of ugly dirt pillars or whatnot, but without outright giving me a view of an entire large area. Left: two large ruin groups; middle: trader wagon (a bit more difficult to see due to snow); right: fire clay patch in bauxite gravel.

If I get it correctly then @MattyK's idea was focusing more on that if different crops can be killed by different diseases and have different resistance to them, then that would incentivize having multiple crops that are all vulnerable to different diseases so that a single blight can't kill all of them. Resistance to disease would also be a good balancing factor, which would allow creating low-risk low-yield crops and high-risk high-yield crops. Which, don't get me wrong, is a very good variation on the generic crop disease idea in itself, and one that I would be perfectly fine to see added to the game. What I was reacting to was more your idea (assuming that part's actually yours) of making crops more vulnerable to diseases if planted repeatedly in the same area. This is also quite realistic, as crop rotation is a basic but sometimes effective way to prevent pests and diseases from fully establishing. Fair. My thought was that most players probably don't optimize so much as to plant the same crop multiple times in a row using fertilizers. If they need a lot of a specific crop (presumably flax) then they can also just expand the farm, so fertilizers are only really necessary when attempting to maximize growth rate to the extreme (potentially due to a limited supply of seeds). Unless you make blights kick in relatively quickly, then they may end up being so rare as to be irrelevant once even very basic crop rotation is used. Either way, it would ideally shift the meta to a much more interesting strategy.

I like this, though increasing the P nutrient is...lackluster, really. Most players tend to care about the K nutrient, since that's what flax relies on. The others...eh...not really a big deal. I'm not sure if desiring low fertility soil really makes sense, though it could be very reasonable to reduce growth speed penalties applied to potatoes due to low nutrient levels, making them comparatively better on lower fertility soil than other plants. Probably makes sense to do the same for some other crops as well. I think increasing P levels could work really well if natural nutrient replenishment were much slower, and several other crops were balanced with an increase to at least one nutrient as well (either directly, or through incorporating plant remains into the soil through tilling as I described in another farming suggestion). Rotating crops would become much more important and fertilizers more worthwhile, because as things stand currently you could as well leave the farmland fallow for two weeks and it's gonna be good as new afterwards. If possible from a realistic perspective, could balance it so that the best crop sources of K consume a lot of P, giving the potato a nice niche as the P replenisher. This is somehow the single best idea I've ever seen for crop disease, and it's not even close. So many people just suggest random blights and that's it, whereas this actually solves a design issue and gives the player an actual problem and solution, not just a random "I guess we have no crops now". One thing I'm not sure is whether a feature primarily aimed to impede hyperoptimizing can really justify the effort required to implement it, especially since nutrient mechanics achieve a lot of very similar goals already and could be expanded more easily.

A common problem with many class systems across different games is that by specializing into one activity, they make everything else comparatively inefficient, which leads to small parts of the game feeling better for specific classes and suboptimal for the rest. I feel like it may be better to avoid classes like miner or lumberjack (and especially farmer, which I've seen suggested elsewhere) simply because people would then have a perfect reason to delegate all class-favored tasks to those classes only, and the inefficiencies may sting if the player has to deal with them as another class. I can't help but notice a lack of debuffs and tradeoffs (which, granted, probably wasn't the primary focus). For both of them you've only explicitly mentioned hunger, and I think at least one negative trait for each should be significantly different from the blackguard. I'll mention that again below. And last point, I would be strongly agaisnt full leaf block drops when chopping down trees - increased, sure, but I think at most ~4x, and even that could be much. These two could be renamed to something like a forester/woodward (maintains forests more than just chops trees) and a collier (mines and supplies coal, may produce charcoal), opening the gates for more traits and exclusive items related to forestry and item transport, among other things. The forester could have some bonuses related to planting trees (incl. fruit trees) and perhaps other plants, alongside other stuff including that melee damage buff, but may take a hit to sprint speed as well as possibly maximum satiety, ore drop rate or ranged effectiveness. They could also get some interesting traits if we ever get multi-stage tree growth, maybe alongside coppicing and stuff, which could allow the player to put more effort into trees to make them more tailored to specific end goals (firewood, boards, sticks, decorative). The collier could have 4 extra inventory slots on top of mining-related buffs and potentially increased maximum satiety, and should probably have some specific penalties to farming, fruit picking, fishing or animal husbandry. They may do something cool with carts, minecarts or other item transport methods as well. I'll also point out that currently all classes (besides the commoner) have some class-exclusive items, so I think it would make a lot of sense to get something for new classes as well. New players already often need quite a while to get the hang of prospecting. Slightly easier or more detailed readings for either of the existing modes could be nice, like by reducing the number of samples necessary to take a reading to two or adding information about rock types, but a new mode would add an arguably unnecessary layer of complexity.

I'm glad that we now seem to agree about the original topic of this discussion, and I'm gonna focus on the code part of the discussion that remains. Note: I'm not sure how to do this without using a completely impractical number of code blocks, so hopefully the links make everything a bit clearer than raw text. The way I said this part initially was admittedly quite messy and unclear, and there's a chance that I've confused myself at some point as well or lost something in rephrasing. As far as I can tell, though it's not the easiest part of the code to read, each value in the ore map corresponds to a 32x32 area (happens to be the same size as a chunk), which is caused by maps with 17x17 size, or resolution, being mapped to 512x512 regions (of particular interest is this line which actually sets the size, and the size is most relevant in this method used for interpolation which I'll mention again in a moment). I'm gonna skip the full explanation of how I got to that, though, because the exact resolution of the ore maps is ultimately irrelevant - the main points are that: IntDataMap2D (the data structure used for ore maps) allows to lerp between four values nearest to a precise location, which is the reason why the ore maps are effectively continuous and not based on chunks (the relevant interpolation method call is in this line, implementation of the method is here in vsapi), IMapRegion is not centered on the player's location, as it seems to be a 16x16 area of full chunk columns used for data storage - I haven't checked this one precisely (same as you I found it kinda difficult to find in the code, if it even is there), but I think I can quite confidently infer that it's not centered from the arguments in the method call in this line, and some other context, including the actual IMapRegion definition here. The first thing I'm gonna assume here is that by "player's position" you mean the reading's position, just so we're clear. Same goes for a few other places where you said this kinda thing. When obtaining a density reading, a map region (IMapRegion) is only ever used here to iterate through the dictionary of ore codes (codes are defined in the JSON deposit definitions) with corresponding ore maps. For each pair, the code is used to organize the data and not for any sort of testing or searching, whereas the ore map is only used to obtain its value at the reading's location. When actually calculating a reading (method call is in this line, actual method here), only 3 position-dependent factors are taken into account: oreMapFactor - the value obtained from the ore map earlier, a single point at the reading's location, rockFactor - proportion of allowed host blocks for the given ore (blocks are initially obtained from GetRockColumn, and are ultimately checked against placeBlockByInBlockId.Keys which only contains the block codes that the ore is allowed to spawn in, initially obtained here; though you can probably follow everything most easily if you start from the method call in this line), mapheight - surface Y level. It specifically uses the local coordinates within chunks to know which indexes to access in their block lists. Notice that the number of loop iterations is equal to the surface Y level, and it returns an array of exactly that many blocks: // Tyrons Brute force way of getting the correct reading for a rock strata column public virtual int[] GetRockColumn(int posX, int posZ) { const int chunksize = GlobalConstants.ChunkSize; DummyChunk[] chunks = new DummyChunk[sapi.World.BlockAccessor.MapSizeY / chunksize]; int chunkX = posX / chunksize; int chunkZ = posZ / chunksize; int lx = posX % chunksize; int lz = posZ % chunksize; ... int[] rockColumn = new int[surfaceY]; for (int y = 0; y < surfaceY; y++) { int chunkY = y / chunksize; int lY = y - chunkY * chunksize; int localIndex3D = (chunksize * lY + lz) * chunksize + lx; rockColumn[y] = chunks[chunkY].Blocks[localIndex3D]; } return rockColumn; }

I've been getting increasingly annoyed with the discussion because I would think that you bringing out the source code could close the argument at once (when I initially thought that the wiki should be enough to prove my point), and yet you don't seem to actually understand that code (though it doesn't change the objective contents of your arguments, I appreciate you at least said that you may make mistakes). I pointed out three things that were wrong in what seemed like your counterargument to mine, which are easily verifiable in the code you've provided yourself (or at least in other, related parts of the source code), and that's "just nitpicking"? Sorry to bother you again, but I think we have established throughout this discussion (and I think we've even had @Teh Pizza Lady explicitly confirm at least the first two points) that: galena only has one deposit generator which governs all of its deposit spawns at any height (as opposed to copper and cassiterite which have distinct surface and deep generators, of which the surface ones don't get detected by the prospecting pick), "surface deposits" of galena are just deposits that happen to spawn high enough, sufficiently close to the surface to spawn loose ore chunks above, density search readings correspond to the actual chance that the game uses to generate deposits, and I think that should make it quite clear how the connection appears. A higher galena reading indicates a higher spawn rate for all galena deposits, some of which will happen to spawn close enough to the surface to generate loose nuggets. Make of that what you will. If there are any doubts or counterpoints, I'll gladly hear them. I want to also mention that I appreciate that you've actually looked into it in your own time.

The map region is not centered on the player's location, because it represents a very specific 16x16 area. In order to obtain the rockFactor (proportion of blocks where the ore can spawn in) only a 1x1 column at the reading's location is used (initially obtained here). The ore map is stored in a 16x16 resolution, but it gets lerped based on the relative position of the reading within a map region, which effectively means that the ore distribution is continuous (the method is defined here in vsapi):

I think it has been pretty common knowledge that prospecting actually informs you about the chance to generate a deposit, and not about actual ore blocks (which is not fully accurate either, by the way, but close enough for all practical purposes). Tyron has also stated at one point that readings are based on position and not on chunks, and that's why we have readings displayed as points and not chunk-sized squares like ProspectorInfo and ProspectTogether do.

Neither nuggets nor ore blocks register in density search. It pulls the base spawn chance from the ore map and scales it based on the proportion of rocks where the ore can spawn in, as well as a few other factors less important in this context.

That's fair. My experience in a ~1000x1000 area covered in sedimentary rocks but with zero galena has lead me to think otherwise.

If what I've been arguing here for is true (even putting aside other evidence, I've basically proven it experimentally for my own use, and you can do the same if you don't believe it), then that leads to a very simple conclusion: In places with no readings for galena, you're wasting time searching for surface deposits, and you should look elsewhere. This can happen quite easily, even in large areas of sedimentary rock, because significant parts of ore maps are just empty (and that's not including areas where there are no suitable host rocks - the ore map is only later combined with that). Additionally, since you're very likely gonna take a few prospecting readings when looking for other resources, you might as well just check if there are any hits for galena without having to deliberately look for them. I also feel like you're overstating the time expenditure necessary to take a few readings, even a couple hundred blocks apart. Small note as well: it's technically possible for a deposit to spawn with no readings, because even "minuscule" only shows up above a very tiny threshold, but it's so low that it practically doesn't matter - "minuscule" is in the range 0.002 - 0.025 on a scale from 0 to 1. For context, "poor" starts at 2/15 (~0.134), and "ultra rich" starts at 2/3 (~0.67), if I didn't miscaclulate something. It is, of course, entirely possible to find surface nuggets purely by chance without any prospecting, and that's exactly what I did the first time I found lead. But I still found it very valuable to know that an area simply cannot generate galena, and I prefer taking an occasional reading over just wandering randomly.

One thing that I don't really see is how the potato could be implemented in a way which accurately reflects its historical benefits and yet avoids making it the single best food crop in the game, at least in temperate and cold climates. It's already really quite easy to set up a small farm that produces all the food a player might need, and food preservation is rarely a problem (and if it is, subsistence on hunting is absolutely possible). Many crops are functionally the same except for different temperature ranges which make them slightly more optimal in different climates. Without a larger farming rework, there is no way to implement the potato in a way that is actually distinct from other crops and still maintains proper gameplay balance, and so it would most likely simply end up as "just another crop", in spite of best intents. One thing that could help would be adjustments to the nutrition system to create an additional axis of balance, to make a distinction between foods that satiate and provide a lot of energy through the main macronutrients (e.g. meat and other proteins), and foods that aren't very caloric but provide a lot of micronutrients (e.g. fruits, mushrooms). The potato could be a satiating but not nutrient-rich crop, making it a strong choice for subsistence but much less suitable for maintaining proper nutrition. The game already includes a bunch of stuff from outside of medieval Europe like redwoods and bald cypress (much of which you're probably well aware of), and want to mention that I recall Tyron saying that they were considering splitting the game world into distinct regions that would each contain flora and fauna from one continent (or in a similar way from geographically distinct regions of the world, not necessarily split by continent). If they do move ahead with that, then the potato would gain a lot more importance.

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. Yeah, small correction to this: naturally generating snow doesn't seem to ever go above three layers, making for a 15% walk speed reduction. Appreciate you pointing that out. It seems that anything above 3 layers can only be artificially created by the player. Full snow blocks can appear in polar regions, but they don't seem to reduce movement speed as far as I can find.