MKMoose

If you can read code, the entire logic related to rooms seems to be here. While I'm not certain about the exact way it scales with room size, I doubt that computational cost is an especially significant factor in the current limits, and stylistic choice seems like a viable explanation. But either way, if you think it could be beneficial to the game, feel free to make a suggestion regardless. People here aren't typically familiar with the code at a low enough level to explain whether a suggestion is technically viable outside of relatively obvious cases, and they tend to care more about matters like gameplay enjoyment and thematic identity.

It shouldn't normally do that, unless you're in the middle of a temporal storm, in which case it should return back to normal after ~5 minutes on default settings. If you didn't have problems before but are now noticing that the area is unstable, then a common culprit is that you're in an area of patchy stability - some spots stable, some unstable - and just didn't notice that earlier as you were moving around in nearby more stable areas. If it's not a temporal storm and not an area with patchy stability, then the only reasonably probable causes that I can think of are mods or a bug. If you're using mods, then you may have to check which of them causes the problem and disable it (make sure to test things on a backup world). If it's not caused by a mod, then you may want to try reporting a bug on the issue tracker. Either way, there's a couple things you can also do if you don't want to just entirely abandon your current house: use the house as a storage building or for any other function that doesn't require you to stay there too long, and make sure you spend most of your time in more stable areas (only feasible if there actually are sufficiently stable areas nearby), use the /worldconfig temporalStability false command to disable temporal stability as a whole (will disable the entire mechanic, including underground instability; needs a world reload to take effect), try a mod like Stable Surface to disable instability on the surface only (best make a backup of your world beforehand).

A new player doesn't need to hyperoptimize, but they also don't need to spend time and resources on a denser search pattern that doesn't help them in any way. For iron specifically, sinking a shaft every 12 blocks takes 16 times more effort than at 50-block intervals, while providing maybe 10% more iron per unit of area on average. Even if you don't consider the average over a larger area, then searching more sparsely will still allow you to find the first deposit much faster. Hence the 50-block interval recomendation for iron. Even at 25-block intervals in a generic case for all ores, the maximum deposit radius that can be missed is ~9, barring partially obstructed deposits and stuff. It's trading a small amount of missed resources from the smaller deposits for a large increase in time efficiency. It's covering the same area with a quarter of the effort for ~60-100% of the total return in most cases (60% for very small deposits, and close to or exactly 100% for larger ones, especially iron). Hence the 25-block interval recommendation for most ores. There are a couple of relatively common ores for which I could potentially recommend mining at intervals below 25, including for cassiterite, bismuthinite and sphalerite, but even then you're generally not trying to precisely strip the area of every single deposit either. Still, an interval of ~18-20 is perfectly fine with fairly low or near-zero resource loss for almost all ores, while still being significantly more efficient than 12-15. Gemstones are probably the only notable exception for which an interval of ~12-15 could be optimal, but that's irrelevant for most players. Child deposits are also different, but that's a completely separate search pattern.

The average radius of iron deposits is 26, and I'd have to double-check the exact distribution. Add the node search radius to that, and you'd have to dig every 2 * (6 + 26 / sqrt(2)) = ~49 blocks to make it ever possible to miss the average deposit in optimal conditions. It is still possible with a 50-block interval to miss deposits which are smaller than average, but the risk remains low at ~30% for the minimum possible radius of 16, if I recall correctly. Any obstructions like cracked rock might sometimes cause issues with this strategy. Uneven and patchy deposit edges also make missing a deposit a bit more likely, but not by much. I think it was 0.85 of sea level, last I checked.

