MKMoose

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.

And all of that can basically be collapsed into my "some items like the shield may still retain some debuffs". It's not about large-scale choices on allowing the player to fail or whatever. It's about a simple design decision: given a specific design goal, do you want to punish the undesirable action or reward the opposite? Starvation - increasingly punish eating too little or reward consistency and variety? Weeds - kill off crops overrun by weeds, or give the player a benefit for removing weeds? Animal health - allow animals to starve and even die when neglected, or boost their productivity when fed consistently and cared for? Death - penalize the player for dying, or reward long-term survival? Creative building - penalize the player for spending time on building (i.e. hunger increase for chiseling), or additionally reward the player for it? Temporal storms - punish the player for hiding, or reward the player for engaging with the storm? Damage types - penalize the player for using the wrong damage type, or reward them for using the optimal one? Progression systems - create problems when using early-game items, or add more benefits to late-game items? Terrain traversability - focus on making some areas deliberately poorly traversable, or on ensuring that certain areas are as engaging and pleasant to move through as possible? Off-hand - penalize having items in the off-hand, or reward two-handed item use? This reward-punishment dichotomy is absolutely everywhere. In many cases, people just make the wrong choice when making suggestions, and that can often be seen in how the suggestion is received. I've just seen a dude suggest adding rats and mice with the only provided justification being that they should eat crops - but how about we maybe think of any benefit to the player? In many cases, developers also make the wrong choice, and are sometimes then surprised or confused when people don't like changes. A lot of the time, both a reward and punishment is preferable, because they can address slightly different problems and can create a deeper system when combined. In some cases, only rewarding the player for voluntarily putting in the effort is practically the objectively correct answer. In certain situations, implementing neither is the best solution. Merely penalizing the player is rarely the correct answer. Letting people enjoy mechanics really isn't that complicated. To a large extent, it's just about framing - psychologically, a reward tells the player "do this more often", which builds more consistent behavior, whereas a penalty just says "stop this" or "avoid this". We tend to perceive benefits more positively and seek them out, but also may get discouraged when losing them or lose intrinsic motivation as a result of consistent rewards, especially if they are seen as controlling. Penalties and punishment trigger stronger avoidance but don't actually teach the player what they should do instead, and don't build consistent habits - they can be a strong short-term motivator, but do poorly for long-term learning. These distinctions matter even if the end effect is ultimately the same. And regardless of whether you're rewarding or punishing, here's my simple recommendation: keep the scope targeted and intentional. A blanket debuff for simply having an item in the off-hand (which applies at all times regardless of what that item is) is not targeted and intentional, which makes its effects disconnected from the benefits of off-hand items. Besides the psychological framing I've mentioned above, there's also the balancing perspective - it is more straightforward to balance weapons as equal in one hand and buffed when dual-wielded (and then estimate the value of the buff to compare with other items that can be used in the off-hand), and I think it would also be more intuitive from the player's point of view. I think that in the majority of cases it is possible to easily determine which items should get the two-handed buff so that they would make sense in gameplay, both by analyzing existing gameplay patterns and by drawing from a realistic perspective: relatively obvious buff: a bow should be buffed with an empty off-hand, because it realistically simply requires a second hand to draw (and it's also probably the strongest candidate for an item which can only be used two-handed, which could be implemented by requiring the player to hold arrows in the off-hand), a spear used in melee combat should naturally get a buff when two-handed, an axe, a pickaxe, a saw, a shovel, a scythe, a hoe, an oar, and a fishing pole should quite naturally be buffed by the empty off-hand, because realistically they are generally more efficient with two-handed use, and there are no major conflicts with any other game mechanics asking the player to use their off-hand (additionally, I think it would be a good thing for theming and player engagement to incentivize stronger focus on separating tasks - when you're chopping wood or mining or fishing, make it look like it, instead of jumping in and out of it), buff when two-handed wouldn't make sense or isn't needed: a shortsword has no business being buffed when two-handed, because it can't really be two-handed - even if you try, you reduce your own reach by keeping both hands on the hilt, a spear and a sling shouldn't require an empty hand for throwing, which would also differentiate them from the bow, a knife is generally a one-handed tool, and it should be that way in the game as well, a chisel cannot be buffed when two-handed because it requires a hammer in the off-hand, several tools like a prospecting pick, a cleaver, a wrench or a crowbar just don't really need any buffs when two-handed, in part because they are only used intermittently, debatable cases: a falx is a bit unclear - I would personally love to see it get two different attacks (one-handed slashing, two-handed chopping, and similar distinctions could be made for some other weapons), but that would take a combat rework first; in the meantime, given that the falx and spear are the primary melee weapons in the game, I think that it would seem reasonable to contrast the two of them by making the falx work the same with or without an empty off-hand (and thereby also indirectly incentivizing the use of shields and other off-handed items), a hammer could potentially be buffed when two-handed for forging as a way to encourage collaborative multiplayer forging, but it's not really necessary and could be seen as penalizing solo players who need to use tongs at the same time, so I would lean towards avoiding undesirable incentives and not giving it a buff when two-handed, whether shears can be one-handed realistically depends on the shears - I would lean towards making them one-handed, although their current gameplay function of chopping branches off of trees tends to disagree, it really doesn't matter much for a prospecting pick whether it's two-handed as long as it's frequently used together with the pickaxe and the shovel which are both two-handed. In some cases, especially those where it can't be clearly defined whether an item should be one-handed or two-handed (hammer, shears, prospecting pick), separating out a light and heavy tool variant is an option if there is a good gameplay distinction that can be made out of it. In the case of the prospecting pick, allowing it to be used for regular mining albeit less efficiently than a full pickaxe seems like a reasonable idea, which would also make it a more enticing item to pack when travelling. The simplest way of implementing most of these is increasing mining speed and damage when using two-handed items with two hands. Some items like a bow or a fishing pole might need special effects. It doesn't seem to me that this would be a significant issue. Granted, I may be biased as the kind of madman who binds the hotbar to [1, 2, 3, 4, 5, Q, Z, X, C, V] and keeps the button to switch hand contents under the thumb, so I have the fastest off-hand in the West, so to speak. Doesn't work in some games that require the left hand to manage significantly more than movement and hotbar, but it works out very well in this case for me. Regarding baskets or bags in the off-hand, on the assumption that they can only be carried in the off-hand as I've described: pick up: [RMB while looking at the bag], just like the existing bags, and probably only when the off-hand is already empty, OR [switch hand contents while looking at the bag], set down: [Ctrl + RMB while looking at a viable location with empty main hand] (may or may not allow to switch to another item in-place), OR [switch hand contents while looking at a viable location] (should also allow to switch to another item in-place). Does it take any more than this? I would have to watch a new player interact with it to see how it feels, but I think it would work quite fine. Managing other items in the off-hand like lanterns is a slightly more complex matter, and it might be useful to just get some sort of modifier to pick up items into the off-hand or place them from the off-hand, but the current functionality is also quite fine by itself, and adjusting it to prioritize taking items like lanterns into the off-hand in line with the above controls would be fine as well. Point given, belts and similar stuff should just stay in their clothing slot. But I do think that belt attachment slots could be used for some purses or pouches that can hold a larger variety of items in small stacks, in large part to solve the problem of completely filling up four backpacks with jewelry and butterfly pins in RA, one or two of each per slot. But regarding the lantern, I think that having more limited dedicated slots for light would produce a more intentional balance than just allowing to hold light in the hotbar. If a lantern could produce light in the hotbar, then there would be almost no reason to ever hold it in the off-hand (especially as long as the hunger penalty is in place), unless its light level in the hotbar was completely neutered. If you only have two or three slots which can hold either a pouch or a lantern, then it's a much more meaningful choice.

One thing that I don't get about this whole discussion is just, why does everything need a penalty? Two-handed weapons and several tools could get a buff when using them without anything in the off-hand. Even if it produces the exact same end effect, it is prudent to frame things in the way you want them to be received by the player. Why just punish them for using a feature, when you can reward the player for using the feature intelligently? I think it would work nicely to promote a "I need to do work here, so let's set up and put away unnecessary items" kind of mentality by limiting the buff to specific tools and weapons, which the current off-hand penalty doesn't achieve at all. Some items like the shield may still retain some debuffs, but I don't think that should be the norm. A secondary benefit of buffing the active tool instead of just applying a broad debuff is that the effect becomes limited in scope to the activity the player is currently doing and only applies when the player is actually doing something, rather than making for this passive, nagging penalty at all times even if the player isn't actually using whatever they have in the off-hand. And regarding the torch, I think that (even without implementing the above) it would be a perfectly suitable solution to just remove the penalty and give the player more useful items to put in the off-hand to serve as the tradeoff themselves. There is a range of things that this could include: a knife, ideally both for combat and for cutting or harvesting things, a walking stick, greater variety of weapons and combat-related items that can be used in the off-hand, like a dagger, a small crossbow, different types of shields, baskets, bags or pouches that can hold items the same way that bags work in the bag slots. Any item the player has equipped takes away the option to use all the other items, but it is a choice that the player makes and benefits from, instead of just having to put up with a debuff no matter what. And if you want to bring up that the player shouldn't just be able to have something in the off-hand at all times, then go back to the first point about buffing certain tools or weapons when the off-hand is empty. Remember that specific items can apply a small penalty if it makes sense specifically for them. I think that dedicated ways to store specific items are likely an excess of complexity, and the hotbar is a somewhat gamified but simple, flexible and arguably necessary solution in a game that wishes to satisfy the preferences of more casual players and especially builders. I've had a very similar concept to what you're proposing, which started off from the idea I've mentioned to hold baskets in the off-hand. I would bring this set of changes to the table: Reduce the generic bag slots to only one back slot for backpacks only (including possibly frame packs and similar stuff, and likely also skeps or whatnot) as the primary determining factor for bulk transport. Add two or three belt attachment slots which could hold a purse or pouch for small tools and items (larger number of slots but greatly reduced stack size, potentially all the way to one), a girdle for larger tools and ideally something else as well, a quiver (possibly giving a draw speed bonus alongside arrow capacity), maybe herb or seed bags, maybe also lanterns, some Jonas tech or improvised devices. Change baskets and linen sacks to be carried in the off-hand. Naturally, some rebalancing may be necessary. In a system like this, the off-hand could play a much more interesting role than it does currently - for example, you could greatly increase your carry capacity with a linen sack on a stick or employ the off-hand for any range of purposes, but at the cost of possibly forgoing a different belt attachment in favor of a lantern. This way, the off-hand becomes involved in multiple context-dependent choices at different scales, the first when you're deciding on what to carry in the longer term courtesy of the overlap between the benefits of off-hand items and belt attachments, and the second on a more moment-to-moment basis.

Try this command: /giveitem lore-book-aged-orangebrown 1 s[] { category: "archives" } The book will automatically give you the next page you're missing from any series in the "archives" category, so you don't need to (and can't though it's possible) specify an exact piece of lore. Regarding customizing the command:

This is, indeed, the correct answer. Verified in practice and in the code - besides the firepit cost, there is no efficiency difference between different configurations of charcoal pits (or at least, there shouldn't be). That said, the inefficiency of small pits is not very significant - a tiny 2x2x2 charcoal pit (8 stacks of firewood plus a firepit) loses just 1.5% efficiency to the firepit (i.e. provides 1.5% less charcoal for the same amount of firewood as a maximum-size firepit would give), whereas a larger 5x5x5 charcoal pit loses a completely negligible 0.1%. The difference is so low that it effectively doesn't matter in practice as long as your charcoal pits are not laughably small. Even the smallest possible charcoal pit - a single stack of firewood with a firepit on top - loses 11.1% efficiency due to the firepit, which is nontrivial but not all that much. And by the way, the wiki is inaccurate since 1.21.0-pre.1 - each stack of firewood now produces 4 to 8 charcoal, 6 on average.

A single set of regular sails should provide 20 kN (up to 5 sets in a full windmill), whereas a single set of large sails should provide 25 kN (up to 10 sets in a full large windmill). It can vary somewhat due to a few factors (mainly how high the windmill is built and how much resistance is added on by other components), but as a general rule, a single full windmill (100 kN) is roughly the minimum to operate a helve hammer at tolerable speed without upgearing, though something more like 200-300 kN per helve tends to be recommended in order to allow faster operation at lower wind speed. When you upgear it once, you increase the speed five times, so the required power is increased proportionally - at minimum about 500 kN (five full windmills) per upgeared helve, but ideally at least twice that. Note: it used to be that upgearing the helve wasn't generally recommended due to its resistance increasing with speed. This has been removed in 1.22 as it was causing some problems, so upgearing is more viable now.

I was mostly in agreement with this a month ago, but as I've been looking into the features we have in VS, I've been increasingly disliking most arguments about anachronism. Restricting some features is naturally necessary to keep the game somewhat cohesive, but there is already quite the number of features that realistically have appeared around the time where firearms became common or even later, for example: bone meal, which wasn't really a recognized thing until the 17th century if I recall correctly, complete suits of plate armor, which only properly appeared in the 15th century, the cementation furnace, which comes from the late 16th century at the earliest, chromium tanning, discovered in the 19th century (this one really kind of baffles me). If we were to also consider planned features - most notably rail transport (roughly 16th century or later, though initially only on wooden rails, whereas iron rails apparently come from the early 18th century and steel rails were first produced in 1857) and the atmospheric engine (invented in 1712), mentioned by Tyron as the highest tier that VS may reach (steam engines more generally starting from around the 16th century but initially simple and inefficient) - then it's easy to get the impression that the target endgame time period seems to be around the 16th century or later, which would make it possible to introduce flintlock firearms with little to no concern about anachronism. And that's the flintlock, whereas earlier forms of firearms appeared in Europe at least in the 14th century, or in China as early as the 10th century.

As a general rule, the ToS or EULA for games and similar products prohibit the usage of one account by more than one person. Even if account sharing is not explicitly prohibited by the agreement, as is the case of Vintage Story's Terms of Service, the agreement can often be considered to implicitly prohibit it, if only because it's made with the person who registers the account and not any third parties. Even if it could be argued that you wouldn't be technically breaking any rules, account sharing is generally inadvisable, especially outside of immediate family or household. If your friend wants to try out the game, it may serve as encouragement that the refund policy for Vintage Story is significantly less restrictive than that of Steam and most similar services.

One thing that I think needs to be given enough consideration is that having to always carry water can easily end up even more boring than having to always carry food - while some juices and alcohols increase that variety somewhat, they cannot get even close to the variety that a culinary system can provide. It is worth noting that water content in food translate pretty much 1:1 to hydration, so it is possible (albeit rare in practice) to subsist on a diet of high-water foods with no additional water intake, especially when avoiding heat and physical exertion. Even foods with pretty average water content like cooked rice or beans still apparently have something like 60-70% water while providing ~100-140 kcal per 100 g, meaning that eating ~3000 kcal of them in a relatively high-calorie diet suitable for the seraph would provide you with ~1.5-2 L of water daily, drastically reducing the amount you need to drink separately. If you eat more vegetables and fruit or other high-water foods, then that can make it entirely viable to live with no additional water intake on top, though most people will also eat a lot of low-water foods. Naturally, separate water intake is more controllable and can be safer. I personally think, and I've seen quite a few people as well as at least one of the devs express similar sentiments, that thirst would likely be more fun as a nutrition-like hydration feature closely tied to heat and mostly limited to hot climates and the summer season, as a special challenge of sorts similar to how cold temperatures are generally limited to cold climates and the winter season. Regarding clean water, I have some doubts about how interesting it would be to actually engage with. One thing I will note, though, is that disincentivizing drinking water from random puddles may be a great way to increase the value of juice, alcohol and other drinks. I remember saying somewhere that a sufficient way to improve the nutrition system would be to just add a nutrition-like fat mechanic, maybe sugar as well, and possibly to separate protein away from nutrition, in the extreme case ending up with a fat-sugar-protein trio of special nutrition-adjacent mechanics with completely unique effects caused by surplus and deficiency, as well as unique consumption mechanics. The primary concern with this kind of mechanic and many other suggestions is that it's just another stat to track, which can easily end up pretty boring. An arguably better alternative that I've thought of recently would be to split satiety into the three primary macronutrient types - carbohydrates, proteins and fats - which would all fit into the single satiety bar, applying various effects depending on how much of each the player has. This would inherently create a tradeoff between the choice of which macronutrient to prioritize at any given time, since the total of the three macronutrients would all fit under a single maximum, making this system potentially much more interesting than just keeping a few extra bars at a high enough level. An additional improvement coming from changes like this could be that late-game large-scale food production wouldn't be going largely to waste, and instead food quantity itself could function similarly to current nutrition - the player may be able to survive on a smaller quantity of food than currently required, but eating more in the long term could provide various buffs. I'm ultimately unsure of what the best solutions might be here, mainly because they are closely tied to the intended gameplay experience, the intended level of realism, the food sources implemented in-game, and a multitude of other factors. Either way, somethingg to introduce more meaningful differences between food categories and make starvation less binary could be very useful in the long term. The main potential problem here is that injuries go well beyond the scope of the initial encounter. If the player were to take a week of debuffs to recover from a seemingly minor encounter with a wild animal, then that can easily feel dispropotionate or unfair. It would require a whole number of concurrent changes to many fundamental systems in the game, including death, entity AI, health and damage balancing, damage mitigation in combat, movement and/or world generation changes to mitigate excessive risks of fall damage, kind of just everything. Most of these would be changes that I would actually be very interested to see, but I frankly doubt that the devs have much interest in this kind of work. While I do somewhat agree with the idea, I don't really see the premise or goal. Why should subsistence on gathering be disincentivized and hunting forced? Foraging shouldn't be completely sufficient all the way into the endgame, that much is natural, but I would actually argue that gathering should be a fundamental part of the game supplementing other sources of food with additional variety that can't be easily obtained from farming. While foraging wouldn't be something particularly efficient, I do think that it should be reliable, to create a balance where the player could survive easily once they get a minimum grasp on the basics (keeping the game more approachable and reducing frustration with death spirals), but would be incentivized to invest in other food sources to reduce the overall time spent on food, increase the time that can be spent between meals, and overall gain more time for other activities, creating a better sense of progression.

The game keeps track of the last state in chunks which are not rendered and fast-forwards to the current time when you visit the area again, so your crops should grow perfectly fine. If they don't, that would qualify as a bug to be fixed.

If I recall correctly, the trigger only goes off on blocks adjacent to the block you mine. Your existing mines will not collapse by themselves, and if you expand them, the risks are the same as in a fresh mine, so you can try it in an existing world with little to no risk. I'm kind of biased against it, but my honest recommendation would be not to bother, because I think that cave-ins are a buggy and unfinished mess that should never have been added to the game in this state. If you want to try it either way, keep in mind that support beams only work one way, though I don't remember which way at the moment.