I have not failed to locate Lead, I've simply found a ton of places with none or miniscule amounts!

[Maelstrom]

I was afraid you were referencing the VS wiki page.  Those pages are largely unchanged since I first read them 3-4 years ago.  If you read the first one carefully you'll find exactly what I've been saying.   Any connection between the pro-pick density search mode and surface nuggets is purely coincidental.   Additionally, that same table shows that lead does not spawn as deep ores, therefore my statement about the density search being blind to lead.

Quote

Deep ores are not indicated by surface deposits in loose stones. Most deep ores can only be found by luck or by exploratory mining guided by a prospecting pick.

Galena also has the highest tries per chunk for surface ores.  The high likelihood of surface ore generation for lead makes your correlation seem strong despite being coincidental.   When I get home I'll poke around with prospecting for lead in density search mode.  I still maintain that your method is dubious with specious results.  

[Teh Pizza Lady]

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:

1. Surface deposits exist for decoration/worldgen only.
2. The propick system is strictly tied to subsurface, aka deep ore blocks
3. 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.

Edited December 5, 2025 by Teh Pizza Lady
numbering of points

[LadyWYT]

7 minutes ago, Teh Pizza Lady said:

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.

Well, actually...halite will show up on the density search readings. It will not, however, show up for a node search reading.

Of course it's also possible that's what you said, and I just misunderstood it. 

[Teh Pizza Lady]

1 minute ago, LadyWYT said:

Well, actually...halite will show up on the density search readings. It will not, however, show up for a node search reading.

Of course it's also possible that's what you said, and I just misunderstood it. 

It's a special snowflake.

[MKMoose]

1 hour ago, Maelstrom said:

Those pages are largely unchanged since I first read them 3-4 years ago.

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.

 

1 hour ago, Maelstrom said:

If you read the first one carefully you'll find exactly what I've been saying.   Any connection between the pro-pick density search mode and surface nuggets is purely coincidental.

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:

Quote

Shallow deposits can sometimes (but not always) be indicated by the presence of loose stones containing ore on the surface of the world.

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.

Edited December 5, 2025 by MKMoose

[MKMoose]

@Teh Pizza Lady A quick note: I'm reading through your post, and it seems absolutely correct in what it describes, but almost entirely unrelated to the preceding discussion. You're making me question if I've maybe just been misinterpreting something, but I do not find that likely.

Surface blocks are the loose nuggets. This is not the same as "surface deposits", i.e. proper ore deposits that happen to spawn with nuggets above them. The way I've been seeing it, this discussion is about whether the prospecting pick's readings are correlated with surface deposit frequency, and only by proxy with loose ore chunks which are the primary way of finding those deposits.

Edited December 5, 2025 by MKMoose

[Teh Pizza Lady]

1 minute ago, MKMoose said:

@Teh Pizza Lady A quick note: I'm reading through your post, and it seems absolutely correct in what it describes, but you're making me question what this discussion is even about, and if I've maybe just been just misinterpreting something.

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.

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.

[MKMoose]

1 hour ago, Teh Pizza Lady said:

bool shouldGenSurfaceDeposit = DepositRand.NextFloat() <= GenSurfaceBlockChance && SurfaceBlock != null;

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.

 

1 hour ago, Teh Pizza Lady said:

3.   The JSON does not control propickability.

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.

Edited December 5, 2025 by MKMoose
Phrasing and spelling.

[Teh Pizza Lady]

45 minutes ago, MKMoose said:

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)

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.

[MKMoose]

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

5 hours ago, MKMoose said:

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.

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.

[TFT]

@MKMoose If I understand your points right. All surface deposits are "surface" deposits, but not all "surface" deposits are surface deposits. Surface copper and tin are distinct because those two metals are the most important for early game progression, so they are not represented by a propick and have worldgen settings to adjust their frequency hence the separate objects in code. "Surface" deposits of everything else like coal, lead, or whatever generate normally and be correlated with propick search data. Whether they happen to be close enough to the surface to produce bits to pick up is dependent on how the terrain generates. Since lead is a sedimentary rock ore it'll be closer to the surface more often than not and you'll find bits on the ground above those deposits.

[Teh Pizza Lady]

3 minutes ago, TFT said:

