MKMoose

That's what bushes do as well, for the most part at least - fruiting bushes and deciduous fruit trees are implemented in a very similar way. As long as temperatures during winter go low enough to make the bush go dormant, it will always leave dormancy at roughly the same time each year and follow a mostly fixed fruiting cycle. If I remember correctly, the cycle length for bushes is: 3.5 ± 0.4 months for the four main growth stages, 1 ± 0.1 month ripe time, which may be affected by one of the traits as well as cut short when the bush is harvested (including eaten by animals). And if the next winter also makes the bush go dormant, the bushes will be synchronized again, just like deciduous fruit trees are synchronized by dormancy. Or when temperatures during winter are not low enough to synchronize them, then they become effectively random - this is in contrast to deciduous fruit trees which need to be vernalized in the dormant state to bear any fruit. What the game technically does is set the vernalization time to above the required threshold for some trees, which as far as I can tell just causes them to always vernalize regardless of temperature the next time it gets the chance. But the tree starts off young, and it only checks for vernalization once it enters dormancy, which only happens when the temperature gets low enough. The evergreen fruit trees in hot climates aren't related to the 1.22 change. They also spawn young, but their cycle is not restricted in the same way that deciduous trees are restricted and instead they just fruit at approximately the same time every year - as long as their flowering season is late enough in the year and their "non-flowering young time" is short enough, young evergreen trees will fruit just fine in the first year.

Note that blocking rifts, disabling rifts and blocking monster spawns are not quite the same effects. A small lantern can block monster spawns in a 10-block taxicab range as well as block rifts in a 15-block taxicab range. Do keep in mind as well that rifts are only relevant on the surface, so underground monster spawns can only be prevented by directly blocking monster spawns. A rift ward disables rifts in a 50-block euclidean horizontal range (disabling a rift makes the game still consider it as if it were active for the purposes of the maximum allowed quantity of rifts, so the effect is better than just blocking), but doesn't prevent enemies from spawning within a 20-block euclidean range of rifts. The rift ward also has a 2.5% failure chance (so a light source is always desirable in case the rift ward fails) and an upkeep cost of one temporal gear every 21 days. The rift ward is not completely useless, but it has no unique purpose as well as an additional flaw and runtime cost to contend with. In most cases where you are using the rift ward, you'll still want to use light sources to help with the 2.5% failure chance, or just for lighting - while exceptions are not impossible, I find that it is very rare at the stage in the game where rift wards become available that a player doesn't have or doesn't want to use at least a few lanterns. And the funny thing is that using light actually nullifies the extra advantage of rift wards related to them disabling rather than blocking rifts, so placing a rift ward in an already well-lit area has no effect. This is a fine suggestion - would certainly make the rift ward more flexible. I would also consider limiting the rift ward's uptime with the number of blocked rifts and not with time, as that would introduce a more direct relationship between cost and benefit. But that said, I personally think that the rift ward will never be an actually good feature unless it's given a unique purpose that is not fulfilled by light sources, at least as long as light sources last indefinitely which probably isn't changing anytime soon. The two most common suggestions for this are (1) blocking spawns in a small radius even during temporal storms and (2) increasing temporal stability in an area - both are essentially trivial to implement, and there are at least a couple mods which make some similar tweaks already.

You can put it in however many slots you feel like - the handbook tells you as much. Even when it says that "the pot is too small", it will work just fine. Using a residue-covered pot or mod interference are the most probable explanations.

It is probably the strangest detail to come out of the 1.22 update. There's been a number of conversations about it, at least one of the devs said that it would be fixed, some relevant changes were made in the code, a supposed fix was mentioned in the patch notes, and yet... nothing. I have found why the supposed fix isn't working - no tree can ever vernalize as long as it's young, and all newly-generated trees start off in the young state - but I genuinely have no idea how a seemingly completely ineffective change got through any sort of testing and into the patch notes. And I've identified a fix (may need some testing to make sure there's no unintended side effects), though I have no idea if I can get it into the game anytime soon given the extremely slow handling of Issues and PRs. Maybe I could make a mod out of it. I'm not aware of any current mods that do this, though I haven't checked exactly. A lot of mods make fruit trees ripen faster, which could be a suitable stand-in and potentially be removed from the world after the first year, but making them start off vernalized is evidently a less straightforward task than to change a couple numbers. If you want to start off with vernalized fruit trees, you could also try advancing the time by one year at the start of the world with /time add 1 year, though keep in mind that this can also have other unintended consequences. Fruiting bushes are effectively seasonal after the first winter, since all timers get reset and not paused during dormancy, provided that wintertime temperatures go low enough to make them dormant. In a rough test this first stopped occuring at roughly 13 °C yearly average temperature for currants (a bit lower for berries), which may be be ~6-12k blocks south from spawn most of the time if I did the math right (very roughly, as there's a huge amount of randomness involved).

If I recall correctly, you can get the eccentric gearbox from the refinery fairly often. There may be one or two more places where you can get a specific part, though I wasn't able to confirm. Some places in structures will have only Jonas parts, and some will have only Jonas sub-assemblies - but this seems mostly negligible in practice. Maybe the Jonas parts could be slightly more common, but I'm honestly not even sure if it's make any practically meaningful difference. Otherwise, it is entirely random, be it from locust nests, highest-tier monsters, bells, ruins, story structures or whatnot. To never hit 1/13 odds in 31 attempts is an 8% chance. Not a high chance, but it's more likely than breaking a tool on the first quenching. Frankly, uncontrolled randomness is one of my biggest gripes with VS. It could be really cool if different Jonas parts required finding some rare materials, looting a specific ruin in short story quest, killing a unique mini-boss during a temporal storm - but no, it's just random. And sure, the current implementation is easy and efficient, but it doesn't strike me as something that speaks to the game's quality or the developers' vision.

