View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0009980 | Dwarf Fortress | World Generation -- Parameters | public | 2016-08-26 15:45 | 2017-08-07 02:19 |
| Reporter | LarryCoolfred | Assigned To | lethosor | ||
| Priority | normal | Severity | minor | Reproducibility | sometimes |
| Status | feedback | Resolution | open | ||
| Product Version | 0.43.03 | ||||
| Summary | 0009980: Filtering during PreEmbark is "inaccurate"(?) | ||||
| Description | Im new to the game so I may just be misunderstanding. I set the filter to Multiple deep and shallow metals along with Frequent Minerals in world gen, yet prospector is showing only Cassiterite. I've had this happen before instead with Native Copper or Coal | ||||
| Additional Information | Again I am very new (haven't experienced fun any more interesting than tantrum spiral and starvation) so maybe im missunderstanding a feature. | ||||
| Tags | No tags attached. | ||||
|
|
I've done some investigation of this issue (0.43.05), and it does seem DF doesn't take the embark depth into consideration. The geo biome may specify metal bearing layers, but those layers can be specified for depths greater than that of the magma sea at the embark, in which case they never show up. The DFHack command "prospect all" run pre embark does account for the cutoff effect caused by the magma sea and seems to perform a correct account of the presence of metals, while it seems DF simply goes by what's specified in the geo biome. Given the general nature of how it works, I assume flux can likewise go missing despite being "promised", for the same reason. Finally, I'd say this is actually the same problem as 0002900. |
|
|
What happens if you actually embark? There's no guarantee that DFHack's "prospect" command is always right, so you can't open a bug report simply based on an inconsistency between what DF and DFHack report. |
|
|
You're correct in that verification should be performed by embarking, and I have done so (and should have mentioned it above). The verification cases made use of "reveal all", but I'm not aware of it having been detected to produce incorrect information, so I trust what's seen there. Looking at DF's geo biome, I've verified that the metal bearing layer in at least one case was the next one after the one hitting the SMR (in other cases I've just noted that the metal bearing layer was missing, without explicitly checking that it was below the last one present). I've also experimented with the aquifer detection, where DF likewise can produce incorrect claims (claiming one is present when it is not: I haven't encountered any cases of a claim for an aquifer to be absent and then actually have one present, but I haven't been looking for it). My experiments indicate an aquifer is present whenever an aquifer supporting layer has a presence at the 3:rd level (from the surface) or lower (those are indications; there may very well be additional condition, or some other actual connection that seeminly produces the same results in my cases), and in all those experiments the aquifer went missing due to elevation caused soil erosion. For the aquifer experiments I've usually embarked and then just dug a staircase, although some whackier ones with a manipulated geo biome that contains multiple layers of (aquifer supporting) conglomerate used "reveal all" and checking for wet stone. I haven't checked clay indications against soil erosion, nor have I checked DF reported soil depth against embarks subjected to soil erosion. I suspect DF may be misreporting there as well, though, but it would have to be investigated to determine if that's correct or not. Edit: I've now found one case of DF failing to report clay. In this case the tool I'm working on reported clay while DF didn't, so I checked it up. The geo biome shows Sandy Clay as the fourth layer. Embarking at the location as a single biome embark, I did indeed find Sandy_Clay with "reveal all", and it probably was the fourth level as it was damp from an aquifer in the sand layer above. Since DF reports clay elsewhere, I'm not sure where the problem is. One possibility is that it's material related, i.e. if DF is using a hard coded list of materials to detect clay (my code uses a rather crummy reliance on the reaction to make clay bricks, which also catches kaolinite: there's no material flag for clay, nor a soil layer flag (e.g. SOIL_CLAY) for it), while another possibility is if DF somehow only scans the first three layers for clay (I've seen "shallow clay", but I'm not sure if I've seen "deep" or "very deep"). |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2016-08-26 15:45 | LarryCoolfred | New Issue | |
| 2017-07-31 05:12 | PatrikLundell | Note Added: 0036685 | |
| 2017-08-06 18:00 | lethosor | Note Added: 0036688 | |
| 2017-08-06 18:00 | lethosor | Assigned To | => lethosor |
| 2017-08-06 18:00 | lethosor | Status | new => feedback |
| 2017-08-07 02:19 | PatrikLundell | Note Added: 0036689 | |
| 2017-08-21 04:10 | PatrikLundell | Note Edited: 0036689 |
