MKMoose

Aside from making sure that your friend actually enters the correct password (potentially has the Caps Lock off, has the correct keyboard layout selected, anything of the sorts which could make the password incorrect), you should contact support through https://www.vintagestory.at/support/ or by emailing office@anegostudios.com.

Feeling personally authorized to make a snide remark, I will say that if you want the issue fixed, it would be more effective to post it in the proper channels for reporting issues instead of the discussion forum. Ideally, that means opening an issue on the VS Mod DB GitHub and properly describing how to reproduce the problem, perhaps without swearing at your discretion. You could also post on the #vsmoddb channel in the Discord server if you don't have a GitHub account. Maybe then somebody will see it.

Are you sure that they are disabled for you? They are available just fine on his channel for me, at least on a couple videos that I checked in this playlist.

Even if we assume that the world did actually get scrambled (which seems to be a guess based on a single line of text more than concrete lore and it would seem more lore-accurate to say that the world has shifted, but anyways) this doesn't necessarily mean that all semblance to real-life climates besides temperature would be lost. Atmospheric circulation and ocean currents are largely determined by factors like the Earth's shape and rotation, so as long as we are still modelling roughly a sphere of the same size which behaves in the same way, wind and water won't really get scrambled, or if they do then they would stabilize again over some amount of time (I have no idea how long it might take, though), again producing the same conditions which promote deserts near the horse latitudes. If a region of the world were scrambled so hard as to end up in a significantly different climate zone, that would be easy to notice and it would take a long time to stabilize again (certainly more than a couple hundred years in many cases). While the world can be argued to be a mess, rough bands of similar fauna and flora are clearly maintained, so realistically, most deserts should remain mostly concentrated near the same latitudes as on Earth even if they get somewhat scattered about. If the world did somehow get scrambled globally, then that is a ripe place for some speculative worldbuilding - what would happen to a glacier in hot climates, a rainforest in colder climates, a bog or swamp which gets moved to a higher elevation or allowed to drain, a desert which lands in a very wet region, a river which loses its continuity. Not to mention the potential for more extreme scrambling like a piece of land or ocean water getting moved upwards and over land or something getting superimposed on something else or removed with a void left in its place, because we don't necessarily have any reason to assume that this scrambling should be purely horizontal and transpositional. This could be very interesting, but arguably even more difficult to implement believably than realistic geography, and it doesn't seem to me that anything of the sort is currently implemented or planned. Tyron has spoken I think around a year ago about wanting to implement large regions of distinct flora and fauna corresponding likely to continents (and it's also been on the roadmap much longer), which would further suggest that even if the world got scrambled, the effects were more local than global so as to preserve these large distinct regions.

Generally yes, though do keep in mind that atmospheric circulation and ocean currents are strongly dependent on latitude, so latitude by proxy can still be a reasonably reliable predictor for climate. While there are deserts pretty much all over the world, all of Earth's major deserts are concentrated at ~15-35° latitude (North Africa, Arabian Peninsula, Australia, and a couple others) and to a lesser extent ~35-45° latitude (often referred to as cold deserts). I will note that the terminology here can be a bit of a mess, because the classic sandy dunes or rocky flatlands are just the most extreme kinds of deserts, but you can also have a variety of drylands, shrublands, grasslands, steppes, savannas and other arid climates which qualify more or less as deserts. They can be classified and grouped in a variety of different ways. So to be fair to @DeanF's suggestion for large deserts, I don't think that it's appropriate to assume that the "desert band" should constitute of purely generic desert and nothing else - you can tell by the mentions of savannas, sky islands, river deltas and other details. Notably, though, the ~20-35° latitude band is closely associated with humid subtropical climates, and includes primarily South-East US, South-East China, and South-East South America (notice the pattern - this is influenced heavily by warm ocean currents). This climate is mostly excluive with hot deserts and would have to be included in roughly the same climate band to make a realistic system. I find that the root issue is kind of just a low level of variety in the world. While yes, having smaller patches of different biomes can be more interesting than huge climatic belts, even small patches ultimately quickly get boring if you keep seeing the same couple patches everywhere. That is why I was describing a bunch of factors which could make the world more varied and interesting, and this is also why more distinct features like rivers deltas or sky islands as mentioned earlier can be very important. If we were to imagine a world composed of e.g. 3 simple biomes (which is what VS sometimes feels like, frankly - dry biome, wet biome and freaky mountains), then I don't think that discussing the ideal scale of these biomes is particularly meaningful, because whether you arrange them into huge climate bands or small regional patches, a couple simple biomes is just not enough to make an interesting world. Ideal world generation needs to have ample variety at all scales, from the overarching climate, through various small and large terrain features and specific biomes, and all the way to the specifics of how individual plants are placed into the world. It is not difficult to find plausible ways to improve world generation at each of these levels, but they ultimately generally require that something is added to the game, not just that something is rearranged.