Storms only drop at most ~0.4 parts per person per storm if you're lucky, so you'd need a huge amount of time to accumulate any meaningful quantity of them. If you need to get a lot of Jonas parts, fighting near the mantle is the preferred option. Given that all thirteen parts are obtained almost entirely randomly, it would seem much more difficult to find people who got exactly what they needed right away. The rift ward does nothing that light sources don't, and still requires upkeep and has a small chance to fail, which means that you still need light sources in case the rift ward fails. Its only benefit is very high range, but I personally don't believe that saves it from being virtually useless. It's purely chance-based - 20% head, 50% torso, 30% legs.

The offset is relative to the origin of the structure as far as I can tell, and usually it's used only to hide the clearly underground parts of it so that it doesn't float. At 42 blocks of height, an offset 16 blocks into the ground will not meaningfully hide the whole structure. You might want to get acquainted with issue #10085. The other way around - the way it should work (though it's reportedly bugged, as mentioned) is that the minimum distance between structures within the same group is 10k blocks. So if you find one structure, then you'd know that there is no other structure from the same group within a 10k blocks radius. I would recommend that you just get the storage containers from them (primarily the entrenched one, because golden can also be found in another ruin) through creative mode. Or if you don't want to "cheat" for one reason or another, then your best option is probably to just wait and hope that the issue is fixed in the next update. They don't give maps for it. You're not really supposed to deliberately find them as much as you are supposed to stumble upon them occasionally while exploring. Though granted, the treasure maps and ruin exploration could readily be expanded as a mechanic. Also, clipping through the ground wouldn't help, because those are surface ruins.

Devastation be upon ye. The nutritional categories of Vintage Story generally use nutritional definitions for classification of food items. Or culinary definitions, since they are almost equivalent for the game's purpose, while the technically correct botanical classification is in this context practically irrelevant.

A survival-obtainable loam flower planter can only appear in one very rare surface ruin, and it's hidden underground. Pay special attention to large clusters (typically with church-like ruins), and try excavating under them a bit. If you want specific pointers, then I can get screenshots in a bit, or you can see the structure yourself by importing the schematic for the structure from \surface\religiouslarge\veryrare\chonky5.json into a creative world. While at it: If you're wondering whether flower pots and planters are available in the new colors (because you have question marks in the table for them, as well as for void for some reason), then no - those are only for storage vessels. Serpents can be found in one surface ruin, generally appearing in clusters with a couple other small structures. Golden can be found in one very rare ruin which only appears in large cluster, similar to the one with the loam planter (as well as in one extremely rare ruin, seemingly nearly unspawnable due to a bug - reported in #10085, open at your own risk due to potential spoilers). Entrenched can only be found in another special, extremely rare ruin, seemingly almost unspawnable due to the same bug.

The descriptive word is influenced by two factors: the ore map value - an under-the-hood map which decides how common ores are, which can be interprered as proportion of maximum possible commonness, the proportion of ore-bearing rock within the allowed Y ranges - how many blocks in the block column at the reading's coordinates within the allowed Y range the ore can generate in (this is why ores which spawn only in sedimentary rocks tend to have low readings, as sedimentary rocks are generally a thin top layer and the igneous stone below can't host the ore); this introduces a small random factor due to how it's calculated. For example, if the ore map decides that at the reading's location a sedimentary-only ore like galena ore has 60% of maximum commonness, and there is a 40-thick sedimentary layer with surface at Y = 120, given that galena is allowed to spawn at any Y level, gives you a 0.6 * 40 / 120 = 0.2 total factor, which ends up being "poor". For an ore like borax which spawns at Y levels of 44 through 110 only the blocks at those relevant levels will be considered, giving a 0.6 * 30 / 66 = ~0.27 total factor, translating to "decent". The permille value is influenced by the two above factors, as well as the following: the deposit's absolute average quantity of ore blocks - a rough estimate for the average quantity of ore blocks per chunk at maximum deposit frequency - this introduces a small random factor on each world load, the surface Y level, used as the denominator to estimate the proportion of ore blocks in the area. For example, copper has an absolute average quantity of ~4330 if I recall correctly, so for a total factor (ore map multiplied by rock proportion) of 0.4 and surface Y level of 120 it has a permille value of 0.4 * 4330 / (120 * 32 ^ 2) = ~14.1‰ (the 120 * 32 ^ 2 part is the equivalent chunk volume at the surface Y level). So, to answer your question: the permille value can be lower in spite of the descriptor getting higher when the surface level at the reading coordinates is higher, so there's more rock for the amount of ore. Sometimes the small random component which is reinitialized on each world load can also influence this. I would actually love to know how close I am in my estimate, since your Y level readout on the map seems dysfunctional: the "high" reading is probably Y = ~170-180, and the "decent" is probably Y = ~130-140. There are some possibilities which could throw it off somewhat that I can't account for. Feel free to ask for any clarification, since I'm probably omitting some details or assuming something is intuitive when it might not be. And keep in mind that the system can be a bit inconsistent or buggy in a few places. As a general rule, the better word tends to be better to mine at. There are some caveats, e.g. it's almost always preferable to avoid mining in the mountains for most purposes, but mining at the better word is a sufficient simplification for almost all purposes. In your case, the difference is quite minimal, so it's pretty much "whichever you like". Side note: there's generally no need to take density readings any more frequently than every ~100 blocks. The ore map doesn't change fast enough for a smaller movement to make a meaningful difference in the vast majority of cases.

