MKMoose

I'd say that, ideally, even terra preta should only be most optimal for a quite limited range of crops. It should probably be the most universal type of soil, good enough for pretty much all crops, but I think it would be a shame to introduce a bunch of new soil types only for terra preta to remove most of the reason to search for less common ones, making farming generally devolve to the same common denominator once the player invests into compost. Realistically, terra preta is apparently most suitable for cassava and fruit trees, but I'd have to look into it further to be sure and to find more details. A pretty cool addition for farming could lie in Mollisols (the most agriculturally productive soils in the world), which would require the player to travel to steppes or prairies to obtain them but which would likely be the best soil type for most grains and legumes. There's also a bunch of options like Fluvisols (near rivers) or Andosols (volcanic ash soils), which seem like they could be most suitable for vegetables, and so many other soil types. Of course, all that slowly and carefully, maybe starting simply with sandy and clay-rich soils. I think it would fit Vintage Story quite well to require some travelling to obtain the best, specialized soils for various crops, but there's a lot of added depth that could come from relatively simple changes as well, especially if we were to also consider pH, moisture requirements and ore deposit indicators. I think it would make sense to just have large areas of clay-rich soils which drop some clay outright as well as are more likely to house proper clay deposits. Realistically, clay can absolutely be obtained from random clay-rich soils, and while it may be lower quality if it has a lot of silt, sand and other contents, it's not too difficult to find something very much usable. This may mean a practically endless supply of clay the moment you find a decent river or some other clay-rich area, but that's also kind of the goal - it's not like we have to restrict the availability of clay as some especially valuable resource. It may also end up highly beneficial for new players to have a clearer goal like "find a river, clay will be there" instead of "find a small red patch on the side of a hill". Same goes for peat. I think it would be perfectly fine to add larger, more biologically accurate peatlands and other wetlands, instead of just spawning these random deposits which realistically just make no sense. If nothing else, I think peat should appear more commonly but only near the sea level, though that's a bit of a separate matter.