That just means the density, though, nothing to do with area. The numbers correspond to the expected density at the exact location of the reading. For example, your 2.13 permille hematite reading means that this general vicinity is expected to contain about 2.13 blocks of iron ore per 1000 blocks of rock (it is only calculated based on a 1x1 rock column, to be specific, but I'm probably not gonna explain the exact code behind it).

The devstreaming channel on the discord, or directly Elvas' Twitch for the building streams specifically.

Skipping only 12 blocks makes a very dense pattern. For most ores, you can generally dig shafts at 25 block intervals, while for iron you'll be fine with 50 block intervals. Additionally, iron ores (and most other ores) only generate in a specific depth range. You can expect to dig ~15-40 blocks down (depending on your surface level) before any iron can spawn, and then it can generate practically all the way down to the mantle. I tend to dig shafts to the mantle for many ores, just to be sure. The density search returns the expected density at the exact point where you take your reading, at the location of the first of the three blocks. I don't know what guide you might have gotten this "1000 blocks" from, but it's not correct and I don't think it ever has been. There's a lot of more or less misleading information floating around about some mechanics, to be honest. It only corresponds to the internal chance that the game uses to generate the deposits. However, for many ores that chance can exceed 1. For example, if the chance in a specific chunk comes out to be 4.5 (it's just an internal number, you can't see it in-game anywhere), then the game is guaranteed to attempt spawning 4 deposits, and has a 50% chance of attempting another. Attempting to spawn does not equate actually generating a deposit, because most deposits can only appear in a number of specific rock types. Either way, for many ores, a high enough reading is practically a guarantee that you're gonna find something in every chunk where there is enough of the appropriate rock types (iron can have this problem in low-density areas, and I could give you the exact ores for which it's especially random). For hematite specifically that internal chance will never exceed 0.5 if I recally correctly, but the sheer size of the deposits largely makes up for it. It has caused a few discussions in the past, where people felt like the system was wasting their time. Mostly nothing came out of them. While the system has some theoretical edge cases, it ends up working out perfectly fine for most people. It could always use some improvements, but it doesn't seem to be a pressing matter.

I think in most cases it's less "hate parkour" and more "can't be bothered to suffer through this particular course". On my first run through the tower most of my frustration stemmed from issues that weren't even directly related to the parkour itself. The glider has a different activation condition from a regular jump for some reason, which caused me to plummet to the ground a couple times where I expected to jump normally, after which I just ditched it and didn't bother bringing it to the tower, which then made falling a much greater risk. The elevator's functionality wasn't particularly clear, and I initially thought it was just decorative because nothing I did would get it to work (could just be user error, but I tried a whole number of things initially and didn't pay too much attantion to it after I started ascending the tower, leading to not noticing until after two or three deaths that I have to set the height manually). It also didn't help that the earlier sections took me more time than I would have liked, which was partly a consequence of not having brought a lantern with me, and caused me to have to choose between rushing some parts of the tower and going the 15k blocks or so back home empty-handed. On the whole, I died I think 4 or 5 times then, every single one to gravity, and the biggest threat besides gravity turned out to be hunger. I'll also note that the player has little way to know what they are even supposed to look for in the platforming sections. Personally, I ended up skipping the last floor, because I just couldn't find a way to do it and was already kinda rushing due to multiple deaths and depleting supplies. One of the biggest issues for me was unironically that I was expecting to have to climb the rubble of the tower walls more, and not random pipes, boilers, machinery, chests or whatnot. If I were to point to one issue with the tower, it's that there are too many sources of pressure on the player that compound into an experience which tends to be more frustrating than it arguably should be, especially in the first and currently only major platforming section in the game. It's a long distance away, takes a fair bit of effort to get to initially and it's an unfamiliar environment unlike practically anything in the game which needs getting used to, the land claim is pretty inconvenient, there's hunger, other sources of time pressure like incoming storms or winter with all the preparation for it, high risk of fall damage or death (especially fun if you don't set your returning point near the tower and have to run back the whole way), and the bird constantly screaming doesn't help either. When I returned to it later in creative to analyze it more, I speedran the tower itself in 3 minutes on the first attempt using the intended route which I was figuring out easily on the fly, simply because I didn't have nearly the same pressure on me. I actually think the platforming itself is really easy in isolation, but it's quite challenging to figure out the correct route under stress. One thing I'm unsure about is how to communicate the alternative option to the player and balance the two between each other. A clearly broken or deactivated part is not necessarily a bad idea, but then 1) why is it broken in the past and 2) how do I know what to do to fix it? A diegetic "requires power from external generator" or some similar sign would probably be suitable, or tracing power cables or something could also be a thing. It may then be difficult, though, to make anyone ever attempt the parkour if the game practically tells them to use the elevator. A common strategy in game design is to introduce a mechanic in a risk-free environment first, before progressively adding more complexity, more dangers, iterating on the mechanic and combining it with others, and finally coming to a conclusion with some sort of final level or boss. The tower has been designed really quite well with this in mind for the most part, but the added pressure from multiple sources can easily make it feel like the "learning" portion is practically nonexistent and it goes almost immediately for an extended final challenge. If I were to give a single suggestion for it, it would be to actually keep the tower itself mostly or entirely unchanged, but add a similar platforming section earlier into the game (potentially also making use of the time switch mechanic or something similar), in a way that would get the player more familiar with what they need to do in a lower-stress context. It could be an earlier part of the second story quest, or it might be entirely unrelated. I thought about giving the player a random platforming or puzzle room to solve each time they die, or a static pocket world which contains some optional challenges, but that may or may not be a good idea. If not something too out-there, then it might be a good idea to revise the section under the tower, to more naturally introduce the platforming mechanics before adding the threat of fall damage and the bird. This might be associated with increasing the threat from the bird to make it more central to the challenge.

One of the things I really don't like about these new huts is that they throw the idea of being reasonably replicable by the player completely out the window. They are almost entirely made using complex chiseling, with many items which are outright unavailable outside of creative mode, and using techniques which are quite difficult for the average player to figure out even in creative. I find that most if not all features of the VS Roofing Mod could be integrated into the game. Or if not that, then simplify the system by adding a couple roof frame blocks similar to current roof blocks, on top of which any types of shingles and stuff could be placed. A couple of shingle position and type presets could defined by the frame, while the shingle model could be independent and defined by the material. This would make the system much more expandable, as well as get rid of the solid undersides in favor of a more reasonable stick or timber frame, which would keep the roofing material entirely or mostly invisible from below and could be matched to the build much more freely using different wood colors. Adding some dynamic elements would be great, including potentially automatic corner pieces and different slopes, but it doesn't need to be particularly complex to be a massive improvement.

I think introducing more complexity to the farming system through new or revamped mechanics like moisture, nutrients, soil pH, seeding, weeds, plant diseases and pests, different growth systems, complex processing methods, and player nutrition, all could do a lot of good for crop variety, with one condition: the properties of various crops would have to be different enough to produce tangible gameplay differences in how these crops are cultivated, and to introduce more meaningful factors into the player's decision-making. If need be, some mechanics, especially diseases and pests, could be made only relevant for a small subset of plants, to make them stand out as more difficult ot risky without impacting the rest of the farming experience. Oats, for example, grow thick enough to outcompete many weeds, are fairly resistant to diseases, and tolerate low-nutrient and acidic soils - this could give you a reliable, low-maintenance crop which can be set up quickly at the start of the game as the player is rushing to get things done before winter, and later on still can be useful to guarantee a safe harvest even if the player leaves on a long expedition. To counterbalance the ease of farming, oat could have reduced yield or be in some way restricted in its uses, potentially even going as far as to make it exclusively usable for porridge (and probably animal feed as well). And for a couple more examples: wheat is much more demanding on soil and relatively vulnerable to diseases and pests (at least nowadays, I would need to double-check if that also applied to spelt in the Middle Ages), which could make it a high-maintenance, high-risk, high-yield late-game crop, rice requires a lot of water to grow and would likely end up as a crop with special requirements (if only just extremely high moisture), which would likely only grow on paddy fields (a specialized type of farmland, or a condition applied to farmland by flooding it in some way), potatoes could provide low nutrition but high satiation, to serve as a good early-game subsistence crop but ending up less desirable when optimizing for full nutrition bonuses, soybeans and other legumes can improve soil fertility by fixing nitrogen, which could make them valuable for optimizing crop rotation and maintaining good soil quality without using fertilizers. The potential issue of overloading the player with all the variables in a complex system could be largely addressed by making several mechanics only really relevant for specific crops and potentially even entirely disabled for others. Ideally, simpler plants like oat and several common vegetables should still allow the player to quickly understand the basics of farming and sustain themselves easily enough, but a larger variety of more demanding and rewarding crops would allow not just to fill out the cellar with more stuff and make more colors of food, but also to produce more meaningful gameplay variety depending on player choice and a number of other factors. It could also be beneficial to make several crops or even entire mechanics opt-in to reduce the number of choices thrown onto the player, e.g. by restricting certain species to only be purchased from traders or domesticated over multiple years from less demanding but low-yield wild plants. Especially applies to something like cabbage, broccoli and cauliflower, which all originate from the same feral plants. Looting from ruins is largely fine as well, but still risks throwing these plants onto a new player quite quickly.

Titanium was first discovered well after the time period that Vintage Story is set in. The Kroll process is a 20th-century industrial process - if anything, expect something closer to the Hunter process. Titanium's real-life applications are almost exclusively a consequence of modern technological advancements and it wouldn't be feasible to use it for late medieval or early modern armor or weapons even if it was known and available in appropriate quantity. If we ever see significant applications for titanium beyond the current use of ilmenite in refractory bricks, it will almost certainly be Jonas tech or some highly specialized applications, not as the next generic metal tier. Tyron has said in an interview a while back that there is no plan for any more metal tiers beyond steel, except perhaps stainless steel and some specialized types of steel for specific purposes. Titanium could feasibly be used as an alloying element then. Why 100k? There were already complaints that the structures are too far, at which point they were adjusted and are now a more reasonable distance away. There is zero reason to move them completely out of proportion again, and they will stay a couple thousand blocks apart. If that doesn't satisfy you, the distance between story structures can be adjusted in world configuration. Cast iron is a pretty common but also a pretty big request, and it's very likely to be implemented sooner or later. A number of mid-game items could be produced from it, like cookware, stove, fences, gates, lanterns, decorations, pipes or chutes, certain tools. I think it would have to be a primary feature of one of the major updates. While it would be technically possible to just add crucible cast iron, I would consider it more likely to come with a blast furnace, potentially pulling with it a separate setup for non-ferrous smelting and sand casting, as well as a finery forge for wrought iron. Additionally, I wouldn't expect significant new features related to metalworking until the temperature system is overhauled, which will hopefully be the next major update.

A lot of this could actually be done in a neat, believable way, without some fantasy ruins and contrived lore explanations, because the sea level does not need to have been historically constant. It could serve as a really interesting plot point that the sea levels have increased after certain events, leading to many ruins of the old world (especially larger towns near rivers and oceans) getting submerged underwater. Would require a bunch of changes to world generation to do it well, but I think it's nonetheless a pretty cool possibility.

The general idea has appeared a couple times in various places. The consensus from what I've seen seems to be that it would be great for the game but should be at most two blocks if added at all (Hytale allows to mantle even higher, up to 4 blocks, too high for VS), but some sort of climbing gear could also be introduced as an alternative to carrying ladders everywhere. I don't know if I'm a fan of painting realism and fun as somewhat exclusive. People don't really know what caves should look like, they have some level of suspension of disbelief, and there is precedent with other elements of the game which are somewhat unrealistic for the sake of fun while remaining believable. I think it's entirely justified to take caves informed by real speleology and adjust their size or potential rewards to tailor them better to gameplay conditions. I think an overhaul is in order sooner or later, because the current caves are both unrealistic and unfun for many people. And my personal diagnosis for that lack of fun is that they're for the most part just boring and pointless. The vast majority of caves you'll ever see is just roughly circular tunnels snaking around and sometimes intersecting in annoying ways with little justification or purpose. Once you go into a cave, you're usually much more likely to run into a dead end than to find anything particularly interesting, neither visually nor for gameplay reasons. That's my experience, anyway. Tyron has talked in the past about making caves better and more realistic, and said he would like them to be more messy, moist and geologically varied, or something in that vein. "Richer caves" are also on the roadmap, so I have pretty high hopes for it. As for ledges, I would first consider creating them with full blocks. They're a pretty neat idea, but I don't think it's necessary to add special blocks for it, especially not as long as a potential larger overhaul is likely at some point. Birds are a really cool idea. On the topic of Hytale, though, I think their birds are honestly pretty awful. Not even counting their appearance and just looking at behaviour, many of them, including ducks for some reason, literally just fly around pointlessly high up in the sky and never seem to land. With that off my mind, yeah, I think birds with appropriately varied and ideally context-dependent calls are one of the most effective elements for natural ambience. This kind of scenario is pretty much how signature moves end up working in Hytale for several weapons, but particularly for the Battleaxe. It has a whirlwind-like signature, which practically guarantees that you're gonna have to heal afterwards, if you even survive, especially if you try to use it in a group of enemies to optimize the damage. At least that's the impression I'm getting in the early game. Either way, I do agree that Vintage Story should stay more grounded. There's still a lot of cool alternative actions that could be added to various weapons while remaining realistic enough, like a generic shove, a versatile polearm buttstroke, risky consecutive strikes with the falx that reward careful but commited attacks, something of the sort.

There are also some items (one that I've noticed was the forgotten noble mask) which aren't even disabled correctly under armor, which causes them to clip through it. It can be a tricky matter on a technical level, because sometimes it's really just a case-by-case issue. In many cases you might want one part of a larger item visible, but a different part hidden. In some cases you might ideally even want two items to appear in different order based on context, e.g. a shirt could be tucked into the pants while you're wearing a coat (it's probably not relevant to armor, but nonetheless part of the same general system). Another issue on a technical level would also be that some items may need multiple models (or at least slight changes to scale) depending on what they're worn on top of. A hat might look good on your head, but could be too small to appear over a helmet without clipping. Those issues are all fixable, of course, if time-consuming. I do agree that a lot more variety would be great on top of armor. Even if not something particularly large, then at least some more smaller items and symbols that would allow to identify a person in armor based on anything other than their nametag. To keep things simple, I wouldn't mind to keep it to items that are intended to exclusively be placed on top of armor (especially a surcoat, tabard etc.), but a more comprehensive overhaul of the clothing system could be beneficial in the long term as well. That said, I think that the existence of armor types which can be worn at little to no detriment could be considered to be the primary issue. It's convenient, but it removes all the incentive to ever take that armor off, except when putting on heavier armor when expecting combat. Whether that's addressed by adding more debuffs to armor or adding some buffs to regular clothing, the player should have more reason to wear regular clothing and not armor while outside of combat. Of course, that doesn't come without its own issues, but it's genuinely detrimental to the game's outfit variety to wear armor literally non-stop. One of the things that could be done to address this to some extent as well could be to localize surface threats to specific areas, making combat encounters more voluntary and letting players feel safer without armor. Adding more creature sounds is a simple improvement as well, and limiting aggression alongside adding more warnings before enemies commit to an attack could also reduce the deaths due to unexpected attacks.

I'm not sure if less than 21 peat is possible. While I haven't tested it personally, I've looked it up recently as I had the same question and found this Reddit post which states that 21 is the minimum. I don't think that the entire post is up to date (the piles ignite each other much more easily), but at least the minimum required fuel should be correct. What's interesting is that the JSON definition for peat says burnHoursPerItem: 0.5 (equal to 60 s), which would suggest that 22 peat is the minimum. Clearly, you've managed to only use 21, which requires an average burn time of ~63-66 s and ends up consistent with that Reddit post. I wasn't able to find the cause for this discrepancy. Oddly enough, the temperature of the items inside the beehive kiln is for all practical purposes entirely irrelevant. As fuel burns, an internal progress value gets incremented linearly based only on burn time. If the fuel stops burning or the kiln door is opened, progress is simply retained. Redram has mentioned that they may revise the beehive kiln's mechanics whenever a larger temperature overhaul comes around: Generally, it's not possible to optimize the fuel consumption in "normal" ways, because the "normal" minimum is simply dictated by the burn time necessary to complete the process. If you want to optimize it further, it requires to basically exploit some flaws in the code. The simplest thing that should work is to pull out the remaining fuel as soon as the process finishes, before the last unit of fuel is consumed, saving you one item of fuel per tile. There's even a horribly named bug report for it. Or, if you're interested in this kind of exploit, it seems to me based on the code that it's possible to fire the kiln while spending zero fuel by simply removing the fuel (all of the full piles) before an individual item of fuel gets consumed, then readding and reigniting it. It should be easy enough to test in creative (I might do just that at some point later), and it would warrant a bug report if it ends up working.

The total loot is the same for all falxes. Anything that the falx rips out is taken away from the main loot pool. That's why monsters killed with a falx are sometimes already harvested. That said, having a slightly higher looting chance with damage or depending on the target's maximum health could be pretty useful regardless, since currently it's pretty common to still have to harvest weaker enemies despite having killed them with the falx.

Is it on the same device that you used before the break? Normally it should only require you to log in once, after which you're free to play offline. If I recall correctly, it's more like verifying a device than proof of purchase. It caches data on the device, so a different device would need to be authenticated separately.

I would be inclined to agree with this if we didn't have fruit trees, Mediterranean cypress and fern trees already in the game. Fair enough, though I feel like gameplay balance, visual appearance and technical implementation can be separated, even though they aren't entirely independent. While any changes to how they grow will inevitably affect balance in some ways, I mainly dislike fruit trees being 1) very similar to each other and 2) completely separate from regular trees in multiple aspects.

Switching to creative may have just been to place the torches. Would be really annoying to light that up otherwise. I'm not sure, but as far as I can tell based on skimming over the cave generation code, it could generate naturally, because: caves are generated in a recursive function, one segment one after another, the width of each next segment is determined by the previous segment, size changes are applied purely based on chance, and it's theoretically possible for several of them to stack over a couple subsequent segments, large caverns are generated by multiplying the previous segment's sizes by a large number, the algorithm does some things to roughly keeps cave sizes in check, but there doesn't seem to be a hard limit (unless it's asymptotic). So it seems to me possible that the cave size was increased very quickly over a couple segments, leading to this monstrosity. As for it looking artificial, I'd argue that applies to almost all caves in VS. The caves are generated just by carving ellipsoids (stretched spheres) in rock. While they do get deformed somewhat with random noise, it's ultimately just ellipsoids. Some deformation is also visible in the screenshots, which, when using something like World Edit, would have to be added in separately from simply carving a ball. There's also basalt with a bunch of pretty believable stones and even flint on the floor as well as speleothems, which would have to be added in as well. If it's artificial, then there was some pretty good effort to keep it really quite in line with the actual cave generation. They are really not that uncommon. I mean, you might have to be pretty lucky to find an actual near-perfect half-sphere, but roughly a blob with a flat basalt bottom can appear anytime a cave generates near Y = 12.

There's a couple other 2x2 tree variants, though they can only be found rarely in the wild. I think oak and two variants of kapok. I feel like trees overall deserve an overhaul. Hytale's trees are arguably better in some ways, but have a few problems as well. There's so many things that could be improved about them in Vintage Story: they should grow more gradually (not necessarily block-by-block, but at the very least with one or two extra stages between sapling and fully grown), there should be something between full logs and branchy leaves, and it would be much better to have actual branches, not unlike on fruit trees (at least some larger branches, not necessarily a branch for every leaf block) small trees should have thinner trunks, because a young 5 m tree has no business having a 1 m diameter, seeds should fall from trees in the appropriate season in large quantity, instead of just having a small chance to drop from leaves, deciduous trees should lose leaves in winter, all trees should ideally have proper stumps and roots, which could potentially be dug up with a shovel without destroying the dirt, as well aa deteriorate naturally over a long period of time when the tree is chopped down. My hot take of sorts is that fruit trees were a mistake. They are too complex for their own good and create an unnecessary divide between regular and fruit trees, while also somehow ending up very samey. Instead of making fruit trees the way they did, I think they should have gone for a simpler system that could be used for all trees universally. Trees are a really fundamental part of the game, and I think they deserve all the attention they can get from the devs. I'm so glad you're mentioning the feel of the combat, and not the specifics like fantasy weapons and special attacks. It's one of the more common pieces of feedback about the game, and a few other discussions seem to have landed on hitboxes as well as a line of sight and hearing mechanic as pretty important areas to improve first and foremost, alongside the status effect system which is planned for the nearest major update. Adding animations and hit feedback to that seems like a very good idea. Honestly, though, I think a much closer analogue to Hytale over Minecraft or Vintage Story is Terraria. Much more similar gameplay style. Having the same first-person and third-person animations can be pretty difficult, because then both tend to have to make concessions so that both look decent. Many multiplayer games which are designed to use the same animations in both perspectives but prioritize good first-person animations end up janky and unnatural when viewed in third-person. Unless they want to entirely switch to the immersive first-person camera (which doesn't seem good enough at the moment), I would say it's fine enough to keep third-person as the secondary focus for multiplayer and the occasional screenshot or something. It's entirely possible to improve the current first-person animations separately. If the third-person camera were to be improved, then the first order of business is to make it over-the-shoulder and not coaxial, because currently I feel like it's borderline unusable for anything except exploration. It would also need to have some sort of zoom function (e.g. bringing the camera slightly in front the shoulder) to allow the precision required for clayforming, smithing and so on.

You're good, different preference is a perfectly fine justification. At most it's just something to keep in mind when people suggest changes that you're not a fan of. I'm interpreting the temporal mechanics in some sense as postapocalyptic or horror elements, while trying to stay in line with the current game direction as much as possible. It's supposed to be a world haunted by eldritch horrors, after all. If balanced well, a properly dangerous area could easily have clear enough signs (environmental indicators, or if not that then maybe just permanent negative stability), so that you wouldn't have to worry about an area that seems good actually being bad. You may have to double-check an area if it's initially unstable but might actually be fine on average, but you wouldn't get kicked in the balls just because you entered an unstable area at the wrong time when there were no signs of it (except when the player simply doesn't notice inditators which are actually there, that is, but the same can be said about the current unstable areas). Whether the environmental changes are purely cosmetic or more functional, I think it misses the point to liken them to fire from lightning. They are generally supposed to add more flavor to world generation or serve as a mostly audio or visual effect, not be in any way destructive. I personally turn off fire from lightning as well, because it's just not a good mechanic by itself. It would be a bit better if plants or trees could regrow naturally. Effects in unstable areas also shouldn't be accumulative, because they've already had a couple hundred years to accumulate. That accumulation over a long timeframe is why I'm talking about soil composition and different flora and fauna. I would say that environmental effects of instability should in many regards be likened more to something like strong winds during natural storms in the case of momentary instability spikes, or to something like climate indicators (different climates have different fauna and flora irrespective of temporary conditions) in the case of unstable areas. I can't help but keep getting the impression that you're looking at my pancakes and saying you don't want waffles. Or at least saying that you don't want the pankaces spicy for some reason. I might try explaining it better at some point, but for now I think I'll let it marinate. If not this, there's other ideas to improve surface instability which don't get the same pushback.

To be honest, I've never needed any of these myself. That is not to say that nobody has, of course. Maybe I was just lucky enough to never have any particularly large unstable areas in vicinity. I would appreciate a diegetic way to measure stability either way, even if it's entirely optional, and I just think it would be much more worthwhile if added together with other concurrent changes. Even convenient mapping or scanning would probably be quite fine for late-game gear, though, as a natural progression reward. I know. I've myself mentioned the idea to move the UI indicator's funtionality to diegetic devices here and here, which at the time was met with mixed reactions, though it may have been significantly influenced by other context around it. But the fact is that a measurement device, unless it has some advanced functionality like automatic mapping or large-scale scanning, would be almost entirely redundant with the gear. This is primarily because a dedicated device would presumably take some resources to craft and potentially operate, and would have to be carried around and potentially taken out and used regularly, unlike the gear which is completely free and accessible at all times. And even with more advanced functionality, many players like myself wouldn't really need it either way.

I'm of a quite different opinion, as I think the UI indicator provides too much information. While it only allows to inspect stability at the player's current location and doesn't allow to as easily check whether an area is only slightly positive or strongly positive, it nonetheless exactly shows whether the player is in an area with negative stability (anywhere the gear turns counterclockwise) and even allows to roughly gauge how unstable it is (based on how fast the gear turns). You could technically map out an entire unstable area on the map using that gear, though it would admittedly be tedious and would probably clutter your map with way too many waypoints. Creating waypoints with one press of a button using macros could make it much faster, though I don't remember exactly how to set that up. I overall like the idea quite a lot, though I feel like it's largely missing a purpose at this moment, except if an optional setting to disable the gear indicator were added. More in the vein of a geiger counter and less a dubious dowsing device, some tech to allow measuring instability could be thematically very fitting and serve a cool gameplay purpose. However, as long as unstable areas are just permanent zones to avoid and the gear exactly shows whether you're standing in an unstable area, I can't quite think of a good reason for the average player to bother with anything more. I'm not entirely sure about mapping as well, as unlike in prospecting there is almost no hidden information that it could provide. While it's a bit slow and annoying, you can do almost the same with your own waypoints and the gear. Automatic or fast large-area mapping would be convenient and I wouldn't necessarily oppose it, though I'm not sure if it wouldn't be too convenient. Alongside an optional setting to disable the UI indicator or as part of some sort of larger stability rework, I think it would generally be a great addition.

If you get the impression that your base has become unstable when it previously wasn't, then that's likely caused by it being in an area with patchy stability, stable in some places and unstable in others, which may have caused you to not notice any issues earlier as you were walking around nearby stable areas more. Temporal storms normally last at most ~10 minutes (~5 in-game hours), and I think by default you can't sleep through them. Assuming it's not actually a bug, then your gear in the middle of the screen should turn counterclockwise while you're in an unstable area, and progressively become more gray. Cyan gear means you yourself are stable, gray means you're unstable (you can hover your mouse over it to see a percentage). Clockwise rotation means you are in a stable area and your stability is going up, counterclockwise means it's an unstable area and you're getting more unstable. If your stability is very low, then it causes effects visually very similar to storms. More things you can check: make sure you leave the world and load in again after changing the configuration through the commands, as they won't take effect until the world is reloaded, you can use the command /nexttempstorm to check the current storm status (it should say something like "the next temporal storm is in _ days" if storms are enabled but a storm is not active). From there your primary options are probably: disable temporal stability, making sure to reload the world, and continue playing in your current base (this will also disable underground stability), put up with the instability and relocate your base to a more stable area, start a fresh world with this newfound knowledge for a smoother early experience. This is very much what world config implies if not states. If it ever works differently, then it's most likely a bug.

@LadyWYT I kind of get you, but I also kind of don't get you at all. The current implementation of surface instability gives a sense of uncertainty? It's unnerving, creepy, unnatural? Whatever you're getting out of surface instability, I just don't really see it. I can see most of the concerns and can absolutely agree that they would have to be considered when making changes to stability, even if I don't see them as particularly significant issues. However, for surface instability to be in any real way engaging and memorable for most people, I think it simply cannot stay in its current state. Right now it's not problematic, because it's simple and generally inoffensive, but I would say that it goes to the point of being simplistic, as well as annoying when it occasionally matters and practically pointless otherwise. I can't really predict and don't really have a preference for whether it gets a more comprehensive overhaul or just some of subtler changes including those that you haven't criticized, but I do believe that even introducing all of the suggestions I've mentioned in this thread (here) could still retain almost all of the current feel and impact of temporal instability while improving the game with very limited negative side effects. Everything would simply have to be designed, tweaked and balanced with the right goals in mind. I've noticed that when I think up a complex, intertwined system, then I'm sometimes surprised when people predictably don't share the same thought process and underlying assumptions. Feel free to try reevaluating dynamic instability as an extension of rift activity and temporal storms, and not as a direct evolution of unstable surface regions. Dynamic instability would still have a purpose closely tied to the current function of rift activity and storms even if it was a global effect with no local variation. At the same time, dynamic instability could also be tailored to improve upon the areas which currently are just permanently unstable. If that distinction doesn't do anything, then we're probably gonna have to let this topic rest, if only because I'm running out of arguments. Also, there's another small thing, though you can mostly ignore it unless you want to pivot the discussion onto it: I would entirely permit only small fluctuations that would have little effect beyond making existing unstable areas pulse or wobble in a sense, slightly changing size and intensity. It would make them less permanent and allow to stay in intermittently unstable areas without eventually dropping to zero stability. I can understand this quite well based on my experience with some more hostile games, Don't Starve especially. I don't really know how to take it seriously, though, because it's the point of dynamic instability to avoid applying pressure on the player either all the time or not at all, and instead to pace it out better. As long as it doesn't impose routine maintenance or end up with some other major issues, the risk seems quite minimal to me, compared to other similar mechanics. Granted, dynamic instability may sometimes force itself onto the player instead of allowing to voluntarily face the threat, and I would say that's largely just a matter of balancing exactly how much pressure it applies so as to land neatly between being irrelevant and overwhelming for most players, not unlike wildlife, rifts and storms already have to be balanced. Additionally regarding the pacing, whether that comes from UI, environmental clues or measurement and warning devices, you may quite regularly see indicators of instability fluctuations that point to an upcoming spike (or a storm) and keep you on edge, but equally you would be able to breathe for a time if you don't see any signs to worry about. There could even be some relatively clear signs of positive stability, which would let you know that you're in the clear for some period of time. I think it would be a really cool detail to have unique bird calls that indicate incoming storms or something of the sort, or that indicate safety. Real birds relay information using various calls, and even other animals recognize and listen for them (e.g. squirrels will hide when birds indicate that there's a hawk nearby, or something in that vein), so it could be fun to learn and listen for specific calls as part of the environmental clues about stability. I feel like this one goes right back to information availability to an extent, though perhaps diverges more onto a matter of predictability and mental effort. I personally don't like knowing that a wolf or bear is pretty much guaranteed to attack me once I'm within a certain radius of it, and I don't like knowing that it won't relent unless I mechanically force it to. It's generally not as exciting or engaging, plus it doesn't match realistic expectations. I would go as far as to say that it's again more suitable for action-packed games where dispatching individually weak enemies can't take up too much of the player's time and attention. I think Vintage Story would benefit greatly from an approach slightly closer to something like horror games, where the goal is often to avoid or potentially outsmart the more dangerous enemies, and calculated risk is a much more prominent element of combat. This especially applies to bears, which would arguably work much better if they weren't as threatening at all times, but potentially even more dangerous than they are now when provoked. It would encourage the player to be more careful and to respect their space, but without the threat of immediate aggression. If not make animals more aggressive in unstable areas, then at least more alert and more hostile or defensive, with growls or other warnings, but overt aggressiveness remaining the same or even decreased until provoked. Besides matters of aggressiveness, erratic behavior could also refer to more audiovisual aspects with less impact on gameplay, something like: more frequent and more distressed animal calls, frequently looking to the sides and changing direction when walking, generally restless movement - walking more and stopping for grazing or whatnot less often, occasionally running around with no clear reason, and so on. Certain indicators, including most changes related to soil and plants, would work well when purely tied to average stability, as a way to more easily tell whether an area is generally and not momentarily unstable. Certain other indicators, like particle effects in the air, unsettling ambient sounds, and perhaps erratic animal behavior, would serve better as signs of incoming spikes of instability. It kind of goes back to the two different purposes of dynamic instability - one closely tied to rifts and storms, and one related to unstable areas. For the most part they should be easy to program by just adjusting a few parameters based on current stablity - the main difficulty comes from the fact that, ideally, every single animal in the game (or at least most of them) would have to be tweaked. I know, but I see it as an extension of rifts, which are described in the handbook as "portals to the rust world". And either way, if monsters can come out of rifts, then why not something much smaller that would affect soil composition or have other downstream effects?