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

[Teh Pizza Lady]

2 hours ago, MKMoose said:

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.

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.

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

this. exactly

[MKMoose]

2 minutes ago, Teh Pizza Lady said:

nuggets absolutely *will not* register in a density search

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.

[ArgentLuna]

All the lead ive ever found has been grabbed from visble on the surface desposits as ive been exporing (and i use a lot of lead with lanterns)

[TFT]

5 hours 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. 

Stands reason to me that it would save a lot of time. You could run around looking in a place where there is no galena and move on after 20 minutes of finding jack squat, or take a couple seconds on a reading telling you there's no galena and move on. But you do you on how you spend your time, I aint your mom.

[Maelstrom]

Over the weekend I checked my map for instances of galena nuggets I waypointed and prospecting results for galena only.  I have two fields of galena and both corresponded to prospecting results for galena as well.

Upon further review the penalty is reversed.  I concur with @MKMoose that there does seem to be some kind of connection between prospecting results and galena surface deposits that create nuggets. 

@Teh Pizza Lady - I'd be interested to hear your findings in less technical terms.  I'd also be interested if you can find a connection between surface deposit generation and pro-pick readings.

[Teh Pizza Lady]

7 minutes ago, Maelstrom said:

I'd be interested to hear your findings in less technical terms.  I'd also be interested if you can find a connection between surface deposit generation and pro-pick readings.

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.

[Maelstrom]

I'm not saying that density prospecting is a way to find surface nodes directly.  I'm thinking more along the lines of using the prospecting results from random prospecting as a potential indicator of surface nuggets if a visual inspection wasn't done.  Granted, this is very, very niche use case.

As for the technomancy?   I think there is some kind of unintended interaction (probably a logic error) going on that indirectly causes density searches and ore generation of surface ore deposits to be linked in some obscure fashion.

[Teh Pizza Lady]

1 hour ago, Maelstrom said:

I'm not saying that density prospecting is a way to find surface nodes directly.  I'm thinking more along the lines of using the prospecting results from random prospecting as a potential indicator of surface nuggets if a visual inspection wasn't done.  Granted, this is very, very niche use case.

As for the technomancy?   I think there is some kind of unintended interaction (probably a logic error) going on that indirectly causes density searches and ore generation of surface ore deposits to be linked in some obscure fashion.

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.

[MKMoose]

13 minutes ago, Teh Pizza Lady said:

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.

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.

[Teh Pizza Lady]

1 hour ago, MKMoose said:

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.

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.

[MKMoose]

7 hours ago, Teh Pizza Lady said:

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.

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

6 hours ago, Teh Pizza Lady said:

int oreDist = value.GetUnpaddedColorLerped(posXInRegionOre, posZInRegionOre);   //returns the actual distribution of ore for that chunk as stored in the ore map

[Tabbot95]

On 12/4/2025 at 7:35 AM, Vexxvididu said:

Trying to find lead for windows and more so for a distill.  ....no luck.  Just did a ton of prospecting this morning.  I have a big area near my base with miniscule amounts, but don't think I've ever seen poor or higher of it.

Is there some trick to how it spawns, or is this just pure RNG?  So far nothing else has evaded me so much...

lead, and iron ores and lime-containing shells should be stuff you should be able to get by panning (with lime obviously far higher in limestone sands).. 

 

 

[Vexxvididu]

53 minutes ago, Tabbot95 said:

lead, and iron ores and lime-containing shells should be stuff you should be able to get by panning (with lime obviously far higher in limestone sands).. 

 

 

I don't agree iron should ever show up from panning (or at least be very rare).  It makes complete sense that you should have to mine deep for it. The rest makes sense.

[Tabbot95]

51 minutes ago, Vexxvididu said:

I don't agree iron should ever show up from panning (or at least be very rare).  It makes complete sense that you should have to mine deep for it. The rest makes sense.

my thought was a low grade bog iron that might need additional steps for refining or have a lower overall yield;

 

[Teh Pizza Lady]

On 12/9/2025 at 3:07 AM, MKMoose said:

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 feel like you're just nitpicking my words now to keep the argument going for no reason.