Slime molds are so weird. Could certainly be pretty cool to add some extra detail, though their typically tiny size makes it diffuclt to see them as a priority. They would likely work at much smaller scale, spicing up leaf litter, tree trunks or other decaying plant matter with colorful dots. Mosses and lichens can sometimes cover dozens if not hundreds of square meters or more in a neat carpet, which is why they are especially useful to add variety to regions with otherwise limited vegetation - in cold or shaded areas they can cover the ground in a similar way to how grasses often do in other regions. And there's more examples to better show what I mean. I've edited the original post slightly to mention some of this from a more gameplay-focused perspective. While I don't know nearly enough about soil pH and mineral contents and whatnot to really speak about it, I do know that it has potential for gameplay benefits with indicator plants and stuff like that, which is already enough to get me on board. I love this idea, and there's just one issue that would have to be solved. Even in the current state of the game, running around and digging up a few spots (e.g. when prospecting) can quite easily net you three or four block types including sand and gravel. I've seen people already sometimes complain that there's so many different different kinds of plants, rocks, and other stuff which largely end up as annoying clutter. Adding a couple new soil types, or even some dozen or two if you include all the combinations with different fertility levels, certainly wouldn't help it. Though it might be going pretty out-there, I would personally think about separating soil and certain other blocks into a two-component system of sorts (could also be more, but I'm trying to keep everything sufficiently simple and intuitive): breaking any block like stone, sand, gravel, soil, forest floor and so on would drop exactly two items that the block is made of (it may be necessary to have some items appear in higher quantities for balancing, but there would generally be at most two unique components), the main soil components would likely include something like rocks, gravel, sand, clay, soil, forest soil and organic matter, optionally, more components could provide even more variety and flexibility, like silt, peat, lime, humus, perhaps some specific soil types (e.g. iron-rich soil, podzol), maybe water in some way to create mud, but those would have to be added very carefully once the baseline system is working to avoid overdoing it with the complexity, placing these components as a block would involve putting either of the materials on the ground (creating a roughly half-block-high pile of that material), and then using the second component on it to convert it into a full block (alternatively they could probably be combined in the crafting grid as well, but it shouldn't be the default), any blocks that contain at least one soil component (and optionally some that contain certain other materials, like organic matter) would be named "soil blocks" or various subtypes of it, whereas other combinations would make different materials as appropriate, ideally, it should be possible to make arbitrary combinations of any two components, though it may be difficult - in many cases multiple combinations would probably make the same block (and they would save what they were made of, to drop the same components if destroyed again), and to give a couple of simple, example combinations, though highly subject to change in various ways depending on a lot of factors: sand x2 => sand, soil x2 => soil (the most average soil), soil + organic matter => high-fertility soil, soil + clay => clay-rich soil, soil + gravel => gravelly soil (lower fertility), soil + rock => rocky soil (very low fertility, could appear between soil and stone layers to make for a smoother transistion), forest soil + soil OR forest soil x2 => forest floor, forest soil + sand => sandy forest floor (lower fertility). One of the additional difficulties here is that a comprehensive overhaul would pull quite a number of concurrent changes with it. A bunch of potential adjustments to farming due to different soil types and potentially pH, a revision to world generation parameters for practically all plants in the game. I feel like a lot of these systems could use an overhaul eventually, but I wouldn't want to get too far ahead of the game's development either. While this idea is not without potential flaws and isn't really usable without ironing out all the details, I think it could offer a suitable compromise between much greater soil variety and simplified item management. It may also let VS stand out with a more material-based approach (as an extension of what it already does with stone or boards, for example) in place of the block-based approach that similar games often default to.

My experimental results suggest that both copying a world and generating a new world with the same seed doesn't seem to change any deposit positions. In both cases there may be differences that I would still have to look into further in the noise used to distort the shape of the deposits (which in rare cases can affect whether they appear at all), but generally they still generate in the same places within a small tolerance. Maybe they could generate differently if you could cause random generators to somehow desynchronize between the worlds, but I have no clue if that's even possible, because the game uses separate generators for many different tasks.

I don't see how this would be significantly more of a problem than rift activity and temporal storms. Sure, if it changed so slow as to force the player to leave the area for an extended period of time, then it would be annoying, but nowhere did I say I would want that. I think it should in most cases on the surface be similar to rift activity in most regards or outright merged with it into a single mechanic. Ideally, low instability could be generally ignored but serve as a warning of sorts of a potential upcoming spike, while such a spike of higher instability could require some combat or to stay at home during the night. If any drawn-out periods of instability were added, they should be balanced in such a way as to keep the player on edge, but not actually dump them into zero stability for an unknown amount of time. Areas with higher average instability would be characterized by slower stability recovery alongside more intense and potentially more frequent instability spikes, but could still usually be used for building perfectly fine, just with increased risks. I see this more as a problem to fix than as a significant counterargument, frankly. The mechanic should apply survival pressure and influence high-level choices, but shouldn't cause the player to wait for an extended period of time, and especially shouldn't make the player search for the most optimal place to wait. I think that the simplest ways to change it would be to: simply accelerate stability drain and recovery rates (or maybe mostly just recovery rate, to avoid excessively reducing the time you can stay underground before hitting zero stability), in order to make encounters with unstable areas more localized to those areas and not delayed on entry and then drawn out after leaving, or introduce more continuous stability effects to allow staying at partial stability in slightly unstable areas (related to the third point of the original list of suggestions), so that waiting wouldn't be necessary in relatively shallow mines and would roughly scale with depth. I think that reliance on the UI gauge is to a large extent a matter of preference for information availability. Besides a general dislike for UI indicators which often are detrimental to immersion, I just find it more interesting and exciting when I don't quite know everything about the situation I'm in and what to expect. I'm coming at it largely from the perspective of games that care a lot about player knowledge and organic discovery, where information is rather scarce and a large point of the game is for the player to familiarize themselves with the mechanics and learn how the world works (which would be very fitting for the unfamiliar, unnatural part of the world that is temporal stability). Games naturally limit the availability of information to make the player learn through experimentation and piece together a complete image of the system, but that is cut extremely short when the UI just tells you almost everything you need to know at any given moment. Having all the information readily available at all times is generally more characteristic of games that focus on action, where the player can't afford to be uncertain about what they can do at any given moment. Games that focus more on strategy, on the other hand, deliberately hide information to make the game more engaging and unpredictable by requiring the player to weigh risks and opportunities when making choices. I think that Vintage Story should (and in some other areas already does) lean towards the more strategic side.

One thing that I find these mods tend to fail at is introducing a tailored set of plants with purpose in world generation. They don't seem to me like they make world generation better, just more varied with a whole bunch new plants dotting the landscape for the sake of it. Large trees, functional plants (functional for the player, not for the world generation) and colorful flowers almost always take the focus, while mosses, lichens, short grasses grasses and the like are often almost completely ignored. A lot of the plants also arguably simply stand out too much. Among my favorites is the Floral Zones: Cosmopolitan Region one, which actually adds crowberry, reindeer lichen and a few other low-growing plants. But I'm very dissatisfied with how they spawn. A patch of a couple berries or ferns in the middle of a gray gravel surface is not that much more interesting than a block of tall grass in the middle of a gray gravel surface. Ideally, it needs a large area covered with multiple types of overlapping but not uniformly mixed patches of mosses, grasses, shrubs, lichens and so on in order to not only look good, but also look realistic. If you look at tundra, deserts and similar biomes, then you can see that even some of the most barren areas on Earth have at least a couple distinct species which cover the landscape, and almost none of them are nearly as empty as many of Vintage Story's temperate or cold gravelly and sandy areas. In a similar vein, I would also like to emphasize the point about larger variety of grasses in plains, savannas and similar biomes. While plenty of mods add a few decorative sedges or something of the sort, almost none attempt to make them remotely competitive with the everpresent tall grass. The current tall grass is functional, but extremely simplistic, so I think it would be beneficial to mix in large areas, not just small patches, of different dominant grass species, to create more natural variety on medium and large scale, which is lacking as of now both in the vanilla game and in practically all mods. I'll also touch on something that I didn't really mention in the original post: soil blocks are extremely samey. Forest floor provides a neat amount of variation in forests, but all other areas just have some nondescript uniformly-colored grass, or nothing at all in the case of areas covered with sand or gravel (which are largely unrealistic, by the way - gravelly and sandy soils are normal, but just gravel or sand by itself is not really a thing outside of very specific environments). Several mosses and lichens could actually be implemented as variations on soil blocks, and not as actual plants. I don't want to say that these mods are bad or something, don't get me wrong, but I just don't feel like they actually change much of anything about how the world looks besides throwing a bunch of new plant stuff on top of the vanilla game, which in some cases can even make the world look arguably worse when there's too many small patches of completely different plants in your vision range. And for a couple of extra examples to show what I mean, which I feel like are nowhere to be found in the current game and in mods. Notice how the lowest layers of plants, even in that rather barren-looking middle image, actually consist of many different species that each contribute to making the ground look more varied, yet without anything standing out excessively:

See, I'm annoyed, as I really don't feel like this has much to do with the suggestions I've made. I mean, fair enough, introducing changes with not a care in the world for how they fit into the game would inevitably have horrible results. It's a fair point that the unnatural shouldn't really become the common. It's also perfectly reasonable that the most unusual of the effects should be limited to special places. But I'm not asking for random crap to be added with no justification. I've specifically said regarding reducing reliance on UI and the environmental changes that it should be subtle and inexplicit, in order to make instability more pervasive and unnerving, promote a sense of uncertainty and keep the player on their toes. I don't think that's far from what you've said you like about the mechanic, but as I see it, all of that uncertainty and unnaturalness is as of now practically absent from surface instability, almost exclusively because of that gear in the UI. How am I supposed to see surface instability as unnatural if I just know the current stability through a perfectly reliable and always accessible indicator in the UI? Wouldn't it be more unnatural if I didn't always know whether a place is unstable and what to expect, but it affected the world in unpredictable and creepy ways, causing animals to behave in strange ways and plants to grow in unusal patterns? Do note as well that animals are unnaturally aggressive supposedly because of something related to lore. I think it's not unreasonable to assume that temporal disturbances are to blame (if not that, then what else?), and I think it would make a lot of sense for animals to be more aggressive and erratic in unstable areas, while behaving more realistically in stable regions. And for both flora and fauna, it can also be a matter of a simple question: does temporal stability and the rust world affect this one in any physical way? If it does, then it will unavoidably have an effect on how the stuff that lives there is affected by it, and by extension the flora and fauna that lives there. And we know it does at least to some extent, as evidenced by story locations. If nothing else, subtle red coloration throughout unstable areas, alongside something akin to iron toxicity in plants, would seem quite fitting. Also, I do think that temporal stability only affecting a certain class of entities is an interesting concept, but then I would say that it shouldn't be arbitrarily dictated by location, because it doesn't make any sort of intuitive sense for it to have been caused by a past catastrophe that changed the world. At this point it's practically identical to sanity mechanics from many other games.

Primary motivation The current assortment of plants is heavily lacking in the area of mosses, sedges, bushes and other small plants. Existing shrubs are implemented in a disappointing way, as they are technically trees so small that they only spawn leaves, ending up strange in appearance and obstructive during traversal. What this causes is that in many regions of the world the trees are the only notable plants that break up the landscape, alongside perhaps patches of flowers, but those only help in grassy areas and forests. The actual ground-level foliage is extremely basic, with there just being grassy soil, gravel and sand, where in reality grasslands, steppes, tundras, deserts and similar biomes have much greater biodiversity than people tend to give them credit for. The main goal of this suggestion is to point to the lacking biodiversity in the current state of the game and list several example species which could be added in high quantity to certain regions of the game to make them significantly more visually unique, diverse and appealing. The suggested species are generally very specific with the intent to more explicitly communicate the intended purpose, but could be broadened into more generalized genera or families or whatnot. Additional possibilities The simplest consequence is that the added plant variety would lend itself naturally to create distinct regions of more unique flora and fauna like shrublands, peatlands, arctic tundras, and many others. This is largely related to the "regions of distinct flora and fauna" category in the roadmap. Any extra variety would also be greatly beneficial for the goal of separating plant species into regions according to their real-life geographical occurence, as Tyron has expressed the intent to do so eventually. Additionally, certain plants may be used as indicators for certain features of the world or for the presence of certain deposits. It would be quite reasonable to adjust the generation of certain plants based on rock types like limestone or based on the density of certain ores like sulfur, as well as on soil types if more ever get added. Some deposits like clay, peat, high fertility soil or surface copper could have specific indicator plants growing above or near them, to help players locate them more easily (not exclusively growing above these deposits, but often enough to be reasonably reliable). This can be greatly beneficial for the main gamplay loops, as it can get the player to pay more attention to the environment and learn about what to look for in the world, instead of simply running around and hoping for a find. It may also introduce a neat alternative to the prospecting pick when looking for certain ores. Finding desired resources using indicator plants would be more satisfying than pure chance and would naturally reward game knowledge. Mosses, lichens, tiny creeping shrubs and similar The primary in-game purpose of these low-growing plants, generally at most ~20 cm in height but may be much lower or somewhat higher, is to increase the biological variety and visual interest in areas with otherwise uninteresting or limited vegetation, like gravelly plains, tundra bogs, boreal forests and the like. The main benefit is that they can create small and medium overlapping patches of varied color, which could cover large areas and are highly effective at breaking up monotonous landscapes and flat surfaces in almost any environment. This is very important to keep landscapes visually interesting, because, as it stands currently, there is very little color variation in terms of soil and grass. Example species include: any bog moss (Sphagnum) - this one can also be a diegetic tell that there's peat nearby, reindeer lichen (Cladonia rangiferina), common liverwort (Marchantia polymorpha), dwarf willow (Salix herbacea), black crowberry (Empetrum nigrum) - can also be a source of fruit, white clover (Trifolium repens), alpine fescue (Festuca brachyphylla) - technically a grass, but I'm including it here due to its intended purpose. Left - sphagnum bog; middle - reindeer lichen and black crowberry; right - alpine fescue. Grasses, sedges, rushes and similar The purpose of grasses, sedges and rushes is primarily increasing the variety of default tall grass in expansive plateaus, plains and savannas, with the goal of introducing medium and large-scale patterns to these otherwise flat and uniform areas. All of these would likely drop dry grass or thatch, and several species may provide edible roots. Certain shorter grasses would also serve well to provide more natural grass coverage to sandy and gravelly areas. Additionally, some species may work well as decorative grasses. Example species include: alpine bluegrass (Poa alpina), Sandberg bluegrass (Poa secunda), cogongrass (Imperata cylindrica) - a great source of thatch, could be used as an indicator for clay, nut grass (Cyperus rotundus), common rush (Juncus effusus) - could be used for actual rush mats, including tatami, as well as potentially for rushlights, Chinese silver grass (Miscanthus sinensis), copper flower (Ocimum centraliafricanum) - not particularly significant, but can serve as an indicator of surface copper deposits in warm climates. Left - common rush; middle - alpine bluegrass; right - Sandberg bluegrass. Shrubs Shrubs are mostly present roughly where they should be. We have an entire climate parameter for shrubbery, but the actual shrubs are just trees that generate so small that they don't have trunks. This is kind of appropriate, as many real shrubs are closely related to trees and can grow into trees given the right conditions, but it also causes a number of issues: random leaf blocks can be pretty confusing - a tree is a tree, a bush is a bush, but a leaf block is expected to be part of a larger tree, the shrubs tend to look pretty ugly, because they lack identifiable, distinct shapes, the variety of the shrubs is ultimately very poor, with just 5 species across all climates, all the shrubs use the leaves of some larger trees and so can't even be identified more properly without looking into their codes, certain shrubs (most notably dwarf birch) simply aren't remotely accurate to their real-life counterparts, larger shrubs impede traversal, and make for a highly unpleasant experience when riding an elk. Some of the same issues apply to berries to some extent, but those get a pass mainly because they don't borrow leaves from larger trees, and don't impede traversal nearly as much, plus they're likely getting reworked soon. Overall, shrubs in-game should arguably have two main subtypes that determine function, depending on size: either as greater variety or dominant plant for areas with relatively low vegetation with generally ~0.5-2 m of height, or as larger bushes with upwards of 4 m of height to constitute large, primary plants in rare shrublands, that is areas with very high shrubbery but very low forestation. The reason for this is that shrubs are limited by two different kinds of requirements for traversal: small shrubs should not impede movement too much, can be very dense, and should be used mostly for visual interest and in areas like tundras, deserts or mountains, large shrubs would have to be relatively sparse as to avoid making areas completely impassable and impossible to see through, and should only appear in relatively fertile places, in-between shrubs like those we have now don't fulfill either role particularly well. Most small shrubs can easily be implemented as regular single blocks, while larger shrubs should arguably be implemented in a way similar to fruit trees, though not necessarily with the full block-by-block growth system. Example shrub species include: sagebrush (Artemisia tridentata) - among the most well-known shrubs in deserts, steppes and mountains, dwarf birch (Betula nana) - already sort of in the game, but it should only be ~1 m high, gray willow (Salix glauca), dwarf mountain pine (Pinus mugo), any rhododendron (Rhododendron), and potentially similar flowering shrubs - would serve well as decorative plants, including for garlands and stuff. Left - dwarf mountain pine; middle - primarily gray willow; right - sagebrush.

In that case, I would probably make them a rare "new" ruin; that is, rather than ruins of the Old World, it's clearly the ruins of a trader camp or survivor settlement that got overrun years ago. There could probably be a better item or two to find, but the instability would definitely prevent players from just turning such a ruin into a convenient base. I actually really like this idea. It's a bit jarring that there's so many traders, and every single one of them is alive and healthy. Wouldn't be unreasonable to just automatically replace every trader with a ruined hut if they're in an unstable area, if not something more complex. That sounds pretty interesting to spice up a next playthrough. Would likely require a bunch of rebalancing and other tweaks to not be a pain to play, but it creates a pretty novel approach to instability. Kind of unrelated to everything else, though. I'll see if I can answer some other points as well, but for now I just want to say that I genuinely don't understand why you're opposed to changes to the environment. As I see it, they are close to necessary in order to adequately communicate the risk associated with an area, in a way not dissimilar from something like temperature-related risks being closely tied to the climate you're in and time of day. Even if something like dynamic instability fluctuations were added, reducing that need for clues in the environment somewhat, it would still simply constitute good game design to give the player environmental hints and diegetic instruments to gauge instability instead of just telling them through UI. This applies doubly if your goal for the mechanic is remotely related to keeping the player on edge and biting them if they get complacent, because having immediate and fully reliable access to the information largely just nullifies that goal. Environmental clues for things are in the vast majority of cases more immersive and engaging. It's good game design in this context because the player doesn't need (and arguably shouldn't have) on-demand access to information about stability. It's expected for the player to have immediate access to information about the character's health, hunger or oxygen and so on, because they are properties internal to the character which are necessary for the player to access quickly when making moment-to-moment decisions. Ambient stability, however, and extending partially to character stability through drain/recovery rate, does not have almost any of the same design factors, because it's a property of the world and not the character, and it is primarily significant in more strategic, high-level choices where information scarcity is a significant design lever.

