Streetwind

@Aoi Kasai Temporal stability depends on where you are.
Some areas have naturally high stability. If you spend time there, your stability will increase.
Some areas have naturally low stability. If you spend time there, your stability will decrease.
Building a base in an unstable area is a very common beginner mistake, as new players won't know how it works.
You will likely have to pack up everything you own and move somewhere else, a place where you see the gear in the lower middle of the screen spin clockwise.

Could be that you're running out of VRAM.
Go to the settings menu, and read the tooltips to find settings that mention that they're heavy on VRAM (I think view distance is one?). Try reducing those settings significantly, and see if it makes a difference.
Could also be that your video card is damaged. However, that would mean you should see broken graphics in other games too. If this only happens to you in Vintage Story, then your GPU is most likely fine, and you're just asking too much of it.
Finally, it could be a driver issue. But I would expect that both Nvidia and AMD have very stable drivers these days. If however you're running on an Intel GPU (either CPU-integrated or one of the new Arc series cards), then yeah, driver hickups are going to be a thing.

...Wait, what? o_O What does it matter where the executable is located? You're not supposed to change that, nor is it necessary. All you're supposed to do is tell the executable at startup where it should look for its data folder.
The data folder can be located anywhere you like, completely independent of the game's install directory. You could have it inside the install directory (to keep everything in one place), but you don't have to. It can even be located on network drives or external drives, so long as you ensure these drives are mounted when you try to launch the client.
I know this because I've been playing Vintage Story like that since 1.12, and it has always worked reliably.
There is probably something you misunderstood about how to set this up. Let me try to describe it again:
Create the directory where you want your data folder to be located in the future, and copy its full, absolute path. Paste the path into a text file or something similar for later reference. You don't need to recreate the folder structure inside the data folder, the game will do that on its own. Go to your VS install directory and create a shortcut to vintagestory.exe. The easiest way to do this in Windows is the select the file, so that it is marked blue. Then, using the right mouse button, click and drag the file to an empty space inside the folder (or some other folder, or even the desktop, wherever you want it). Upon releasing the mouse button, a context menu pops up. Select "create shortcut". Rightclick the shortcut, and select "Properties". A small window pops up, with a few editable fields. The topmost one is called "Target". Inside this field, do not delete anything that's already there. Instead, go to the very end, press spacebar once, and then write --dataPath your:\path\here. That's a double dash at the front. You input the absolute path to your desired future data folder that you set aside during the first step. Finally, pay attention to quotation marks inside that target field. If the absolute path to your game's install directory contained spaces, then the contents of the target field in the shortcut will likely have been encased in quotation marks, so that the operating system understands it. By appending something to the very end of that, you'll have broken it, because you'll now have a quotation mark somewhere in the middle, where it doesn't belong. Find that quotation mark, and move it to the very end again, after everything you have typed. If there were no quotation marks, then add them just to be sure. One at the very start before anything else, and one at the very end. This covers the edge case where your path to your desired future data folder may contain spaces or other weirdness. Press OK to close the properties window. Doubleclick the shortcut in order to launch the game. Pay attention to your desired future data folder; the game should auto-populate it with certain required files and subfolders. If this did not work, I'll need you to describe to me step by step what you did, or better yet, show me your shortcut's properties with screenshots. If this worked correctly, you can now move your savegames and clientsettings.json over from the default data folder to the new one.

1.17 increased crop growth times, including berry bushes.
In return, yields were increased. Overall the amount of produce harvested from a crop type across an ingame year should be close to what it was in older versions, but split into larger but less frequent harvests.

Crop growth times were changed in 1.17. I guess nobody got around to updating everything on the wiki yet.
Remember, the wiki is maintained by community volunteers, not the dev team.

Unfortunately, the terrain generator does not support large bodies of water at the current time.
It's on the development roadmap for the future, but there are currently no indications when it might happen. The theme for the next update right now is "storytelling, lore, and ruins".

It's a little bit of column A, a little bit of column B.
By default, the server is set to pause (basically, slowing the global sim speed to more or less standstill) while nobody is online. The moment one player logs in, it resumes. The server can be configured to keep running normally when no one is online, but the default behavior is pausing.
This means that whether or not long processes continue to happen while you're offline will depend on whether anyone at all is online. If you're the last person to log off, causing the server to pause, and then return before anyone else, you'll find things pretty much where you left them. On the other hand, if the server is more or less always populated, you can log off with a freshly seeded field and return to fully grown crops later.

