MKMoose

Two questions would help narrow down what this is: Do you know whether the rift activity changed recently? Monsters spawned earlier will linger for some time even after rift activity turns to "calm". Do the monsters include drifters, or just bowtorn and shivers? I've found a bug or oversight recently which seems like it allows bowtorn and shivers to still spawn, so there's a chance that this is what you're experiencing. Naturally, this issue did not exist before bowtorn and shivers were added in 1.20. In general, calm rift activity should ideally prevent all new drifter spawns on the surface, though bowtorn and shivers can still spawn rarely due to a bug as far as I can tell. When they do spawn, it is expected that they might walk out of caves, or occasionally spawn under very large trees which might be less intentional. World stability has no effect, except by proxy through the player's own stability. Please try to keep in mind what I told you in the other thread here. Rift activity only has effect on surface and deep drifters, so its impact is significant at Y > 0.55 and gradually becomes less meaningful until is essentially irrelevant at Y <= 0.22.

I'm unable to fully reproduce this in 1.22.7, but it does seem like there might be a bug. Possibly worth reporting on the issue tracker. The footsteps are audible regardless of how I turn around, but they do seem like they're quieter when directly behind the player. Besides these sounds being awfully quiet, note that part of the reason for issues with their audibility is that: bears' footstep sound range is 15 or 25 blocks when they're walking running respectively (note that this could be modified by mods), bears' seeking range is 16-30 blocks depending on context (this is the range from which they start chasing the player), wolves' footstep sound range is 10 or 15 blocks when walking or running respectively, wolves' seeking range is 15 or 25 blocks depending on temperature. So you'll notice that a lot of the time you will only hear them after they've aggroed and started chasing you.

The fact that a solution doesn't somehow also fix entirely unrelated problems or that it doesn't remove a potential challenge which doesn't need removing doesn't make it a bad solution. Why would you even want it to achieve anything of that sort? Similarly, a solution having some potential problems is not particularly relevant when those problems are entirely conditional on its implementation being poorly designed or buggy. Player corpses have one primary purpose, and they achieve that purpose flawlessly. Most items will not float, including bags with whatever is inside them - that depends on their density. And even if items did float, I see no reason why a corpse shouldn't float to the surface as well.

You can also just do a fallow rotation without pointlessly replacing or fertilizing the soil. Leave the fields empty for however long they need to recover - having to clear the grass afterwards is the only potentially meaningful drawback. If necessary, use a couple separate fields and rotate between them for better short-term food security.

VS has had many New World plants and animals for a long time now. Botanical definitions are irrelevant to nutritional categories, and the devs have said about as much. For the distinction between vegetable and grain, cassava has created the precedent for grinding a vegetable into flour to make it a grain, so if that's not an oversight then corn can follow suit.

Hence why there's a "keep inventory" option available. [...] That's an overcorrection, though. "Keep inventory" does keep the items safe, but also removes the primary reason for the runback. It can turn dying into the optimal, quick way of returning back home from a trip, unless another death punishment is added. A religious shrine which takes offerings of food, blood and riches (or whatever selection is deemed most appropriate) seems like it could be a perfect fit for Homo Sapiens. I like this general idea a lot. On the whole, by the way, arguably the main benefit of such a structure or block would just be the quality of life. The current charge level would be easily visible. The respawn location would be a nice and immersive thing you can see in the world instead of a hidden value remembered by the game. It could be charged beyond the capacity of a single gear, which would be especially convenient when playing with a low number of respawns per gear. It could be used simultaneously by multiple players. It may also be more intuitive to allow the player to keep multiple returning points charged and respawn in the nearest one. Multiplayer concerns could make it less straightforward. Frankly, I like this less and less the more I think about it. If it's just an optional toggle then that's fine, but to me it just feels like a bandaid to a more fundamental issue. When you think about two options: respawn the player in an arbitrary location near world spawn, try to respawn the player near where they likely want to be, then I just see very little reason to intentionally select the first one. The only thing I can think of is that the world spawn is a more consistent and predictable location which may sometimes help players find their bearings or find each other in multiplayer, but I'm not sure that the drawbacks are worth it. The length of the resulting runback is unlimited which can end up disproportionately punishing, and it discourages early-game travel in favor of just settling near world spawn. Simply giving the player a temporal gear doesn't fundamentally change anything about the base respawn mechanic. In the best case scenario, it makes the world spawn quite literally irrelevant for the purposes of respawning - nearly as irrelevant as cheap respawning that uses something other than temporal gears could make it. In the worst case scenario, it ends up much more frustrating than the current mechanics, because when the player expects that they can set their own spawn point once they find a great place to settle, then it is only more frustrating when that expectation is unmet if the player happens to die before using the gear. And no, making the gear into an amulet doesn't help if the player still has to either run back to their lost items, or start from scratch which they could also do on a new world. I feel like this is a problem which you can't properly solve with respawn mechanics, just because it's a problem which isn't really caused by respawn mechanics, or arguably not even related to them at all. It's more so caused by the fundamental incompatibility between one-of-a-kind story locations and a practically-infinite procedurally-generated world. One potential idea is to adjust how the story quest starts. Somewhat spitballing here, to be clear. A treasure hunter could initially send the player to some kind of relatively small ruin, which would spawn much like standard ruins unrelated to the main story. They could have ~10k distance between them at default settings, so that travelling to the nearest one is similar to travelling to the RA. They should be relatively inconspicuous and difficult to find accidentally. They should also be notable enough to justify having a bunch of Jonas tech or temporal shenanigans there - possibly part of some kind of translocator network. The ruin could have a special translocator in it, or a temporal anomaly, or something of the sort. Through this translocator or whatnot, the player would travel more or less directly to the RA, or at least to world spawn (though if something like this is introduced, then the RA alongside other story locations could technically be moved to a near-arbitrary location instead of being generated relative to world spawn). Naturally, some way back would be necessary - and that is frankly a much bigger challenge to design, because it needs some way to return the player to where they came from. Turning the RA into a hub-location of sorts or creating one from scratch could be interesting, but could also be argued to be pretty overpowered due to the direct translocator links at arbitrary distances, which may have to be limited by only allowing players to only return to the entrance which they last entered. A much simpler option could lie in creating a one-time portal back to where the player came from which only that player can use. Extracting the idea for a translocator network into its own thing, it could make sense to actually create ruins of a translocator hub near (possibly under) the world spawn, which could also somewhat justify why the player spawns there. Related ideas include adding player-craftable stuff, possibly crafted from components obtained from that small ruin. Either translocators (for which the world spawn could function as a valid target), or something akin to the terminus teleporter and base return teleporter which can take the player to and from world spawn in some way. You might notice that all of these ideas involve teleportation or similar methods of fast transportation, and I would be genuinely interested to hear any reasonable solution to the problem which doesn't involve that.