[MKMoose]

6 hours ago, Teh Pizza Lady said:

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

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"?

 

On 12/8/2025 at 5:56 PM, Maelstrom said:

I'd also be interested if you can find a connection between surface deposit generation and pro-pick readings.

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.

Edited December 11, 2025 by MKMoose
Phrasing.

[TFT]

I think this is pretty easy to verify if nothing else. Using the block overlay mod I searched around for lead ore bits (first image), then set it to show lead ore blocks (second image), then took a propick reading of the center of the zone. For this example the reading I was given was "decent 4.59%". Even poor and very poor readings produced surface bits and deposits directly below and deeper around the area. Try it yourself.
Seems pretty conclusive to me. Where there's a lead reading, there's surface ore bits. Where there isn't a lead reading, there's no surface bits. The same cannot be said for copper and tin where an area absolutely littered with surface bits and only shallow deposits produced no propick reading for them, but an area with deeper ore did and any surface bits are coincidental. This conclusion shouldn't be a surprise as copper and tin are the only unique outliers and are specifically coded to be so, as has been stated ITT.

So if you really want to find lead, take a propick reading and if you have something above minuscule then it can be worth taking a look around for bits and the easy deposits below. Of course lighter sedimentary rock strata and flat plains or badlands will make it much easier to spot. If anything is decent you could treat it as you would any other ore and start mining shafts and use the short range node search.

[Maelstrom]

@TFT Seems like you wrapped up the debate and put a nice pretty bow on it, to boot!

That's a ton of lead!

[Teh Pizza Lady]

7 hours ago, MKMoose said:

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"?

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.

[LadyWYT]

Given that @TFT seems to have settled the debate, now I want to know if coconuts migrate.

[Teh Pizza Lady]

I mean.. yeah. TFT certainly did that.

The short of it is this:

you prospect
Computer does a big beep boop and calculates how much ore is surrounding you based on what's possible for that area in a predefined radius surrounding your position. It does so by grabbing all the chunks that surround your position, calculating the ore distributions for each one (ignoring ores that are outside the Y bounds for that ore type) and then adding it all up and dumping it to the chat log.

So yes, very much position based, Tyron didn't misspeak. players just misunderstood him. You can have ores so shallow and so sparse that they don't show up on the density search even though they generate surface bits to indicate their presence.

It all just *seems* chunk based because the ore and terrain generation is 100% chunk based.

TFT's screenshots show that there's a LOT more ore than the surface bits would indicate. I don't know what to do with this data... might be time to make bigger mines when it comes to digging for lead.

 

[Maelstrom]

2 hours ago, Teh Pizza Lady said:

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.

Easily to prove him right or wrong.   Take a reading.   Move over 8 blocks and take another reading.  Check to see if the reading are identical (including the per mille output) or not.  If Tyron is right the per mille reading will be a wee bit different between those two readings.

[Maelstrom]

2 hours ago, LadyWYT said:

Given that @TFT seems to have settled the debate, now I want to know if coconuts migrate.

 

Are we using African or European swallows?

[Teh Pizza Lady]

4 minutes ago, Maelstrom said:

Easily to prove him right or wrong.   Take a reading.   Move over 8 blocks and take another reading.  Check to see if the reading are identical (including the per mille output) or not.  If Tyron is right the per mille reading will be a wee bit different between those two readings.

yeah and I account for this by allowing the region size that the propick checks to not be an exact chunk amount so that moving around within a single chunk WILL give you different outputs. I really have no idea how it determines the map region to check... couldn't find it in the code, but once it gets that data then it does what you say.

I already know he's right, but I couldn't rationalize it in the code without accounting for the map region being wishywashy when the ore check is performed.

[MKMoose]

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.

6 hours ago, Teh Pizza Lady said:

To be perfectly frank, I don't know where you got the 16x16 area idea from.

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.

 

6 hours ago, Teh Pizza Lady said:

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.

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.

 

6 hours ago, Teh Pizza Lady said:

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.

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

Edited December 11, 2025 by MKMoose