I did all of the story on 1.21.7 for the first time, if I recall correctly. Hearing about the shenanigans from the original Chapter 2 release kind of makes me glad that I didn't experience it back then. Personally, I wasn't impressed even with the current state, and I somewhat wonder how much of the broad community sentiment about the Tower is influenced by a kind of "at least it's not as bad as it used to be". At the same time, since we have little other story or bosses in the game, almost no mods attempting anything of this kind, and there's not too many games similar to VS, it is easy to make assumptions and tricky to find relevant references to compare with. I feel like a large part of why this can be difficult to judge and somewhat divisive at times is that the Devastation does a large number of things at the same time, some of them very new and unusual - long travel, hostile region, somewhat puzzle-like or maze-like sequence, platforming section with a focus on a new ability, and a boss fight with a flying enemy. If its scope was more constrained then it would be easier to polish to a high quality and easier to judge in isolation. Technically, the RA kind of does this as well, but the RA is a pretty conventional dungeon which retains more similarity with regular gameplay, whereas Chapter 2 takes a lot more liberties. As far as I can tell, Erel used to have 1000 health, or 400 effective health because only part of it needed to be taken off, now it's 200 (or 196, technically) - less, because the total health was nuked. For reference, a nightmare drifter has 40, a bell has 100, and the immobilized eidolon has 500. Here's a funny thing: if you have high-tier plate armor, then Erel deals something like 0.5 damage per melee attack on standard settings, and the ranged barrage becomes almost negligible. It's entirely viable to just sit still waiting for the dive attack, get four or five melee hits in while the Crow is sitting there, and repeat until done. Without ever using any ranged weapons or the time switch ability. Now that we have the quenching and sharpening, you can easily increase the average damage of your falx by ~50%, letting you kill the Crow within 6, maybe even 5 dive attacks.

The enjoyment of the whole Devastation area when I first visited it was heavily brought down by several factors: I wasted a huge amount of time and resources on a couple of the floating islands. I've tested that they seem to all be technically accessible for all classes, but being regularly attacked by shivers and bowtorn on a parkour section which may require you to take off your armor to maximize movement speed is a miserable combination. I tried using the glider, but found it detrimental and frustrating if not borderline unusable for parkour because of #8198. After wrestling with it for a while on the small parkour sections I just ended up putting it away, and I effectively also had one less backpack as a result. I wasted a lot of time and resources in a couple places within the tower itself but especially on the parkour section, because the correct path felt very unintuitive to me in a couple places. It was actually quite good for the most part, but the few misleading or contrived parts contributed very negatively to the overall experience. The elevator is implemented in a somewhat odd way and requires to unlock each next floor manually with seemingly no indication whatsoever for whether a floor is unlocked or not, causing me to spend an unnecessarily high amount of time trying to figure out how it works. The huge distance to the tower combined with how much time the area itself took meant that I was running out of supplies, which meant that I had to hurry if I wanted to finish it and not have to come back later. Add to that two deaths exclusively caused by fall damage, add to that all the previous issues, and the place quickly turned from an interesting challenge into a frustrating slog. And at the pinnacle and culmination of all this effort was probably the easiest and most boring boss I've fought in any game for a long time. Granted, it was easy because I had tier 3 plate armor, so I lost at most maybe half my health while barely trying to dodge anything, but in lighter armor the fight can be pretty miserable if you don't cheese it. This is ultimately a fault of the combat system as a whole more than the boss specifically, though making the boss itself less janky and more reasonably balanced wouldn't hurt either. On subsequent attempts, I find it easy. But the first experience I had with it was anything but smooth, and that was after all of the relevant changes and improvements, so given the amount of time I spent initially on preparation I can't imagine most players find it much better than I did.

They despawn if you don't bother them for 15 minutes (or, well, if they don't then that's a bug): { code: "despawn", minPlayerDistance: 30, minSeconds: 900 }, Not quite "like any other mob", though, because (1) animals are persistent and it's only monsters that permanently despawn when too far away, and (2) bells' despawn timer is very long - for comparison, regular drifters despawn after just half a minute or less: { code: "despawn", minPlayerDistance: 32, minSeconds: 30 }, { code: "despawn", minPlayerDistance: 64, minSeconds: 6 },

ConfigKit is the closest alternative that I know of, but frankly, it is not a popular option in spite of an attempt to improve upon Config Lib and not just replace it. Integrated Mod Manager is a slightly different solution which seems to have gained much more traction, though it doesn't seem to be a drop-in replacement.

The intended option for this seems to be the Selectable Collider meta block - use Ctrl + F to render meta blocks when using them. Chiselled glass is a suitable survival-friendly alternative, though it's not perfectly transparent. We don't seem to have an exact equivalent to the barrier. For your purpose, the Selectable Collider seems most suitable, but it's different in that it can be destroyed in survival unlike the barrier (would probably need a land claim to make it indestructible in survival). The regular Collider meta block is a similar alternative and it can't be destroyed since it can't be targeted, but unlike the barrier it doesn't prevent block targeting through itself.