Here's what I got from a quick creative test in a flat world, so that maybe the argument might turn ever so slightly more objective. Times are very approximate, not precise measurements. Tower height: 64. Distance covered with the glider, jumping from the 64-block tower: Trying to stay up in the air longer: ~200-250. Diving quickly first to gain speed, then flying horizontally right above ground: ~350. Time spent flying: Flying: ~8 s (very roughly, may depend on the method). Building a new tower: ~30-35 s. Getting up the tower using ladders: ~30 s. Running up the tower using stairs: ~12 s (this adds a 64-block horizontal distance as well, and assumes stairs going in a straight line - curved stairs will make the player slower). Time spent travelling 100 blocks: Running: ~15 s (~6.7 m/s). Running on an elk: ~9 s (~11 m/s). In the optimal scenario, running 64 blocks up using stairs and flying 350 blocks allows to travel ~400 blocks over ~20 s, which is ~20 m/s - this is close to double the speed of an elk, so it's very fast, but the setup cost of something like this is very high. Both the glider and the elk will be slower in practical situations, but the general proportion will remain similar. But in a less optimal scenario when building a new tower or using ladders, you end up with up to ~350 blocks over ~38 s, which is ~9 m/s - slower than an elk. Even compared to running, over which it's ~30%+ faster, I think the necessary setup makes it not worthwhile for most purposes. Note: I've briefly tested gliding from other heights, and the flight distance seems like it ends up roughly proportional to the total height. I haven't compared to the sailboat, but it apparently goes ~6.7 m\s, around as fast as a running player. My own conclusion: The glider can be a very useful way of traveling, primarily over short distances, if you set up a fast method to get at least a couple dozen blocks up.

