MKMoose

As per the Wiktionary, a vug is "a small to medium-sized cavity inside rock that may be formed through a variety of processes." In the context of Vintage Story, it's just a small empty space (usually ~3-5 blocks in diameter, from what I've seen) inside of quartz or olivine veins, which contains large crystals.

No, it won't. Rhodochrosite is a regular ore, while amethyst is a vug which generates using a separate mechanism (it's just a structure, technically). Yeah, they're the same thing. If you've found them in caves, that's probably because a cave happened to go through a vein. Big crystals generate within vugs. Amethyst vugs only generate within underground quartz veins. I'm not sure what "underground" exactly means here and if they have any additional generation requirements, but there doesn't seem to be anything else in the JSON definitions. For the best chance to find amethyst, you should just search through underground quartz veins (ideally thicker ones), presumably by digging tunnels every three blocks within them. You may also be able to find a bunch of gold and silver this way. Do note, though, that amethyst is the rarest of all the crystals, so it's not gonna be quick and easy.

Tyron has said a few months back that "the next update will probably have iron spears", and "there was some balancing done on the spears". My guess is that it will likely primarily involve a ranged damage nerf, but maybe it's gonna be more creative. I kind of hope that they don't touch the Stone Age tier, though. That's one of the things I don't get about these balance discussions. These are just numbers, and as long as any changes don't mess with some important thresholds (e.g. flint spears one-shotting rabbits), they don't really matter too much and can be freely adjusted to keep balance in check. It's entirely possible to compress the damage progression on the spears and end up with the overall balance of the game practically unchanged. Sure, and since it's just a variant it's probably really easy. I could probably do it in at most a couple hours with essentially zero prior VS modding experience. But, here's a thought: making the game yours is the easiest way to end up with an incoherent and unbalanced mess and drop the game once you start losing control of all the tiny adjustments, especially as new game versions start introducing conflicts and changes. Especially when someone has only recently started, they tend to at first play the game as the developers designed it according to their own vision. They can appreciate it for what it is, but will inevitably question odd choices like the lack of iron spears, and the natural reaction is to suggest an obvious change instead of modding everything in in a knee-jerk reaction. You asked in another thread at one point to recommend damage changes to spears. Side note, you've also said that a 0.25 damage difference requires a multiple of 4 hits to matter. It doesn't - it can make a difference on any number of hits, especially once you start considering damage modifiers. Also, keep passive health regeneration in mind. Back to spears, how about we start by reducing the disparity between the different bronze alloys and copper, to make space for iron? Something kind of like this, alongside a few examples where each next tier helps with breakpoints assuming no damage modifiers: damageByType: { "*-granite": 4, "*-flint": 5, "*-copper": 5.75, // two-hits T0 bowtorn, down from 3 for flint "*-bismuthbronze": 6.5, // -> 6.25 // two-hits T0 drifters and three-hits T2 bowtorn, down from 3 and 4 respectively for copper or flint "*-tinbronze": 7.5, // -> 7 // two-hits T1 bowtorn, down from 3 for bismuth bronze, copper or flint "*-blackbronze": 8, // -> 7.5 // three-hits T2 drifters, down from 4 for weaker bronze or copper (probably the weakest tier here) // "*-iron": 8 // 2-hits wolves and pigs, down from 3 for bronze or copper // "*-meteoriciron": 8.25 // two-hits T1 drifters and 4-hits T4 bowtorn, down from 3 and 5 respectively for iron // "*-steel": 8.25 // alternatively, 8.5 could have some interesting thresholds, but I think they're better left for the bow }, I don't really think it would make metal spears in any real way underwhelming, especially as long as their durability is reasonably high. With the above changes, a steel spear would have ~19% higher damage than the average of the three bronze spears when thrown, while a parallel comparison would yield a ~26% difference between arrows (assuming using the recurve bow) and ~17% between falxes, so it's not particularly slow progression by any means. And if damage changes are not enough, then there's also other things that could be done, whether to balance spears as a whole, to balance them against bows, or to balance different spear tiers between each other. Even not considering anything that would be better included with a proper combat rework, a spear rebalance could quite easily involve adjusted accuracy, increased charge time required to throw a spear, adjusted attack speed, varied melee range, increased durability loss when thrown (possibly dependent on what it hits), adjusted throwing range, whatever, really. I would personally consider throwing charge time as the most interesting balance choice here, but each of them can have a purpose depending on what we would want the spears to exactly be. That is my preferred route as well. Maybe not necessarily halberds, as there is an endless variety of other polearms that could be added, like a bill, a poleaxe, a ji, and so many others. As mentioned before, the game has a bunch of "ruined" weapons that include a boar spear, a voulge, a war fork, a ranseur, and a couple axes which could be classified as polearms as well. Also, a lance or pike as suggested by @LadyWYT elsewhere may fit what several people here are mentioning, as it naturally wouldn't be throwable but could have further exaggerated melee capacity with ~4-4.5 m range compared to the spear's 3.5 m (whereas other polearms would more likely have ~3-3.5 m). I want to mention, though, that I think we need some combat changes for more weapons to make much sense. Currently, weapons only really use three parameters that affect their balance: durability, damage and range.

That's a nice point. I would say that the reason the Creeper still works decently well has a lot to do with it being very satisfying to kill (rush of dopamine and then relief) and serving as a challenge of sorts, which reinforces skill and game mastery. You can get this from storms to some extent as well, but the whole thing lasting upwards of 9 minutes once it ramps up just gets tedious and drowns out that positive reinforcement. Additionally, the Creeper is fairly easy to keep away due to much more generous monster spawn protection than VS offers - I genuinely don't remember the last time I had a Creeper blow up anywhere near my house, while drifters are constantly in my face at night until I invest into a bunch of lanterns. The Phantom, for contrast, is quite widely disliked throughout the community, because it's annoying to fight, it's not a challenge or a test of skill, it comes in uninvited even in areas otherwise safe from mobs, and tends to be just overall inconvenient and disruptive. The negative end effect of Phantoms is ultimately rather minimal compared to Creepers, but player sentiment is influenced in many other ways as well. Tyron has said they don't want to permanently modify blocks, but I wouldn't rule out other mechanics that aim to achieve similar effects in different ways. I can generally agree that the player should have countermeasures to use and face some risks for not using them, although I would also say that the countermeasures should ideally be intuitive and reasonably accessible, as well as effective enough to be preferred over cheese and other less immersive solutions. Fences specifically are a very good example, because they are the simple and obvious solution to keep livestock in and keep predators out, they are reasonably cheap and easy to make, and they are deliberately made somewhat gamey and not realistic to reduce the incentives of double fences, dirt walls or similar workarounds. I think that it's borderline impossible to punish the player in a way that somehow ends up making them enjoy fighting the storm. Unclear or weaker consequences (e.g. breaking blocks in a purely cosmetic way) that aren't seen as severe enough to warrant the risk and effort of fighting the storm may not even make the player attempt it in spite of the added maintenance. I just don't see how it would be beneficial to make the player engage more with storms, which they already often don't want to do, by making sitting them out in a hideout even less appealing than it is now - as I see it, it would easily end up highly discouraging instead. That's a pretty good point. I think the main counterargument to it lies in that while winter does require the player to prepare, it doesn't significantly limit what the player can do once they make at least basic preparations. It's like if storms lasted many in-game days but only caused rare and fairly weak monster spawns (a bit like what we have with rift activity), which would generally make the player prepare armor and weapons for it, but without heavily restricting what they can do over its duration. As it stands now, temporal storms make it nearly impossible to do anything in open spaces besides combat, even in the late game with steel gear, which is much more limiting than the reduced resource availability in winter. By adding consequences to ignoring storms, you might end up forcing the player into combat to the point where even the optimal solution that prevents greater consequences would often feel like punishment, just because the player would feel like they have to do it. Also, last note, keep in mind that merely adding an incentive to go out into the storms makes hiding less desirable through opportunity cost, reducing the need for other consequences. I'll see if I can comment on some other things later if I think them through.

Starts at 43:45, to be specific. I'm not immediately confident about this video translating fully to vanilla. Nothing in the modlist seems to affect bears besides Butchering, but I'm not so certain about player speed (I'd have to look through more of the lead-up). Don't know if I would call that fight nonchalant, frankly, with multiple close calls which may or may not have been avoided entirely by chance. I'm not entirely sure how the guy doesn't end up getting hit in a few moments like 44:10 and 45:08. Can't really tell if it's precise movement or just luck, but I've been unable to replicate it with sufficient consistency. The difference between brown and black bears is pretty massive, keeping in mind the numbers from assets/survival/entities/animal/mammal/bear-adult.json: movespeedByType: { "bear-sun-*": 0.01, "bear-black-*": 0.015, "bear-polar-*": 0.019, "bear-brown-*": 0.02, "bear-panda-*": 0.015, }, Last I checked I couldn't find the exact player movespeed to compare numerically, but it seems to be something like 0.018. Black bears are easy to just run away from on almost any terrain, since they seem to be ~20% slower than the player. Brown bears, though, are ~10% faster than the player or right about exactly the same speed with the "fleetfooted" trait, so they can be pretty tough to fight even for the hunter and the clockmaker. The only strategy that has consistently worked for brown bears for me without "fleetfooted" (besides the cheesy ones, like hiding underwater, hiding in a 1x1 hole, pillaring up, running backwards) was running around a small to medium pond, not unlike the guy in the video did, but even that tends to be a bit sketchy. Rough terrain and shrubbery can be very useful as well depending on how good you are at navigating it yourself, but can also be risky when there's too much of it, especially if you don't know the terrain beforehand. I guess the short of it is that fighting in a good spot seems to me much more important than just skill and practice, not even counting cheesing.

Man, before anything else I would kind of love to have the options for cave painting be more explicitly acknowledged in the description and the handbook. They can't be looked up like pigments using the search function. Limonite doesn't even have the "drawing" section in the handbook, which is really odd because they specifically added one for hematite. Drawing using both hematite and limonite has been in the game since cave art was added in 1.15, and yet many people (including me until today) are unaware of the possibility to use anything besides charcoal and chalk and it's not even present on the wiki (even though it appeared in patch notes, and information about charcoal and chalk is on the page for pigments). Just looked it up to confirm that rich or bountiful hematite and limonite chunks do work and there's no other hidden options, as defined in assets/survival/blocktypes/overlay/caveart.json { code: "material", states: ["chalk", "charcoal", "redochre", "yellowochre" ] }, Pretty annoying that the red and yellow come from hematite and limonite chunks respectively, and only rich or bountiful at that, making them (especially the yellow one) much rarer and more expensive than I would expect.

This is expected during 10% of the storms. From assets/survival/config/mobextraspawns.json, a pattern is chosen randomly by weight to determine the maximum quantities of each type of monster that are allowed to spawn: spawnPatterns: { "default": { weight: 5, groupWeights: { drifter: 0.5, shiver: 0.25, bowtorn: 0.25 } }, "drifterstorm": { weight: 1, groupWeights: { drifter: 1, shiver: 0, bowtorn: 0 } }, "shiverstorm": { weight: 1, groupWeights: { drifter: 0.4, shiver: 0.6, bowtorn: 0 } }, "bowtornstorm": { weight: 1, groupWeights: { drifter: 0.4, shiver: 0, bowtorn: 0.6 } }, "shiverbowtornstorm": { weight: 1, groupWeights: { drifter: 0.25, shiver: 0.375, bowtorn: 0.375 } }, "driftershiverstorm": { weight: 1, groupWeights: { drifter: 0.4, shiver: 0.6, bowtorn: 0 } }, }

Ilmenite belongs to the trio of resources which have reduced base spawn rates, alongside chromite and anthracite, meaning that you may sometimes have to search quite far to find it. It can form at most Y levels besides close to the surface and very close to the mantle (Y is in the [0.05, 0.85] interval), in all three igneous rock types and in both metamorphic rock types, so you can look for readings pretty much anywhere. It's possible to find "ultra high", but "decent" or "good" will be fine if there's nothing higher nearby, and you should generally ignore "poor" or lower readings for it. I tend to roughly search the area with a distance of ~400 blocks between readings, which tends to allow me to find it reasonably fast, but sometimes the random generation is just uncooperative. I have a world where I found ilmenite on my second reading, but it took ~50 readings spaced ~400 blocks apart to finally find chromite, which is about as common as ilmenite. Once you find a reading for ilmenite, it's just a matter of sinking a bunch of shafts deep down. You can make multiple vertical shafts, or you can dig horizontal tunnels, both optimally in ~25 block intervals, of course using node search regularly. For this case it's mostly just a matter of preference whether you dig shafts or tunnels - if you have almost exclusively igneous and metamorphic rocks then vertical shafts are probably a bit more efficient, while if you have a thick layer of sedimentary rocks or basalt on top then horizontal tunnels might be slightly more convenient. Halite is a bit of an odd case. Many people just buy salt from traders and don't bother looking for deposits. Dry lake beds in hot climates are mostly down to luck as they aren't detected by the prospecting pick (besides the sylvite in them), but domes can be resonably predictable. The readings for halite are wrong and appear higher than they should, even in areas where there is little to no chance for it to spawn. For a quite reliable chance to find a salt dome, you'll generally want a "poor" or "decent" reading in an area with an at least ~30-block-thick sedimentary layer or with a basalt top layer. If you find a "decent" reading with a basalt top layer, then you've hit the jackpot, but don't ignore other "poor" or "decent" readings in search of the perfect one. At that point you have to dig tunnels below the sedimentary layer in ~50 block intervals. If that returns nothing in a faily large area, then you can make more tunnels in-between, but there's generally no need to go lower than ~12 block intervals as it tends to be pretty tedious and doesn't offer particularly high chances of finding something that you've otherwise missed. The prospecting pick's node search can't detect halite, but it can find sylvite which spawns in halite, so you can still use it to locate the domes to some extent (and you may also find a bunch of other resources this way). If you're digging dense tunnels, then you can make them at more varied or more specific heights for a better chance at finding other deposits (e.g. Y <= ~40 if you get pentlandite or chromite readings in the area). For prospecting specifically, I think it would be quite fine to just include more practical information in the handbook, perhaps in a dedicated mining and prospecting guide that would describe where certain ores actually spawn - the information about the ores above comes largely from analyzing the code (and you could also get a bunch of it from the wiki), but in-game information is really quite limited. I do like the general idea. While the specifics are up to debate, it would just make sense that traders are roughly familiar with the area around them and may share some information about it, even if for a price. While prospecting information might be limited to specific ore types and may only be provided by specific NPC types, things like bees or nearby rock types could be familiar to pretty much every trader. One potential issue which I'll point out is that players tend to lose motivation when they know the steps required to get a reward, and just have to slog through to get it, so it's not just about avoiding making some other methods less practical. If implemented carelessly, this system can run the risk of making resource acquisition more tedious, by largely removing the need to search for things and by extension taking away the excitement that comes from finally finding a good reading or something. Of course, the flipside is that players tend to also lose interest if they keep searching with no payout, which is why I wouldn't mind a reasonably expensive but reliable way to know "what you're looking for is somewhere in this area (in a decent quantity), you just have to find it". While it's a fun idea, I think it would be fine enough to just provide a rough distance and direction. Don't get me wrong, more immersive directions could be amazing if implemented well, but I have doubts about how to implement it in a way that is actually reliable. Spending a bunch of time on a mechanic is more justified when you know the system will be more useful than annoying. This would ideally require some care to avoid making special NPCs too much of a challenge to find themselves, but it would make a lot more sense than just the more generic traders we have now. A cartographer is an interesting idea, and some others could include a prospector and a hunter or a woodward, and additoinally, the treasure hunter could be included in this category. Traders are getting new huts and stuff soon-ish to replace the current wagons, but I don't know whether that will come with any mechanical changes. Having some more unique and specialized NPC types could allow some of them to live together while avoiding issues with trading between two traders in a single hut and other shenanigans.

I'm kinda late to the party and you've had a fair share of pushback already on this, but I want to mention that Tyron has said something to the effect that they have a general rule to never damage, destroy or replace blocks through means external to the player, especially player-placed placed blocks, in the Standard mode (outside of special cases like bricks used in furnaces). He didn't go into much detail as far as I remember, but the reasoning seems to be roughly consistent with a bunch of what has been said in this thread. Regardless of how well-intentioned it is, damaging or destroying blocks comes with risk of restricting player creativity, incentivizing cheesing with ugly workarounds, imposing tedious maintenance, or inadvertently creating undesired incentives like running away from home for the duration of the storm, all of which are easily detrimental to player engagement. That is not to say that it can't work at all or couldn't be added to Wilderness Survival or Homo Sapiens, just that it's unlikely to be added to the Standard mode, or if it gets added in some form then it will very likely come with some simple, intentional workarounds (e.g. a way to lock doors as a solution to drifters being able to open or break them). There have also been suggestions to introduce a somewhat similarly-motivated mechanic but without permanent effects, which included: monsters or other threats that can move through blocks or in some other way reach a player indoors, monsters that can render blocks temporarily immaterial instead of physically damaging and destroying them, large, moving rifts or brief fissures that temporarily modify the world in some way within their area, and probably other stuff I don't remember or haven't seen. Overall, I would personally much rather see an incentive to go out into the storm and voluntarily face the challenge, but keep the player generally undisturbed if they still decide to wait it out in the safety of a hideout. As a general rule, it tends to be better for long-term engagement to incentivize something that you want the player to do instead of punishing the opposite, especially in a game with as large casual appeal as Vintage Story has in the homesteading elements. Punishment for inaction tends to be a very hard sell. I would expect that adding consequences to ignoring storms would significantly increase the number of people who turn them off, and amplify the feedback about storms harming the overall experience as a disruption that serves only to the player's detriment (which you can even see in this thread). Just a note: it is possible to provide a lot of rewards without making farms lucrative at all, and it only depends on how they are implemented. Conventional monsters have a whole bunch of issues and inherent design limitations that enable mob farms in the first place, but they are not nearly the only possible source of loot. I don't know if you've seen it, but there seems to be a small Temporal Storms Require a Fight mod which allows to reduce storm duration by killing monsters, with a pretty flexible config, if you're interested. There were also at least two other ones that did the same and some other things on top, but they seem to be outdated and less stable. Personally, though, I would be interested to see the storms actually much longer and impossible to shorten or skip completely, but with much weaker adverse effects for most of their duration, making it so that the player would be able to stay outside without too much risk and enjoy the audio and visual effects of the storms (which could use some improvements, but that's another point). They would just have to stay careful and watch out for signs of imminent extreme rift activity spikes, and hide or fight for a much shorter duration during these intense but brief storm phenomena. The thing with temporal storms is that they are hardcoded as a quite low-level, tightly-connected system that's not easy to modify beyond simple changes to a few variables or numbers, which also means that any two mods that attempt to significantly change it are very likely to be incompatible. A proper overhaul would likely require large sections of the code related to storms to be entirely rewritten, and that ideally also requires close familiarity with a bunch of the game's internal workings. Most of the code for the storm's mechanics is here, if you want to take a look.

Nice. And here's PlayerUID in the API: /// <summary> /// Returns the players identifier that is unique across all registered players and will never change. Use this to uniquely identify a player for all eternity. Shorthand for WorldData.PlayerUID /// </summary> string PlayerUID { get; }

There is a playeruid which appears in quite a few places (I'm not sure if it's the same one that you're talking about), but I think we can quite safely assume that the devs wouldn't plaster it all over the logs and tell people to post it on the internet if it was in any significant way compromising. It even appears in server logs, which means that it's probably visible to the owner of any server you join. As far as I can tell, its primary purpose is simply to allow the server to identify different players, and allow those that leave and rejoin to access their position in the world, their inventory and so on. I don't really know if that's unusual, but I've had zero problems finding fire clay, almost to the point of suspicion. On my longest-running world so far (~200 hours) I've found a large area of bauxite gravel and sand relatively easily (~10k blocks away), housing at least 5 large fire clay deposits, and I haven't even used up the first one. On the same world I've accidentally found three fire clay deposits underlaying coal without even deliberately looking for the coal. And this also reminds me that the current fire clay generation seems a bit odd, because the small deposits that are supposed to be common have a minimum rainfall requirement of 0.27 while low fertility soil starts to appear at 0.33. This makes large deposits end up more common in certain areas despite a 20x lower spawn chance, as they only require 0.1 rainfall. The funny thing right now is that unless you're making steel armor, then a single batch of 16 ingots may quite feasibly last for an in-game year or more, at least for players on the more casual side. My recommendation actually tends to be to make the bare minimum of bricks required for a cementation furnace (I think it was 224 = 3 x 64 + 32 bricks, doesn't really matter if it's T1 or T2), then beeline for ilmenite and use T3 bricks from that point onwards. It's not a bad idea to locate an ilmenite deposit before you even have steel, and I think you can even use ore-blasting bombs to mine it (though it still requires steel pounder caps to pulverize). T3 bricks have 99% heat resistance shown in the handbook, which is already much better than 90% for T1 or 95% for T2, but the actual value in the code is 99.9%, meaning that they break extremely rarely (assuming there's no rounding shenanigans, but experimental results support 99.9% from what I've seen). It's far from necessary to go for ilmenite as fast as possible, as all of the resources for T1 or T2 bricks can be obtained in large quantities quite easily either way, but it is something to consider.

That's interesting, because all of the paths in my logs and in multiple logs I've randomly checked off of GitHub appear as "%appdata%\Vintagestory\...", and frankly I'm not sure what could cause them to reveal the full path. Is it maybe because these seem to be related to a mod (do vanilla debug messages also have the full path)? Is it maybe because the appdata folder was chosen as the game's directory manually, causing the game to remember the provided path instead of accessing it through %appdata%? Maybe it's caused by an older installation of the game saving the full path instead of %appdata%? Tough to say more without a more detailed investigation. Actual errors and not simple debug messages could potentially show some stuff in the stack trace as well (I've found what looks like Tyron's username in one of the log files, which was kind of amusing, though it's not like I learned anything new), but most of the time the paths they print will start from VintagestoryLib or VintagestoryApi and not anything that could contain identifying information. The part I kind of don't get is that if someone really cares about privacy, then that username shouldn't correspond to their real name in the first place, and so there should be no real need to even remove it. Unless maybe that someone is really concerned over the same username appearing under multiple accounts that they have, allowing to link them together, but at that point it could probably qualify either as paranoia, or as using a sensitive work PC for the wrong things.

Part of this is probably already solved with the storage vessels that you can find in a few rooms, at least two of which are in the library itself, which you can use to safely store some items are return for them whenever convenient (don't confuse them with cracked vessels, and note that collapsed chests, unlike the ceramic storage vessels, don't allow to place items back into them). I think it's also possible to place items into display cases, though I recall that there were some related shenanigans as well. Regardless of all that, I do broadly like this suggestion, as it would be a global solution impacting all story locations including future ones, avoiding the requirement to deliberately place specific items in other locations for gameplay reasons. And I have to appreciate that you've immediately pointed to what is largely the crux of the issue in items which have hitboxes. What follows here is more of a general discussion. A few adjacent topics have bounced around the forums quite a bit recently, though with less focus on inventory management. I think that this summary of various ideas by @Bruno Willis is a pretty good outline of roughly where we landed (my apologies for kind of throwing a bunch of text at you like this, please don't feel like you have to read through all of it to contribute). My personal suggestion on this topic (closely related to the recommendation at the end of that summary) was to introduce a small class of "portable" items which could be placed in claimed areas, with some restrictions (implementation-wise it would probably just be a simple behaviour). They could be automatically broken if in the way of some machinery or otherwise blocking or obstructing something (could be made temporarily temporally unstable when enemies get too close), and they may get automatically collected back into the player's inventory when they walk too far away. This category of items may include some light sources like torches and lanterns, bags (i.e. backpacks and so on), the firepit or some sort of a portable stove, maybe a bedroll of sorts, optionally ladders (though they may make access to some places too easy), perhaps bombs and other traps (griefing would have to be addressed). The goal in the original discussion where I posted this was to allow the player to perform some basic survival activities and implement intuitive problem-solving methods that they're used to from outside of claimed areas, without giving complete creative freedom. It would make a lot of sense to include most if not all ground-storable items (e.g. bowls as you've mentioned) in this category of portable items as well, especially since there's a bunch of them already present in claimed areas and they can be freely collected but not put back. The difficulty for the devs comes mainly from the fact that this could require placing a bunch of extra checks and conditions in various places of the code, to ensure that the items don't disrupt anything within the story locations, which may heavily complicate some logic if not done carefully. There's also a few potential risks depending on the functionality of items that could be placed in claims, like inadvertently allowing to skip some mechanics or bypass barriers, or encouraging some sort of cheesy combat strategies. In certain cases it may also be necessary to allow clearly distinguishing between items integral to the claimed location and those placed by the player which can be picked back up. Those issues are all solvable, of course, but nonetheless require a bunch of work on implementation and playtesting that the devs may or may not want to undertake.

I'd be interested to know where that appears. Any paths in file contents should start from %appdata% or equivalent, any filesystem metadata should not be included when you upload the file (unless you upload the logs as a .zip or something of the sort, which may preserve some or all of it), and I haven't found any indication of embedded metadata in the log files (I would be very surprised if I did, because they're just text files). Under normal circumstances, according to everything I know, you don't have to sanitize the log files, or at least not for the purpose of your example. Feel free to elaborate on the deeper issues as well.

Every single person that I've seen playing the game simply took a moment to process why they can't pick the thing up, learning that picking things up generally requires an empty hotbar slot, and adjusting their habits accordingly with little to no effort. In fact, I've seen a few cases of people annoyed that an item got picked up while they were doing something else, and I think it was usually about eating or bandaging. It may be nice to prevent picking up anything until the next button press after starting a long action (e.g. eating, healing). I don't think that going all the way to either extreme (RMB always picks up / RMB only picks up with empty main hand) would be necessarily beneficial, because a lot of the time it's a relatively complex question that depends on whether the player is reasonably likely to want to pick up what they're aiming at depending on what they are holding. I don't think the current system is flawless, but I also don't think it has any major flaws. I think the relatively low popularity of PickupArtist and similar mods indicates that most people share a similar sentiment. I find it quite amusing that your highly knowledgeable self seems unaware that: the only information that should appear in the logs which could remotely reasonably warrant sanitization is basic device information (OS, GPU, CPU), merely describing the issue should allow to easily find it on GitHub and discover your separate identity, assuming you've actually reported it - I couldn't find anything, leading me to assume until proven otherwise that you haven't even posted it.

My intention was largely to suggest a general strategy that I've found reliable even as I was starting out, but running around like a maniac is an option as well. A bit more risky on higher difficulty or for classes other than a Blackguard, though. I think most of the work on temporal mechanics should focus on making them more immersive, more interesting in terms of visuals, sounds and feedback to player actions, and overall more fleshed out as an integral part of the world. That includes much more than just what Temporal Symphony does, although it would be a start. If any significant gameplay changes come out of it, then I'll be very interested, but I think other areas are at least equally deserving of improvements. Temporal stability and storms have been added in 1.12, if I recall correctly (rifts even earlier), with almost no meaningful changes since then besides new monsters. I'll quote myself on that from another post where I was admittedly kinda complaining, but it reflects the main things I'd like to see adjusted quite well: I'll mention that this is already an effect somewhat (though it's pretty weak), and you've said yourself elsewhere that storm strength affects the number of enemies. Both would be very easy to modify just by adjusting two numbers in the code for each, so I wouldn't mind to see some changes there. I do also quite like the idea to allow rare spawns in any storm even with only T0-T2 spawns (currently they only have a chance to replace T3 and T4 spawns), since then they become mini-bosses of sorts in low storm strength, and less experienced players aren't locked out of their loot behind more dangerous storms. I'm not sure if it makes much sense to add another early-game item to give more uses to a resource which tends to be obtainable in much larger quantities in mid and late game. Not that it's a bad idea, but I don't think it would solve the stated issue of scrap metal having limited uses. Making the scrap bomb better would be the first step for me, and I think any new uses for scrap metal should ideally also be consumable items which can be useful all the way into the endgame.,This would make the player choose between different consumables if they only have a limited amount of scrap, and make it more likely that different players with different playstyles will find their preferred use for it. Additionally, I was thinking to allow crafting a very limited supply of Jonas components out of metal parts, recycyled scrap metal and some other resources, which could be useful to largely solve the issue with Jonas components being random drops. Could require disassembling one component (or more) to turn it into another, to still require the player to actually find the required number of components in the first place instead of crafting them from "nothing". Something similar was mentioned in this thread.

This is a very reasonable suggestion, especially as a configurable option. Kicking due to inactivity is a common thing across various multiplayer games, while in singleplayer it could just pause instead of outright quitting.

This is a really difficult thing to balance for the vanilla experience, because while some people find storms too easy in various ways, you may also see complaints (especially from newer players) that the storms shouldn't cause enemies to spawn indoors at all, because a beginner with Stone-Age gear just isn't prepared to defeat a corrupt or nightmare monster that happens to materialize near them. Currently, there is no mechanic that would reduce indoor spawns, so you can still get jumped, especially in rooms that are on the larger side. There have been related suggestions to make the monsters announce themselves in some way (e.g. by first spawning a small rift, and only then having the monster come out of it), to give the player a heads-up when they spawn, which would at least help slightly with beginners dying suddenly where they thought they would be safe. I've recently argued that the main way to make storms more engaging (and potentially harder by extension) is to give the player more reason to go out into the storms. The incentives that we have currently are very weak, since storms aren't the primary source of any resources, so the player doesn't really have a good reason to leave their hiding spot. The advantage of this solution is that as long as the resources acquired from storms are not required for anything particularly important, then the less experienced or casual players won't be significantly disadvantaged if they choose to stay inside, especially during the heavier storms. There is also the option to give the player something unique to do indoors during storms, but outside activities are more conducive to increased difficulty and would also naturally allow the player to see storm effects in their full glory. I frankly have no idea how good most people are at fighting storms, but I can survive them quite easily with iron or better gear, as long as I stay either in a fenced-off enclosure (recently I've used a ~15x15 area just because that's what I happened to have) or near a small shelter with at least two exits and ideally with a bunch of windows as well (I've used my greenhouse a few times), to have more control over what I fight and when. The ability to hide for a moment to heal in relative safety is extremely valuable if you don't have good gear yet, but ideally you'll want to fight all the way through a storm to prevent enemies from accumulating. I tend to lose about 10-40 health per storm in total, though that depends heavily on the equipment I use, the type of storm and a lot of other random factors. Drifters aren't really a threat due to how slow they are and they mostly just deal some chip damage with their rocks unless I whiff an attack. Bowtorns aren't much worse unless multiple spawn at the same time, though it's often best to make sure no other enemies are nearby before chasing them. The real threat is T3+ shivers for me, although those can also be sort of cheesed quite easily sometimes since their hitbox is wider than one block.

Can only guess exact reasons, but the roadmap in the latest development update includes an "item heating overhaul", and the devs have shown some other work related to metalworking, among other things. Fingers crossed it's gonna include firepit improvements, because I do agree that they're long overdue.

From a game design perspective, this is just not how it works. If there are mechanics that are seen as cheesy or boring or whatnot, then it's the designer's job to incentivize more engaging gameplay. "Just don't do it" can be a solution to dissatisfaction with combat in some cases, but it doesn't change that the boring options exist, many people will use them, and the game has to be balanced with them in mind. You may have heard the quote generally attributed to Sid Meier: This especially applies to things like running backwards and pillaring up, because they're just the most efficient combat strategies currently available in many situations. Sure, I can avoid utilizing them, but I will always have it in the back of my head that I will probably have an easier time if I use them. Or if I get killed, I will always have it in the back of my head that I could have probably survived if I just used some of the more cheesy strategies. Cheesy, grindy and overall unfun solutions are often a symptom of a problem, and in the case of Vintage Story I would identify that problem with a simple observation: the game doesn't offer any other accessible and reliable methods to avoid taking damage during combat. Maybe shields are a thing, but they're implemented in an unconventional way, occasionally just don't work against melee attacks, are much less effective against high-damage attacks, and take up the offhand slot which also increases hunger rate, leaving them impractical in the eyes of most people. As for wolves and bears specifically, I really feel like it's mostly a dead horse at this point. The complaints stem primarily from how unnaturally aggressive they are and how they give almost no warning before attacking, and not necessarily from anything directly related to combat. Or if it relates to combat, then the complaint tends to be that they are too difficult to dodge and run away from. Bears are actually quite realistic or even too slow, and would probably be absolutely fine even if they were faster if they didn't aggro onto the player so easily and immediately get aggressive. Wolves are also much larger and much more dangerous than real-life wolves, from what I've seen, but that's a separate point. I'll also take the opportunity to introduce another of Sid Meier's influences on games, the definition that "a good game is a series of interesting decisions", which can be seen as a different way to say that a game has to provide the player with a sense of agency (or autonomy as described by models like self-determination theory). This can apply at any scale, from the most high-level decisions like world generation parameters, through long-term strategic choices like deciding which equipment to craft, and down to tiny reactive choices like whether I should step back to avoid getting hit by an enemy or risk a hit to attack the enemy myself. As it is currently implemented, combat offers very few interesting decisions, because meaningful equipment variety is unimpressive and most of the time the player only can perform two or three fairly shallow actions: free movement (completely unimpeded by anything most of the time), a point-and-click attack (falx or spear), optionally a ranged attack (bow or spear). This is why I was suggesting a shove action which would push away nearby enemies, because (if balanced well with weapon knockback) it would allow a choice at any moment during combat between an offensive and defensive action. That is also why I was suggesting to add more meaningful weapon choices that are more effective in different contexts, to shake up what for most people boils down to "falx for melee, bow for ranged" with almost no wiggle room.

From what I've seen, being below 0.25 stability can slightly increase the tier of monsters during storms as well, especially during low and medium storms. But I don't know exactly what proportion of spawns during storms come from the base spawning system, if any, making it difficult to properly estimate the impact. Either way, the effect probably will be rather minor, and it will not cause more double-headed drifters or deepsplit shivers to spawn as those come exclusively from the additional storm spawns.

There's a chance that it used to be different, but right now this is how it tends to spawn. Vintage Story doesn't really have biomes the same way that many other games do it, and instead a lot of things including tree generation depend on randomly generated maps for parameters like average yearly temperature, average rainfall levels, soil fertility (world parameter, not fertility of actual soil blocks) and forest coverage (also world parameter, not the actual amount of trees). Mediterranean cypress has very particular generation requirements, which makes it much less intuitive and unpredictable to find than other trees. If you're interested, these are the parameters for Mediterranean cypress as defined in assets/survival/worldgen/treegenproperties.json (assuming Floral Zones don't disrupt it in any way, because they might slightly modify the parameters directly or cause other trees to be chosen randomly instead of cypress): MinTemp: 8, MaxTemp: 22, MinRain: 30, MaxRain: 90, MinFert: 72, MaxFert: 130, MinForest: 28, MaxForest: 72, MinHeight: 0, MaxHeight: 0.8 And the takeaway from this is: temperature is in degrees Celsius, and 8-22 C is a pretty wide band (default temperate starting location tends to be around 5 C if I recall correctly, while tropics I think were around the 30 C range), and there's a few in-world indicators I can give you for it if you need, easiest being that you need to be somewhere around an area where redwood can appear (14-18 C), or you can go far enough south from the starting location that you start finding sunflower, amaranth or bald cypress (14/15+ C) and then you'll be certain that pretty much anywhere you go East or West can have the greenspire; alternatively you can also use /wgen pos climate to check the exact parameters at your location, if that doesn't break your immersion, rainfall levels are allowed in the [0, 255] interval, so the greenspire cypress requires 12-35% rainfall, meaning that rain has to be pretty uncommon but the area can't be completely dry, fertility is also [0, 255], so it requires a very narrow band of 28-51%, and a good rule of thumb here is that medium fertility soil is too fertile while sand or gravel are not fertile enough, so you need low fertility, forestation is again [0, 255], and again it has to be low but not near zero at 11-28%, typically easiest to find by following the edges of larger forests, height is in the [0, 1] interval and corresponds to the proportion of world height, so it just means it won't appear above Y = 204, which you probably don't have to worry about.

I don't know if that could qualify for the unpopular opinions thread, but I feel like this will change quite literally nothing for combat. It's only a significant consideration when crafting the weapon (and I'll gladly welcome more complex smithing, don't get me wrong), but I'd imagine that many people will just choose something that seems fine enough and think nothing of it afterwards. I feel like combat issues tend to revolve more around insufficient depth in combat itself, while equipment crafting is just the means to get the required gear in the first place. Even if extra variety or complexity in combat were the goal of the heat treatments, then completely new weapon types or other tools would probably have more impact than minor stat variations over existing ones. Realistically, a flanged mace would probably be most suitable, especially at the iron and steel tier. I do agree that some sort of a stunning weapon would be great, because it would lean into a currently very underutilized balance axis. As of now, every weapon has very similar knockback, and it could be beneficial to break that up and make certain weapons better either defensively (low damage, high stagger and knockback, useful against shivers) or offensively (high damage, doesn't push the enemy away, efficient but risky). Weapon choice would then be much more meaningful and case-by-case, instead of just comparing damage numbers. Roughly the same reasoning lies behind my suggestion for varied attack hitboxes, because a weapon with a small hitbox (especially the knife, probably the spear and the falx) might be very stong for single targets but forced to stay defensive if surrounded, whereas a weapon with a larger hitbox would be weaker against single targets but capable of controlling multiple enemies at the same time, again making for an actually interesting and meaningful weapon choice if balanced well. I think Tyron has said that they're adding iron spears and rebalancing the rest in some way in the nearest major update. Haven't seen further details as of now, though, and I don't remember whether he clarified whether that will also include meteoric iron and steel. Yeah, that's the one thing I don't get about the "but iron spears would be too strong when thrown" argument. Like, bruh, then just keep their ranged damage low enough to remain balanced. Or, as you suggest, add a different polearm that can't be thrown at all, which might be even better. Lances and pikes might be a somewhat odd fit for the game, since they were typically used for formation fighting and in cavalry charges. I could see one of them added, though, potentially with even greater reach than a spear (~4 m, maybe even ~4.5 m) and perhaps a short minimum range, as a situational but highly unique weapon used primarily to keep enemies at bay. Also, on the topic of polearms, I would personally love to have something like a poleaxe with a devastating anti-armor charge attack, requiring more deliberate placement but providing unmatched damage output against heavily armored targets. While it does creep a little into the "combat simulator" and "fantasy RPG" territory and is admittedly much less important than the more systemic improvements, I think that opening up some complex and specialized weapon choices would make for a satisfying reward for reaching iron and steel. Gating more complex weapons behind iron and steel would also naturally keep early-game combat experience much more streamlined. I have doubts about mounted combat, though, because it's a very niche feature that doesn't make me feel like it's worth the effort. Some games do it, and it often ends up cheesy and janky. I think I'd prefer any resources put into combat in the near future be directed at improving the core combat experience, whatever that might exactly entail for the devs.

Yeah, that seems consistent with the source code, appreciate it. Just checked, I probably just misremembered something with that stilt shiver. And I'm pretty sure that the other one is consistently referred to as "deepsplit" everywhere. Though "deepslit" admittedly rolls of the tongue better, I think "deepsplit" makes a lot of sense if you compare its appearance with other shivers. Name and spawner in the story location in the screenshot below, but for appearance comparison I'd recommend just jumping into creative and spawning a few shivers. Additional spawns for this area are implemented mainly in this method, if you're interested, and the JSON data is in assets/survival/config/mobextraspawns.json (alongside storm spawns), so I don't think a gearfoot can be found there. We have Vintage Story's bigfoot now, it seems. I would disagree that finding Jonas components underground is less optimal. Sure, combat may be more difficult (I don't know if I even agree with that, to be honest), but at least you can find more than two rare spawns per storm. Either way, while I can appreciate that they are supposed to be difficult to come by, it is also worth mentioning that: low drop rates tend to encourage tedious grinding and cheesing, people don't complain about the drop rates too much probably because a lot of Jonas components can be found in story locations to kickstart the collection process and sometimes provide all the components that the player may be looking for, and they just aren't particularly useful as of now, any consumable items risk being completely impractical with drop rates this low - the base return teleporter takes 8 Jonas components, not even counting the other resources, which would take 10 storms assuming the very optimistic 0.8 average, and assuming you only get the components you need, which would be a frankly somewhat absurd investment even if the reward was much better. While they aren't a priority as of now, I think they will have to be adjusted in some ways whenever more Jonas tech gets added.

Could you clarify which story location you mean? I've seen a stilt shiver in the first location of chapter 2, so I'd imagine it could be this one? I'm not sure how spawns are defined in story locations, but either way gearfoots don't seem to appear anywhere normally, which might warrant a bug report. The double-headed drifter, deepsplit shiver and the gearfoot bowtorn cannot spawn using the regular system, but rare spawns during storms don't include the gearfoot bowtorn: rareSpawns: { variants: [ { code: "drifter-double-headed", groupCode: "boss", chancePerStorm: 1 }, { code: "shiver-deepsplit", groupCode: "boss", chancePerStorm: 1 }] } Ah, I forgot to note that the limit of one of each rare spawn applies separately for each player (with a bunch of extra caveats that also might benefit from a bug report, but that's another matter). I've edited in a clarification. In multiplayer, spawning frequency seems to be effectively multiplied by the number of players, but the maximum count is evaluated separately when trying to spawn monsters for each player, which makes multiple rare spawns possible if the players are far enough away. The chancePerStorm property in the JSON for rare spawns above defines the maximum quantity of each per player. I'd be curious if you've also seen more than one double-headed drifter or deepsplit shiver when playing solo or when separated from other players (at minimum ~50 blocks apart) throughout the entire storm's duration.