Having minor crosshair drift during the grace period doesn't have to encourage frame-perfect release timing, because the crosshair drift would presumably be active right as you start drawing the bow, not just while at full draw, so you'd need to readjust your aim no matter what. "Neutral" in the sense of "neither positive nor negative". Simply part of the system, not something to be avoided, not something desirable - just a mechanic which you need to take into account when using the bow. A useful middle-ground could be quick and short crosshair drift which is only active initially when drawing the bow, followed by a zero-drift grace period to give the player a moment to readjust their aim more easily. Having a zero-drift grace period is not necessarily a bad thing, and it would work quite fine. That said, I think it can be argued to have several flaws: Within the optimal time to release the arrow, crosshair drift does not exist - this means that as a mechanic it becomes primarily if not only a punishment to less experienced players, while for practiced archers it is very nearly irrelevant. I believe it would be ideal if skillful hunting was about achieving high accuracy in spite of crosshair drift, not about being fast enough to avoid it altogether. Especially when aiming at stationary targets (a very common occurence in hunting), you can line up the shot well before you draw. This means that the player doesn't really have to learn how to aim with the bow at all. They can just point the cursor, then draw and release the arrow immediately as it reaches full draw with no strings attached. This also means that the grace period loses its purpose against stationary targets - it is intended to be a time-sensitive window to aim after drawing, but if the player can aim beforehand then they don't need that grace period and can just loose the arrow immediately regardless. Unless significantly restrictive stamina mechanics are implemented as well, you can just cancel the draw and try again however many times you want - this renders crosshair drift doubly irrelevant. Because crosshair drift is entirely avoidable and only relevant when the player does something "wrong" (keeps the bow drawn for too long), players are not encouraged to learn how to counteract the crosshair drift or account for it - they are only encouraged to avoid it. A mechanic that is intended to be avoided does not immediately strike me as a particularly well-designed mechanic. Introducing quick, short crosshair drift when initially drawing the bow (just to throw off the aim slightly, still with a zero-drift grace period afterwards) would be an easy way to partially address these potential issues and a reasonable middle-ground. Having to readjust your aim a bit would certainly take more skill and practice than having no crosshair drift at all, especially against stationary targets. Introducing light crosshair drift to the grace period would address these potential issues mostly if not entirely. I think it would make aiming noticeably more engaging with little risk of being unnecessarily difficult or frustrating, as long as it is relatively minimal relative to the increased drift after the grace period, just enough to make the player slightly readjust their their crosshair and pay attention to their timing. You have two standard methods: You can quickly readjust your aim at any point and hope that the crosshair drift doesn't throw off your aim at the last moment. As long as the drift is reasonably slow and smooth, this is a suitable strategy at short to medium range, especially if you need to make the shot quickly. This strategy is still viable even if crosshair drift is purely random. Taking note of the more predictable periodic oscillation, you can identify the phase in which the crosshair is more stable, and anticipate where it will be the next time it's more stable. In the case of simple vertical oscillation, the crosshair is more stable at the lowest and highest point of the sine wave, so you'll want to loose the arrow when the crosshair is at the lowest or highest point of the wave and not when it's moving more quickly between those points. An additional random drift component means that you may still have slight last-moment adjustments to make. This is the preferred strategy for more accurate long-range shots, and it is not possible with purely random drift.

It is close to what I might consider ideal sway mechanics, with a couple caveats. Note that as it is currently implemented, releasing the arrow early is nearly impossible - that's why I was saying in the post above that shooting as fast as possible comes with little to no accuracy penalty. I'm not sure on the exact timings, but the interval between the minimum time required to actually loose the arrow and the time when the bow is "fully drawn" (accuracy reaches the maximum, not accounting for the tiny pulsing which activates a bit later) is so short that for most purposes it essentially doesn't matter. In my brief testing, attempting to loose the arrow as fast as possible seemed to produce a roughly 10% larger spread than full draw. Adding a more meaningful interval at which the bow is partially drawn would be absolutely reasonable either way. Some games still allow to shoot from partial draw with full or almost full accuracy, but lower arrow speed and by extension lower range and presumably lower damage. It could be interesting to in some way emphasize partial draw as a legitimate strategy instead of a mistake. A very short grace period would be reasonable for some of the heavy ones, but I think it doesn't seem appropriate for light bows, in part because it may not be particularly approachable to newer players figuring out the mechanic, so I would be strongly in favor of varying the grace period duration between different bows. If you look at real-life archery, it seems quite normal to aim and keep the bow drawn for potentially up to a couple seconds to line up the shot properly, even with traditional bows - granted, it may also depend somewhat on when exactly you consider the bow fully drawn. Another thing that some games also do is have relatively high sway normally, and allow to hold breath to greatly reduce it for a couple seconds - and if you keep holding your breath for too long, the sway increases back up potentially beyond the base value. Certainly not something I would insist on for VS, but it could be worth considering. It also seems more appropriate to me to have a small amount of drift at all times to require a bit more attention right from the get go (especially if the grace period is extended for lighter weapons), since having no drift at all by default could also push the player to rush their shots before it kicks in, or make them keep resetting repeatedly. Having no drift at all in the grace period would easily cause people to view it as something bad to be avoided, potentially making people avoid learning how to deal with it at all, whereas making it inherently unavoidable in a small capacity would allow it to be seen less as a punishment and more as an integral, neutral part of the system. It doesn't have to be strong, of couse - enough to keep the player from completely ignoring it, but not too much, as we certainly don't want to make aiming difficult or frustrating. Having no drift at all initially would also mean that achieving perfect accuracy on a stationary target would be completely trivial, because you could just aim before drawing the bow - some small drift seems borderline necessary to me, at the very least while initially drawing the bow. This seems rather nonspecific, since the severity of the sway caused by alcohol depends entirely on how much you drink. I would say that roughly what you get after 1 L of wine (0.15 intoxication, you can also set the same value with /e cmd s[] setattr float intoxication 0.15) would be around the maximum reasonable drift for the initial phase right after drawing the bow assuming no breath mechanics (likely prefer closer to 0.05 if vital areas are introduced to animals), and I would avoid anything higher than ~0.5 intoxication, even after holding a heavy bow for a while. Naturally, this also depends on how fast the drift is - faster drift generally needs a smaller amplitude, and the alcohol-induced sway seems a bit too slow to me. Also, I would like to stress that purely random drift is generally undesirable, as a partially-predictable vertically-oscillating pattern tends to be much more satisfying. It makes it more straightforward to anticipate the crosshair movement a shory moment ahead, and a small random component keeps it unpredictable but doesn't make it as frustrating as purely random drift can be. To summarize the most important changes that I would make: Ensure that light bows have at least a couple seconds to make the shot - a fraction of a second grace period seems only appropriate for heavy bows. Add minor crosshair drift active at all times when aiming the bow - an integral, neutral component of the system, not just a penalty that needs to be avoided. Make the drift partially predictable with vertical oscillations rather than purely random. Other than these caveats, I like this a lot. I particularly like integration with a potential stamina mechanic and the idea to give different bows a varied maximum-accuracy interval.

