MKMoose

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.

The most important parts of this are implemented in EntityBehaviorHarvestable. I don't have the assets on hand to check, but I'd imagine based on what I'm reading in the code that you'd need to add a deathByMultiplier in the mod's files for tamed wolves (or just modify the value if it's already defined).

It's missing a lore category attribute. I've reported it in #9748 with some additional information.
In the meantime, if you want to get the book requested by the trader, you can do so using the following command (explained in more detail here, though be wary of spoilers if you haven't done the story yet) :
/giveitem lore-book-aged-orange 1 s[] { category: "diaries" }

You can fish in smaller lakes and even artificial ones (ideally at least ~1200 blocks of volume). But if that's not an option as well, then no, you're not missing anything - fennel is just as bad as it seems.

As a general rule, the ToS or EULA for games and similar products prohibit the usage of one account by more than one person. Even if account sharing is not explicitly prohibited by the agreement, as is the case of Vintage Story's Terms of Service, the agreement can often be considered to implicitly prohibit it, if only because it's made with the person who registers the account and not any third parties. Even if it could be argued that you wouldn't be technically breaking any rules, account sharing is generally inadvisable, especially outside of immediate family or household.
 
If your friend wants to try out the game, it may serve as encouragement that the refund policy for Vintage Story is significantly less restrictive than that of Steam and most similar services.

Gotta love seeing the problem I anticipated pop up pretty much exactly.
 
The turbulence range is 1.5 times the windmill's radius. I don't remember whether the turbulence radii can't touch or just can't overlap, but I think they can touch based on the patch notes. In that case, full large windmills need 30 blocks of separation. If you want to be sure, you can test it in creative.
If you don't want to move the windmills, you can also remove some of the sails so that there's a total of 16 sets on both windmills, to match your 24-block distance.

Try this command:
/giveitem lore-book-aged-orangebrown 1 s[] { category: "archives" } The book will automatically give you the next page you're missing from any series in the "archives" category, so you don't need to (and can't though it's possible) specify an exact piece of lore.
Regarding customizing the command:

A single set of regular sails should provide 20 kN (up to 5 sets in a full windmill), whereas a single set of large sails should provide 25 kN (up to 10 sets in a full large windmill).
 
It can vary somewhat due to a few factors (mainly how high the windmill is built and how much resistance is added on by other components), but as a general rule, a single full windmill (100 kN) is roughly the minimum to operate a helve hammer at tolerable speed without upgearing, though something more like 200-300 kN per helve tends to be recommended in order to allow faster operation at lower wind speed. When you upgear it once, you increase the speed five times, so the required power is increased proportionally - at minimum about 500 kN (five full windmills) per upgeared helve, but ideally at least twice that.
Note: it used to be that upgearing the helve wasn't generally recommended due to its resistance increasing with speed. This has been removed in 1.22 as it was causing some problems, so upgearing is more viable now.

The game keeps track of the last state in chunks which are not rendered and fast-forwards to the current time when you visit the area again, so your crops should grow perfectly fine. If they don't, that would qualify as a bug to be fixed.

You have a residue-covered pot on the firepit. You need to use a clean one to make food. Granted, the game should probably be clearer about what the issue is.

Does the resulting tool have a Buffable behavior? If not, then you need to add it for the buffs to apply.

Baby goats and sheep can be caught in both traps, though crate traps have a significantly higher chance of success (70% > 30%). Baby pigs can only be caught in basket traps, interestingly enough.
 
More generally, the basket trap can catch:
chicken, hare, fox (baby), hyena (baby), raccoon (baby), wolf (baby), pudu deer (baby), goat (baby), sheep (baby), pig (baby). And the crate trap can catch:
fox (adult), pudu deer (adult), water deer (adult), all deer except pudu (baby), gazelle (baby), goat (baby; higher chance than basket trap), sheep (baby; higher chance than basket trap). That's based on the JSON assets, so it's fully accurate assuming no bugs or other odd behavior. Also, keep in mind that many animals (especially adult animals) can eat the bait from the trap but can't be caught.

The most likely option is that you happened to be in a place where there are no fish, as fish follow fish distributions similar to ores, although they're binary and not based on density - either there is fish, or there is no fish. More specifically, there's 10 groups of fish, each with a shared animal map, I think randomly assigned to different species, so you'll find some different species in different spots.
Worms should generally work as bait in any region, since juvenile fish bite worms. Then, once you fish out a juvenile of a larger species, then you can try meat for a chance at adults, or you can use small and tiny fish to specifically target larger adults. Stinkmeat and meat are generally the most universal type of bait, but they can be expensive, so it can be better to first check for fish with worms or stinkdough, and then target the larger ones (if present at all) with meat or with the small fish fished out in the process.
That said, I could be wrong, but there's also a chance that juvenile fish don't currently spawn at all, based on what I'm seeing in the assets. If you do find any juvenile fish, I would be greatly interested.
 
Here's the fishing guide text, for your convenience, since it's bugged in-game: