MKMoose

Quite a lot of people have had problems. It's a known issue, #9175.

Seems like it might be a known bug, #4181.

Seems like a bug more than an intentional limitation of spur gears, especially since it worked as expected for me. Most likely related to #9391, possibly also to #8349 or #9596.

It's entirely plausible, and actually quite likely if the continent is relatively small. While you do seem like you're aware of at least the basics, I want to note a couple things just to be sure if you need tips on searching for borax: Sometimes random generation just does its thing. If you've roughly prospected in all areas which can generate borax but got no readings for it, then it's safe to assume you need to look for it elsewhere.

Besides durability, higher-tier knives have a couple advantages: higher plant harvesting speed (e.g. a stone knife has 1.0x, tin bronze has 1.8x, steel has 2.4x) - doesn't matter all that much given that the axe and scythe are usually better for mass-harvesting of plants, but can be very useful occasionally, hidden bonus to entity harvesting speed (equal to half the plant harvesting speed bonus, e.g. a stone knife has 1.0x, tin bronze has 1.4x, steel has 1.7x) - arguably the most important bonus of these, given that the knife is the only tool used to harvest animals or monsters, significantly higher damage (e.g. a stone knife has 0.8, tin bronze has 2.5, steel has 4.0) - usually irrelevant if you have a proper spear or falx on yourself, but might occasionally help out in a pinch.

Poisoning with a stew generously prepared by a friend is a strong contender for me. My favorite, though, is accidentally picking up the rope ladder too fast while leaving a mineshaft. Genuinely haven't died to anything more than that.

The most important parts of this are implemented in EntityBehaviorHarvestable. I don't have the assets on hand to check, but I'd imagine based on what I'm reading in the code that you'd need to add a deathByMultiplier in the mod's files for tamed wolves (or just modify the value if it's already defined).

This part specifically, I don't really like, because realisticaly most animals still generally won't pursue. Just to give some context: even for relatively dangerous animals like bears, easily thousands of minor encounters with humans can occur for every human death. For some animals, there are virtually no recorded deaths from animal attacks, or if there are then they can often be estimated to land in the ranges of one human death per millions of encounters. Attacks are often warned about and studied, and for good reason because the risk is very much there especially if certain risk factors are met, but the actual danger is often quite overemphasized. You can take a look at statistics regarding, for example, bear encounters and attacks in national parks compared to the number of annual visitors. Yes, with the caveat that skipping formalities should be specifically triggered when the player approaches very quickly or otherwise disrupts the animal (kind of like boars do currently where they will run away when approached slowly, but attack when the player gets too close, though the ranges could probably be tweaked and they still give little to no warning). I think it really should give a distinct "you've made a mistake" or "you've been careless" feel, not just be random and unpredictable. That applies even for many predators. And it's also probably worth noting that animals can actually become unusually dangerous in some often overlooked situations like during the mating season (if the devs decide to introduce something like this, then that would warrant taking overall aggression down a notch but bumping it up at appropriate times) or when caused by disease or other pathology (if implemented, then ideally in a way that allows the player to actually see and hear that something is wrong with the animal before it attacks). Overall that could be argued to be included in the "warn the player appropriately" phrase, but fair enough, it is an important thing to keep in mind.

One problem with pure persistence hunting is that, as far as we know, it wasn't really a significant hunting method ever since humans figured out that throwing a pointy stick at the animal makes it much easier to track and catch up to. Humans' superior endurance and more developed sweating can be beneficial in hunting, which has even been documented in relatively modern times in some tribes in Africa (which has some biomes especially suited for getting animals to the point of heat exhaustion), but it's just one hunting method. Why not trapping, stalking, drive hunting? Another problem with persistence hunting is that I frankly feel like it would be really quite boring and one-dimensional in gameplay. Well-developed hunting mechanics tend to involve multiple stages like observation, stalking, making the shot and tracking, with each stage asking different gear, skills and strategies of the player. Persistence hunting kind of devolves to just running for extended periods of time, and it's also largely devoid of gameplay progression. If the animal is easy to keep track of, then it's just tedious. If the animal is difficult to keep track of, then it becomes unreliable and frustrating. Striking the right balance feels borderline impossible when you have a lot of players at different levels. Some sort of endurance system for animals can be a fun addition, but I personally feel like endurance should only matter when injured. This way it doesn't reward rather uncreative activities like chasing an animal for a long period of time, instead strongly pointing towards stalking and ambushing to injure the animal as the optimal way to slow it down first while still leaving the tracking aspect as an important part of the process. I think it would just be a better system in almost every way over simply allowing the player to tire out a healthy animal. And if you specifically want a way to chase animals, then it might be better to lean into pit trapping and drive hunting, rather than simple persistence hunting - both, assuming they're implemented well, would arguably be much more engaging and rewarding due to the layer of strategy and adaptation (finding a good spot, preparing the area, directing the animals towards that location) which persistence hunting largely lacks. Frankly, I really feel like this cannot be reasonably fixed in any other way than just reworking animal behavior to be more involved and actually kind of realistic, rather than what for real animals would just be considered pathological. A bear shouldn't chase you until the end of the world. It could as well be twice as fast in full sprint for what I care, as long as it's more defensive, so it warns the player appropriately before attacking and relents quickly unless pestered repeatedly - what makes it really questionable currently is that it's hostile in the exact same way as the rust monsters. Wolves should avoid the player most of the time, but give them a run for their money when they hear a hunting pack in the middle of a forest. And once you address their heatseeking behavior, then what you do with their endurance no longer has backhanded balance implications that make designing the game into whack-a-mole with obvious and predictable problems popping up after any significant change.

Chiseling down a failed workpiece makes bits. For everything besides steel this serves as a way of retrieving all the metal after a mistake, with the exception of pieces which had more than one ingot added.

You can do it perfectly fine. You just need to make sure that they work in tandem rather than counteract each other.

Just to clarify, because I realize now that it can be interpreted in various ways: by "initial growth time" I mean growth from cutting to young bush (2-4 months) which can be gamed to consistently get close to 2 months, but then the maturation stage (2-4 months again) can't be cheesed the same way. You can reduce the total growth and maturation time in months from 4-8 (6 on average) to 4-6 (5 on average), and the fruiting cycle then also takes on average 2.5 months regardless. So it's not all that impactful. A very similar way to game the growth time randomness has always been a thing with with tree saplings, by the way.

The things that are actually working as intended are closed and labeled with "status: wontfix". There have been plenty of reports regarding, for example, clothing balance, which could easily be said to be "working as designed" and yet were not even labeled as suggestions. Do note that the standard procedure towards issues labeled as suggestions is to close them, which is why I was pointing out my issue not being closed despite getting the label as unusual. Also, it's not like a GitHub issue being both a bug report and a suggestion would be a paradox, you know. And ultimately, when the way the game "working as designed" allows to objectively show that large windmills are flat-out worse than regular windmills in nearly every aspect, then I think it's also fair to call it a bug.

More on the historical inspiration side of things, for something simple, a log cabin in the Norwegian Museum of Cultural History - bonus points if you add a sauna to something like this: For something larger, Schronisko Murowaniec (Murowaniec shelter) in the Polish Tatras (admittedly relatively modern and probably overkill in size, but fits the aesthetics and block palette of VS quite well): For something further back in time, a Bronze Age house drawing that I could find here, for when you want to torture yourself with getting all that thatch: If you're not sure what to do, I cannot recommend anything more than to start small with easy shapes, and try to prioritize variety and small decorations to spice things up: a different roof material here, a different floor there, a fence to lead the eyes between two things, a path to the lake and a small pier on it (maybe it will even be good enough for fishing), a few hay bales next to the farm, a stack of firewood on the side of the house, some flower pots next to the door, a few berry bushes under a boring wall, a table and chair with some bookshelves on the inside to keep cozy. If you only start off from a small hut, then adding on a second building for the forge, or a granary, or a hut for storage crates, is a fairly simple, step-by-step process, and can produce a neat little village of its own. Integrating a lot of things into one huge building, on the other hand, and decorating it all in a cohesive way, especially with the resource scarcity that VS sometimes likes to hit you with, is very hard and time-consuming even if rewarding. If you're relatively new, it's also impossible to really predict how much of that space you're actually going to need. I personally spend almost all of my time in houses that don't exceed a roughly 5x10 footprint on the inside, and even that tends to be large - my first house was a 2-floor 5x7 with a cellar plus an outdoor forge with some storage crates, which carried me through a 200+ hour world with no major issues.