Oh yeah, this is a very important part of it. A clean kill can provide a bit more meat, better trophies or higher payout, both in games and in real life, but the psychological satisfaction and relief alongside ethical considerations can be a huge factor on their own. Though as I see it, there are three broad animal groups which warrant a strong distinction: Large game and megafauna - I do generally maintain that these should practically always require multiple shots, as that could produce an interesting, distinct category which would favor different hunting strategies, most notably endurance hunting, something akin to drive hunts, and group ambush in multiplayer. This may invite other forms of balancing - instead of skittish and fast like most smaller animals, these may be more defensive or territorial. Could favor heavier weapons, that is primarily spears, crossbows, possibly firearms. Medium game, though that can be fairly loose depending on definitions - I do agree it would be ideal to allow a clean one-hit kill here in most cases (preferably only or primarily when hit in the lungs), albeit I would prefer to avoid instant kills on the spot. Tracking mechanics are a good opportunity to increase mechanical variety and add an interesting tension-release loop, not to mention realism, and I think it would be a shame to skip that step entirely. There's no need for tracking over hundreds of meters (unelss as a sort of punishment for missing vital organs), but most animals should be able to run at least a couple dozen blocks after being hit in most circumstances. The bow may be preferred here by virtue of superior effective range. Small game, including birds - This is where an instant kill on the spot makes sense, even for relatively light weapons, making for simpler and more accessible hunting targets. The small animals (except flying birds) could be slow to give new players an easier target, but may also use a sort of hiding spot system so that they're not completely trivial. These would also likely be the primary target of trapping if that ever gets expanded on. The sling may excel here as a cheap and accessible weapon which could still one-tap most animals despite having little to no bleeding. The advantage of this kind of separation (though in practice it may still be quite blurry, naturally) is that it has the chance to introduce a lot of variety to what otherwise would be fairly samey hunting and give different weapons a chance to shine in different scenarios. That variety would reinforce different player preferences and playstyles as well as it may be influenced in interesting ways by climate, biome and time of year. I've recently checked out Combat Overhaul's aiming mechanics, so I cannot blame you if that's what you know crosshair drift for. Bullseye's crosshair drift is fast, purely random and jittery, whereas the standard implementation is smooth and periodic vertical breath with slow horizontal random sway. But this also means that I have little reason to take any of your pushback seriously until I know we're talking about the same thing. And you're not giving me that reason, in large part because of the insistence that crosshair drift would meaningfully affect rapid long range shots which is patently false. For quick shots, crosshair drift is very nearly the same as just a tiny bit of projectile spread. At short range, it practically doesn't matter. Assume one block of maximum deviation due to sway at a range of ~50 blocks. Even if you completely ignore it and just aim with the cursor in the center of the screen, this is about exactly the same as the current random spread (up to about one block of deviation at 50 blocks, assuming a longbow and no accuracy buffs) or even better since the current spread is uniform. This is very similar to what Combat Overhaul uses, though preferably at least smoothed, ideally slower and autocorrelated. For some context, this is ~4-5 times worse than what traditional bows in theHunter have when holding breath - different game, naturally, but a notable comparison nonetheless. At a range of ~10-20 blocks, this is just 0.2-0.4 blocks of maximum deviation. If you're in a situation where you have to rush multiple shots, then whether you're able to accurately put the cursor on the presumably moving target is almost unaffected by fraction-of-a-block inaccuracy built into the weapon. As much is true with the current projectile spread, so this would change nothing at worst and could easily actually make aiming much simpler. As it is implemented currently, shooting as fast as possible comes with little to no accuracy penalty. I would think that intuitively encouraging the player to take their time with aiming would be universally considered a good thing, as opposed to having very nearly zero mechanical accuracy difference between slow, careful aiming and frantic arrow spam.

The malefactor's sling as well as the hunter's crude bow and arrow are arguably pretty disappointing, because both are overshadowed potentially within minutes of obtaining them. They can be useful in the early game, but they change little in the long run. Because of this, I generally have some strong doubts about class-restricted primitive items, as they easily seem somewhat contradictory and potentially even pointless - if it's simple or primitive then why should it be class-exclusive? The one way that I think this can make sense is when the changes reinforce a specific playstyle or modify the progression path in a meaningful way - the malefactor, for example, could in some way get the ability to repurpose scrap found in ruins (not unlike what @ifoz has been arguing for) and potentially even use it as an alternative source of some metals instead of mining. Similarly, expanding on trapping and letting the malefactor focus on it particularly strongly would let them occupy a more distinct niche in the protein space, presumably with a particular focus on small game as a result of both trapping and the sling, which may have a range of additional implications as well. I personally feel like no class will really be unique if it doesn't actually shake up the gameplay in a more significant way. As long as each class is just slightly better at one or two things, slightly worse at one or two things, and maybe has one or two unique items, the ultimate result is mostly just that some parts of the game feel a bit smoother and some parts are a bit more annoying or time-consuming. I could forget which class I'm playing and it wouldn't make much of a difference. This especially applies to singleplayer where there is no opportunity for specialization between players, so there's a lot of things (especially related to the main progression line) that the player simply has to do in the exact same way regardless of class traits or preferences. And it's not strictly undesirable, to be clear - it's certainly easier to design, and sometimes the flavor, lore or aesthetics alone play a large enough role to justify classes. I was wondering if it would be desirable to group the playable classes into two primary buckets, or along an axis, with significant gameplay changes as a result of this - those who can survive in the wilderness on one end (malefactor and hunter especially), and those who rely strongly on infrastructure on the other (clockmaker and tailor especially). Some other distinctions of this kind could me made as well. This would have larger-scale effects on which mechancis different classes can use or use efficiently, for example: Some classes may be able to forge small quantities of metal relatively easily, others would be unable to do it and greatly benefit from an early-game tilt hammer. Some classes may know how to make crucible steel in small batches, others would prefer a large helve hammer and cementation furnace for steel processing. Some classed may be able to more readily survive off of foraged foods, others would rely on quickly establishing a garden bed and farm. Some classes may know how to quickly produce a variety of useful items from simple materials like cordage, sticks and tree bark, others would rely on special workstations and more advanced materials. Some classes may be able to dress an animal efficiently, others would need a butchering table. A lot of this stuff could also be integrated into the game without any class distinctions, of course, leaving the player to choose their own strategy. But one thing I've found is that if there are some easy and universally useful strategies (not to mention mandatory progression milestones), then I have no reason not to use them regardless of the class I'm playing, so that's why I had the thought to integrate some relatively fundamental progression changes into classes.