Except Nekkowe did from the start. What other block games allow you to set your spawn point with a bed? I'm curious. "They mentioned Minecraft because they mentioned a bed spawn mod" is a truly extraordinary leap in logic. Terraria released with bed respawns just a couple months after Minecraft had them added. Since then, it's been a common, simple and intuitive mechanic found throughout the survival genre. Rust, ARK, Conan Exiles, Raft, Grounded, Valheim, Hytale, and many others. Suggesting that mentioning bed respawns is functionally equivalent to mentioning Minecraft exposes your own biases more than anything else. To mention that bed respawns would have to be implemented differently than in Minecraft to fit VS? That's fair. I don't see the point of bringing up Minecraft, but I guess it's popular, and a fairly common comparison point to VS. To assume that the person frustrated with the current respawn mechanics and turning to a bed respawn mod wants Minecraft's mechanics to be ported over directly with no changes? Absolutely not. That's absurd and unjustified. Yeah. Minecraft beds detect enemies in proximity, and back in the beta versions they actually used to perform pathfinding logic and spawn monsters in nearby dark areas (I have no clue why that was removed, frankly). Room detection is a thing in Terraria, among other games. Changing the mechanic from "click a bed to set a respawn point" to "sleep in a bed to set a respawn point" is also a pretty obvious tweak. And that's how it worked in Minecraft prior to 1.15, if I recall correctly. Bears have some sounds with a 15/25 block range when walking/running (with a 16-30 block seeking range depending on context) - those are not terrible, though still too quiet and too low range. But wolves' footsteps have a pathetic 10/15 range when walking/running (with a 15 or 25 block seeking range depending on temperature) and are so quiet that I had to go into the game files to make sure that they are actually there. Even if they were louder, their range is so small that they are almost always only audible after the animal has aggroed. Audio mixing in general is also lacking in VS, with music and environment sounds often masking whatever quiet footstep sounds there are. Do keep in mind that while you can change the despawn timer, you can't change the fundamental problem of items disappearing forever semi-arbitrarily - even a one hour timer is clearly not a guarantee that the items will be safe. What makes this worse is that, if I recall correctly, the timer is not paused in unloaded chunks. And this is another case where the game sets up an expectation that the player will generally be able to retrieve their items (it's easy most of the time, or trivial with a 1-hour timer), but ends up kicking the player in the balls on the off-chance that they don't make it in time. Long runbacks themselves are plenty discouraging already - adding on the pressure of having to get there quickly enough not to lose all items permanently is just unnecessarily frustrating. While the despawn timer can be a necessary performance consideration for dropped items, player corpses are a very simple and common feature which circumvents performance problems, and it's among the most popular mods in the game's history. They are already stupid enough to walk straight into a pit. If that is not satisfactory, you can place food above the pit to attract animals in a 48 block radius. This is, by the way, a prime example of the unintentional side effects I was talking about - by fixing a bug which caused animals not to eat player-grown crops, intended to incentivize enclosing farmland with fences, the devs have inadvertently introduced an extremely effective and dirt cheap way of trapping animals. Overall on trapping, I would prefer to have passive traps be only viable for birds and small game. I think that larger game should be hunted actively, because it just seems like a much more interesting option over waiting for an animal to walk into a pit and then stoning it to death.

You're mentioning rift activity here, though, which is another component of the system that wasn't brought up earlier. Should have probably mentioned that myself as well. When saying that "this is not true" I was referring specifically to "unstable surface areas are more likely to spawn rifts, and unstable areas underground are more likely to have monsters", just so we're clear. Overall, the code relevant for the temporal mechanics can be found primarily in these classes: SystemTemporalStability in TemporalStability.cs (most important for our purposes), EntityBehaviorTemporalStabilityAffected in BehaviorTemporalStabilityAffected.cs, ModSystemRifts in Rifts.cs, ModSystemRiftWeather in RiftWeather.cs. The "ambient" temporal stability affects nothing except the player - doesn't make rifts more likely, and doesn't increase monster spawns. The SystemTemporalStability.GetTemporalStability() function is only called in one place in the entire codebase, in EntityBehaviorTemporalStabilityAffected, and it is used to modify the player's stability. The player's own temporal stability is used primarily in two places: In SystemTemporalStability.Event_OnTrySpawnEntity() to bump monsters to higher tiers at low player stability (only takes effect below 25% stability). In SystemTemporalStability.CanSpawnNearby() to determine whether enemies can spawn nearby. Broadly speaking: low player stability gradually reduces the effectiveness of artificial light sources at blocking spawns (at below 25% stability), on the surface, monsters can only spawn in proximity to rifts, much less frequently during the day, underground, they can spawn regardless of rifts (because rifts don't even spawn underground) - in this context, low player stability has the following effects: at below 25% stability, gradually reduces the minimum distance at which monsters can spawn, from the default of 18 down to ~12.7 at 12.5% stability, at 12.5% stability and lower, reduces the maximum distance at which monsters can spawn to 10 blocks, and ignores minimum spawn distance - this actually greatly reduces the effective spawn rate, since it reduces the spawning area to just a 10-radius sphere around the player. The currently active rifts are only accessed through the ServerRifts property in SystemTemporalStability.CanSpawnNearby() as mentioned above, to check proximity to rifts when determining whether a monster can spawn on the surface. The rift activity is used in ModSystemRiftWeather.onServerTick() to adjust the maximum quantity in the runtime spawn conditions for surface drifters and deep drifters depending on the current rift activity. For some reason, it doesn't affect shivers and bowtorn, so it still allows large quantities of them to spawn regardless of rift activity. And this kind of problem is precisely what makes me say that I increasingly doubt "intentional design choices". How can any progress ever come out of a discussion when the default reaction to criticism of the current system which didn't even bring up Minecraft has to include the mention that porting over that game's system with no changes would be worse than what we have now? You're disproportionately focusing on just one solution and discounting it on the account of being unfitting for whatever you're imagining Vintage Story's design direction to be by immediately assuming that the person who mentioned beds would want them to be implemented just like in Minecraft. No one in this discussion except you two has even mentioned Minecraft. This is what Tyron has said in the latest dev update, and it is very nearly everything we know - next to nothing as far as actual specifics go:

Is it really that difficult to read a sentence for what it is? "Why should it change, though?" - a simple question. "I get that you don't like it, but that's a different question from whether it should be different." - a simple statement. Establishes a level of understanding, but notes that disliking something isn't by itself a sufficient argument for making design changes. "What's actually not working about it as it fits into the game right now, and if something is genuinely broken, how would you go about fixing it?" - a reasonably simple question. Asks to elaborate on the complaints and suggest a more specific direction for addressing them. Frankly, the more I see of the game the less I believe that. There's naturally a lot of deliberate design choices that make the game what it is, but equally there's a lot of old baggage, unintentional side effects, questionable decisions, and yet-unimplemented plans. Temporal storms and temporal stability are a great example - they've clearly been added fully intentionally and had some kind of design thought put into them, but that doesn't mean that every single effect that they have on the game is intentional. They've been almost entirely unchanged since they were added in 1.12 besides the addition of bowtorns and shivers, so the game has changed plenty since then, and rifts are even older. Saraty and Tyron have said in the interview with Mahjong Blonsky (here, timestamp at the question) that storms are far from fleshed out and they have a bunch of ideas on how to improve them, which may address some of the complaints brought up here.