Realistically? Not really, real windmills should be placed further apart than that, especially in the direction parallel to the direction of wind. In terms of consistency? Small windmills use the same system, and both need 1.5x radius, so I don't see issues there (although there are some caveats regarding the possibility of cheesing the system). But balance-wise? The whole large windmills are underwhelming, to the point that I opened a bug report which was promptly labeled with "status: suggestion" by one of the devs but also given "priority: medium" by another, and it wasn't closed. Your two large windmills, even if they weren't cut short by turbulence, would produce the power equivalent of five small windmills (for context, a small windmill should give 100 kN) while costing the flax equivalent of eight of them, and 24 iron as well. Reduced in size to avoid turbulence, they give the power equivalent of four small windmills at the flax equivalent of 6.4 of them.

My preferred method is to place one lit torch on the ground and light the remaining stack from that one - still technically one-by-one, but at least all in one go, just holding down RMB for however long it takes. Unlike the firepit, this method doesn't consume fuel.

Gotta love seeing the problem I anticipated pop up pretty much exactly. The turbulence range is 1.5 times the windmill's radius. I don't remember whether the turbulence radii can't touch or just can't overlap, but I think they can touch based on the patch notes. In that case, full large windmills need 30 blocks of separation. If you want to be sure, you can test it in creative. If you don't want to move the windmills, you can also remove some of the sails so that there's a total of 16 sets on both windmills, to match your 24-block distance.

See, that's what I'm saying. You're talking about Minecraft and beds again. I'm aware of the community sentiment around beds and I largely share that sentiment, which is why I've never suggested it. But, there's plenty of ideas which don't rely on arbitrarily setting the spawn point when sleeping, some of which have seen reasonable support from the community: a respawn anchor, effigy or something of the sort, which would work pretty much just like the current gears but could be used by multiple players, could be charged beyond a single gear's capacity, and wouldn't waste charges when switching between anchors if the player has multiple home locations or is temporarily setting a spawn near a boss or something of the sort (this is by far the most common suggestion I've seen), to address early-game frustration, the easiest solution is to make the default respawn location centered around the point of death, or arguably better - in the vicinity of where the player has spent the last day or two, as that addresses most possible death-loops and retains a short runback, which would naturally also give some weight to beds as they effectively make the player spend several hours in a single spot, a related solution could lie in an item which could be carried on the person (could literally be a temporal gear, if nothing else) which would behave in a similar way to the anchor or effigy from the first idea when placed, and shift the respawn area to the player's vicinity like in the second idea when carried. And if that feels like it makes death lose its weight (it really wouldn't lose much of anything - respawning would just be less frustrating or tedious), then how about we consider to actually integrate death with temporal stability? Apply a penalty to maximum stability or stability recovery rate (it would need temporal stability to be revised to work) or other debuffs (ideally debuffs which don't impede regular gameplay and are most impactful in already-dangerous scenarios), which could be fixed by using temporal gears or other means (the current feature of using a gear to restore temporal stability could be reused for this). If any sort of long-term injuries or diseases are implemented, letting most or all of them persist through death would also give plenty of weight to it and, crucially, incentivize interacting with several other systems to mitigate those penalties faster. Then there are also some universal improvements to death and respawning that could be made: shift the spawn point away from temporally unstable areas and avoid spawning right next to monsters and hostile animals (at least for the default spawn, for the location set by the temporal gear it may not work as well and isn't as important anyways), improve the core death and respawn effects (purely audiovisual, or something more elaborate), because it is rather odd to just disappear from one place and pop into another in an instant, add a player corpse that stores the items (the single most suggested and most popular in mods death-related feature as far as I've seen), because the risk of losing all of your items is just annoying when it happens (especially if it happens to some very valuable items - I've had a share of fun with lore books myself), keep the death markers for all deaths (and ideally only remove them when the corpse is picked up), not just the last one. And also as a side note, if we're looking for incentives to use beds other than respawning, then my suggestion for that would be to just lean into probably the most important purpose of beds besides sleep: if any sort of long-term injuries or diseases are implemented (as Tyron has mentioned that this is a consideration with status effects), then sleeping should be an important way accelerate the recovery, even if no long-term injuries are implemented, beds should probably be better at accelerating healing without also chugging the entire satiety bar. Ideas are the easiest thing in game design. Of the above, I think that each has potential and probably wouldn't cause any major issues, though naturally there's all the usual caveats. And there's plenty of ways to improve the mechanics without constantly circling back to the one option which consistently receives pushback whenever it's suggested.