I could see a pottery wheel, powered manually or possibly with mechanical power, as a way to simplify and speed up clayforming. The easiest way to implement a pottery wheel would be to just abstract away aiming at individual voxels and say that the pottery wheel automatically forms whatever shape is needed, not unlike the Simple Pottery Wheel mod. This has two potential problems: it is just better over regular clayforming in every respect and takes the brain almost completely out of the process, it works for every form, which doesn't really make sense given that a pottery wheel is only reasonably usable for simple objects symmetrical around a central axis - but a restriction would also mean that items which can't be made on the pottery wheel would have to be done with regular clayforming from scratch regardless of whether they are completely unsuitable or just deviate by a couple voxels. Another alternative is letting the player place full rings of clay voxels around the center of rotation while using the pottery wheel. Placing such a ring could normally be restricted to placing directly on a ring which exists on the previous layer, requiring then to push the ring outwards or inwards in some way. This could tolerate minor irregularities to allow the player to build most of the shape first and then clean up or add a couple extra voxels when needed - though it would certainly require some changes to the way clayforming works under the hood.

It seems to me that the "Vintage Story isn't solely about hunting" idea can be readily used to actually justify adding crosshair drift to bows and making hunting more immersive. Because if the player doesn't like it, they could always try a different ranged weapon for the same or similar purpose (crossbow, sling, spear, ideally balanced in such a way that different ranged weapons are most suitable for different animals) or a different meat source altogether (trapping, fishing, animal husbandry). I would argue that the variety could be very beneficial for the game in the long run, letting new activities feel much more fresh, unique and individually engaging. I don't see how crosshair drift would ever be an issue with making several rapid shots. Frankly, I feel like you're again assuming it would be much worse than what I had in mind. Even glossing over the fact that rapid shots are usually only required at short range where neither projectile drift nor crosshair drift matters particularly much, what you're saying feels kind of like you're comparing a bow with crosshair drift to a perfectly accurate bow, which inevitably produces a skewed result. If you instead compare a bow with crosshair drift to a bow with roughly equivalent projectile drift, then I think you ought to find that the bow with crosshair drift is better, or at least isn't worse - if only because pure randomness can't really be counteracted given constant conditions, whereas crosshair drift can be accounted for. Projectile drift can be very unsatisfying at a quite fundamental level because the player can't do anything about it besides getting closer to the target, which is largely intentional for my idea of crossbow balancing but is the opposite of what you'd want for the bow. Crosshair drift in the extreme of rapid shooting is almost the same as projectile drift, but still allows you to be more accurate with some care and practice including at long range when you're not rushing every shot. You could even say that keeping calm and not rushing is an integral part of the more skill-based nature of the weapon. Keep the crosshair drift at a reasonably low level, and it will be just fine. It is primarily intended as a way to introduce a skill factor to shooting at medium range and beyond, and if it somehow makes shooting unpleasant or unsatisfying then that's something to fix, not an inevitable side effect. I don't see much of a problem with setting up the expectation that it's possible to kill many animals with a single shot, as long as the player is given the means to do so reasonably reliably without an excess of randomness or whatnot. It's a pretty neutral design decision, so it has some advantages and it has some potential issues which can and should be accounted for. "Skyrim had a problem with it" is a pretty weak argument, so I'm gonna need you to elaborate on why that problem is relevant to VS. If we're talking rust monsters, then that's a different kind of balance which has to be considered largely separately from hunting, and I wouldn't really push for any one-shots here. The fantastical nature of drifters makes it possible to reduce the effectiveness of bleeding on them and to adjust their health or damage resistances somewhat arbitrarily, which can be extremely useful for balance. If we're talking about realistic hunting, though, "dropping most targets with a single shot" is generally almost a given, though also an oversimplification. Small animals like hares and foxes, sure, you may be able to kill those on the spot if you use a powerful enough weapon. Something larger like goats, pigs or deer would pretty much always need tracking after the first shot, possibly a second finishing shot as well or more if you're using a relatively weak weapon or if you aren't hitting the lungs. Larger animals like moose, bears or (hopefully added at some point) bovinae should require multiple hits from all weapons besides maybe specialized late-game firearms. The damage type should probably matter greatly as well. Slings with blunt projectiles may deal high direct damage but apply little to no bleeding, making them particularly suited for killing small targets on the spot. Bows would focus much more on bleeding, with very high potential damage per shot applied over an extended period of time, making them particularly useful for medium game which can't be reliably killed on the spot, but can be killed or greatly weakened through blood loss from a single arrow. Crossbows and spears would lilkely land somewhere in-between and could be balanced in such a way as to make them the preferred choice for large game (in part because large game isn't necessarily as skittish and as such can be approached more easily and hit from close-by, reducing the need for the bow's superior range). Shorter range and more pronounced projectile drop is essentially the same as low projectile speed (assuming gravity remains constant), which as I mentioned is entirely possible to counteract, especially on stationary targets which are very common in hunting. Damage falloff has the problem that it doesn't really communicate anything to the player, especially in a game with no damage number indicators. A successful hit is clearly successful, so reduced damage often feels somewhat artificial. If the goal is discouraging long-range shooting, then I would argue it would be much better done with intuitive unreliability, not with forced ineffectiveness. That said, some minor damage falloff would be entirely acceptable or even desirable as an additional incentive, just as long as it's not excessive.