I see people bringing up this idea somewhat regularly, and yet there is so little meaningful evidence for a claim this strong. Direct archaeological evidence for persistence hunting is extremely scarce, because there is no easy way to determine that an animal was first exhausted before it was killed. Even in areas where we have evidence of persistence hunting, numerous other hunting strategies have been in use as well, almost always with none being clearly dominant. Even in areas where persistence hunting is common, it is often used primarily on a specific category of animal species which are worthwhile to hunt in this way, so it is not a universal strategy. Even in groups which employed persistence hunting in a significant capacity, projectile weapons would have appeared early and would have been used to weaken the prey before attempting to exhaust it, somewhat similar to the standard hunting strategy of wolves and to stalking. It takes no genius to figure out that a wounded animal is easier to pursue, and energy efficiency is a huge factor in survival-focused decisionmaking. The primary advantage that humans have is thermoregulation through sweating, not exactly endurance, which means that they can primarily outcompete animals in hot climates but not universally in all climates, which then aligns with where the majority of documented examples of persistence hunting come from. Other ecological factors like clear visibility, open terrain or reliable snow cover that allow persistence hunting to be significantly viable also further point towards it not being the primary hunting strategy in many contexts. Endurance has plentiful benefits outside of persistence hunting. It can significantly benefit even a forager who has never killed an animal in their life. And we do know that many hunter-gatherers have relied overwhelmingly more on the latter part of the term. It is clear that persistence hunting is a real and meaningful strategy, but I don't personally see any real reason to go as far as to say that "humans are famously persistence hunters". It's a popular idea, but not one that is particularly well supported. While this is not exactly part of your suggestion so I'm addressing it more broadly, I want to also note that I kind of hate the idea of giving animals stamina. Because I don't get the point of adding the boring version of hunting - if there is the possibility to implementing mechanics allowing the player to stalk, injure, track and finish off the animal, then I don't understand why it would be seen as a good idea to pick out the most boring step from the whole process and allow to just follow the animal until it starts keeling over from exhaustion. The one feature that I think is sufficient to make hunting better is to implement reasonably realistic bleeding - weakened animals could have dulled threat perception and should probably be a bit slower, but I don't see any need for standard stamina mechanics. Wait, is this part true? I thought this was just one of those mod features people think are vanilla. This is absolutely not true as far as I know. It's part of the reason why I've been harping about temporal mechanics being a disconnected, unfinished mess. The only factor that has any impact is the player's own stability, which will naturally tend to be lower in unstable areas and change how monsters spawn (though it doesn't actually increase spawns directly, it actually effectively reduces them in many contexts), but that's a second-order interaction. I can point you to the relevant code if interested. The ability to set a respawn point can be powerful, sure, but there is no world where that justifies any and all related design decisions. And regardless of all that, you've not addressed the comment that the game somewhat arbitrarily treats the spawn point as a particularly special location, and players are significantly encouraged to settle near the spawn point as a result of the easily-frustrating respawn mechanics combined with a couple other factors. I don't wanna copy-paste a comment from another topic where I've mentioned around ten possible ideas for improving respawning and beds, but I do want to specifically mention one thing regarding giving the player a temporal gear on spawn - when you set up the expectation that the player can run off and set their spawn wherever they want with a free temporal gear, then it's gonna be even more frustrating if the player happens to die before they decide on a suitable location. As a side note, a similar reason contributes to rifts being complained about so much - when you set up the expectation that the player can spend a night in calm rift activity with no monsters, then it only becomes more frustrating when that expectation is not met and monsters do appear, even though monsters are technically less common than if they spawned each night in the same quantity. The boss drops all loot each time it's killed - this is at least partially a consideration for multiplayer servers where it's unlikely that everyone fights the boss at the same time to get a share of the loot. If you settle reasonably close to it, then it can be a very efficient way to farm temporal and rusty gears as well as metal parts and scraps.

Pretty sure that since 1.22 the temperature ranges for spawning use the temperature at a fixed elevation of (if I remember correctly) 1.09, where 1 is sea level (Y = 110 on the default configuration), so it would end up being something like Y = 123. So this one seems like it should spawn fine, though minY: 1.9 is still quite questionable and might make it extraordinarily rare (and 1.9 should be Y = 241, I think?). Other than that the details seem fine at a glance, though I haven't verified them exactly. I can absolutely get behind making a full butterfly collection more reasonably achievable.

It sounds like you're pressing the middle mouse button simultaneously. Double-check what key you have bound to "pick block". It should be the middle mouse button by default. Make sure that you're not just fat-fingering it. Consider checking whether that input is also triggered when it shouldn't outside of VS. Consider rebinding "pick block" to some unused key and see if that fixes it. If it does, then you could technically end there, though you might also set it back to what it was and diagnose the issue further. Try pressing that key and see if that maybe resets it. Otherwise try disconnecting the mouse and plugging it back in. Otherwise try using a different mouse. Or if you're not using a mouse, check whatever device that input comes from. On a laptop, you might want to check whether the equivalent of the middle mouse button input is detected correctly on other sites, and whether you can modify how it's detected.