This sure ain't it. This isn't an explanation. There's no in-universe mechanism for this. And how is "can be shattered to create a returning point" any better? It doesn't clarify the mechanism in any way. There is no lore offering any explanation for how it might work other than a vague pointer in the direction of the temporal mechanics. You're constantly circling around seraph immortality and returning to the world, broad themes of the game, but failing to provide any explanation for how setting a respawn point actually works, because there is no explanation beyond that broad theming. I'm well familiar with the themes of the game and the background of seraphs, and my point has not been anything other than that there is no lore which forces any specific design for how respawning should work in gameplay, and especially there is no lore explaining how setting the respawn location via temporal gears works. How can you say this without seeing the circularity when the only way you can know that they are "anchored to a point" is that the respawn mechanic throws you back to the initial spawn location or to the one you manually set? If the respawn mechanic was different (e.g. centered around the point of death or more elaborate variants I've described), then the lore inferred from that mechanic could be different, but no lore would require any changes whatsoever to retain its internal consistency. And actually, for all we know, it could as well be that it's the exact opposite of what you've said - the conversation at the end of Chapter 2 mentions that seraphs are likely not tied to time and space the way humans are, which can be easily argued to conflict with the current respawning mechanics: I'm gonna answer this with another quote of yours, originally on the base return teleporter: Why is the respawn location not affected by temporal stability, temporal anomalies (i.e. the lore locations, especially Chapter 2), rifts, rift wards, or anything else that interacts with the temporal themes, but then completely determined by the seraph just... breaking a temporal gear? Is everything else not somehow distinctive in the temporal flavor? Sure, it works as a way of adding a gameplay function, but it weakens the lore, not strengthens it, when a feature is added in a way that operates purely within its own bubble and doesn't interact with things that it clearly relates to in theming. Frankly, there is nothing that I would like to see in the temporal mechanics more than large-scale integration with the game in a way that is based on a number of core rules applied systemically. My original point on that topic was admittedly somewhat overstated. The intent of it was primarily to point towards the idea that (more broadly, not just in the case of Vintage Story's respawn mechanics specifically) if there is little to no explanation for why a mechanic is good besides that it is related to the lore, then it doesn't seem to me that the lore alone is a sufficient reason to avoid changing that mechanic.

I've spoken plenty about them in the berry bush rework sentiment poll among other places, but regarding growth times specifically: initial cutting growth time can be minimized by just replanting the cutting until you get a low value (close to two months), total time from plating a cutting to the first harvest is (assuming you don't cheese the initial growth time) 4-8 months until maturation and then on average 2.5 months until the first harvest, but it also gets slowed down by low temperatures - if you plant them shortly after starting a new world in the temperate climate, they will tend to yield the first fruit after fruit trees (tested planting 5th of June shortly after midnight in 5.9 °C climate, regular berries against pink apples specifically), so I genuinely don't know why I should ever bother with cultivating the berry bushes (in subsequent years they will ripen before fruit trees, but only that first harvest really matters from a balance perspective and early-game value), the cold end of the temperate climate band is around the range where bushes tend to only give one harvest per year, but will happily fake you out by progressing all the way to ripening and then suddenly going dormant (you might be able to mitigate this with a greenhouse). Timegating can be a mostly fine balance component, but when both fruit sources are timegated in a roughly similar way and yet one of them has several advantages over the other (long spoil time and no fertilizer use, most notably) and is only slightly limited by randomness and scarcity, then I don't see much evidence for any thought having been put into balance at all - technically, we do know that some changes are planned for fruit trees, but that doesn't exempt the current state of the game from scrutiny. And more generally on the topic of timegating, while it can work in some ways, I think it's generally inferior for most purposes to almost all other forms of restricting access to features, because it doesn't ask motivate practically any engagement in the player. Being told by the game to just wait doesn't even help with feature discoverability by informing the player of other things they could do in the meantime, while for example resource gating gives the player a thing to look for by hinting that those resources can be obtained in the first place.

