MKMoose

You've got the rough equation pretty much right. The relevant information can be found in WgenTreeSupplier.GetRandomForClimate, in TreeSupplier.cs:
float suitabilityBonus = GameMath.Clamp(0.7f - val.Value, 0f, 0.7f) * 1 / 0.7f * val.Key.SuitabilitySizeBonus; float size = val.Key.MinSize + (float)rnd.NextDouble() * (val.Key.MaxSize - val.Key.MinSize) + suitabilityBonus; and TreeGen.GrowTree:
this.size = treeGenParams.size * config.sizeMultiplier + config.sizeVar.nextFloat(1, random);  
The val.Value in the suitability size bonus is the distance calculated depending on how well the tree matches its conditions (and all that is done individually for each tree variant), so that trees with perfectly matching conditions will generally be larger:
fertDist = Math.Abs(fertility - variant.FertMid) / variant.FertRange; rainDist = Math.Abs(rain - variant.RainMid) / variant.RainRange; tempDist = Math.Abs(temp - variant.TempMid) / variant.TempRange; forestDist = Math.Abs(forest - variant.ForestMid) / variant.ForestRange; heightDist = Math.Abs((y / worldheight) - variant.HeightMid) / variant.HeightRange; double distSq = Math.Max(0, 1.2f * fertDist * fertDist - 1) + Math.Max(0, 1.2f * rainDist * rainDist - 1) + Math.Max(0, 1.2f * tempDist * tempDist - 1) + Math.Max(0, 1.2f * forestDist * forestDist - 1) + Math.Max(0, 1.2f * heightDist * heightDist - 1) ; if (rnd.NextDouble() < distSq) continue; float distance = GameMath.Clamp(1 - (fertDist + rainDist + tempDist + forestDist + heightDist) / 5f, 0, 1) * variant.Weight / 100f;  
As for how that size value gets translated to actual height in blocks, or any other details, I'd need to look further into it. You can also look at the code yourself in the public GitHub repos - tree generation should be in vsessentialsmod, I think.