Why would it not provide satiety? I'm talking about decay reducing the value of food, but not reducing it to zero. Partial satiety, or unchanged satiety but removed nutrition, or both. I've been referring to it as "decay without spoilage", because the point is expressly to make food decay without spoilage, so this counterpoint is almost entirely irrelevant. The original motivation that I mentioned was to make it possible to make unspoilable foods a core element of the game while retaining an incentive to eat them reasonably early instead of just keeping them forever without the slightest worry. Why would it even work only with risk of getting sick anyways? I can certainly get behind something like this, but I don't quite see why anything of the sort should be a requirement. As for not being able to compost unspoilable food, I would also mention that only being able to compost rot and not any organic matter is in itself something that I would want to see changed regardless, because it just doesn't make sense from practically any perspective, not even simplicity in gameplay or implementation. Why wait until your excess food completely rots inside out in your storage containers and only then throw it out? If you don't need it, dump it into a composter - it should be as simple as that for the most part. Whenever I have large farms, I tend to end up making storage for unspoiled food which I have no purpose for, but can't compost yet. If that's the only change you make, then sure, it could increase the time the player needs to spend on food. But why not just counterbalance that change with another adjustment? It is only natural that achieving some kind of design goal should be done while minimizing undesirable side effects. In this case, those side effects are so easy to address that I didn't personally see any need to even bother mentioning them. Personally, what I would be interested to see for meat especially would be to increase the meat yield from medium animals to well beyond what a single player can reasonably eat before it spoils when prepared in standard ways (i.e. raw, cooked, and in some basic meals). Naturally, increase it proportionately for other animals as well, beyond what multiple players can eat in the case of large animals. The specific spoilage time is arguably much less important here than whether the player can eat all of the food before it spoils. Saving meat from spoiling is how drying, curing and other preservation methods would then become an actually integral part of the process and significantly reduce the amount of time that a player needs to spend on acquiring meat in the first place. As long as it's balanced in this way, meat preservation doesn't even need any satiety reduction or anything of the sort from a balance perspective - making preservation properly worthwhile would be a great way to incentivize actually doing it instead of letting the leftover meat spoil and killing another animal. Do note that this is different from seasonal plants and crops in that the player should generally be able to decide themselves what they kill and when they kill with little to no inherent pressure or specific windows. Fruit could be more of a carousel where the player can pick and choose what they want to preserve, and crops likely shouldn't change greatly from their current situation and at most could get more reasonable planting and harvest seasons (e.g. "this has to be planted in spring and ripens in summer", instead of "this can be planted and collected when it's not winter"). As a general rule, I think that virtually all foods should be usable in meals, especially in soups and stews. Fresh, cooked food could get some special purpose in particularly fancy meals. For drying and/or smoking, I would much prefer to have distinct processes, not just cooking again. Especially for drying. My initial thought is that adding both would be quite fine: Air drying could be as simple as leaving raw meat over multiple days in appropriate environmental conditions (mainly low moisture during cold months, although the current game doesn't support that too well), with full air exposure (i.e. ideally on a drying rack in an open space, and certainly not in a cellar). Smoking would use fire, and could be done more easily in conditions and climates less suitable for air drying. An added fuel cost over air drying, but greater reliability and flexibility. A lot of simplifications always need to be made here, because the real factors that affect the safety of drying with the required temperatures and so on are too complex to reasonably implement them, and they would more than likely just cause problems in a gamified environment. As a side note, I think drying, curing and possibly cooking should be reworked into an effect of sorts which is applied onto an item, because having them as separate items largely just adds unnecessary clutter. Possibly also allow to combine preservation methods, which is realistically nearly required to achieve properly reliable preservation. I find that pemmican tends to be extraordinarily overrepresented in suggestions and in media. It's just a single regional variation out of a whole spectrum of related fat preservation methods (which we somewhat have in the game in the form of sealing crocks with fat), so it generally seems too narrow for the vanilla game to me.

I see no reason why decay without spoilage couldn't have an effect on the visuals of the food as well. Some changes to the visuals before food starts to spoil could in itself be a nice new feature for existing items. To say that it would be the same as regular spoilage is also mildly absurd given that it literally wouldn't be the same on a fundamental level, as the food would remain edible indefinitely. A simple though not ideal implementation using existing mechanics could involve either capping the spoilage to a maximum of less than 100% for certain items or converting them to a lower-quality item instead of rot when spoiled, so that the food remains partially edible indefinitely. I have no clue why you're bringing up "focusing on other aspects of the game instead of just food" when the whole point of natural cycles seems closely related to different foods being available at different times and essentially unrelated to how much time the player spends on food in total. You could easily increase seasonality and emphasize natural cycles while keeping the total time that the player needs to spend on preparing foods roughly the same or even significantly reducing it. There's even a fun trick you can do: make a specific food item abundant almost to the point of absurdity, but only available within a very short time. If the food spoils quickly enough, then that strongly incentivizes food preservation to extend its availability and naturally communicates seasonality and imposes food variety through limited availability windows. I know. I've kept them in a cool basement in real life. The point is that if I can eat apples throughout the year with no issues, then dedicated fruit preservation methods like jam or alcohol lose most if not all of their gameplay purpose and end up largely delegated to vanity. I've personally never even made jam in survival, even though I've had honey on many occasions, just because on standard settings you can keep your fruit satiety topped up through the winter, or at least most of it, with regular berries made into pies or something of the sort, not to mention apples.