And yet its respawn mechanics are extremely similar to Minecraft, with the only really meaningful difference being temporal gears instead of beds. In some sense, it is even more forgiving than Minecraft because it keeps clothing and armor on the player, and it is incomparably less "uncompromising" than many classic survival games which implement permadeath mechanics. Why are you so fixated on Minecraft and beds? Besides that, I've literally been explaining why some people dislike VS respawning mechanics this whole time. The original point of this discussion which gets constantly sidetracked is that respawning in VS is more frustrating than it needs to be. It has borderline nothing to do with death having weight or being punishing in isolation. This is the opposite of what I said. The games I've mentioned there (roguelites most notably) implement mechanics which make death significantly less frustrating, so it stands to reason that VS could take a page out of their book. Naturally, since they're different games, their solutions may not be entirely fitting for VS - ideas revolving around permadeath especially shouldn't be integrated into the standard world configuration - but there is nonetheless plenty of methods that can be found across many different games which aim to make death less frustrating. I applaud the observation. Being unable to secure a spawn in a home that isn't immediately on top of the spawn location in the early game is one of the main sources of frustration with the mechanics. Do keep in mind, though, that when you set up the expectation that the player can run off and set their spawn wherever they want, it's gonna be even more frustrating if the player happens to die before they decide on a suitable location. Frankly, I've always thought that it's a wholly inadequate solution to a problem which shouldn't exist in the first place. The devs knew that the current design of the respawning mechanics can be frustrating and the ability to return to the point of death quickly can be very valuable, so they added... an expensive endgame device which a large portion of the playerbase is never gonna build. Seriously? That could be likened to recognizing the early-game food struggle and deciding to add some exotic endgame method for more efficient farming. It can be a fairly satisfying endgame reward, but in the extreme, if frustration compounds into the player quitting the game, then it doesn't matter what the endgame has in store. I've personally never even crafted the terminus teleporter because in every single world I've wanted to do so I've either spent the Jonas parts elsewhere (night vision mask or rift ward, before I've realized that they are largely useless) or just could never find one or two specific parts. The terminus teleporter solves almost nothing and should not be used as an argument against changes to respawning.

How you do not see that as exactly proving my point is beyond my understanding. The only lore you can find on the current respawning mechanics is the mention of a returning point temporal gear's and base return teleporter's descriptions, and the respawn text. Everything else you've mentioned is generally irrelevant, because it only describes that the seraph can't seem to die or at best mentions how they initially got into this world, not actually explains anything about the respawning mechanics. Any attempt at justifying the current state of respawning mechanics through lore inevitably relies on the scraps of information drawn directly from the items which allow to interact with the returning point in the first place and from interpretation of the current mechanics - ergo, circular justification. If you want to talk logic, then rather than ask me to justify a random idea that I've never even argued for, how about you explain how it makes any logical sense that the player is always returned to an arbitrary area placed kilometers away from the place where they can be logically deduced from the lore to have first entered the world (or a single, manually set point which cannot be reasonably presumed to be the only such point in the world and yet is somehow matched to the player) even if they die hundreds of kilometers away from that location? Sleep being tied to respawning can be explained easily by just saying "the returning point is tied to the last location that the player has slept in". There are no further details necessary, just like the current temporal gear doesn't explain absolutely anything beyond "can be shattered to create a returning point". Though you could think up a range of metabolic changes, memory imprinting, or other ideas equally made-up as all the interpretations of what the returning point is. Other alternatives include tying respawning to the location of death, to the general area that the player spent time in shortly before death (sleeping would be naturally integrated with it by registering the entire time that the player has slept in a single location, giving it significantly more weight), and to any number of items and blocks which could be carried, placed down or activated to move the returning point. Some kind of temporal anchors could be placed in some ruins, which could pull the player away from the returning point, helping new players with discoverability by directly putting them where they can find the materials to create their own anchor or any other Jonas tech or improvised devices, and potentially serving as a lore hook. Coming up with ideas is the easiest part in game design.