Given that they disappear when you get closer, my first guess is a missing LOD model. Check whether adjusting "far LOD bias" in graphics settings affects this.
It would be useful to know what the affected blocks actually are. I'm thinking of two alternative methods:
Method 1: Reduce render distance to a very low value, possibly as low as 32. Go near the afected blocks to be able to better take a look at what they are. Method 2: Go into creative mode with /gm 2. Open the World Edit menu (by default using ` - backtick, next to the `1` key). In the top-right menu, increase "picking range" to the highest value. Look at the blocks with texture issues and find their names. Would also need to know what mods you have, since this is clearly not the vanilla game. The first mod to suspect would be whatever it is that adds the affected blocks or changes their textures if the affected blocks are vanilla (kind of looks like Conquest, but I'm not familiar with the mod to be sure). If you do find that there is a specific mod which causes this, it would be best to report it to the mod author, ideally after checking that you have the most up-to-date version of the mod appropriate for your VS version.

ConfigKit is the closest alternative that I know of, but frankly, it is not a popular option in spite of an attempt to improve upon Config Lib and not just replace it.
Integrated Mod Manager is a slightly different solution which seems to have gained much more traction, though it doesn't seem to be a drop-in replacement.

Four days is very little time for a fruit tree, even with mods that accelerate growth. The most likely answer is that you just have to equip yourself with a little bit of patience.
Do note, also, that deciduous fruit trees need to vernalize before they can bear fruit. Unless a mod breaks that behavior, you will only be able to get fruit once after each winter regardless of growth speed.
 
If there is an issue with the tree actually not growing, then mods are always first to suspect.
You could test it like this:
Start a new world. Go into creative mode with /gm 2. Get a few fruit tree cuttings of the appropriate species from the creative inventory and plant them. Advance time with commands like /time add 1 day or /time add 1 month and see how the trees behave over time. You can do so both in the vanilla game to check if any issues occur there, and with mods to check if your mods are causing issues.

There are no known bugs related to the shatter chance or its display.
In all likelihood you're just experiencing the wonders of uncontrolled randomness. Breaking a toolhead on QTQ is a 12.6% chance, so breaking 5+/9 (not counting the QQTTQ) is a delightful 0.0022% chance if my math is still right.

The game is trying to load two mods with the same assembly name, suggesting that you have both the new and the old version enabled. The first thing to do would be to clear out the cache (%AppData%\VintagestoryData\Cache if on Windows), and make sure that the older version is correctly disabled or removed from the Mods folder.

A number of ruins can have it, though the chance is low - buried slightly below surface ruins, in underground structures, in procedural dungeons, in some story locations. I think procedural dungeons are your best bet, underground ruins second.

Realistically, it is generally preferable for cellars to be relatively small and square-ish, as that reportedly allows to maintain more stable moisture and maximizes the available space relative to the surface area for thermal exchange. I do tend to agree, naturally, that having strict cutoff points and a separate long-cellar case like this can be a bit odd regardless.
If you do want a lot of space in your cellar, my recommendation currently tends to be to just create multiple cellars right next to each other. They can have a shared wall and doors in-between, and you can even keep the doors open with no negative effects. Doors do technically reduce cellar effectiveness whether open or not, but the difference tends to be minimal.
There is the Configurable Room Size mod which allows you to configure room sizes, though it reportedly has soft incompatibilities with some other mods. There is also a mod which is supposed to allow larger cellars (BiggerCellarsRebuilt), but it is bugged in a hilariously obvious way and the author seems to be completely clueless about what the code in their own mod does.

Reminds me of #8246. If it is indeed the same issue, then it should be possible to fix it by placing and breaking a block in these pockets.

The maximum dimensions for a room, and by extension a greenhouse as well, are 14x14x14 on the inside, so your greenhouse is too long.
It looks like separating it into two rooms by adding a wall in the middle would be a viable course of action.

If you go into the game files (you can copy the path into Explorer if on Windows, on other platforms you'll need to adjust it for your system):
%AppData%\Vintagestory\assets\survival\textures\block\plant\berrybush\cloudberry\berries you will be able to find that among the three subfolders, \bountiful, \healthy and \struggling, the bountiful berries are missing three textures, floweringinside*.png.
That's the bug - missing texture files. Only affects flowering bountiful cloudberries. I've taken the liberty to report it in #10069.

As far as I can tell, you can:
Rebind Sneak to something other than Shift. Uncheck the "Mouse click modifiers locked to Sneak/Sprint keys" checkbox in Settings > Controls. Keep in mind that this will also return the Sprint modifier to the Ctrl key, if you have it rebound.
Unfortunately, I'm not aware of a method to rebind the modifier keys while keeping Sneak bound to Shift.

Trees which are generated using the tree generator (i.e. created on world generation, grown from saplings, or placed with World Edit) are considered "grown", and they can spawn cicadas. As a general rule, the only logs which can't spawn cicadas are those manually placed by the player.
Your options in this case - if you want to stay in the same area and keep the trees, but remove cicadas from that specific area, besides custom modded solutions - currently include replacing the logs from natural trees with artificially placed logs one-by-one (easier to do in creative, but you can also do so in survival using a saw), or just removing the trees and building artificial ones from scratch (will generally require you to get leaf blocks from creative as they are unobtainable in survival).

Story structure distance scaling is independent from all other settings.
Note that if the world size is too small to spawn a structure, you may end up having to generate it manually - not necessarily a problem, but may be worth keeping in mind, especially if you've never experienced the story naturally yet. At 100% distance scaling you currently need 51k width and 25k length, and it will likely increase eventually, at some point in the future. Changing the scaling naturally changes the the world size required for natural generation proportionately.
 
Keep in mind that this is not exactly possible in the vanilla game currently, not in a clean way at least, because the world center is always at your spawn location and not at the equator. Maybe some mods could help with that.
Unless you're looking for a very specific result, there's no harm in bumping the world size higher than you think you need - the default size is 1M x 1M, but most people don't go beyond the "hemisphere" that they spawn on either way. The parts of the world which haven't been generated yet do not impact performance, save size or anything of the sort in any practically meaningful ways.
 
Deserts are more or less equally common in all climates, if that definition includes gravel and ice as well. Even if you only consider sandy deserts, it's not really possible to fully prevent story structures from spawning there using standard methods as far as I know.
In terms of hot climates, though, which is what you may also be talking about, this primarily depends on story structure distance scaling and polar-equator distance.
Several story locations are placed near the latitude of the world spawn, so where they are placed depends almost exclusively on your starting climate.
For other structures, at 100% distance scaling and a temperate start, you would need 25k or less polar-equator distance to risk spawning structures in hot climates (they may equally spawn in icy climates), or 50k polar-equator distance to spawn structures in cool or warm climates. Reducing the scaling would naturally allow you to reduce the polar-equator distance as well.

There is a chance you won't even need decompiling anything, as a large portion of the code is publicly visible in Anego's GitHub repositories. Worldgen specifically is in https://github.com/anegostudios/vsessentialsmod. Do note, also, that it ought to be possible to directly call existing worldgen functions from the game's DLLs without the need for duplicating any code - the most important ones for this purpose do have PDBs attached for the sake of modding, so it's relatively easy to make use of them.
From that repository's license:
If you're looking for a more concrete answer, then your best course of action might be to directly ask a developer.

Opening a support request seems like your best bet.

That leaning to the side is purely visual, though, no? Based on my experience and on the code, horizontal movement seems to be normally just directly equal to the input, with no drag or anything of the sort. It allows you to jerk around wildly, practically just as fast as you can move your fingers. Changing direction is instant, hence I say that movement lacks weight.
This is usually good for creative building or whatnot, but it isn't particularly immersive, and for combat it can easily be argued to be detrimental - moving towards or away from an enemy is not a commitment at all, because it can be freely reversed at any moment to bait then avoid an attack.
 
If that's what the problem is, then what I mentioned may indeed be the culprit. Because when you look up or down at steep angles, then moving forward and backward becomes essentially impossible due to those inputs being transformed to be very similar to dedicated vertical movement inputs.

The short answer seems to be no. Story structures use a separate system which tracks exactly which structures are generated and which are missing as well as guarantees that only one of each structures is generated in a single world under normal circumstances, and allows other game systems to access the data about those structures. Generating a village using World Edit or the /wgen structure spawn command does not register the story structure and still allows the original story structure to generate, so the locator maps still target the original locations.
The intended way to change the location of a story structure with all the surrounding systems working correctly is to use /wgen story stepos (which is the same as /setstorystrucpos).

The coordinates in log files are absolute coordinates, whereas the ones you normally see and use are relative to world center. To use the absolute coordinates in /tp or some other commands, you need to put an "=" sign in front of each coordinate that you want to interpret as an absolute coordinate, e.g.:
/tp =512123 120 =512456 As a side note, it may also be an option to just subtract half the world size from X and Z, but that then requires you to check the world size and do a tiny bit of math, so using the "=" sign is more straightforward. And also, I'm not certain whether the (0, 0) point is always actually half the size or can be slightly offset, and I'm not aware of an option to check it aside from experimentally by subtracting the result of two /tp commands.

It uses a wildcard, so any type of linen works, and you can even mix multiple types in one sailboat.

Personally, I see the hub as four 3x3x3 cubes with holes on the sides, one empty 3x3x3 cube in the middle, and the corner parts which connect the cubes, so I will use that description. The way I do it is as follows:
Place three ingots or a plate and an ingot on the anvil - it's fine to just place them all at the same time for simplicity's sake. You can rotate the workpiece three times with RMB before placing the third ingot, if you're using ingots. First build as much of the four outer 3x3x3 cubes as possible, which should probably be the easy part (just treat them as solid 3x3x3 for now): If you're using ingots, start by moving the material from layers above the third layer down into the cubes. You can use heavy hit to make it faster, but you might then have to pick up some material from the sides and move it back up. If you do so, you can leave one voxel of material in the corners which aren't part of the cubes, and it may also be useful as a staircase for other voxels. If you're using a plate, start by moving all the material from around the hub inwards and upwards. Leave one voxel of material in the corners which aren't part of the cubes, and use them as a staircase for other voxels. Then you'll need to move the material from the top layer of the central 3x3x3 cube to finish the outer cubes. You will be missing five voxels if you're using a plate or have left one voxel each in the corners below - don't worry about that at the moment. Once you have the four outer 3x3x3 cubes (optionally with a few missing voxels), you need to fill out the corners - looking from the side, it's:
down > down > right > down > down
     
the five first images show which voxel I'm targeting for that move, and the last one is the finished result. Repeat for each corner. If the first voxel is in the corner already, then you just skip the first step, and you might need to move the third in from somewhere else if you're missing something on that side. You should now have a cross with five voxels in the second layer of the central cube, and two voxels missing from each outer cube for a total of 8 missing voxels (or three voxels missing from one of them for a total of 9 missing voxels if you're using a plate). Move the voxels from each arm of that cross in the second layer of the central cube clockwise or counterclockwise to have an X, and then bump them up to the third layer of the outer cubes to fill out the voxels which you've just used for the corners. You can also move the central voxel to fill out whatever your're missing.  You should now have at most one voxel missing from each cube. You have to now destroy the middle voxel from the lower layer of the central cube to access the other ones. Then, you need to move the missing voxels from the bottom layer to the top layer: Make sure that your missing voxel is centered like this, at least for the first side, since you can only access four voxels adjacent to the one removed from the center at the moment:
Then you need to make space by temporarily moving a voxel to the fourth layer, and bring the voxel from the bottom layer up:
up > up > up > down > down
     
the five first images show which voxel I'm targeting for that move, and the last one is the finished result. You can account for this step by leaving one voxel on the fourth layer earlier, but I skipped that for simplicity's sake, in part also to show that you can do it on the fly as well. If you accidentally break some voxels, you can use the other voxels at the bottom in a similar way to make up for any losses. Remove excess voxels in the middle, and remove the excess voxels from the sides of the outer cubes (make a 2-voxel deep hole in each cube). For the voxels in the middle, you can just jump on top of the anvil to reduce the risk that you look at something wrong and break something. I strongly recommend to sit using G when removing the voxels from the sides, and rotate the workpiece with RMB. Figuring out whether you need to break another voxel in the hole can be a bit tricky here due to the black and purple wireframe being very similar, so you have to be kinda careful here. Feel free to tell me if anything is unclear.

If it's already smelted, then you don't need to smelt it again. Just bring it up to the temperature and pour.

First, calculating the survival chance of a tool only requires that you multiply the survival chance (1 - shatter chance) for each iteration. In your case, assuming you've tried quenching each of your tools 3 times, with a temper after each one (besides the last which doesn't matter), the overall survival chance is approximately 0.95 * 0.92 * 0.895 = ~0.78. For 12 tools, that gives you on average 12 * 0.78 = ~9.4 surviving tools.
Using a binomial distribution (for example with the Desmos Graphing Calculator - you can try something like this document to see different configurations yourself) for 12 tools with a 78% survival chance, we can calculate an ~10% chance that 5 or more out of 12 tools break (i.e. up to 7 favorable outcomes). Low but not terribly unusual, as far as probabilities go - it's twice the chance of breaking a tool on the first quenching.

You can use bellows to raise the temperature of the forge above the default maximum for a given fuel type. Coke has the highest maximum of all fuel types at 800 °C (700 °C is the baseline, and you can see the bonus in the tooltip). Both of them are viable to make an iron anvil which requires at least 800 °C, although bellows will generally be easier to make and more broadly useful than coke.

ProspectTogether's chunk display is misleading (and has a few other known issues). Neither the ore generation mechanism nor the vanilla prospecting mechanics are meaningfully affected by chunks from the player's perspective, and they can be generally considered to change continuously throughout the world with no chunk boundaries.
Only the node reading can tell you exactly whether there are any ores within a given range from the reading, but it just has a 6-block range by default (i.e. it tells you how many ore blocks are within a 13x13x13 cube centered around the reading).
When the prospecting pick returns you a density reading, the result is roughly proportional to the chance at that location that the world generator uses to spawn a deposit. Even an "ultra rich" reading is not a guarantee that you will find a deposit under it (for some common ores like copper or sphalerite it is fairly close to being a guarantee, but even then you shouldn't strictly treat it as such).
 
The permille (‰) number next to the descriptor is just a mathematical estimation which roughly tells you "if you dig out a huge area, it will on average have roughly this many ore blocks of this type as a permille of total rock blocks where the deposits can spawn" (e.g. 2‰ means 2 ore blocks per 1000 rock blocks). It's not even accurate, though, and has a couple bugs. The standard advice tends to just be "ignore the permille value".
The qualitative descriptor (e.g. "very poor", "poor", "decent"...) is also not fully reliable, as some ores (borax among them) can never reach readings above a certain threshold, but it is entirely sufficient. For borax specifically, even "poor" tends to be more than enough to find a few deposits.
The "minuscule" reading is not sufficient for almost anything. For most ores, it indicates a roughly ~0.2-5% of maximum possible density.
There are some tricks that you can use for certain deposits which allow you to say that "if the reading for this deposit is at least this much, it means that there is almost certainly at least one deposit within the chunk", but it is not something that most players will ever find notably useful.
 
You can also find some loose ore bits on the surface for some ores, indicating a deposit under them, which for borax can sometimes be a better way to find a deposit than prospecting.
 
Two additional notes regarding the prospecting strategy, if you will:
Sinking a shaft every 12 blocks is generally unnecessarily dense. Since deposits tend to have a couple blocks radius, you can detect most of them if you dig shafts every ~20-25 blocks, allowing you to cover a much greater area within a fraction of the time. Taking density readings closer than every ~100 blocks is usually unnecessary. The ore maps are fairly smooth, and it's rare to find hotspots that are so small as to squeeze in 100-block gaps. It is also unnecessary to search for the exact highest reading in a small area. Slightly denser can be fine in some cases, but taking a reading in every chunk is just more work for little to no benefit.  
The prospecting guide in the in-game handbook can tell you some of this information. If you're interested, there is a fairly decent prospecting guide and ore deposit table on the wiki. They are not in any way necessary to get a solid grasp of the mechanics, but they might help you out if you're running into issues.