MKMoose

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.

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. I'm not aware of player temperature having any impact.

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

While I like the idea of crafting maps, I've never liked Minecraft's way of doing it. I'm not sure how it could be implemented to be sufficiently simple and intuitive for Vintage Story's exploration style, because having to bring a dozen maps with yourself when on a trip could get very inconvenient very fast. The coverage of Minecraft's maps being completely dependent on where they are activated has always frustrated me. There's a lot of ways to arguably improve upon a more realistic implementation, like by abstracting it away to some extent to avoid constantly taking up inventory slots, by reducing resource consumption to avoid imposing tedious maintenance, and it kind of devolves back into leaving the system as is, because it's just simple and convenient. It could certainly be immersive to have more realistic maps, and I would appreciate any middleground between full map and no map whatsoever, but I'm just not sure it would fit the standard game experience well enough to justify the effort. There's also the potential issue that if this system gets added, then many new items could be rendered useless (besides decorative uses) when playing with the map active at all times or completely disabled, which may then have to be addressed in item tooltips or the handbook in some way to avoid confusion. While I typically find myself disliking the "it would be better as a mod" response, in this specific context it seems more appropriate than usual, unless there are other good reasons for craftable maps. This part seems very good. The concern about the table losing all functionality when not using realistic maps even gets circumvented with waypoint sharing, and it could even allow sharing prospecting data (which technically are just a bit different waypoints, but still). It may be necessary to do something to avoid the need to clean up dozens if not hundreds of unnecessary waypoints each time after exchanging them, though, while still ideally allowing to transfer specific waypoints. I don't know what specific implementation you have in mind, but just in case I'll mention that automatic systems automatically make me stop paying attention to the surroundings. Reducing friction when marking the 76th trader and 134th copper deposit would be great, but the player should still be required to actually notice what gets marked. It could be done just by making automatic waypoint range very short, or perhaps better by having the player get close enough to things and right-click the important blocks (fruit trees, surface nuggets etc.) with a map in hand, or something in that vein. If that's roughly what you had in mind then I get you, just wanted to be sure because it's a very important point that I've seen people neglect in other contexts and then be surprised that exploration has become boring, after they take away most of the mental stimulation from it.

I just noticed, small correction on that part: it's 7 blocks average radius, while 14 blocks is the diameter.

Right, I kind of missed that, thank you. Although, keep in mind that if you ever find yourself wondering "can bees spawn here?", you'd generally prefer not to risk the chance and be in a common or very common area.

Prospecting data (specifically density search) is not concerned with what ores actually end up generating. The game generates a random distribution for each ore type that can be detected by the prospecting pick's density search, and this distribution is used both when randomly generating the ore and when the prospecting pick gives you a reading. That is, the density readings inform you about the actual chance that the game uses to generate the deposits, but whether that ore has actually generated under the reading is a separate matter. Caves generate first, then ore deposit generation replaces rock with ore blocks. Air is treated as a different block, so it doesn't get replaced. Either way, the end result is as you're assuming - if a cave happens to pass through a deposit, it effectively removes a bunch of the ore blocks. I've recently found a cassiterite deposit with exactly one ore block in a cave, which was quite amusing. Your case seems pretty unlucky, since deep copper deposits (I'm assuming you're talking about a deep and not surface deposit) tend to be much larger than cassiterite deposits: ~14 blocks average radius, and can generate up to 3 blocks thick. It is nonetheless entirely possible for a cave to remove most of it, provided the cave is large enough.

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.

To my knowledge, bees just require a warmish climate without too much rainfall in order to spawn, as well as a tree or something to spawn in. The flower type doesn't matter--the plant just needs to count as a flower in order for the bees to use it. It's not that bees only spawn when there are certain flowers or trees nearby; it's that plants, just like bees, have specific climate requirements to spawn. If a tree's or flower's requirements overlap strongly with bees, then finding those plants can be an indication that bees may spawn in the area as well, though this is only really reliable for temperature as it has less significant local variations. Bees require the following conditions: yearly average temperature: 5 - 35 deg. C (temperate climates are on the lower end of this range, so it's possible to find them on default spawn parameters but preferable to move south when searching), rainfall: 0.35 - 0.95 (either common or very common in the character panel), forest: 0.25 - 1 (basically anything resembling a forest is good enough). Notable tells that a location is somewhere in the correct temperature range (but not necessarily correct rainfall and forestation levels) include: crimson maple, walnut, redwood, cypress (both) - all of these trees never generate outside of the 5-35 temperature range, catmint, forget me not, wild daisy, and golden poppy - all of these flowers also never generate outside of that temperature range. Do keep in mind, though, that a place having none of these plants does not mean that bees can't spawn there. Many plants spawn in very narrow conditions, and they may appear in places where bees actually can't spawn, even though the temperature is correct. There is no clear, unambiguous indicator that bees can spawn in an area (unless maybe if you get a perfect combination of plants in a small area, but I don't even know if it's actually possible), and all the plants are little more than a rough indication that you are in the right climate. They don't have to be present for bees to spawn, and their absence doesn't prevent bees from spawning. And lastly, if you find yourself wanting to be absolutely sure whether bees can spawn in a place or not, the generation parameters (yearly average temperature, rainfall, forest, as well as other stuff which is irrelevant in this context) can be checked for your location using the command /wgen pos climate.

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. Now, to get back to this: 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:

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

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

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