Not sure when exactly you edited it and when I posted, but somehow I didn't see it at all until after writing this reply, so that's on me. May be that your edited post didn't update for me until reloading the page? I will leave this in a spoiler, because it was written prior to reading your full earlier post. There's still an answer to what you've mentioned in there, just keep in mind that I could as well have been replying to a different person. I didn't think of a map viewer, frankly. That can be pretty useful. And TOPS stands for The Official Public Server, run by Anego themselves. It loops around smoothly with multiple "equators" and "poles". The VS wiki has this image, which should illustrate the point quite appropriately. Frankly, this world size is almost entirely pointless - almost nobody ever leaves the starting "hemisphere" either way, because why would anyone? The vast majority of landmarks on the current TOPS are within a roughly 50k x 50k area.

A 640k world is absolutely humongous. The default polar-equator distance is 100k, so I see no reason to change that. Aside from this, the proportion between these climatic bands seems generally reasonable. It's already a huge dice toss in terms of where the game spawns you. I had one 200x200 island spawn where I had clay, chalk, copper, cassiterite, iron, goats, sheep, pigs, chickens, four fruit tree species and six crops including flax, among other things, all on that tiny piece of land. And I had plenty of spawns in the middle of a granite wasteland with very little in terms of food or valuable resources within some thousand or more blocks in each direction - not to mention the empty island spawns. I've seen a person wander for two hours without finding any cattails. The solution is to control the spawn area better or to introduce alternative resource sources and less linear progression, not to just avoid features which could make the already-existing problem potentially worse. Not to mention, this change may actually help to avoid frustrating or difficult spawn locations, because the assumption that the player could just randomly get spawned in a huge desert is not necessarily justified. If this desert is only confined to a specific rough climate band, then the player would only spawn in the desert proper if they choose that spawn location, which could be appropriately advertised as difficult during world creation. Overall correct, with the caveat that there aren't really any strict climate bands and it's more of a continuous gradient which ends up mostly producing five rough regions: polar (a lot of glaciers), cold (basically temperate but worse), temperate (the baseline), warm (redwoods, bald cypress and sandy areas), and hot (acacias, tropical forests). Besides this, it's just a repetitive small-scale patchwork of dry, grassy and forested areas. Looking at something like the TOPS map can give you a good idea about how the world actually looks at large scale. I would note that excessively rigid climatic strips (and especially large, uniform strips) would also likely be quite boring. There is a number of additional factors like ocean currents, continentality, air circulation, water systems and mountain ranges which can greatly influence climate in much more varied and interesting ways than just latitude. Even relatively simplistic climatic approximation could be much better than . I tend to refer to the Köppen climate classification and OneEarth ecoregions for a general overview of Earth's climates. I don't really have any good references for more details regarding climate-shaping mechanisms at the moment, though. On this specifically, there is a kind of debate between Minecraft-like and VS-like climate and biome generation, and I would actually argue that Minecraft gets closer to reality in principle in certain aspects. Minecraft defines unique biomes based on climatic conditions first, which then determines the biological makeup of the region, whereas VS only allows defining broad matching conditions for each plant individually and the emergent patterns can be described as biomes, so the causality in the two approaches is directed in opposite ways. Realistically, very similar climatic conditions can still produce different biomes based on a large variety of additional factors - Minecraft largely reflects this by adjusting the entire world generation depending on biome, so that each small region always follows a cohesive formula, whereas in VS a lot of world parameters are independent, which can feel much more samey and indistinct as well as sometimes contradictory. Neither is perfect and both can work fine, naturally, and in-between solution may provide the best results. In that vein, some things which I personally would like to see in the long term. Spoiler because it's a bit of a long tangent to an already excessively long post.