You can remove temporal stability as a whole, but that also hits underground instability and removes this effect from rifts and storms. If there was a way to disable surface instability specifically, then Stable Surface wouldn't have a reason to exist. One thing that I personally find quite disappointing given the lore significance of temporal mechanics is that both temporal storms and temporal stability were introduced back in 1.12 (Q1 2020), and saw practically no meanigful changes since then besides the introduction of bowtorn and shivers. While I'm not sure if I want to entirely recap a few other discussions on the topic, I would like to point out a few things: I absolutely agree that in-your-face effects like an immediately noticeable overlay would be terrible, for a number of reasons - a much more common suggestion in this vein (which we've also discussed a few weeks back) is to add some sort of environmental clues, I don't actually remember ever seeing a suggestion for increasing stability drain rate, and I think it would fix practically nothing as a standalone change - drain rate is mostly just a matter of balancing and not a significant design factor, it would arguably be much better to create an interesting threat by removing the gear from the UI entirely or in some other way adjusting the mechanic, not by making it so irrelevant most of the time that you end up forgetting about it, personally, I have yet to have temporal stability catch me off-guard in any way, while surface instability specifically could as well not exist and it would change practically nothing about my experience with the game. If I were to recommend a set of slightly more specific changes (mostly but not entirely independent of each other), it would probably go something like this: Remove the UI indicator or reduce its reliability, and introduce environmental indicators of instability - this would make for a much more believable and immersive tell of past catastrophe, and could have a number of beneficial effects, primarily requiring the player to pay attention to their surroundings instead of just looking at the UI. It doesn't even have to be in any way explicit, because it may be limited to modified animal frequency and behaviour, different ambient sounds, less common plant growth overall and more sand and rocks, more scattered stones, sticks and other clutter, adjusted relative frequency of different plant species (e.g. less flowers, more thorny bushes), and other changes like that. Only in very low stability it would begin getting anywhere close to proper rust world effects, which would primarily occur underground. Some of those new or changed things in the environment could be in some ways valuable, e.g. certain plants for herbalism. Overall, it would do wonders for immersion and create an unnerving sense of uncertainty about the player's and the region's stability, requiring to actually face the world and think critically instead of being able to immediately nope out of an area the moment the gear starts turning wrong. Some measurement devices could be added to allow testing a spot for instability or measuring the player's own stability, but they shouldn't be necessary for anything either. Make ambient stability change over time - it's among the most common suggestions that I've seen, and it would greatly reduce the risk of new players getting thrown into an indefinite period of 0% stability for no apparent reason, as well as allow to address the complaints about good spots being unsuitable for building. This way, instability would be able to catch every player off-guard occasionally, even if they decide to just stay back home forever, but would naturally ease off after a period of time. It could be implemented as a global modifier that fluctuates like rift activity, or it could be a dynamic system like rain or something of the sort which evolves randomly over time in more complex ways but still depends on average stability in every spot. It would likely have to be implemented in such a way that even the most unstable areas would remain stable for some time semi-regularly, and even the most stable areas would face occasional spikes of instability. Some measurement devices could be added to gauge the current stability and predict it in advance to some extent. Reduce the effects of slightly unstable areas, and increase the effects of heavily unstable areas - as it is now, for most practical purposes, ambient stability could as well be a binary value and very little would actually change, because all areas have either of two possible end effects, and just progress towards them at different rates. Making stablity effects more gradual would also allow the player to better familiarize themselves with them before getting thrown into deep water. It may also be worth to just make specifically surface instability never naturally exceed a certain threshold, to keep the most dangerous effects to the underground and to storms. Increase total coverage of unstable areas - again, this would really reinforce that the world is no longer what it used to be, and make surface instability an integral part of the world that the player has to contend with instead of a rare inconvenience. It could make the player less avoidant of unstable areas by making them a frequent and expected occurence. This is largely reliant on the previous two points (dynamic instability and more continuous instability effects) to make sure that the world doesn't feel inaccessible and excessively punishing, and to allow the players to hang out in less stable areas while keeping relatively small added risks in mind (generally smaller than indefinite 0% stability). Make rift frequency more tied to surface stability to keep the mechanics more cohesive, and introduce instability spikes lasting at least a couple hours before and after storms, likely replacing the current fixed stability drain during storms. Storms could even be removed as a distinct mechanic, and instead occasional extreme stability spikes integrated naturally into random stability fluctuations would serve the same purpose. Make ruins more likely to spawn in unstable areas, kind of as part of the environmental clues as well. Ruins are a very intuitive way to signal that it may not be a good idea to stay there in the long term, even if there are some valuables, which would also add a small risk-reward pattern to looting ruins. Do note that my point here is expressly not to kick the player in the balls for daring to play the game, at least not significantly more than rift activity and temporal storms already do. The point is to make temporal stability more immersive and more integral to the world and gameplay without making it a pain to deal with. There were also some ideas for features that are in no way critical to improving temporal stability, but which I think could potentially work very well for the game if implemented with the right goals in mind and justified appropriately through lore: Add temporal anomalies that appear occasionally throughout the world but primarily in the most heavily unstable areas, which cause small to medium-sized localized disruptions in a plethora of possible ways, like fog, particle effects, devastation, barren ground, scarred and torn apart soil, rust spikes and thorns, floating stuff, repeated terrain geometry (like in some rooms in RA), pockets of completely altered climate conditions, pockets where time flows differently. Also, they could just be large rifts, active permanently though growing in size and strength as rift activity increases. They may or may not be interactive or valuable in some ways. Overall inspired by the anomalies found in S.T.A.L.K.E.R. games, but should probably be adapted to the temporal flavors of Vintage Story. Add some sort of rare trinkets, devices, or just corpses to some ruins which would cause the nearby area to be more unstable, or cause some other issues. They could also briefly flash into existence during temporal storms in some manner. Primarily related to Jonas tech. A bunch of these could perhaps be looted and some may even be quite valuable and useful, but then they would apply the same detrimental effects on the player holding them or in the area where the player puts them away. They could usually be destroyed, disassembled, in some way purified or at least contained to remove those detrimental effects, generally losing any useful functionality in the process as well. Introduce some sort of immaterial ghosts, visions, illusions or something of the sort to unstable areas (as part of the environmental clues as well), which would also appear during temporal storms and some lore locations. Think visages of people and perhaps of animals or rotbeasts, which briefly appear wandering aimlessly or doing something specific near ruins. The player may be able to interact with them in some limited ways, and maybe even talk to them or obtain something from them using a Jonas device. Inspired by the ghosts of Fyke Isle, if you've played The Witcher 3. Alternatively, it could be really cool to have ruins that appear like a mirage but fade out when the player gets close to them, and could potentially even be accessed in some cases using the dimension system. Adjust the properties of the world in temporally unstable areas in some ways (not unlike mentioned by the OP), e.g. change the temperature by a couple degrees, adjust other climate parameters in various ways, influence terrain generation, slightly adjust the speed at which certain processes progress. This would again also function as one of these environmental clues of instability.

How does adjusting capacity to be less focused on arbitrary slots and stack sizes imply a reduction to the amount of things the player can carry? Sure, any changes would probably reduce the capacity for some items, but they could very well also increase the capacity for other things. Also, if any significant reduction to capacity of this sort were introduced, I would expect to see bulk transport methods like frame packs or carts to come alongside them as a way to offset that capacity reduction. The main goal that I have in mind when suggesting something more akin to a weight or size system is to dictate capacity more by the total amount of items, and less by the number of unique items. As an example, I currently have three chests for random looted clothing, one of which has more than a dozen butterfly pins and more than a dozen items of jewellry, while all my building materials fit in just one chest simply by the virtue of stacking. The problem is not that the building materials take too little space (though I wouldn't mind small changes to it). The problem is that the clothes take a comparatively absurd amount of space because they don't stack.

If you search for something like "surface instability" (searching with quotation marks matches the full phrase), you should be able to find quite a few posts. A large portion of them (including mine) arguing that surface instability should be adjusted (or removed if nothing else). If you find yourself wanting to turn off surface instablility specifically, you may want to try a mod like Stable Surface, though I'm not certain if it works on the current version. This is among the most common and most frustrating arguments I tend to see in favor of surface instability. It can seem like no matter how people try to explain the issues with the mechanic, there's always someone that will go "well, I personally don't mind it" and optionally proceed to describe the ideal design goals that the mechanic aims to accomplish instead of looking at what it actually accomplishes in practice. I do agree wholeheartedly with those design goals and that's why I would prefer surface instability changed and not removed entirely. I think surface instability should be more prevalent and visible to actually show how the new world is changed, more disruptive to require the player to pay attention and keep track of it (potentially replacing paying attention to rift activity in the UI (why is it even in the UI?), more challenging to actually apply survival pressure and not just be a minor annoyance, more dynamic to catch players off-guard but relent after a period of time, more integral to the world and connected to storms and rifts to promote a sense of cohesion and immersion. What it should not be is forever unchanging, entirely uninteractive, completely invisible, and yet altogether inconsequential in nearly every single case.

I do think the game could benefit from an approach to capacity that is less tied to stacks and more to size, weight or whatnot. While the current approach is simple and functional, it's also kind of silly that two different items effectively take up twice as much space as a full stack of identicals items. Or instead of reworking capacity, something like the other block game's bundles could be a neat addition. The new displayable system is also a massive step in the right direction. That said, making every object visible in storage containers would likely be a massive pain to implement and it will only get worse the more different storage options are added to the game. The reduced capacity coming with it would be a pain to deal with as well, because realistically it would make even dedicated storage (chests, crates and so on) actually really quite bad at storing things. Visualizing the contents of containers and perhaps limiting the capacity of some of them may be a good idea, but taking it to the extreme is not. Broadly, I would say that immersive storage options should be made more practical and varied. Improve ground storage for bulk items to be more practical (why only 12 ore nuggets, why only 10 grass or cattails, why only 6 thatch?), add dedicated liquid storage methods (casks, barrels, tubs etc.), potentially reduce the overreliance on chests and crates by adding some different containers more suited for different things, like actual barrels that can be picked up, sacks for produce or flour or dirt or other stuff, free-standing shelves, racks for stacking long and thin items, open containers for grains or grass and the like, more gameified wardrobe sections as a way to store a larger quantity of unused clothing. And one of the most stupid things, arguably, is that you can actually get stacks of two temporal gears. Dropped from the first boss. I would love to be able to hang the gears on rope from the ceiling, or something like that. Would make sense since they provide light and lore-wise it would be quite reasonable to keep them easily accessible.

As per the Wiktionary, a vug is "a small to medium-sized cavity inside rock that may be formed through a variety of processes." In the context of Vintage Story, it's just a small empty space (usually ~3-5 blocks in diameter, from what I've seen) inside of quartz or olivine veins, which contains large crystals.

No, it won't. Rhodochrosite is a regular ore, while amethyst is a vug which generates using a separate mechanism (it's just a structure, technically). Yeah, they're the same thing. If you've found them in caves, that's probably because a cave happened to go through a vein. Big crystals generate within vugs. Amethyst vugs only generate within underground quartz veins. I'm not sure what "underground" exactly means here and if they have any additional generation requirements, but there doesn't seem to be anything else in the JSON definitions. For the best chance to find amethyst, you should just search through underground quartz veins (ideally thicker ones), presumably by digging tunnels every three blocks within them. You may also be able to find a bunch of gold and silver this way. Do note, though, that amethyst is the rarest of all the crystals, so it's not gonna be quick and easy.