Feels like a matter of preference. I've enjoyed more methodical shooting mechanics, for example as found in hunting games like theHunter, and camera or crosshair drift tends to be fundamental to the experience in those cases. Besides accessibility (which we've discussed already, by the way), I don't personally see much reason to avoid mechanics which, as I see it, are pretty much just better - more immersive, more actionable and learnable, more difficult to blame for the player's own failure, more realistic in large capacity. I'm also thinking that "crosshair drift" may not be the ideal term for a few reasons, but frankly I have no idea if there's any better name for a moving aiming point (the crosshair may stay in the center of the screen, and the camera doesn't move). While I can understand not wanting crosshair drift active at all times, do keep in mind that both bows and crossbows need to have some manner of inaccuracy in certain situations or at certain stages of the process. In those cases, I personally think that at least a small amount of crosshair or camera drift mixed in is almost always preferable over simple projectile drift: possibly when raising or drawing the weapon - pulling the crosshair up over roughly the first half of the drawing animation instead of it immediately being there is mostly just a neat optional detail, when starting to aim - both crosshair drift and projectile drift are fine here, as the primary job here is for the crosshair icon to communicate the optimal timing to release, while moving - the crosshair bobbing up and down with each step is fantastic feedback to the player which for the most part can't be communicated adequately with a projectile drift indicator alone, while holding the draw for too long (at least for the bow) - crosshair or camera drift, especially downwards drift in some capacity, just makes more intuitive sense than the weapon's accuracy becoming arbitrarily lower, possibly while turning the camera - both crosshair drift and projectile drift as well as several other similar solutions could be used here. I don't know what you might be imagining when I say that the crossbows could have projectile drift, but I don't mean anything significantly worse than the bows as they are currently in the game. Maybe a bit worse for the most unwieldy crossbows, but not by much. It is intended to prevent reliable long-range sniping, not make crossbows "unreliable even at close range". The thought process is simply as follows: Bows should to be skill-based => bows need to have crosshair or camera drift, which is the standard somewhat skill-based aiming mechanic and requires careful shot placement. This doesn't mean that the bow can't have projectile drift, but it should be low enough to avoid interfering with the bow's long range and already-difficult aiming. Realistically, a crossbow is more accurate than a bow, and it is obviously easy to aim => crossbow should have little to no crosshair drift. A crossbow shouldn't be able to outrange the bow as a result of pinpoint accuracy => add some projectile drift to the crossbow, just enough to make it unreliable at long distances. This can be largely done with lower projectile speed, but low projectile speed can also be accounted for with some practice, especially against stationary targets which are very common in hunting. Projectile drift, on the other hand, generally cannot be meaningfully counteracted with skill.

I think ultimately a good way to go about it would be to do it roughly the same way that the Crossbows mod did it, where each crossbow tier corresponds to a different crossbow type and may be in some ways distinct - and one of those could well be a gastraphetes with some unique selling point of its own. If each next tier is just better, that's boring, whereas if each next tier has some unique purpose, that can provide a lot more gameplay variety. I don't know what the devs' stance might be, but with the things that every class can do, among them forging especially, most class restrictions are pretty difficult to properly justify with anything besides gameplay purposes anyways. I find that a class restriction makes the most sense for an advanced and unique but not strictly superior variant of an item, not unlike the tuning spear, hence the idea for a mechanical crossbow which can pull back the string automatically, albeit slowly. It could be lighter than most crossbows, possibly even one-handed (because most other bows and crossbows should be made two-handed), and it would be pretty much the epitome of a convenient and easy-to-use ranged weapon. Especially if we were to lean into the "dealing with mechanical creatures" part, I would be also interested in (admittedly pretty far-fetched) sticky bolts with some kind of small improvised stunning device attached. A more utility-focused crossbow bolt would pair beautifully with a self-drawing crossbow, and it could be very effective against bells. Would probably need to be careful not to give too many things to the clockmaker, though - they could still really use clocks at some point. I find that this would actually be a great thing to implement both for bows and for crossbows, alongside some manner of crosshair motion (primarily while the player is moving to throw off the aim, because we don't want perfect aim while moving). Frankly, it is difficult to really think up any proper means of distinguishing bows and crossbows mechanically, because apart from relatively obvious differences like fire rate it can be very difficult to figure out distinctions which make sense and also reinforce a desired gameplay niche. For example, it is easy to make an argument for @PineReseen's suggestion to make the crossbow more suited for defensive or ambushing gameplay - but then the hunter class, which should probably favor a bow, would get the weapon which is more suitable for open combat than for hunting? I would propose that an arguably more practical method of distinguishing bows and crossbows could lie in range and bleeding. Bows could be tailored better to combat at long range, and by extension also better at hitting animals before they detect the player. The skill-based nature of the weapon could be influenced by crosshair drift, which requires much more careful aiming than the crossbow's more stable crosshair, but is rewarded with greater range. For the sake of hunting, I would argue that the bow should also have lower direct damage but apply a stronger bleeding effect, if that is ever added. Crossbows could be more practical at shorter ranges, especially in direct combat, in part because of low projectile speed which is often corollary with short range. Having high direct hit damage with low bleeding would be especially useful for quickly dispatching high-risk enemies. The low-skill nature could be emphasized with actually higher projectile drift, further directing the player to use the crossbow at relatively short ranges. The gastraphetes specifically as originally described would naturally become a hybrid which has the relatively low range of a crossbow, but higher fire rate and less damage in favor of stronger bleeding. While at it, some thoughts on other weapons: Spears, to me, should have their damage and charge time significantly increased. The core idea of throwing a spear is that it should be a commitment, in two ways. First, lose your weapon, gain a benefit - this one's pretty obvious. Second, charging up the throw should be a risky move which exposes the player to attacks, and for that it needs to be much slower and ideally also reduce movement speed while charging - as it stands, you can just charge a spear in the middle of melee combat pretty much risk-free. Firearms to crossbows are kind of what crossbows are to bows - even higher damage, even longer reload time, lower accuracy. In the extreme implementation, they could be essentially an expensive get-out-of-jail-free card, and care would need to be taken to prevent this from going too far - the player shouldn't be incentivized to carry multiple guns and delete bosses in a matter of seconds. Reducing direct damage but adding high bleeding could ensure that high-tier enemies are not killed instantly on the spot, and making that bleeding only partially stackable would ensure that multiple rapid shots don't melt bosses excessively fast. Slings are a pretty odd weapon, because it kind of feels like they should be even more skill-based than bows, though their skill is much more so a matter of timing. They have a very distinct flavor, so it's not really possible to place them in a clear spot in the overall balance - they are kind of just different, and they can also be very flexible with different sling types and different projectiles. The best thing that I think could happen to them besides a general revision of how they work at a more technical level is the addition of ceramic (stunning) and leaden (high-damage) sling-bullets.