Under normal circumstances, the game caches a valid session key and only asks you to log in if the key gets in some way invalidated or removed. If you have to input your credentials each time, it is most likely caused by something about the way your PC or network connection is set up, or perhaps some kind of nonstandard game installation or launch configuration. I don't really know the specifics of what could cause this, and the only minimally plausible cause I can think of at the moment would be a VPN which changes your location or IP address each time you launch the game. You'd likely need to share more details about how you've got everything configured for anyone to be able to say much more.

This statement clearly suggests that using steel casings could be considered for the game even if it's not the most preferable option. The word "often" implies that it would be historically common, but it doesn't convey the fact that the transition to steel shells only occured in the second half of the 19th century and as such is virtually irrelevant to the vanilla game from a historical perspective. You only stress that early blast furnaces wouldn't have a steel casing (and an earlier sentence mentions that they had stone/clay lining), but fail to explicitly mention any other differences from the modern blast furnace that you've otherwise described. The first use of a proper charging bell seems to come from 1850. Granted, some early experiments may have been occurring earlier, but the proper bell-and-hopper system only comes into the picture in the middle 19th century. The first mention of "cooling metal plates", whatever that is exactly supposed to mean, seems to date to around the 1880s in the context of water cooling systems, which makes it doubly impractical for the game's limitations. Carbon lining was reportedly first used in the 1930s in Germany, and saw more widespread adoption after WW2 - while you did mention that early blast furnaces had stone or clay lining, your earlier phrasing could be easily seen as implying that carbon lining was a typical for blast furnaces potentially much earlier than the 20th century. The intentional use of titanium in blast furnaces was apparently only introduced in the late 20th century. When you mention at least five modern blast furnace innovations from the 19th and 20th century without noting the timeframe when they were introduced or at least noting that they are modern, and only state two of them as missing from early furnaces, then that doesn't give me any confidence to assume that you actually know what those early blast furnaces ought to look like. A reader who doesn't necessarily have the time and inclination to extensively fact-check everything wouldn't get an accurate idea from your post either. The blast furnace in the refinery actually has a closed top, which could suggest experiments from the 18th century or so, and that is alongside the reverberatory furnace which seems to come from the late 17th century at the earliest. Keep in mind that Tyron has said (here in an interview with Mahjong Blonsky) that the current plan is for the main technological progression line to stop at the Newcomen atmospheric engine, which was designed in 1712 - still well over a century before the primary modern design innovations in blast furnaces. Even if we were to mostly ignore the historical concerns, I wouldn't personally expect any of the more modern furnace features except maybe a top hopper or hatch to make it into the game for the simple reason that they could make the furnace much more complex for little practical benefit - I would rather put most of the budget into making the fundamental process more engaging. Keep in mind, also, that 19th century blast furnaces could reach around 20 m or more in height and output counted in tons per day. Personally, I would start from looking into simple European furnaces from roughly the 12-13th century, perhaps intermediate designs and not really blast furnaces in certain cases. Main structure made of refractory bricks with a 3x3 footprint and ~5 blocks of total height. Hearth at the bottom probably carved from stone. One or more special refractory brick blocks for the main iron tap, for slag, and for tuyeres. Additional infrastructure includes primarily: bellows - possibly alternating paired piston bellows, though a lot of options are plausible, a casting bed for pig iron - it could potentially be made of a variety of different materials, but the most notable option seems to be sand, likely a slag pit - just a hole in the ground to prevent it from spreading out, no special implementation required, likely a separate finery hearth for refining pig iron. Regarding details of operating the furnace: A single cast could probably be made every ~8 in-game hours or so, and produce up to ~16 ingots worth of iron. At five blocks of height, there would be space for three blocks of charge in the furnace. The furnace could be allowed to operate in a process consisting of startup, an arbitrary number of batches, and shutdown, to better accomodate multiplayer servers by allowing convenient single casts. Startup and shutdown would just mean adding fuel with no iron - this additional cost would produce a preference for continuous operation. Alternatively, a perhaps even simpler implementation could involve reduced amount of fuel required to add to the charge while the furnace is partially full, to represent the partial reduction in higher parts of the furnace and incentivize more regular maintenance. Damaging the bricks may only occur when the furnace is operated improperly (e.g. no fuel is added for proper shutdown). If the furnace gets damaged during runtime then it would presumably need to be designed in a way that doesn't cause the furnace to just die arbitrarily at random points. If at any point the furnace cools while there is still iron in it (primarily when the air blast stops, which is why water power would be very valuable), the remaining charge could solidify into a salamander, which could be mined out - it could be useless, or it could potentially be chiseled down to recover materials. Slag produced as a byproduct could potentially be used for some building applications and as a P fertilizer. Regarding iron processing: The default output of the blast furnace is pig iron. Casting cooking pots and other cast iron items would ideally need a more controlled process, which would also save the implementation effort related to making all the molds integrate with the casting bed. Direct casting is possible, but would be more implementation-heavy and inconvenient in practice because it doesn't allow mass production of raw material and gradual processing as it's needed. I would strongly consider requiring to remelt pig iron in a crucible to make cast iron, and using individual molds in this way at much less implementation cost - it's not really historically accurate, but it's easy to implement and convenient in gameplay. Some furnaces, including a reverberatory furnace given that it is present in-game in the refinery, could be also considered for this purpose, though that's a largely separate proposition and it shouldn't be the only way to produce cast iron products. Processing pig iron into wrought iron would ideally require a separate finery hearth to cook out the excess carbon and let it form a bloom which would then be hammered. The hearth could probably just be a single new block roughly similar to a forge. Simplifying it and allowing to directly work pig iron wouldn't be entirely unreasonable, especially to make it more competitive with bloomery iron, but I would be very interested to see the full process reflected accurately regardless.