Tyron has said a few months back that "the next update will probably have iron spears", and "there was some balancing done on the spears". My guess is that it will likely primarily involve a ranged damage nerf, but maybe it's gonna be more creative. I kind of hope that they don't touch the Stone Age tier, though. That's one of the things I don't get about these balance discussions. These are just numbers, and as long as any changes don't mess with some important thresholds (e.g. flint spears one-shotting rabbits), they don't really matter too much and can be freely adjusted to keep balance in check. It's entirely possible to compress the damage progression on the spears and end up with the overall balance of the game practically unchanged. Sure, and since it's just a variant it's probably really easy. I could probably do it in at most a couple hours with essentially zero prior VS modding experience. But, here's a thought: making the game yours is the easiest way to end up with an incoherent and unbalanced mess and drop the game once you start losing control of all the tiny adjustments, especially as new game versions start introducing conflicts and changes. Especially when someone has only recently started, they tend to at first play the game as the developers designed it according to their own vision. They can appreciate it for what it is, but will inevitably question odd choices like the lack of iron spears, and the natural reaction is to suggest an obvious change instead of modding everything in in a knee-jerk reaction. You asked in another thread at one point to recommend damage changes to spears. Side note, you've also said that a 0.25 damage difference requires a multiple of 4 hits to matter. It doesn't - it can make a difference on any number of hits, especially once you start considering damage modifiers. Also, keep passive health regeneration in mind. Back to spears, how about we start by reducing the disparity between the different bronze alloys and copper, to make space for iron? Something kind of like this, alongside a few examples where each next tier helps with breakpoints assuming no damage modifiers: damageByType: { "*-granite": 4, "*-flint": 5, "*-copper": 5.75, // two-hits T0 bowtorn, down from 3 for flint "*-bismuthbronze": 6.5, // -> 6.25 // two-hits T0 drifters and three-hits T2 bowtorn, down from 3 and 4 respectively for copper or flint "*-tinbronze": 7.5, // -> 7 // two-hits T1 bowtorn, down from 3 for bismuth bronze, copper or flint "*-blackbronze": 8, // -> 7.5 // three-hits T2 drifters, down from 4 for weaker bronze or copper (probably the weakest tier here) // "*-iron": 8 // 2-hits wolves and pigs, down from 3 for bronze or copper // "*-meteoriciron": 8.25 // two-hits T1 drifters and 4-hits T4 bowtorn, down from 3 and 5 respectively for iron // "*-steel": 8.25 // alternatively, 8.5 could have some interesting thresholds, but I think they're better left for the bow }, I don't really think it would make metal spears in any real way underwhelming, especially as long as their durability is reasonably high. With the above changes, a steel spear would have ~19% higher damage than the average of the three bronze spears when thrown, while a parallel comparison would yield a ~26% difference between arrows (assuming using the recurve bow) and ~17% between falxes, so it's not particularly slow progression by any means. And if damage changes are not enough, then there's also other things that could be done, whether to balance spears as a whole, to balance them against bows, or to balance different spear tiers between each other. Even not considering anything that would be better included with a proper combat rework, a spear rebalance could quite easily involve adjusted accuracy, increased charge time required to throw a spear, adjusted attack speed, varied melee range, increased durability loss when thrown (possibly dependent on what it hits), adjusted throwing range, whatever, really. I would personally consider throwing charge time as the most interesting balance choice here, but each of them can have a purpose depending on what we would want the spears to exactly be. That is my preferred route as well. Maybe not necessarily halberds, as there is an endless variety of other polearms that could be added, like a bill, a poleaxe, a ji, and so many others. As mentioned before, the game has a bunch of "ruined" weapons that include a boar spear, a voulge, a war fork, a ranseur, and a couple axes which could be classified as polearms as well. Also, a lance or pike as suggested by @LadyWYT elsewhere may fit what several people here are mentioning, as it naturally wouldn't be throwable but could have further exaggerated melee capacity with ~4-4.5 m range compared to the spear's 3.5 m (whereas other polearms would more likely have ~3-3.5 m). I want to mention, though, that I think we need some combat changes for more weapons to make much sense. Currently, weapons only really use three parameters that affect their balance: durability, damage and range.

That's a nice point. I would say that the reason the Creeper still works decently well has a lot to do with it being very satisfying to kill (rush of dopamine and then relief) and serving as a challenge of sorts, which reinforces skill and game mastery. You can get this from storms to some extent as well, but the whole thing lasting upwards of 9 minutes once it ramps up just gets tedious and drowns out that positive reinforcement. Additionally, the Creeper is fairly easy to keep away due to much more generous monster spawn protection than VS offers - I genuinely don't remember the last time I had a Creeper blow up anywhere near my house, while drifters are constantly in my face at night until I invest into a bunch of lanterns. The Phantom, for contrast, is quite widely disliked throughout the community, because it's annoying to fight, it's not a challenge or a test of skill, it comes in uninvited even in areas otherwise safe from mobs, and tends to be just overall inconvenient and disruptive. The negative end effect of Phantoms is ultimately rather minimal compared to Creepers, but player sentiment is influenced in many other ways as well. Tyron has said they don't want to permanently modify blocks, but I wouldn't rule out other mechanics that aim to achieve similar effects in different ways. I can generally agree that the player should have countermeasures to use and face some risks for not using them, although I would also say that the countermeasures should ideally be intuitive and reasonably accessible, as well as effective enough to be preferred over cheese and other less immersive solutions. Fences specifically are a very good example, because they are the simple and obvious solution to keep livestock in and keep predators out, they are reasonably cheap and easy to make, and they are deliberately made somewhat gamey and not realistic to reduce the incentives of double fences, dirt walls or similar workarounds. I think that it's borderline impossible to punish the player in a way that somehow ends up making them enjoy fighting the storm. Unclear or weaker consequences (e.g. breaking blocks in a purely cosmetic way) that aren't seen as severe enough to warrant the risk and effort of fighting the storm may not even make the player attempt it in spite of the added maintenance. I just don't see how it would be beneficial to make the player engage more with storms, which they already often don't want to do, by making sitting them out in a hideout even less appealing than it is now - as I see it, it would easily end up highly discouraging instead. That's a pretty good point. I think the main counterargument to it lies in that while winter does require the player to prepare, it doesn't significantly limit what the player can do once they make at least basic preparations. It's like if storms lasted many in-game days but only caused rare and fairly weak monster spawns (a bit like what we have with rift activity), which would generally make the player prepare armor and weapons for it, but without heavily restricting what they can do over its duration. As it stands now, temporal storms make it nearly impossible to do anything in open spaces besides combat, even in the late game with steel gear, which is much more limiting than the reduced resource availability in winter. By adding consequences to ignoring storms, you might end up forcing the player into combat to the point where even the optimal solution that prevents greater consequences would often feel like punishment, just because the player would feel like they have to do it. Also, last note, keep in mind that merely adding an incentive to go out into the storms makes hiding less desirable through opportunity cost, reducing the need for other consequences. I'll see if I can comment on some other things later if I think them through.

Starts at 43:45, to be specific. I'm not immediately confident about this video translating fully to vanilla. Nothing in the modlist seems to affect bears besides Butchering, but I'm not so certain about player speed (I'd have to look through more of the lead-up). Don't know if I would call that fight nonchalant, frankly, with multiple close calls which may or may not have been avoided entirely by chance. I'm not entirely sure how the guy doesn't end up getting hit in a few moments like 44:10 and 45:08. Can't really tell if it's precise movement or just luck, but I've been unable to replicate it with sufficient consistency. The difference between brown and black bears is pretty massive, keeping in mind the numbers from assets/survival/entities/animal/mammal/bear-adult.json: movespeedByType: { "bear-sun-*": 0.01, "bear-black-*": 0.015, "bear-polar-*": 0.019, "bear-brown-*": 0.02, "bear-panda-*": 0.015, }, Last I checked I couldn't find the exact player movespeed to compare numerically, but it seems to be something like 0.018. Black bears are easy to just run away from on almost any terrain, since they seem to be ~20% slower than the player. Brown bears, though, are ~10% faster than the player or right about exactly the same speed with the "fleetfooted" trait, so they can be pretty tough to fight even for the hunter and the clockmaker. The only strategy that has consistently worked for brown bears for me without "fleetfooted" (besides the cheesy ones, like hiding underwater, hiding in a 1x1 hole, pillaring up, running backwards) was running around a small to medium pond, not unlike the guy in the video did, but even that tends to be a bit sketchy. Rough terrain and shrubbery can be very useful as well depending on how good you are at navigating it yourself, but can also be risky when there's too much of it, especially if you don't know the terrain beforehand. I guess the short of it is that fighting in a good spot seems to me much more important than just skill and practice, not even counting cheesing.

Man, before anything else I would kind of love to have the options for cave painting be more explicitly acknowledged in the description and the handbook. They can't be looked up like pigments using the search function. Limonite doesn't even have the "drawing" section in the handbook, which is really odd because they specifically added one for hematite. Drawing using both hematite and limonite has been in the game since cave art was added in 1.15, and yet many people (including me until today) are unaware of the possibility to use anything besides charcoal and chalk and it's not even present on the wiki (even though it appeared in patch notes, and information about charcoal and chalk is on the page for pigments). Just looked it up to confirm that rich or bountiful hematite and limonite chunks do work and there's no other hidden options, as defined in assets/survival/blocktypes/overlay/caveart.json { code: "material", states: ["chalk", "charcoal", "redochre", "yellowochre" ] }, Pretty annoying that the red and yellow come from hematite and limonite chunks respectively, and only rich or bountiful at that, making them (especially the yellow one) much rarer and more expensive than I would expect.

This is expected during 10% of the storms. From assets/survival/config/mobextraspawns.json, a pattern is chosen randomly by weight to determine the maximum quantities of each type of monster that are allowed to spawn: spawnPatterns: { "default": { weight: 5, groupWeights: { drifter: 0.5, shiver: 0.25, bowtorn: 0.25 } }, "drifterstorm": { weight: 1, groupWeights: { drifter: 1, shiver: 0, bowtorn: 0 } }, "shiverstorm": { weight: 1, groupWeights: { drifter: 0.4, shiver: 0.6, bowtorn: 0 } }, "bowtornstorm": { weight: 1, groupWeights: { drifter: 0.4, shiver: 0, bowtorn: 0.6 } }, "shiverbowtornstorm": { weight: 1, groupWeights: { drifter: 0.25, shiver: 0.375, bowtorn: 0.375 } }, "driftershiverstorm": { weight: 1, groupWeights: { drifter: 0.4, shiver: 0.6, bowtorn: 0 } }, }

Ilmenite belongs to the trio of resources which have reduced base spawn rates, alongside chromite and anthracite, meaning that you may sometimes have to search quite far to find it. It can form at most Y levels besides close to the surface and very close to the mantle (Y is in the [0.05, 0.85] interval), in all three igneous rock types and in both metamorphic rock types, so you can look for readings pretty much anywhere. It's possible to find "ultra high", but "decent" or "good" will be fine if there's nothing higher nearby, and you should generally ignore "poor" or lower readings for it. I tend to roughly search the area with a distance of ~400 blocks between readings, which tends to allow me to find it reasonably fast, but sometimes the random generation is just uncooperative. I have a world where I found ilmenite on my second reading, but it took ~50 readings spaced ~400 blocks apart to finally find chromite, which is about as common as ilmenite. Once you find a reading for ilmenite, it's just a matter of sinking a bunch of shafts deep down. You can make multiple vertical shafts, or you can dig horizontal tunnels, both optimally in ~25 block intervals, of course using node search regularly. For this case it's mostly just a matter of preference whether you dig shafts or tunnels - if you have almost exclusively igneous and metamorphic rocks then vertical shafts are probably a bit more efficient, while if you have a thick layer of sedimentary rocks or basalt on top then horizontal tunnels might be slightly more convenient. Halite is a bit of an odd case. Many people just buy salt from traders and don't bother looking for deposits. Dry lake beds in hot climates are mostly down to luck as they aren't detected by the prospecting pick (besides the sylvite in them), but domes can be resonably predictable. The readings for halite are wrong and appear higher than they should, even in areas where there is little to no chance for it to spawn. For a quite reliable chance to find a salt dome, you'll generally want a "poor" or "decent" reading in an area with an at least ~30-block-thick sedimentary layer or with a basalt top layer. If you find a "decent" reading with a basalt top layer, then you've hit the jackpot, but don't ignore other "poor" or "decent" readings in search of the perfect one. At that point you have to dig tunnels below the sedimentary layer in ~50 block intervals. If that returns nothing in a faily large area, then you can make more tunnels in-between, but there's generally no need to go lower than ~12 block intervals as it tends to be pretty tedious and doesn't offer particularly high chances of finding something that you've otherwise missed. The prospecting pick's node search can't detect halite, but it can find sylvite which spawns in halite, so you can still use it to locate the domes to some extent (and you may also find a bunch of other resources this way). If you're digging dense tunnels, then you can make them at more varied or more specific heights for a better chance at finding other deposits (e.g. Y <= ~40 if you get pentlandite or chromite readings in the area). For prospecting specifically, I think it would be quite fine to just include more practical information in the handbook, perhaps in a dedicated mining and prospecting guide that would describe where certain ores actually spawn - the information about the ores above comes largely from analyzing the code (and you could also get a bunch of it from the wiki), but in-game information is really quite limited. I do like the general idea. While the specifics are up to debate, it would just make sense that traders are roughly familiar with the area around them and may share some information about it, even if for a price. While prospecting information might be limited to specific ore types and may only be provided by specific NPC types, things like bees or nearby rock types could be familiar to pretty much every trader. One potential issue which I'll point out is that players tend to lose motivation when they know the steps required to get a reward, and just have to slog through to get it, so it's not just about avoiding making some other methods less practical. If implemented carelessly, this system can run the risk of making resource acquisition more tedious, by largely removing the need to search for things and by extension taking away the excitement that comes from finally finding a good reading or something. Of course, the flipside is that players tend to also lose interest if they keep searching with no payout, which is why I wouldn't mind a reasonably expensive but reliable way to know "what you're looking for is somewhere in this area (in a decent quantity), you just have to find it". While it's a fun idea, I think it would be fine enough to just provide a rough distance and direction. Don't get me wrong, more immersive directions could be amazing if implemented well, but I have doubts about how to implement it in a way that is actually reliable. Spending a bunch of time on a mechanic is more justified when you know the system will be more useful than annoying. This would ideally require some care to avoid making special NPCs too much of a challenge to find themselves, but it would make a lot more sense than just the more generic traders we have now. A cartographer is an interesting idea, and some others could include a prospector and a hunter or a woodward, and additoinally, the treasure hunter could be included in this category. Traders are getting new huts and stuff soon-ish to replace the current wagons, but I don't know whether that will come with any mechanical changes. Having some more unique and specialized NPC types could allow some of them to live together while avoiding issues with trading between two traders in a single hut and other shenanigans.

I'm kinda late to the party and you've had a fair share of pushback already on this, but I want to mention that Tyron has said something to the effect that they have a general rule to never damage, destroy or replace blocks through means external to the player, especially player-placed placed blocks, in the Standard mode (outside of special cases like bricks used in furnaces). He didn't go into much detail as far as I remember, but the reasoning seems to be roughly consistent with a bunch of what has been said in this thread. Regardless of how well-intentioned it is, damaging or destroying blocks comes with risk of restricting player creativity, incentivizing cheesing with ugly workarounds, imposing tedious maintenance, or inadvertently creating undesired incentives like running away from home for the duration of the storm, all of which are easily detrimental to player engagement. That is not to say that it can't work at all or couldn't be added to Wilderness Survival or Homo Sapiens, just that it's unlikely to be added to the Standard mode, or if it gets added in some form then it will very likely come with some simple, intentional workarounds (e.g. a way to lock doors as a solution to drifters being able to open or break them). There have also been suggestions to introduce a somewhat similarly-motivated mechanic but without permanent effects, which included: monsters or other threats that can move through blocks or in some other way reach a player indoors, monsters that can render blocks temporarily immaterial instead of physically damaging and destroying them, large, moving rifts or brief fissures that temporarily modify the world in some way within their area, and probably other stuff I don't remember or haven't seen. Overall, I would personally much rather see an incentive to go out into the storm and voluntarily face the challenge, but keep the player generally undisturbed if they still decide to wait it out in the safety of a hideout. As a general rule, it tends to be better for long-term engagement to incentivize something that you want the player to do instead of punishing the opposite, especially in a game with as large casual appeal as Vintage Story has in the homesteading elements. Punishment for inaction tends to be a very hard sell. I would expect that adding consequences to ignoring storms would significantly increase the number of people who turn them off, and amplify the feedback about storms harming the overall experience as a disruption that serves only to the player's detriment (which you can even see in this thread). Just a note: it is possible to provide a lot of rewards without making farms lucrative at all, and it only depends on how they are implemented. Conventional monsters have a whole bunch of issues and inherent design limitations that enable mob farms in the first place, but they are not nearly the only possible source of loot. I don't know if you've seen it, but there seems to be a small Temporal Storms Require a Fight mod which allows to reduce storm duration by killing monsters, with a pretty flexible config, if you're interested. There were also at least two other ones that did the same and some other things on top, but they seem to be outdated and less stable. Personally, though, I would be interested to see the storms actually much longer and impossible to shorten or skip completely, but with much weaker adverse effects for most of their duration, making it so that the player would be able to stay outside without too much risk and enjoy the audio and visual effects of the storms (which could use some improvements, but that's another point). They would just have to stay careful and watch out for signs of imminent extreme rift activity spikes, and hide or fight for a much shorter duration during these intense but brief storm phenomena. The thing with temporal storms is that they are hardcoded as a quite low-level, tightly-connected system that's not easy to modify beyond simple changes to a few variables or numbers, which also means that any two mods that attempt to significantly change it are very likely to be incompatible. A proper overhaul would likely require large sections of the code related to storms to be entirely rewritten, and that ideally also requires close familiarity with a bunch of the game's internal workings. Most of the code for the storm's mechanics is here, if you want to take a look.

Nice. And here's PlayerUID in the API: /// <summary> /// Returns the players identifier that is unique across all registered players and will never change. Use this to uniquely identify a player for all eternity. Shorthand for WorldData.PlayerUID /// </summary> string PlayerUID { get; }

There is a playeruid which appears in quite a few places (I'm not sure if it's the same one that you're talking about), but I think we can quite safely assume that the devs wouldn't plaster it all over the logs and tell people to post it on the internet if it was in any significant way compromising. It even appears in server logs, which means that it's probably visible to the owner of any server you join. As far as I can tell, its primary purpose is simply to allow the server to identify different players, and allow those that leave and rejoin to access their position in the world, their inventory and so on. I don't really know if that's unusual, but I've had zero problems finding fire clay, almost to the point of suspicion. On my longest-running world so far (~200 hours) I've found a large area of bauxite gravel and sand relatively easily (~10k blocks away), housing at least 5 large fire clay deposits, and I haven't even used up the first one. On the same world I've accidentally found three fire clay deposits underlaying coal without even deliberately looking for the coal. And this also reminds me that the current fire clay generation seems a bit odd, because the small deposits that are supposed to be common have a minimum rainfall requirement of 0.27 while low fertility soil starts to appear at 0.33. This makes large deposits end up more common in certain areas despite a 20x lower spawn chance, as they only require 0.1 rainfall. The funny thing right now is that unless you're making steel armor, then a single batch of 16 ingots may quite feasibly last for an in-game year or more, at least for players on the more casual side. My recommendation actually tends to be to make the bare minimum of bricks required for a cementation furnace (I think it was 224 = 3 x 64 + 32 bricks, doesn't really matter if it's T1 or T2), then beeline for ilmenite and use T3 bricks from that point onwards. It's not a bad idea to locate an ilmenite deposit before you even have steel, and I think you can even use ore-blasting bombs to mine it (though it still requires steel pounder caps to pulverize). T3 bricks have 99% heat resistance shown in the handbook, which is already much better than 90% for T1 or 95% for T2, but the actual value in the code is 99.9%, meaning that they break extremely rarely (assuming there's no rounding shenanigans, but experimental results support 99.9% from what I've seen). It's far from necessary to go for ilmenite as fast as possible, as all of the resources for T1 or T2 bricks can be obtained in large quantities quite easily either way, but it is something to consider.

That's interesting, because all of the paths in my logs and in multiple logs I've randomly checked off of GitHub appear as "%appdata%\Vintagestory\...", and frankly I'm not sure what could cause them to reveal the full path. Is it maybe because these seem to be related to a mod (do vanilla debug messages also have the full path)? Is it maybe because the appdata folder was chosen as the game's directory manually, causing the game to remember the provided path instead of accessing it through %appdata%? Maybe it's caused by an older installation of the game saving the full path instead of %appdata%? Tough to say more without a more detailed investigation. Actual errors and not simple debug messages could potentially show some stuff in the stack trace as well (I've found what looks like Tyron's username in one of the log files, which was kind of amusing, though it's not like I learned anything new), but most of the time the paths they print will start from VintagestoryLib or VintagestoryApi and not anything that could contain identifying information. The part I kind of don't get is that if someone really cares about privacy, then that username shouldn't correspond to their real name in the first place, and so there should be no real need to even remove it. Unless maybe that someone is really concerned over the same username appearing under multiple accounts that they have, allowing to link them together, but at that point it could probably qualify either as paranoia, or as using a sensitive work PC for the wrong things.

Part of this is probably already solved with the storage vessels that you can find in a few rooms, at least two of which are in the library itself, which you can use to safely store some items are return for them whenever convenient (don't confuse them with cracked vessels, and note that collapsed chests, unlike the ceramic storage vessels, don't allow to place items back into them). I think it's also possible to place items into display cases, though I recall that there were some related shenanigans as well. Regardless of all that, I do broadly like this suggestion, as it would be a global solution impacting all story locations including future ones, avoiding the requirement to deliberately place specific items in other locations for gameplay reasons. And I have to appreciate that you've immediately pointed to what is largely the crux of the issue in items which have hitboxes. What follows here is more of a general discussion. A few adjacent topics have bounced around the forums quite a bit recently, though with less focus on inventory management. I think that this summary of various ideas by @Bruno Willis is a pretty good outline of roughly where we landed (my apologies for kind of throwing a bunch of text at you like this, please don't feel like you have to read through all of it to contribute). My personal suggestion on this topic (closely related to the recommendation at the end of that summary) was to introduce a small class of "portable" items which could be placed in claimed areas, with some restrictions (implementation-wise it would probably just be a simple behaviour). They could be automatically broken if in the way of some machinery or otherwise blocking or obstructing something (could be made temporarily temporally unstable when enemies get too close), and they may get automatically collected back into the player's inventory when they walk too far away. This category of items may include some light sources like torches and lanterns, bags (i.e. backpacks and so on), the firepit or some sort of a portable stove, maybe a bedroll of sorts, optionally ladders (though they may make access to some places too easy), perhaps bombs and other traps (griefing would have to be addressed). The goal in the original discussion where I posted this was to allow the player to perform some basic survival activities and implement intuitive problem-solving methods that they're used to from outside of claimed areas, without giving complete creative freedom. It would make a lot of sense to include most if not all ground-storable items (e.g. bowls as you've mentioned) in this category of portable items as well, especially since there's a bunch of them already present in claimed areas and they can be freely collected but not put back. The difficulty for the devs comes mainly from the fact that this could require placing a bunch of extra checks and conditions in various places of the code, to ensure that the items don't disrupt anything within the story locations, which may heavily complicate some logic if not done carefully. There's also a few potential risks depending on the functionality of items that could be placed in claims, like inadvertently allowing to skip some mechanics or bypass barriers, or encouraging some sort of cheesy combat strategies. In certain cases it may also be necessary to allow clearly distinguishing between items integral to the claimed location and those placed by the player which can be picked back up. Those issues are all solvable, of course, but nonetheless require a bunch of work on implementation and playtesting that the devs may or may not want to undertake.