This one's because the structures always spawn in a quite narrow range, and if it happens in an ocean then that's the result. Seems like it should be relatively easy issue to fix by placing a continent there and not just a measly island, but alas. That's a bug as old as the village, unfortunately, GitHub #5469. Though it is unlikely to actually fix the problem, you could apparently try getting the trader you're currently looking at to restock with the /entity cmd l[] setattr string lastRefreshTotalDays 1 command. That will make their restock timer more normal, but the restocked items will most likely still be very wrong. The command will also apparently crash the game if the trader's UI is open or when used twice on the same trader, so use at your own risk. It is seemingly a pretty annoying bug to track down, because it only happens rarely and there are no clear reproduction steps. Out of curiosity, what mods are you using if any?

It is a feature of meals and pies specifically (not bread, not individually cooked food items), and the effect can actually be decently strong (even a small portion of a hot meal can raise temperature by up to 5 °C, so it can be useful to eat fractional servings frequently). But, if you do have a hot meal on yourself, then it probably also means that you have a firepit which will warm you up just fine - or if you don't have a firepit, then the meal will go cold quickly either way. Though with that said, given how massive the satiety multiplier and spoilage time extension from meals and pies currently are, I'd be careful about making them even more useful. Cooling with drinks is definitely the more important half of this idea. If we wanted to make cold climates more interesting or make fire a more integral part of gameplay, what could instead go a long way is toning down the effect of rooms which currently makes it impossible to freeze, making animals and/or drifters afraid of fire in some capacity, and probably related rebalancing to a few other parts of the system. Arguably the biggest issue with the current nutrition bars is that they are completely independent from each other and almost entirely self-contained. The optimal strategy is to just keep all of them as high as possible all the time. What makes macronutrients as I've described them potentially much more interesting is that they would fit under a single satiety bar, which means two things: The perceived complexity of a single bar which can be filled in a few different ways may be lower than multiple individual bars, even if it is actually more complex. The shared ceiling means that the player can't just max out all stats, and instead has to choose between different food types in some capacity. While the nutritional categories do incentivize some variety by requiring at least 5 distinct food items to keep everything high, the variety which they incentivize can get somewhat boring simply because it doesn't have any tradeoffs or priorities and as such it is independent of any context. You just have to eat some minimum amount of every food type on average. On the other hand, having to choose between a couple food categories depending on the situation that the player is or is about to be in would (if balanced appropriately) have the chance to create much more dynamic gamepay where the food choice is a more significant part of short-term decision making. The difficult part is preventing one food category from being optimal all the time or preventing specific situations from having an obviously optimal answer which can actually end up reducing variety, as that requires some deliberate and restrained design choices. All that said, while I do think macronutrients are a very notable alternative or addition to nutritional categories and satiety, it is certainly not something I would insist on. The other changes I've described above which focus more on food availability and spoilage may have a much better effect on food variety. Side note: taking this general concept further could land you at "buff foods" - specific items which provide less satiety (or even no satiety at all in certain cases) but apply some unique effects specific to these foods. This could be a bit gamified and include primarily certain difficult-to-obtain foods like rare fruits, cheese or whatnot, but there are also some cases where it could even be quite realistic - various drinks including alcohol most notably. The most obvious effects include temperature resistances, health regeneration similar to the existing saguaro fruit, and of course intoxication, but a lot of other options are there as well. The main advantage of providing little to no satiety is that it would be impossible to check multiple boxes (satiety and a buff) with regular food, and as such the buff item would effectively be almost like an additional, flexible nutritional category providing different buffs depending on which specific foods you've eaten recently. This could actually be a pretty interesting if gamified direction to go into with hydration.