This is not a thing, no. Drifters do not set anything on fire. Not even if the drifter itself is on fire (you can hit them repeatedly with a torch for that).
I'm quite sure that the base was on fire because a pit kiln was too close to something flammable.

The first thing you can try is pressing F11 once the client has launched and the window is in focus. That should switch display modes.
If that doesn't work:
There should be a file called clientsettings.json somewhere (I don't know where it is located on OSX, sorry). There's a "screenWidth" and a "screenHeight" definition in it.

If you're not adverse to installing a mod, Accessibility Tweaks provides a number of additional graphical options that the base game doesn't have.

Make a shortcut of vintagestory.exe Add the "--dataPath InsertFolderPathHere" switch to the shortcut target, according to where you want your new Data directory to go Start the game once via the shortcut to create and populate the new Data directory Migrate your existing savegames to the new directory Only start the game via the shortcut from here on out (If you want to install the game itself somewhere else, you can choose the location when running the installer.)

If you're in a 1x1x1 hole, then jumping will get you out. Blocks do not have any collision from the inside.
Knockback pushing you into blocks is a known, if very rare, bug in 1.16.x versions of the game. But even when it happens, it will only ever push you into the first block. There's no such thing as "solid blocks on all six sides". You just haven't found the way out yet, likely because you got disoriented by what happened.
Finally, in singleplayer, you can always do /gamemode creative to allow you to break any block with a single click of your bare hand, and then /gamemode survival to return to what you were doing before. Note that this will not break the block you are already inside of. You still need to jump/walk/fly out of that one.

Which version of the game are you running on? That's always one of the most important pieces of info you can include.
Additionally, state if there were mods present, and if so, which ones. Does the error still appear if you remove them before loading into the world? Has there been a specific subset of mods that has always been present whenever you got this error?
Also, did you try loading the world in Repair Mode? (It's a box you can check inside the saved world's details.)

I think the recipe is defined as "any chisel + any anvil", and therefore loops through all those options in the handbook. However, upon actually trying to do it, the game also checks if the chisel has enough durability. Higher tier anvil consume more durability for breaking down, and so a copper chisel may not have enough, even when full. This check must happen at the moment of crafting, since it must catch any possible case, including partially damaged chisels. This cannot be shown in the handbook recipe preview.
Try using a higher tier chisel, and observe exactly how much durability the process consumes. Then compare that value to the maximum durability of the copper chisel.

/worldConfig propickNodeSearchRadius [radius]
Pick a number for the radius. The larger the number, the further away you will be able to pick up ore, but the more difficult it becomes to triangulate. Numbers around 6-8 are recommended. Do not include the square brackets.
After entering, quit to main menu and then reload the world.

You need to use the big cogwheel to split power, yes. Unfortunately that also acts as a big accelerator gear, so you're going to lose a lot of torque. The counter to that is using a second big cogwheel as a reduction gear further up.
Connect your windmill rotor with an angle gear to the rim (not the shaft) of a large gear. That is your reduction gear. Now bring the shaft down into your workshop, and connect your consumers with angle gears to the rim (not the shaft) of a second large gear. That is your accelerator. The two will cancel each other out, and the system will act as if you had zero large gears, but you are still splitting power.
 
Not without installing a mod, no. That said, your forge gives off plenty of heat. You'll have to live with the +25% winter food usage penalty, but you're not going to freeze.

Welcome to the forums
Placement of blocks can be context-sensitive. For example, it can depend on the direction you are currently standing/looking, or on which side of another block you try to attach something. With logs, for example, try placing them on the side of another block, not the top, if you want a horizontal placement.
As for lower-half slabs, no, you cannot place objects directly on them without a gap. The game works in a block grid, and every object occupies a block space. You cannot have an object sit halfway between two block spaces, and especially not have it invade the space that another object is already occupying. Even if the lower-half slab looks like it is only the size of half a block, it is still an object, and it still occupies its block space completely. You can verify this by trying to place a second slab on top of the first one. They should both fit in the same space, but they do not. Each is an object, and each wants its own exclusive block space.
Now, there are potential solutions to this limitation that could be implemented. Minecraft for instance allows you to place two slabs into the same block space by way of secretly deleting the first slab and replacing it by a full block that looks like it is made out of two slabs. That way it can maintain the "one block space, one object" rule. But right now, Vintage Story does not implement such a thing. Maybe it might at some point in the future? Who knows. For now, the game is still a long way from finished, and with only one person working on code, new features take priority.

When you use the public listing, you will be trying to connect to your public internet IP. This IP is only reachable from the internet. You, however, are not coming from the internet. You're on the same local machine as the server is. For this reason, using the public listing may fail.
Instead, try the "Add New Server" button to create a custom entry. For the IP address, enter 127.0.0.1 followed by a colon followed by your server's port. This is is your "loopback address" - that is, a unique IP address that points to yourself. Every computer has it. The word "localhost" can often be used as a stand-in.

If you want to use different mods (or no mods at all) in different worlds, then you need to toggle them on/off in the mod manager in the main menu before joining those worlds.

You can potentially buy them from other traders and sell them for profit? To be fair, I've not checked if that works with cracked vessels, but there are several other trade goods with which that works.
Additionally, the Malefactor has a chance for a cracked vessel to drop itself instead of its contents. That way you can make a few extra gears on vessels which no longer contain anything interesting to you.

Inside your VS install directory, go to ...\assets\survival\entities Open item.json in a text editor, and chenge the despawn time to your liking. It must be given in seconds. Save and close. Run modmaker.exe inside the VS install directory. Wait and follow the instructions until complete. Open item.json again, and change the value back to the default 600. Save and close. You now have a mod that changes your item despawn time to the value you want. It is likely already where it needs to be, and you'll be able to activate it from the mod manager in the game's main menu.
If you suffer from performance issues when running that mod - well, redram already explained why But in singleplayer it should be okay, so long as you don't choose an utterly ridiculous value.
If you just want to keep your stuff from despawning when you die, by the way, it would be way easier and less problem-prone to just set /worldconfig deathPunishment keep instead of fiddling with despawn times.

Sounds like the chunk reset. That should definitely not happen.

Not really a bug, no.
I can't really tell you how precisely cellars are coded, as I cannot read the code. But I can tell you how it works in practice in the game. Cellars are not truly 'rooms' - you don't need to build a completely enclosed space of certain specifications. No, they work through proximity of stone-type or soil-type blocks. Each storage vessel, chest, shelf, and so on will check around them in a radius of as much as five blocks away, to see if it can find valid cellar blocks. The greater the ratio of valid blocks to invalid blocks, the slower food spoils. The slowest possible food spoilage rate is achieved if the storage vessel detects only valid blocks - that is, there is a wall, floor, and ceiling made up of valid blocks in any and all directions, and none of them is more than five blocks away. It can be much closer - for example, a vessel buried underground by itself essentially occupies a perfect cellar of size 1x1x1. But if it's further away than five blocks in one direction, then it'll detect only air that way and it will no longer be perfect. This is why people tell you that cellars should be 5x5x5 rooms. Not because there's actually a room setup requirement, but because that ensures that there's valid blocks nearby in all directions.
By removing the valid blocks in the floor and replacing them with invalid blocks (wooden slabs), you reduced the effectiveness of the cellar significantly.
If you feel like you storage vessels aren't updating to the correct value, try picking them up and putting them back down.
 

Pretty sure there is no random spawning mechanic either. I've played for multiple ingame years in worlds with zero wild crop respawns.
You just sometimes come across a plant you missed the first five times going through that area. It happens. Just like it does with surface copper deposits - where you return from your three thousand block copper scouting mission only to discover the deposit right next to your base that you completely missed all this time.

Not a bug, working as intended. Every item maintains its heat for roughly one minute after the last time its temperature increased, provided that nothing else updates the item's temperature in the meantime. Not just in the firepit, but with all heat sources. This is supposedly so that you can do something with the item you just heated before it cools down again, for example smithing a tool on the anvil.
Updating the item's temperature through any means waives this grace period immediately. For example, you can heat a stack of 30 unfired bricks to 600°C, and then pull it out of the fire. It will maintain those 600°C for about one minute. But as soon as you merge one other brick into that stack, the stack's temperature will be recalculated to be the average temperatue of all 31 bricks in the stack. This modifies the temperature, and so the grace period is waved, and the whole stack starts cooling down immediately.
You can actually use this behavior to exploit the heck out of the firepit. For this reason, the roadmap already has a rework of the firepit earmarked. And who knows, maybe the temperature system as a whole will get overhauled at the same time? Or not. We don't know. Nor do we know when it will happen.
Until then, however, this is not a bug.