This supposed lore is entirely nonexistent as far as I can find, and it's especially not found anywhere in ruins or through panning, as that lore is predminantly focused on the events from hundreds of years ago and has no mention of seraphs. Specifically the words "energy" and "flow" return zero relevant hits in lang files, so they are at best an interpretation of the mechanics, and at worst just made-up nonsense. If you want to be so confident about it, then point to where exactly it can be found. The closest I've seen is the conversation at the end of Chapter 2 talking about how the player got back into this world, and the in-game error message mentioning a "temporal anomaly", but neither provides information on how the player can return each time, just how they got here initially. The only piece of information we have on the location where the player returns to the world are the temporal gear description [1] and the respawn message [2]: which only mention the existence thereof and do not in any way describe the underlying mechanism. Unless you somehow dig up lore that I can't find on the official website and in the game files, we land exactly where we were: there is nothing that we know of in the lore which forces respawn mechanics to be implemented in this very specific way or prevents alternative mechanics from being implemented. Changes to mechanics within a reasonable capacity wouldn't even require the slightest modification to any lore, because the lore provides practically no constraints. The explanations which are provided for the current state of the mechanics are notoriusly just an interpretation of the mechanics which doesn't reference any lore external to the mechanics.

The existence or partial subjectivity of bad mechanics does not in any way make justifying them with lore any more reasonable, so I don't really know what you're supposedly disagreeing with. Keep in mind that I'm mostly talking about the fact that lore still tends to be used as a justification for mechanics and sometimes seen as immutable even when there are few if any gameplay-centered arguments for the mechanics, as is the case for several components of temporal stability, respawn mechanics and animal hostility in Vintage Story. Also, attempting to paint old games as holding up better over time and newer games tending to fall to the wayside seems like it conveniently ignores the swathes of old games which you've never heard of and the plentiful relatively new games which are highly popular and beloved, as well as the trends in the quantity of games released over time and the incentives behind those games. One of the biggest reasons why older games can seem like they hold up well is that the games which hold up well, regardless of how old they are, are also the ones you're incomparably more likely to now be familiar with. Keeping inventory on death is helpful for casual players and for the sake of accessibility, but it does little to address frustration with the respawn mechanics themselves. It just reduces one of the consequences of death to the point of irrelevance. The reason I'm using the term "heavy frustrators" is because I specifically mean heavy frustrators, believe it or not. Some frustration is expected and natural, and acting like removing all possible frustration would lead to a better game would be absurd. What is a priority to address in game design is features or mechanics that frustrate players frequently and cannot be easily addressed by the player themselves in a satisfactory way to an extent that the player is at risk of putting the game away. The only things which keep the current respawn mechanics in VS from generating an onslaught of complaints are the option to keep inventory on death and the ability to use commands, but neither represents an proper solution to frustration with the respawn mechanics - they circumvent or neuter death mechanics instead, which only indirectly makes respawn mechanics less frustrating. Regarding the game examples: Death in roguelikes and especially roguelites is a completely expected part of the process and is not a significant frustrator by any stretch of the imagination. Especially not in some of the best-designed ones like Hades, where death is largely reframed as a means to progress. Barring long runbacks, which are a common frustrator, soulslikes are very similar to roguelites in this regard. Even in games like Dark Souls, the most you'll generally lose on death besides time is souls or equivalent currency, which you shouldn't have much of on yourself either way. Runbacks, in moderation, can also be easily argued to be beneficial as a way to create spacing between fights, but even in the worst cases, a long runback is generally a frustrator by itself, not the death that leads to it. In some games, there's also the matter of recovering healing items, which is a similar kind of frustrator to item recovery in VS. VS is much worse in this regard overall, because you risk losing everything you had on yourself and you have to make the way back with spare equipment or nothing at all. And if you respawn far away from the point of death because you didn't decide to use a temporal gear in the middle of nowhere just in case you might die specifically on this trip, then the runback is a grueling chore more than any sort of breather, challenge or learning opportunity. Hardcore games or modes are something that the player very much signs up for fully aware of the consequences of death, and in fact you can do so in VS as well, so trying to compare hardcore games to base-game VS seems rather silly. Either way, any frustration in this case is far more likely to be focused on the mechanics or other players that caused the death, and there are fundamentally no respawn mechanics, so the comparison is doubly irrelevant. You're pointing to how death punishment in all of these games is fine, but you're seemingly failing to realize that they are actually drastically different games where different design decisions make death in most cases much less frustrating than death in a far-away location in VS. I love how you claim that what I said is false yet provide no explaination for why that is. Besides that, the fact that survival itself is an overarching challenge in survival games does not mean that any and all death punishment that affects prior player progress is free game. Expecting a roughly neutral outcome is exactly what the game conditions in the player by allowing to easily retrieve items on death, and the frustrating part is the process of getting back to those items or the consequences of those rare cases where you don't manage to do so in time. In the majority of cases, all items can be retrieved trivially, and it's just tedious and annoying if the way back is long, so death already has little weight and exploration has little tension compared to many classic survival games - The Long Dark, The Forest, Project Zomboid, Don't Starve, and so on. I don't know that most classifications would even consider VS to be a "true" survival game, though that also depends on whatever that term is supposed to mean in the first place, because it's more often used as a means of gatekeeping with no consistent definition. What exceeds the scope of the challenge in VS is not the death mechanics. It's the unnecessarily restrictive respawn mechanics which don't even do anything to make the game more challenging and tend to just be tedious, and the random loss of items which tends to just feel unfair and arbitrary when it eventually happens. Here's a fun idea to consider for you: respawn mechanics in Wilderness Survival are less frustrating than on Standard settings. Why? Because Wilderness Survival presents a different set of risks and consequences evaluated in a different context based on a different set of expectations. Death in Wilderness Survival is more punishing and respawn mechanics more random and more restrictive, but they are a better fit for the playstyle. You wouldn't even be aware of this "already established lore" if the mechanic didn't exist, and there is no internally consistent system or pattern which can be extended to respawning. There is nothing that we know of in the lore which forces respawn mechanics to be implemented in this very specific way or prevents alternative mechanics from being implemented. You're exactly demonstrating an even worse example of justifying a mechanic with lore - a circular justification.