@MKMoose If I understand your points right. All surface deposits are "surface" deposits, but not all "surface" deposits are surface deposits. Surface copper and tin are distinct because those two metals are the most important for early game progression, so they are not represented by a propick and have worldgen settings to adjust their frequency hence the separate objects in code. "Surface" deposits of everything else like coal, lead, or whatever generate normally and be correlated with propick search data. Whether they happen to be close enough to the surface to produce bits to pick up is dependent on how the terrain generates. Since lead is a sedimentary rock ore it'll be closer to the surface more often than not and you'll find bits on the ground above those deposits.

Correct.

And also... Just to clarify

39 minutes ago, MKMoose said:

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.

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:

On 12/4/2025 at 9:39 AM, MKMoose said:

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

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.

[Teh Pizza Lady]

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

[MKMoose]

7 hours ago, Teh Pizza Lady said:

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.

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:

7 hours ago, Teh Pizza Lady said:

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.

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.

Edited December 6, 2025 by MKMoose

[Metalton]

*squints* Could be wrong, but see "Density Search" being thrown around a lot, but feels like some are referring to Node Search as Density Search.

Now, before I completely confuse myself.. or maybe because I've completely confused myself.. Density Search is based on the ore heat map only, and it does not matter whether the ore is there or whether it spawned near the surface or not. All that matters is if the ore itself is listed in the heat map (which excludes certain special ores/rocks like "surface copper").. and if the ore is on the heat map, the best place to look for it is where there is a reading.. unless you get lucky with a deposit popping up outside the heat map area (and therefore has no propick reading)

Node Search is limited range (adjustable) and -will- detect anything in range, excluding certain special ores/rocks.

..and as with all things VS the best way to find anything is to stumble across it while your busy doing something else.. like falling down a very deep hole in the ground..

[Maelstrom]

@Metalton Correct!

[MKMoose]

5 hours ago, Metalton said:

Density Search is based on the ore heat map only, and it does not matter whether the ore is there or whether it spawned near the surface or not.

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.

 

7 hours ago, MKMoose said:

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.

Now, to get back to this:

8 hours ago, Teh Pizza Lady said:

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;
}

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:

8 hours ago, Teh Pizza Lady said:

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.

Edited December 6, 2025 by MKMoose
Spelling.

[Teh Pizza Lady]

10 hours ago, MKMoose said:

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:

19 hours ago, Teh Pizza Lady said:

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.

then maybe I AM misreading the code.

I have a degree in computer science. I know this stuff. But I do make mistakes.

[MKMoose]

3 minutes ago, Teh Pizza Lady said:

then maybe I AM misreading the code.

I have a degree in computer science. I know this stuff. But I do make mistakes.

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.

[MKMoose]

15 hours ago, MKMoose said:

15 hours ago, Teh Pizza Lady said:

then maybe I AM misreading the code.

I have a degree in computer science. I know this stuff. But I do make mistakes.

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:

On 12/6/2025 at 9:04 AM, MKMoose said:

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

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.

[LadyWYT]

4 hours ago, MKMoose said:

whether density readings are useful when searching for surface nuggets that indicate surface deposits. 

I would still say the answer is "no", really. Even if density search does serve as an indicator for potential surface nuggets/deposits(and I'm not convinced that it does), the player is still going to need to actually look for those nuggets after conducting the density search...or searches, since they'll probably be prospecting multiple times. The time they spent prospecting just to find lead readings is time they could have spent just scouting the surface visually for a sign of lead. 

Prospecting is really only worth it if the player is looking for things other than lead.

[MKMoose]

1 hour ago, LadyWYT said:

I would still say the answer is "no", really. Even if density search does serve as an indicator for potential surface nuggets/deposits(and I'm not convinced that it does), the player is still going to need to actually look for those nuggets after conducting the density search...or searches, since they'll probably be prospecting multiple times. The time they spent prospecting just to find lead readings is time they could have spent just scouting the surface visually for a sign of lead. 

Prospecting is really only worth it if the player is looking for things other than lead.

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.

Edited December 7, 2025 by MKMoose
Formatting.

[Zane Mordien]

In general, when the discussion gets this deep into the code of the game, it really takes away from the fun of the game. 

[LadyWYT]

2 hours ago, MKMoose said:

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.

Not really. My entire point is that if the player is only after galena specifically, they're wasting their time by prospecting for it. That's all. But that's also just like, my opinion man. 

[MKMoose]

3 minutes ago, LadyWYT said:

Not really. My entire point is that if the player is only after galena specifically, they're wasting their time by prospecting for it. That's all. But that's also just like, my opinion man. 

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