Teh Pizza Lady

To be perfectly frank, I don't know where you got the 16x16 area idea from. That's not explicitly stated in the code that either of us searched. That's a ChatGPT answer. I know because I tried, it too, out of curiosity, dumped the source code for the propick into the prompt and it still couldn't explain where it got the 16x16 number from either. Conclusion: AI is bad. Second, the ores it searches for comes from the ore map and it performs those searches by searching in a region defined by a set radius centered on the players position. And, finally, if you bothered to check the definition for the GetRockColumn method, you would see that it uses the chunk that the player is standing in, not the singular 1x1 column. Why does it matter then that Tyron said it's based on the position the player is standing, and not chunks? Everything seemingly points to him being wrong. The answer is probably related to the map region is maybe not perfectly sized with respect to the chunk sizes so the reading can shift even within the same chunk depending on where the player is standing. Or maybe he thought it was based on position, not chunks, and the code changed after he made that statement. Or someone told him it was position based. Or he got confused by his own code, something that I've done plenty of times myself. I don't know. I just know what I see in the code and I cannot rationalize it with your statements hence my suspicion that you're just nitpicking semantics at this point to keep this going.

I feel like you're just nitpicking my words now to keep the argument going for no reason.

I meant the chunk surrounding the player's position. The ore map has a much lower resolution than the world map. You can tell this based on the way the game attempts to triangulate your position in the ore map before pulling the reading otherwise it would be based solely on your x,z coordinate. The reading at your position is still based on all the readings in the surrounding areas based on that region of the ore map. IMapRegion mapRegion = world.BlockAccessor.GetMapRegion(pos.X / regsize, pos.Z / regsize); int lx = pos.X % regsize; int lz = pos.Z % regsize; then for each ore map in the region foreach (KeyValuePair<string, IntDataMap2D> val in mapRegion.OreMaps) { IntDataMap2D value = val.Value; int noiseSize = value.InnerSize; float posXInRegionOre = (float)lx / (float)regsize * (float)noiseSize; float posZInRegionOre = (float)lz / (float)regsize * (float)noiseSize; int oreDist = value.GetUnpaddedColorLerped(posXInRegionOre, posZInRegionOre); //returns the actual distribution of ore for that chunk as stored in the ore map ... ppws.depositsByCode[val.Key].GetPropickReading(pos, oreDist, blockColumn, out var ppt, out var totalFactor); } So it will iterate through the region centered on your location and then get the oremaps for that region iterate through them, and tally it all up using the blocks below you to rule out any impossible spawns (like galena in granite). Because the oremap is such a low resolution, it can seem like it's chunks. It's like zooming into a small painting in MSPaint. You are seeing small pixels that actually cover multiple pixels on your screen. The pixels of the ore map cover entire chunks of the world map.

The game uses a pre-generated ore map (probably linked to the seed) to determine where ores should go. Then it checks to see if the ores actually can go there. When prospecting, the game then refers to the ore map to limit its search and then checks for ores within that chunk to see what's actually there. Sometimes, what's there is so small or super thin enough that it doesn't show up in the search. Realistically you could enter an area with sedimentary rocks and just do a density search in one location. Galena should pop up on the ore map. If it doesn't then a quick scan for surface nuggets will confirm the results.

computer does a big beep boop and magic happens. Sometimes if the ore is in the oremap but the actual generation doesn't allow the ore to generate, it can create skewed results.. For example on a previous world I located a good magnetite deposit. HOWEVER, the only way to access it was via under ground tunnels from our initial dig point. You may remember the bell-head shiver story... That was the same mining shaft/dig site. The magnetite was actually located 50-100 blocks away from where the prospecting results said it should be. because of this, prospecting for ores that give surface deposits nuggets is really only useful if you use the node search instead of density search. Far easier to just locate the nuggets with your eyes, and then do further exploration around the area with node searches (every 12 or so blocks) to see if there are additional deposits that didn't generate surface nuggets.

Multiplayer would be unavailable without internet, anyway. Kind of a no-brainer there.

The fact that you cannot repair bear armor seems intentional and I honestly cannot think of a good way to do it outside of skinning and tanning the hide of another bear to use for the repairs.... which at that point you might as well just make another set of armor.

nuggets absolutely *will not* register in a density search. So if the deposit is tiny enough also not to show on a density search, then you could miss the galena by simply prospecting for it. this. exactly

then maybe I AM misreading the code. I have a degree in computer science. I know this stuff. But I do make mistakes.

I had to travel a days trip by boat to find bees in my last world. It was painful.

And as a side note, you now have a better understanding of what those danged permille readings mean when you do a density search!

