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.