That leaning to the side is purely visual, though, no? Based on my experience and on the code, horizontal movement seems to be normally just directly equal to the input, with no drag or anything of the sort. It allows you to jerk around wildly, practically just as fast as you can move your fingers. Changing direction is instant, hence I say that movement lacks weight. This is usually good for creative building or whatnot, but it isn't particularly immersive, and for combat it can easily be argued to be detrimental - moving towards or away from an enemy is not a commitment at all, because it can be freely reversed at any moment to bait then avoid an attack. If that's what the problem is, then what I mentioned may indeed be the culprit. Because when you look up or down at steep angles, then moving forward and backward becomes essentially impossible due to those inputs being transformed to be very similar to dedicated vertical movement inputs.

I find that swimming tends to suffer from the same issue that makes creative flying annoy me, which is pitch not being locked to zero. That is, forward and backward movement follows where the player is looking instead of being locked to the horizontal plane. Other than that, I've found swimming in VS to be fantastic due to how weighty it feels, largely owing to using periodic bursts of movement instead of a constand movement speed - it's actually kind of immersive and it feels like underwater movement to me. That is in stark contrast to walking and running, which feel like creative movement and have basically zero weight behind them.

It's not how it has always worked. Just double-checked that this behavior doesn't occur on 1.21.7 (the last major version prior to 1.22). Shift-clicking only produces one type of item until the resources for that specific item are exhausted, and doesn't attempt to exhaust all items in the crafting grid by producing other items.

I find that drying, primarily for meat and possibly for other foods including mushrooms and fruit, would be a good candidate for a simple and effective method for easy and accessible long-term food storage, with low upfront cost, little active effort and a high satiety malus for balance. The main reason why I specifically focus on drying meat is that, ideally, I think this would tie in well into some kind of a revision to animals which could make them more difficult to initially obtain and process, but increase the yield significantly and possibly even reduce the spoil time of unprocessed meat, to reduce the mass slaughter that the player needs to perform just to keep themselves fed. Drying would then be integrated more tightly into the gameplay loop as a critical means of increasing the return from a single animal beyond its baseline spoil time. An additional potential idea I would like to mention is decay without spoilage - reducing the satiety value of food items over time. Or just the nutritional content, i.e. the satiety to nutrition conversion ratio. This could apply to all foods, but its primary point is giving foods with indefinite spoil time an incentive to eat them earlier rather than store them literally forever, which could be applied to dried foods among other things. As an extra note, an opposite effect could be applied to items like cheese, wine or pickled foods, so that their value increases over time, up to a point. Frankly, I tend to feel like food spoilage is actually too slow on default settings to facilitate this idea of natural cycles properly, great idea though it is. Grains last 6+ years in a storage container in a cellar. Even something that might seem easily spoilable like fruit actually ends up lasting well over a year in a cellar in the case of apples, which means that you can eat fresh fruit all year long if you store a couple stacks. The only food category where spoil time can be really meaningful is protein, but fresh protein can often be obtained readily at any time of year, especially once you get any sort of animal husbandry going, or completely circumvented with soybeans that last 12+ years in a cellar. There isn't actually all that much in terms of proper seasonality in the game, I would say. Or no proper seasonality at all, even, depending on how you define it. I was advocating for a seasonal growth system for berry bushes and fruit trees instead of the current system which causes a whole bunch of problems, and the only answer I got was that it is some kind of a long-term goal which would ideally be applied to virtually all plants in the game but there's no telling when it will be done, if ever. Well, the wiki states it at least and I've also experienced weight-loss in livestock if not feeding it for a while. This stuff is defined in BehaviorHarvestable.cs. Animal weight changes as follows: if the animal has eaten within the last week => increases by 5% per hour, up to a maximum of 100%, if the animal has eaten within the last 4 months => increases by 0.1% per hour (2.4% per day), if the animal hasn't eaten for at least four months, and the current temperature is at or below 0 °C => decreases by 0.1% per hour (2.4% per day), down to a minimum of 50%. Animal weight currently only has one purpose - it's a multiplier to the quantity of food items among the animal's drops, which for most practical purposes means meat and fat. If it's at 100%, you get 100% food, if it's at 50%, you get 50% food, and anything in-between.

Salty's TerraTag might be of interest to you: https://mods.vintagestory.at/terratag