Right off the bat, changing existing textures is most likely a no, because it disrupts existing builds and it's generally not advisable to modify things this long after they've been released unless there is very good reason to do so. Adding new blocks or in-game means of changing a block's color are much more plausible. While the color selection certainly isn't perfect, almost every option can be someone's favorite or a good fit for a specific palette. You can find a large variety of preferences in the community, for example in this thread: Note, also, that player preference is influenced by more than just the aesthetics of each type in isolation, which can introduce a lot of additional bias, since some people may just use whatever is most convenient for any of a number of reasons: Plenty of colors can be chosen depending on how well they match with other colors, e.g. purpleheart is not a bad color in isolation but it can be tricky to make it work with the game's color palette. Oak is the color of blocks which aren't wood-typed (e.g. shelves) which causes people to gravitate towards it more. Specifically for trees, a number of reasons unrelated to aesthetics can also be a factor: Several tree species are very common and accessible, making them a common default choice. Pine is extremely efficient (e.g. for charcoal production or large-scale building) because it can pretty much be chopped down without touching leaves and still drop enough seeds. Some trees are woefully inefficient due to a small number of seeds which often makes it tedious to plant at least as much as you harvest to maintain a reasonable reward for the investment (and aged wood types are also extremely tedious to obtain in any decent quantity). Oak is very efficient for sticks, since it has a lot of tightly-clustered leaves. Acacia and oak can be used for tanning, which makes them extra convenient as general-use trees. Pine and acacia also provide resin. For stone, some similar factors which may affect popularity can be found, especially the easy availability of granite. While easy dyeing of all blocks similar to e.g. Terraria could be a bit overkill and somewhat unfitting for the game's style, I do generally agree with the suggestion - it could be implemented in some less freeform ways, and it could be used to supply both vibrant and toned down colors. For wood, the devs have spoken about some kind of finishing (reportedly that's one of the reasons why linseed oil was added despite currently having no use) which could provide a variety of new colors. More species can be just fine as well, and we've had willow trees teased a few months ago. For stone, changing color would be less straightforward, although there is also a large variety of new rock types and colors which could be added for greater variety - and as long as they don't introduce an excess of inventory clutter, new rock types have pretty much no drawbacks - but being able to "dye" them is less plausible. For general color variety, I've always thought that some kind of plaster or stucco (applied on blocks as an overlay similar to wallpapers) would do wonders for builders. It can even reasonably be made be completely historically accurate to Europe in the Middle Ages and Renaissance. This would strongly benefit from overlays and pigments being generally improved upon and expanded.

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.

For proper pixel art: Aseprite ($20, though open source so you can compile it for free) - the gold standard for pixel art. LibreSprite - closest completely free alternative to Aseprite. Piskel - web-based as well as desktop, not particularly great but very accessible if you just need to doodle something quickly. For general use, not dedicated to pixel art but still sufficiently suited to it for many purposes: GIMP - image manipulation program - my personal favorite for most purposes, though it can be quite unintuitive. Krita - drawing app. All of the above besides Aseprite are free and open source. A quick web search will allow you to find a whole lot of other options if you're looking for something more specific.

Abraham Darby did indeed introduce a new method for producing cast iron with coke-fired furnaces, which allowed to produce thinner and cheaper pots, although cast iron in general was introduced much earlier than that, especially in China (see e.g. cast iron history, or more generally ferrous metallurgy). His cast iron was likely less brittle than that made with earlier methods, but cast iron as a whole is regardless generally brittle relative to wrought (forged) iron and to steel. This is a fairly modern use of titanium. For refractory bricks specifically as it's used in the game, ilmenite is as far as I can tell not useful at all due to its relatively low melting point of ~1400 °C - proper refractory materials tend to favor melting points of at minimum ~1600 °C, and some go above 2000 °C. I have no idea why ilmenite is used as a refractory in the game, but it should have no effect on whether high-tier refractory bricks should be required for the blast furnace because it's not a direct use of titanium. You're speaking about fairly modern furnaces in general. Specifically metal reinforcements and cooling systems seem to only appear in the late 19th century as far as I can find, so it is entirely irrelevant for the game's purposes. For simplicity's sake we can pretty much even skip the lining and just use refractory bricks for the whole main furnace structure and stone for the hearth, to stay close to the game's existing mechanics and style. The tall furnace on the right is explicitly named a blast furnace in game files. The one next to it is almost certainly a reverberatory furnace which may be used for a number of metals including copper and copper alloys, tin, lead and pig iron starting from the 17th century and in this case has solidified iron in the hearth. From the late 18th century it has also been used for processing pig iron into wrought iron in a process referred to as puddling. I don't quite see where those nails would be useful. Frankly, I feel like the best way to restrict the blast furnace in progression is just through setup costs and infrastructure. It would be a bit strange, even for a significantly simplified process, not to require: the main blast furnace structure, probably made from any refractory bricks (realistically you don't even need fire clay, but I guess it's fine for game purposes) which requires a pulverizer, large bellows, which means a lot of leather, almost certainly mechanically powered and ideally powered with a water wheel to ensure continuous air blast, specialized casting molds for some items including cookware (potentially with a special ladle or something of the sort to pour the iron in a more controlled way), and a rough casting bed for pig iron, ideally a separate finery hearth with its own bellows for remelting pig iron to make it into wrought iron. A lot of simplifications are naturally possible, but in general I feel like just the complexity and setup cost of the whole process seem like they are enough of a progression gate that we really don't need any additional restrictions on top, be it steel or high-tier refractory bricks. The greatest easily justifiable hard restriction is iron, I think, since it would probably be preferable not to allow the player to skip bloomeries entirely, but there's no real way to use it for the furnace itself that I can find - maybe for the tuyeres and bellows, which would still be a pretty arbitrary restriction but probably much more defensible. Frankly, as I'm looking into it more, I'm getting the impression that it is ultimately a pretty obscure topic. Making the mechanics fully realistic and historically accurate would naturally be impractical (if you can even find properly reliable sources to base some of the smaller details on), but trying to simplify it for better approachability while retaining historical accuracy can also be a fool's errand. Historically, a blast furnace can only be used to smelt iron, because that's what it is specifically designed to do. A proper blast furnace needs to run continuously with no breaks - simplifying this is entirely possible and likely preferable, but then that would be more like an 11-12th century intermediate furnace. A blast furnace naturally needs a lot of setup work as mentioned earlier. It can be tricky to make the blast furnace actually worthwhile for mass production of iron unless greatly simplified, since the process has a significant extra step relative to the bloomery process: smelt iron and cast into pig iron, remelt pig iron in the finery hearth to burn out the excess carbon and let it form a bloom, hammer out the impurities out of the bloom to make wrought iron. Making the blast furnace require additional maintenance would make it further difficult to let it naturally outcompete the bloomery. I've had the thought to make it only take damage when operated improperly, to make the mechanic more interesting and allow the player to reduce costs with some skill or care.

The quantity is rounded randomly depending on the fraction. The pseudocode for it would look like yield = floor(avgQuantity) + 1 if random() < (avgQuantity % 1) else 0. The small berries which have 2.75 average yield have a 25% chance to produce 2 berries and a 75% chance to produce 3 berries. Reducing it by 15% gives ~2.34 average yield, which means a ~66% chance to produce 2 berries and a ~34% chance to produce 3 berries. Funny thing is, since you can get a new cutting from young bushes right as they grow from a cutting, you can actually still propagate them really quite quickly. Even starting from a single bush, you can get one new cutting every 3 months on average for the first year, then two every 3 months in the second year, then four and so on. That's a bug, #9943 on GitHub. If you're able to consistently make them lose traits, then having concrete reproduction steps would be useful.

A prospecting pick is the only way to find most ores efficiently. You can use other methods, and there are select ores for which other methods can be better, but for deep ores like pentlandite they are a waste of your time. Take a "density search" (first mode) reading every ~100 blocks or more. Stop once you find a "decent" or better reading for pentlandite. You can take a couple readings to the sides to check whether there's a better reading nearby, but there's generally no need to take readings more often than every ~100 blocks. A worse reading can be fine, but it will require more digging and in rare cases may have no pentlandite at all. Dig a vertical shaft downwards, all the way to the mantle. Ladders, especially rope ladders, are useful here. While digging the shaft, take a "node search" (second mode) reading every ~5-13 blocks. Pentlandite only occurs deep, but you can take node readings all the way through if other ores also occurs in the area. If you don't find pentlandite in this shaft, move ~25 blocks and dig another shaft. Repeat until you find the ore. Also, the wiki is fairly reliable for prospecting. Ore deposit generation details: https://wiki.vintagestory.at/Ore_Deposits. Prospecting guide: https://wiki.vintagestory.at/Guide:Prospecting.

Most likely haven't messed up anything. The game simulates solar and lunar movement quite accurately and makes an attempt to illuminate the world appropriately depending on the position of the sun and the moon, but sometimes it doesn't go quite as well as it should. You might see completely pitch-black nights which seem like they completely lack starlight, and you might see red sunset-like light in temperate climates at midnight. Mod interference is not implausible, but those issues also occur in the vanilla game.

To add on to what @Professor Dragon has suggested. You can use the command /wgen regen <chunk_range> (e.g. /wgen regen 2) to regenerate chunks in the given chunk radius. Using /wgen regen 0 will only regenerate the chunk you're currently in. This will remove any of the changes you've made to these chunks, and has the potential to be very destructive - make a backup before messing with it. You can also try using /db prune <threshold> <keep/drop> as a faster and more robust but less precise alternative - it will remove all chunks which have had a number of changes made by players lower than the given threshold. It is also risky, and it might not work quite as well on older worlds, so again, make a backup. After running it, double-check that it didn't remove things you wanted to keep. The threshold is the minimum number of player-made changes for a chunk to be preserved. Use e.g. /db prune 1 keep for very careful regeneration, where only chunks with no player-made changes are removed. Increase the threshold to maybe ~3-5 to also discard almost-unchanged chunks. Use e.g. /db prune 10 keep for more aggressive deletion, which might remove a couple things you've placed or left in chunks. Increasing the threshold above ~10 is generally not recommended unless you're absolutely sure you really want to clean up the world more aggressively. The keep/drop option refers to whether land claims should be preserved, which preserves any structures (e.g. traders) as well as player-made claims. You could use it to deliberately protect your structures after making a claim on them, but it should be usually unnecessary. Change keep to drop in any of the commands listed above to also regenerate structures. Initially, it will tell you how many chunks would be removed and kept. Once you decide on the specific command, add confirm to it to actually run it (i.e. /db prune <threshold> <keep/drop> confirm, e.g. /db prune 3 keep confirm). If you're unsure, you can run the prune with a lower threshold first and increase progressively if it doesn't have the expected effect. After running /db prune, you can also take the chance to run /db vacuum to reduce the save file size. Finish by reloading the world. Recreating the forest more or less manunally is also a possiblility, but for an area this large it would take a prohibitively long time - still, you can consider it in chunks which you can't regenerate without losing something. If you need to see chunk boundaries near your structures, use .debug wireframe chunk. And also, in case you have fire from lightning enabled, you can consider turning it off with /worldconfig lightningFires 0 to avoid this kind of situation in the future.

What was the reading, though? For halite, you're generally looking for "poor" or better. How deep the sedimentary layer is also matters. You're generally not gonna find much halite if it only reaches ~20 blocks deep. It just didn't generate, as it's a matter of chance. Density readings only correspond to the internal probability that the game uses to generate deposits. While for several common deposits a high reading is essentially a guarantee, for less common deposits including halite it is ultimately random. As for how likely it is for it to not generate at all, it depends on what kind of readings you actually had. Halite also happens to be affected by a small bug which makes is less likely to appear at low readings, which is related to why the sedimentary layer thickness matters and you generally want either a ~40-block thick layer, or potentially a ~20-block layer if it's under basalt. Just FYI, taking density readings every chunk is almost always excessive. You don't need to take readings any more often than every ~100 blocks in most circumstances, because it doesn't provide you with any significant new information. It can be even better to go every ~200-300 and only narrow down to ~100 when you find a reading you're looking for.

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.

Fences completely prevent animals from moving over them under normal circumstances. If they don't in your case, it most often means one of two things: The animals may have some way to get on top of the fence - any kind of cliff, hill, shack, or other stuff adjacent and higher than the fence which they could walk over. As a general rule: if you can get inside over the fence without jumping directly over it, then animals can as well. The animals may spawn directly inside - they can't spawn directly on farmland as far as I remember since it's not considered a full block, but they absolutely can spawn on other blocks nearby if there are any empty spots. You can only prevent this by making sure that there's no free space for animals to spawn on, as far as I can tell, often done by only enclosing farmland and water blocks with nothing else. Feel free to upload a screenshot of the fence if you're not sure what the issue is, as it would be easier to check it visually.

Normally, mods can be configured to be required on server or on client. Depending on that configuration, both the server and the client may have its own mods which are not synchronized between them. Most mods which add actual content, though, should get automatically disabled or enabled to match the server. TOPS specifically does not currently permit any mods, not even client-side mods, as you can find on https://topsinfo.vintagestory.at/. VS has a built-in mod blacklist in server configuration, though by itself it is pretty trivial to bypass. But there are at least four or five mods which offer more advanced functionality including a whitelist, notably FairPlayGuardian which is made by Dilli (dev and TOPS admin).

Either is completely plausible, and it could actually be interesting if it was mixed. On the technical side, stopping the attack after the first hit would benefit from additional animations which VS might or might not currently have the proper tech for, but ultimately there isn't much implementation difference between the two. Currently in 1.22.7, locational damage seems to be only implemented in terms of random chance to use one of the three armor slots to get armor stats from. If there is something else, I'd love to see it. While there is some chance that they've been working on it - Tyron has mentioned some kind of "new combat hit detection tech" in the development update - no further details have been explicitly mentioned as far as I'm aware.

I'm failing to find the technical explanation for it now, but if I recall correctly the issue was that newly-generated chunks were saved immediately with the entity and older chunks were only updated on autosave, which causes the same entity to be saved multiple times in the same world if the game crashes, which in turn causes conflicts when the game tries to load the same entity twice. Take it with a grain of salt, because I might be misremembering that from one of Zaldaryon's comments. Other entities are fine because they've been saved to disk earlier so the crash cannot affect them. The issue is tracked by GitHub Issue #7298 and should be fixed for 1.23.

And how is this meaninfgully worse than the current system? Log on a little bit too late, and oh no, the trees are all dormant and the crops have all died. There is a million ways to make seasonal harvests work just fine on multiplayer servers. Increase the length of the harvest windows. Make plants decay slowly to make slightly missing a harvest window less punishing. Introduce many different plants with separate harvest windows, so that the combined harvest season is much longer than individual windows. Increase the yield from individual harvests and emphasize the effort that goes into processing which can be done at any time of year (this I think is the most noteworthy idea, because it allows to get a large supply at different times of year and instead places the challenge on processing). Ensure that at least some food sources which permit inefficient but accessible subsistence are available at any time of year. Introduce highly efficient food sources available in winter, allowing the player to survive the cold months with either preparation or adaptation. Incompatibility with multiplayer playstyles is a problem conditional on seasonal growth being poorly implemented and is regardless entirely fixable. Not to mention how cool and immersive seasonal growth could be if done well. (Sorry if I got too annoyed, but I genuinely think that seasonal growth would be one of the best features which could be added to the game, and I prefer to find ways to make it work over pointing out why it might not work.)

It doesn't seem to me that threats in the ocean are really conducive to interesting gameplay. It would indeed be preferable to make swimming willy-nilly with no boat in the middle of an ocean more risky, but I see little current reason to extend the same to rafts and especially to sailboats. I especially wouldn't like to see threats which could destroy the sailboat - at most make it slower until repaired. There is one other thing that oceans don't have aside from threats: value. Finding an ocean is largely worthless in VS for most purposes - maybe a bit less so now that fishing is in the game, but still. Oceans offer almost no unique resources of any kind, they don't really make travel any easier, arguably don't even look particularly good in terms of visuals, and just don't serve much purpose in the game. A number of features which could readily be added to oceans are for example: seashells (in less pathetic quantities, possibly via panning improvements), sea salt, marine mammals (especially for hunting in cold climates, could include some threats), crustaceans and other miscellaneous animals (for seafood and pearls especially, could include some threats), whales (could be hunted, could serve as a threat in some capacity). But you'll notice that none of them except whales actually require large ocean bodies, which would generally just end up boring even if a lot of ocean content is added. One of the best things that I think could happen to oceans in VS would be to make them into more sprawling and interconnected water networks instead of simple blobs of water - rivers ought to help with this, but they're unlikely to be sufficient on their own. This ideally combined with increased raft and sailboat speed could make oceans into convenient travel networks, rather than the obstacles that they are now. I have to say, though, having some ocean-specific enemies related to the Rust or Rot could be very interesting as a challenge of sorts. Maybe even a boss which would be best tackled in a sailboat. Would prefer them to be localized to unstable areas, though, not spawned anywhere throughout oceans.