Correct. And also... Just to clarify Correlation is not causation. The presence of loose surface blocks (the nuggets or chunks you see on top of dirt covering the rock layers) does not determine whether density readings appear. Density search looks only at the full ore blocks within the deposit’s vertical range. The game's code shows this VERY CLEARLY if you bother to look at the C#. Galena uses the disc-followsurface generator, and its depth is controlled by the JSON yPosRel: yPosRel: {dist: "uniform", avg: 0.5, var: 0.5 } The "follow surface" generator overrides the GetYMinMax method like so: public override void GetYMinMax(BlockPos pos, out double miny, out double maxy) { float yrel = 9999f; for (int i = 0; i < 100; i++) { yrel = Math.Min(yrel, YPosRel.nextFloat(1f, DepositRand)); } miny = yrel * (float)pos.Y; maxy = (float)pos.Y; } In other words, it runs some RNG to determine the actual depth. The min and max y levels are then computed relative to the Y level of the current position given to the method with maxy being the surface level at that X and Z coordinate. Surface deposits as we have defined them here are shallow by design; their miny often ends up very close to maxy. Density search excludes blocks greater than maxYAvg, so these shallow deposits frequently fail to produce readings, even though they exist underground. Surface blocks are sometimes generated on top of these deposits, creating the loose ore you see on the surface. These surface blocks are purely cosmetic/lootable and do not affect whether the deposit is detected—they are simply an indicator that the underlying deposit is near enough to the surface for nuggets to appear. Interestingly enough if the ore generates below the miny value, then it will also not trigger the density search. Let's follow the code path again for the density search starting here: public override void GetPropickReading(BlockPos pos, int oreDist, int[] blockColumn, out double ppt, out double totalFactor) { int qchunkblocks = Api.World.BlockAccessor.GetTerrainMapheightAt(pos) * 32 * 32; double oreMapFactor = (double)(oreDist & 0xFF) / 255.0; double rockFactor = oreBearingBlockQuantityRelative(pos, variant.Code, blockColumn); totalFactor = oreMapFactor * rockFactor; double relq = totalFactor * absAvgQuantity / (double)qchunkblocks; ppt = relq * 1000.0; } oreBearingBlockQuantityRelative is defined as: private double oreBearingBlockQuantityRelative(BlockPos pos, string oreCode, int[] blockColumn) { HashSet<int> oreBearingBlocks = new HashSet<int>(); if (variant == null) { return 0.0; } int[] blocks = GetBearingBlocks(); if (blocks == null) { return 1.0; } int[] array = blocks; foreach (int val in array) { oreBearingBlocks.Add(val); } GetYMinMax(pos, out var minYAvg, out var maxYAvg); int q = 0; for (int ypos = 0; ypos < blockColumn.Length; ypos++) { if (!((double)ypos < minYAvg) && !((double)ypos > maxYAvg) && oreBearingBlocks.Contains(blockColumn[ypos])) { q++; } } return (double)q / (double)blockColumn.Length; } So, if the ore is shallow enough, then it will not appear in the density search because it doesn't get counted. It's too shallow and not inside the range of detection. Surface deposits being near the top make them too shallow to reliably trigger density search, even if they spawn surface blocks above. You initially claimed: as a refute to Maelstrom's claim that the propick doesn't register surface deposits. I'm attempting to explain why this is sometimes true. I trust her to know what she's talking about especially since she's played the game a LOT more than I have... but I trust the code more and the code tells me that sometimes deposits can actually be too shallow to register... and sometimes won't have surface bits to indicate their presence either.

I did not spell everything out because it would have made my post even longer. Yes you can override these values. That does not exclude the ore from the surface deposits, but rather shows that sometimes surface deposits will not have surface blocks to indicate their presence. IN OTHER WORDS, you can have a surface deposit without surface blocks, but not surface blocks without a deposit. My original statement is true, that surface deposits for Galena will not be revealed by the propick in density search. You can only find them with node search.

RNG is a cruel mistress and we are all bound to her will. Your seed sucks for Lime. End of story. I've been screwed over by Bauxite before. My current map has it EVERYWHERE, but I cannot find Olivine anywhere. Borax was literally on top of the surface for me and there's an entire limestone/chalk beach across the ocean from me. My seed sucks for Olivine. It's a struggle. Welcome to Vintage Story. This is your life now! Try a different seed or keep looking for other sources. You'll get there!

You're making this very tempting......painfully so. You play Vintage Story. This is your life now.