So you want to be able to make significant stockpiles of this non-perishable food... at a point in the game where the player doesn't have significant stockpiles of fresh food? What you're asking for, by all accounts, is a way to cheaply and easily get back into the game after a long break with no added work imposed. That is, for all intents and purposes, quite literally unachievable with a new food item which is supposed to: be available very early into the game, be achievable prior to existing methods for long-term food security, be accessible to inexperienced players, take little to no effort and time when getting back into the game, not take an excess of time and effort to initially produce, not require a significant initial setup to start producing, not have a significant luck component, be producible largely at night, possibly something else that I've missed, and also remain balanced. If you think you can make it work, then feel free. But as of now you're mostly just making excuses for why existing solutions are insufficient while seemingly ignoring the fact that your solution would also need significant drawbacks if it's supposed to remain remotely balanced, and as such would likely inadvertently get struck by the same arguments that you're using against other alternatives. Nothing requires the game to explicitly enable and support "extreme long-term [multiplayer] content", especially on its default configuration which is tailored primarily for singleplayer worlds. Server-specific world configuration is the built-in method which allows you to largely solve your own problems, which includes making the world more suitable for irregular multiplayer play. If this fails, it's the other players that can welcome you after an extended break - that is largely point of playing on multiplayer servers in the first place. There is a point at which "permanence" just becomes irrelevant. If you're playing a survival game, then it is only natural that you have to put in the time and effort to survive. VS is advertised as an "uncompromising wilderness survival", for better or for worse, and permanence as a concept can be easily argued to be largely incompatible with that design direction. At the same time, I do want to mention, VS as a survival game is already quite easy, much easier than many survival games like Project Zomboid, The Long Dark or Don't Starve. Long-term and even indefinite food storage is not a problem for the "immersive homesteading sandbox" side of VS, which often seems like a much more accurate descriptor for the game, and personally, I think that this split between difficult survival and casual homesteading drives a lot of issues with the game. It does certainly broaden the game's appeal and can contribute to player retention, but it also contributes to scope creep and easily makes the game seem like it lacks proper design direction.

Note that you can use Ctrl + F1 to reload the world quickly, and that is enough to reload lang strings as well. The only thing it won't work for is the main menu, it seems.

I feel like just having a single "internal organs" item of sorts would be sufficient and arguably more interesting from a gameplay perspective, as it could have multiple purposes for which different organs are used realistically. No slippery slope as far as I'm concerned. Personally, I would make it only obtainable when processing an animal on a dedicated table or whatnot, while requiring animals killed in the wild to be field dressed (thereby discarding the organs) to keep the corpse from spoiling if the player can't bring them back in time. What I find amusing now that fishing is in the game, is that it's entirely possible if you find a good fishing location to convert bushmeat into fillets at a ~1:2 ratio or better, which translates to a ~7.5+ satiety multiplier. I'd been living near-exlusively off of that until the first spring of my recent survival world. Even disregarding already-existing options for indefinite food security which easily include honey, fat, alcohol, animal husbandry and traders, it seems to me that there is a second elephant in the room here. Grains in a storage container in a cellar last, if I can trust the wiki for the exact value and assuming a 0.13 rate multiplier, ~550 real-life hours on a 24/7 server on standard settings. Most servers run only while someone is active and often deliberately slow down spoilage rates because it's important even for regular gaps between play sessions, so that real-life spoil time equivalent is easily extended to multiple months if not over a year depending on the specific world configuration and on how active the server is. There is a bunch of other foods which are also effective, of which the most notable I think are soybeans and peanuts, jam in sealed crocks, waxed cheese, as well as cured meat which all last about twice as long as grains if I recall correctly. Would need to double-check to be sure, though the wiki at least seems like it agrees. Assume spoilage rate configured to 50% and server running 6 h/day (which is arguably quite a lot, still), and you already have 6 real-life months until your grains spoil, and longer for some other foods. There are caps for specific categories or species of entities, but I'm not personally aware of any global spawn cap, so I'd be interested if you can show where it's implemented or point to some experimental evidence. Either way, I haven't personally noticed any meaningful population shifts on my island world which is a ~200x150 area with conditions to spawn wolves, bears and several species of prey animals. Even if it's theoretically a possibility to have no animals of a given species spawn due to some caps, it seems exceedingly unlikely in most contexts given that different species spawn in different conditions.

Whether bows are accurate up to 100 m is largely just a matter of how you define "accurate". Trying to achieve reasonable hit probability on a line of enemy soldiers or a ship is entirely different from trying to ensure a clean hit to the heart of a deer. But in terms of objective measures, VS is not accurate to real life by any stretch of the imagination. A one-meter group at 20 m with a traditional bow is entirely within the capabilities of a beginner with very little experience (ask me how I know). For an experienced archer, around 20 m is often considered to be around the maximum range in hunting, where a clean kill is required - targeting the heart or the lungs, which is often approximated roughly as a sphere 20-30 cm in diameter for a medium-sized deer. It is worth mentioning, though, that the targets in the game are ridiculously huge compared to realistically practical targets due to a lack of weakpoints, and they also tend to chase the player more than anything else, and the quantity of arrows that the player can carry is borderline absurd in some ways, so the bows' poor accuracy still ends up more than sufficient in practice most of the time. The game's ranged weapons are overall very simplistic and have a number of quirks which would be best done away with, both from the perspective of game design and immersion or realism. I think I was complaining about it a while back here, though a couple things there (mainly if not only about spears) are outdated now in 1.22. Do note, though, that the scaling is not uniform and not even consistent, because it tends to be done on a case-by-case basis and is rarely updated. Many things (especially small ones) are scaled up for various reasons, and some things are scaled in odd ways largely as a result of being old and never updated. Trees are a prime example of odd and inconsistent scaling which is arguably long overdue for a rework. I would say that practical range should likely be similar or maybe slightly lower than what it is realistically, in which case accuracy is mostly tolerable currently but would need to be improved greatly if any sort of vital areas or weakpoints are introduced.