Frankly, it is amazing to me how seemingly the more a design decision in VS gets justified with lore, the worse design decision it is. I mean, not that you're saying that it's good because it's justified by the lore, just a general pattern. There is a case to be made for mechanics to be informed by lore, but I've seen way too many cases across many games where developers seemingly ignore obvious problems or the community seemingly blindly defends the developers just because the mechanic is seen, in the extreme case, as some kind of sacred artifact that cannot be tampered with due to its lore significance. It is tedious and frustrating to have to slog a long distance to the point of death to retrieve dropped items, just to come out roughly even and not grossly negative, and that's assuming the items haven't disappeared entirely. The "solution"? Spend at least two temporal gears - one to set the respawn near wherever I'm active, and another to presumably reset it back to the long-term home. Or, you know, just circumvent it with commands. There are two very simple ideas that make me believe that the current design of death and respawn mechanics is misguided: heavy frustrators are the first priority for developers to address, a penalty that significantly exceeds the bounds of the challenge is an excessive penalty. This would be almost the exact same mechanic as Project Zomboid has, and it would inevitably end up the same - disabled in multiplayer. Even if you gloss over a range of problems and exploits that this would create, it is in most cases virtually impossible to regularly coordinate a larger group to sleep all at once without people just getting fed up with it. Fire arrows very much were a thing in the Middle Ages, although granted, their primary use cases are almost entirely absent from VS as it stands. The value of setting something on fire from a distance was often way too great to pass up even if a large portion of simple flaming arrows would extinguish themselves before reaching the target. Larger arrows with a cage holding something like hot coals were also a thing. And so were Chinese arrows which utilized resin-soaked cloth and gunpowder. I'm reminded of Rain World's explosive spears, which would be a blast to throw into a cave. If not purely cosmetic, then it seems to me that the most obvious pointer to what a monocle should do is just to make it related to the temporal mechanics. A "Lens", if you will.