Surface blocks are entirely different and separate from the surface deposits. The density search will ignore surface deposits, which are guaranteed to *also* generate surface blocks, as found here: public abstract class DiscDepositGenerator : DepositGeneratorBase { [JsonProperty] public float GenSurfaceBlockChance = 1f; public override void GenDeposit(IBlockAccessor blockAccessor, IServerChunk[] chunks, int chunkX, int chunkZ, BlockPos depoCenterPos, ref Dictionary<BlockPos, DepositVariant> subDepositsToPlace) { ... bool shouldGenSurfaceDeposit = DepositRand.NextFloat() <= GenSurfaceBlockChance && SurfaceBlock != null; ... } } DepositRand.NextFloat() generates a value between 0f and 1f... meaning it will always generate surface blocks for surface ores. Thus if you find surface deposits for lead, propicking will fail on the density search.

It's a special snowflake.

So... this is going to be a long post. My apologies to those with short attention spans. Surface deposits are simply NOT propickable. This is not determined by the JSON but rather by the in-game ore generator. 1. The propick only checks "in-block" deposits. These are separate from surface deposits. The propicking system uses DepositVarant.GetPropickReading() defined as so: public override void GetPropickReading(BlockPos pos, int oreDist, int[] blockColumn, out double ppt, out double totalFactor) { // Calls the generator to compute propick readings GeneratorInst.GetPropickReading(pos, oreDist, blockColumn, out ppt, out totalFactor); } For the DiscDepositGenerator (used by both galena and halite), this is implemented as so: public override void GetPropickReading(BlockPos pos, int oreDist, int[] blockColumn, out double ppt, out double totalFactor) { int qchunkblocks = Api.World.BlockAccessor.GetTerrainMapheightAt(pos) * 32 * 32; double oreMapFactor = (double)(oreDist & 0xFF) / 255.0; double rockFactor = oreBearingBlockQuantityRelative(pos, variant.Code, blockColumn); totalFactor = oreMapFactor * rockFactor; double relq = totalFactor * absAvgQuantity / (double)qchunkblocks; ppt = relq * 1000.0; } Here the rockFactor is calculated only from ore-bearing blocks in `placeBlockByInBlockId`. In other words. Surface deposits are skipped. I'll explain why. private double oreBearingBlockQuantityRelative(BlockPos pos, string oreCode, int[] blockColumn) { int[] blocks = GetBearingBlocks(); // returns placeBlockByInBlockId.Keys ... } public int[] GetBearingBlocks() { return placeBlockByInBlockId.Keys.ToArray(); } The propick ONLY sees blocks stored in this dictionary in the code. SURFACE DEPOSITS ARE HANDLED DIFFERENTLY. 2. Surface ore blocks are NEVER added to `placeBlockByInBlockId`, but rather, go into `surfaceBlockByInBlockId`: if (SurfaceBlock != null) { // This is used only for world generation surfaceBlockByInBlockId[block.BlockId] = SurfaceBlock.Resolve(variant.fromFile, Api, block, key, value); } This dictionary here is NEVER checked by GetPropickReading() and in fact, is never mentioned again in the code that I looked at for this deep dive...so surface deposits are NEVER included in the propick readings. 3. The JSON does not control propickability. It only defines the ore distribution, which ore generator to use, and what blocks to place: [ { code: "galena", ... generator: "disc-followsurface", attributes: { inblock: { code: "rock-*", name: "rock", allowedVariants: ["claystone", "sandstone", "shale", "chalk", "limestone", "chert", "conglomerate"] }, ... surfaceBlock: {code: "looseores-galena-{rock}-free" }, ... }, ... } ] Bottom line: Surface deposits exist for decoration/worldgen only. The propick system is strictly tied to subsurface, aka deep ore blocks To make surface deposits propickable, the generator code itself would need to ALSO include surfaceBlockByInBlockID in GetBearingBlocks(), which it does not. Halite is not propickable because the way it is defined in the JSON means it never gets added to the placeBlockByInBlockID list for the propick search, despite being a subsurface rock. It's very similar to how substrata also do not show up in the propick search because they are rocks, not ores. I hope this helps everyone and settles the argument once and for all.

it actually does... a default of 40% movement reduction speed at max fat level. We found that any lower induced a "slo-mo" effect which made the game janky in a lot of ways.

I could pull the whole "drain nutrition before health" bit into Expanded Stomach or at least into a companion mod. I'll add it to my roadmap for sure with an option to toggle it off in case another mod handles it, too.

given how much RNG is already in the game I don't think it would be a big deal to have a season start/end vary by a few days. Bearing in mind that the standard month length is...10 days by default?

wrong thread XD XD

I don't find it strange. Maps and minimaps are one of the most downloaded features for other block games and some of the more popular mods for this game. I am absolutely down for anyone who wants to turn it off for a more challenging experience however. That option is there to be used!

The problem is that there are those of us who are right and those of us who are diplomatic. They seldom intersect.

Probably. now I have a bunch of Subaru jokes stuck in my head... What do you call a Subaru that's under water? Scubaru What do you call a Subaru that comes with a vacuum? Subaroomba