Stone-tier tools should remain mostly as they are for the sake of simplicity, to make things more approachable for newer players. The initial recipe could include some cordage, and potentially it could be possible to add some glue as well to increase durability, but as the first tools that the player will generally use they shouldn't be made too complex. If even cordage and glue is deemed to complex, then it may be reasonable to add simpler tools which would be just appropriately shaped rocks, with no stick or anything - it would also make more sense for a digging tool than a stone shovel. For metal tools, even without allowing tool handles to break, it would be very reasonable to allow or outright require more and better materials for handles - the current state where virtually 99%+ of a tool's cost is the metal is just kind of stupid. Wood and bone carving would be expected here, alongside adhesives. A more primitive attachment method with cordage and glue could remain an option for copper and maybe bronze, but it shouldn't be possible for iron and beyond. Some items could require or at least allow additional materials, for example a saw should take twine and a more complex handle, while a falx could take leather as well as nails and strips. I think this would be fine to implement, with a couple caveats. The most fundamental idea that I think tool handles should follow is that a handle shouldn't break more often than a player expects it to - which is a somewhat nebulous goal to aim for, but that is kind of necessary when trying to keep unnecessary frustration to a minimum. Stone-tier tools should remain simple and have very low durability, so it's fine if they break completely without allowing handle replacement. Especially at the copper and bronze tier, it would be strongly preferable for handle replacement to not be too common relative to the tool's main durability. It could even be an option to only allow handle replacement for iron, because copper and bronze still have fairly low durability which could cause handle replacement to become more frustrating than it should be even if it only had to only be done once at the halfway point. Replacing handles should be reasonably simple and intuitive even out in the wilderness, even at the steel tier, because it would feel pretty bad to have to carry clutter from broken tools and only be able to fix it back in an advanced workshop. Some way to repair or replace a tool handle before it breaks would be extremely valuable, to reduce the risk that the player ends up with low-durability tools which are too weak to take on a longer trip without having to also carry a replacement handle. This may require some changes to the inventory system to be implemented first, so that carrying extra handles or glue or whatnot wouldn't take up multiple valuable inventory slots. I tend to see this as a bit incompatible with the game, plus it can produce annoying clutter. Some way to recast copper alloys and reforge iron could be very nice, but it would have to be well-integrated into the gameplay loop, and it kind of fundamentally doesn't mesh with mining being as prevalent as it is currently. If recycling was as useful as it is realistically, then the player wouldn't really have to mine for almost any metals after a couple initial deposits, except maybe for decorations or whatnot. If recycling is made less useful to keep mining for new deposits more relevant, then the benefits of it could be easily outweighed by the negatives of added clutter - and unlike tool handles, broken toolheads fundamentally cannot be repaired out in the field. Frankly, while what we have in the game is referred to as sharpening, from a realistic perspective it doesn't make all that much sense. Sharpening is a very fundamental component of toolmaking and maintenance, so I find it pretty baffling that it was gamified into a critical hit chance. Grindstones are simple, ancient tools, so I find it pretty baffling that it was gated behind mechanical power - an "uncompromising wilderness survival", which can't help but lock important mechanics behind infrastructure. I think it could be interesting to allow the player to carry a number of tools and utilities without taking up an excess of valuable inventory slots, making the player's personal bag into a general toolkit and effectively a tangible indicator of progress. Sharpening stones could be among the items which would be carried in this way, used to maintain tools regularly. Add to that some cordage, some medical items, a temporal gear, maybe an adhesive and a tool handle or two, and possibly some other necessities and useful tidbits. Would need to be a bit careful to not give player too many things to carry around, but as a general idea I think it would be interesting and very immersive. Regarding the effects of sharpening, I think it would be preferable to avoid excessive drawbacks, to make sharpening actually feel useful for tool maintenance. Increasing the speed or damage of well-sharpened tools would be quite fine. Reducing durability loss would be reasonable. Some more meaningful effects could be ideal, though they're less straightforward to think up and implement. Something like increased drop rate of certain blocks collected with a sharp scythe, or a slightly higher boost to soil fertility when tilled with a sharpened hoe. I don't quite see the point of reducing durability in exchange for power, because that's what quenching currently effectively does via the shatter chance consuming additional materials - unless quenching is reworked into an even less realistic system than it is now, then I think that sharpening probably shouldn't serve largely the same function. At least for my preferred gameplay style, this would be kind of perfect, since I keep a couple tool racks at home and only take the tools I know I need with me, so it could actually be pretty fun to maintain the tools before putting them back. I think that rust would be fine, similar to tool handle breaking, but it also needs a couple considerations and caveats, primarily the following two: Rust shouldn't progress at all as long as the item is oiled and is not being used. This is primarily a concern for multiplayer servers where it would feel awful to log back in to all tools being rusted, but even in singleplayer it would be really annoying to have to maintain unused tools. Rust shouldn't be an immediate concern the moment a tool is used. It would have to take quite a bit of usage to wear out the oil, and after that there would likely need to be some kind of grace period, e.g. to allow the player to come back from a trip and coat the tools at home instead of having to carry oil everywhere - some things could be fine to have to carry around, but I think oil wouldn't really be one of them. One of my main concerns is also other metal items besides tools. It would be expected that if tools can rust, then so can all other items and blocks made of ferrous metals, at least visually if not with any drawbacks. For things like metal doors this wouldn't be too much of a concern - for simplicity's sake they could just be oiled once when initially crafted - but it is much less straightforward for something like the water wheel, which realistically should rust quite quickly due to contact with water. It is also tricky for things like chests, which take nails and strips but currently look the same regardless of which metal is used.