Streetwind

Welcome to the forums The item despawn timer is 10 minutes. That's already twice as long as in Minecraft, for example. Further increasing the timer risks inviting problems, as each itemstack sitting unattended in the world costs performance. The longer each itemstack lives, the easier it is to get a larger number of them at the same time, and thus, the easier it is to kill your FPS. As for the wolf's perceived invulnerability - I didn't see what you saw, but as per the numbers in the game files, a wolf has 10 hp and the weakest arrow (crude arrow fired from a crude bow) does 2.25 damage. Therefore four hits at most should make a wolf flee, and a fifth hit should kill it. Perhaps at most one extra arrow if you play a class with a ranged combat weakness. A wolf surviving twelve hits is impossible. Remember that anytime you do not hear an audible "ping" noise when shooting a creature, your arrow did not actually hit; also, keep in mind that wolves appear in pairs fairly often. You might have killed one but been killed by the other, and just confused them for being one creature. To increase your chances of survival against wolves, craft and wear improvised armor. It costs nearly nothing and has no downsides to wearing it. And while it'll only last you a single fight with a wolf, it'll reduce enough damage to make the wolf need an extra hit, and that's usually enough for you to win even in melee (or at least make it flee). Furthermore, a varied diet will improve your base HP over time, so you can take more hits that way too. (But of course dying resets it.) Finally, there are other ways for storing items aside from chests. Next to the reed baskets you use to increase your inventory at the start of the game, there is a second type of reed basket with a slightly different recipe that can be placed on the ground like a chest. Once you have access to clay, you can craft large storage vessels which offer more storage space. Chests are sort of the endgame storage solution - you're not supposed to start with them.

We already have one "tech mod", called QPTech. Perhaps you can look into it, determine what you would consider missing from it, and then implement that? Or perhaps, if the author is amenable, collaborate? Although I must admit, I would personally enjoy a closer-to-physics electricity system than QPTech's packet network kinda thing... "producer -> cable -> consumer -> works" is boring. Give me actual engineering challenges, and perhaps teach me something along the way

Apologies if I sound a bit confused, but... you've never used node search or even seen it used, right? Because that is not at all how it works. When you are talking about "triangulating the location of ore with multiple samples" - that's literally what node search does. That's its intended use case. You break a block and get the info that ore is somewhere in the scan range; thus a minigame begins where you need to break blocks in multiple areas/directions to try and deduce which direction the ore is in and how far away it is. The default propick mode (density search), which tells you the spawn probabilities of ores in the area, is not turned off. It remains available, and indeed remains required, as node search alone will find nothing anywhere except by absolute dumb luck. Node search helps you look when you know something is nearby, true - but density search tells you where it is worth looking in the first place. Both modes do entirely different things that complement each other and work together. No functionality is replaced or rendered irrelevant. You don't have to take my word for it, though. Create a new world with node search enabled at one of the recommended settings (4, 6, or 8). Spawn yourself a propick and as many pickaxes as you need. Now try and find cassiterite using only node search and nothing else. I guarantee you, before ten minutes are up you'll be begging to be allowed to use density search first!

The food spoilage problem on multiplayer servers is an ongoing discussion, and I don't want to marginalize it. But what you're requesting here is not the solution you think it is. Instead, it's a huge exploitation hole. If food only spoils while a player is online, then what keeps people from storing their food in offline players' land claims and completely remove food spoilage from the game? Heck, a group of people could just chip in together and share the cost of an extra VS account whose only purpose is to log in once, claim an area at the central hub, and log off to never return. Now everyone has access to an infinite-duration food storage zone. The same works with two people playing in different time zones. Just store your food in each other's homes. At that point, why not sidestep such degenerate player behavior paths, and just set the server to something like 0.00001% food spoilage speed from the get-go? Same result, without needing a mod, and forcing players to do unimmersive things. Things like this are part of the reason why the base game hasn't implemented a solution yet. Because as it turns out, most quick and easy solutions... aren't. A variant I've seen is that food in the player's inventory doesn't spoil while the player is logged off. That's not exploitable by other people... but it is also limited in utlity for each individual player, as inventory space is limited. And it might be fairly annoying and unimmersive to empty your inventory and then pull everything off of your shelves everytime you want to log off, only to have to put everything back where it was once you log in again. The best actual solution in my own personal opinion is slowing the whole server down significantly. If people can only log in rarely, it's weird for them anyway if ingame years take only a hundred-odd RL hours. Logging in once every few days is like rolling the dice on which season it is right now. Switching to 30-day months from the base 9 goes a long way towards a more steady, believable progression of time in a game world where the player isn't present 24/7. You could even do more than 30 days per month, or increase the RL time an ingame day takes to pass - all these numbers are configurable by the admin. Along with it, you'd greatly slow down food spoil speed to match the increased year length. You might need a mod to adjust crop growth cycles... but I think there is one already, I just forgot the name at the moment.

I've said my piece on firearms in other suggestion threads already (this should be a mod yada yada) so I'll just focus on one thing here: there's a potential imbalance in your suggestion. If a quarter of the shots of a foxshot blast should be enough to one-shot a racoon, that means that this quarter must deal at least six damage, which in turn means that the full blast must deal at least 24 damage. This will one-shot a tainted drifter when fired point blank, and two blasts will kill any enemy in the game, including nightmare and double-headed drifters. Compare to the single highest damage weapon right now, which is a thrown ornate spear at... 8, I believe? And that's a non-reloadable, single-use attack. Everything else does less damage per shot/hit. The best melee weapon does 5.25. A hunter-crafted bow would certainly out-DPS the foxshot, and at higher range too, but single-shot damage attacks are powerful in their own right, because they remove the enemy's ability to fight back from the equation. As such, blunderbusses would completely replace spears and change the nature of cave exploration. Right now, the point of a spear is that you carry like three or four of them to yeet at approaching single enemies, which lets you kill most drifters before they can even take a swing at you. Should your suggestion be implemented, the player would take two blunderbusses and a stack of ammo instead. Each shot would realistically replace four thrown spears, so you've just doubled your ranged alpha strike potential while still using fewer inventory slots, and expanded the number of viable targets you can take care of in this way to include even nightmare drifters. The firearms will also more accuracte and reliable - it's easy to miss one out of four spears, but you just fire the blunderbuss at like 2 blocks distance where the spread doesn't matter. And they're reloadable without having to walk over to where your spears are lying on the ground, so you can just keep retreating instead of having to maneuver around enemies. On the topic of reloading: blunderbusses also reload the fastest out of all your firearms, so that makes them even better! What you're missing is attack tiers for your ammunition types. Foxshot should be a tier 0 attack type, dealing full damage only against entirely unarmored targets, while someone in steel armor would pretty much ignore it. Buckshot could be tier 2. The lead ball could be tier 4 or 5. Unfortunately that doesn't fix the PvE issue, though, because right now, only players use armor tiers. Animals and drifters use attack tiers, but no armor. So even if you gave your ammunition appropriate attack tiers, the game would first have to refactor how enemies are statted up for this to work.

Have you looked at the link and followed the advice given within?

There is already this mod:

...Wait, what? o_O What does it matter where the executable is located? You're not supposed to change that, nor is it necessary. All you're supposed to do is tell the executable at startup where it should look for its data folder. The data folder can be located anywhere you like, completely independent of the game's install directory. You could have it inside the install directory (to keep everything in one place), but you don't have to. It can even be located on network drives or external drives, so long as you ensure these drives are mounted when you try to launch the client. I know this because I've been playing Vintage Story like that since 1.12, and it has always worked reliably. There is probably something you misunderstood about how to set this up. Let me try to describe it again: Create the directory where you want your data folder to be located in the future, and copy its full, absolute path. Paste the path into a text file or something similar for later reference. You don't need to recreate the folder structure inside the data folder, the game will do that on its own. Go to your VS install directory and create a shortcut to vintagestory.exe. The easiest way to do this in Windows is the select the file, so that it is marked blue. Then, using the right mouse button, click and drag the file to an empty space inside the folder (or some other folder, or even the desktop, wherever you want it). Upon releasing the mouse button, a context menu pops up. Select "create shortcut". Rightclick the shortcut, and select "Properties". A small window pops up, with a few editable fields. The topmost one is called "Target". Inside this field, do not delete anything that's already there. Instead, go to the very end, press spacebar once, and then write --dataPath your:\path\here. That's a double dash at the front. You input the absolute path to your desired future data folder that you set aside during the first step. Finally, pay attention to quotation marks inside that target field. If the absolute path to your game's install directory contained spaces, then the contents of the target field in the shortcut will likely have been encased in quotation marks, so that the operating system understands it. By appending something to the very end of that, you'll have broken it, because you'll now have a quotation mark somewhere in the middle, where it doesn't belong. Find that quotation mark, and move it to the very end again, after everything you have typed. If there were no quotation marks, then add them just to be sure. One at the very start before anything else, and one at the very end. This covers the edge case where your path to your desired future data folder may contain spaces or other weirdness. Press OK to close the properties window. Doubleclick the shortcut in order to launch the game. Pay attention to your desired future data folder; the game should auto-populate it with certain required files and subfolders. If this did not work, I'll need you to describe to me step by step what you did, or better yet, show me your shortcut's properties with screenshots. If this worked correctly, you can now move your savegames and clientsettings.json over from the default data folder to the new one.

@redram Hmmm. And yet, I've always gotten the same (very low) numbers for cassiterite, regardless of whether the area was favorable (all igneous top to bottom) or unfavorable (only third layer is igneous). It's always 0.1‰ for most of the range, but it goes up to 0.2‰ on either high or very high (I forget). Considering the main spawn area of cassiterite is in the middle layer, and it requires igneous rock, shouldn't we get significantly different ppm results depending on whether or not that layer is igneous? Could it perhaps be that the ppm calculation for cassiterite relies on the ultra-rare, ultra-deep large vein spawn? Since the third layer is always igneous, that would explain why it never changes; and since it spawns so rarely, that would explain why the reading produces such an abysmally low number, despite there generally being plenty of ore (of the regular, small, middle-layer kind) in practice when digging down in a suitable area. It has long mystified me how the ppm can be that small when I'm finding like 3-4 veins in the same chunk with an ultra-high reading.

Ah yes. The good old "it was there all along" switcheroo.

Fireflies are currently just a graphics effect. They're not actually there, so you can't click on them.

This is a common suggestion, but the devs have stated that the base game will never implement firearms. And while people may of course change their opinion sometimes, you should consider the suggestion rejected until further notice. More non-weapon uses of blackpowder might be considered, such as fireworks. But that'll probably go somewhere into the ten kilometer high stack of content addition ideas for later reference. In the meantime, there is a mod adding a hand cannon and arquebus for your firearm needs. Doesn't look like it's up to date for 1.16.5 or 1.17.x, but I used it in 1.16.1 and it's quite faithful to real life.

Native copper can spawn in all rock types, and no changes were made to its generation. You're just having bad luck. I had a world like that, too, once.

Borax generates in every type of sedimentary rock except bauxite. It may spawn right at the surface, or pretty far down; it has a big range. But keep in mind that it does not generate in non-sedimentary rocks. So the moment the stone layer changes into something non-sedimentary, you don't need to bother with further digging. It is one of the ores that will produce surface rocks if they spawn close enough to the surface. So I will typically follow my usual sparse grid prospecting methodology in a sedimentary area until borax shows up. I will then keep an eye out for surface rocks as I narrow it down. They look a lot like quartz does - plain white flecks in the stones. Once I've narrowed down the hotspot, I'll canvass the surrounding chunks for surface stones one more time. Failing any results, I'll dig for it like regular ore. But I almost always find it by surface stones, sometimes even accidentally when I'm not even looking for it.

Agreed, the number does not mean what most people think it means. It's more debug output than useful information. Pay attention to the wording only, and you'll be much more focused on what's actually important: the probability for ore to generate. Each ore has a number of attempts to generate per chunk column. For example, cassiterite tries seven times. But this is modified by the spawn probability in each individual chunk column. If the prospecting pick does not indicate the presence of the ore, that probability is zero, and so all seven rolls are guaranteed to fail. If the prospecting pick detects a "miniscule" presence of the ore... then well, each of those seven rolls has a miniscule chance of succeeding. And if it detects "ultra high", then each roll has a near-guaranteed chance of succeeding. That is despite showing an incredibly low number of 0.2‰. Which is why you should forget the number and focus on the wording. Note that even a successful roll doesn't mean that the ore will actually spawn. For example, it might choose to try spawning in the middle of a cavern, where there is only air. Or it might try spawning at a y-level where the wrong stone type is present, a stone type which cannot host cassiterite. That means that, even with an "ultra high" result, you'll likely get very different yields from digging in an area that has two sedimentary layers over one igneous, compared to an area that is all igneous top to bottom. Additionally, there are ores that try fewer than once per chunk column. Iron ores in particular do this, with limonite at 0.8, hematite at 0.5, and magnetite at 0.3 tries per chunk column. In return, iron veins are massive, spanning multiple chunks. But it does mean that searching for iron (and particularly magnetite) is a bit different than searching for other kinds of ore. It's perfectly possible for multiple "ultra high" chunks to have nothing, whereas two chunks away where it reads only "decent", there's a successful spawn. You still want to check the highest probability areas first, but you have to understand that the game might not even have tried to roll at all in these areas. Searching all around the hotspot in a sparse grid (every fifty blocks is plenty) will yield results eventually.

Your chisel requires a certain minimum durability for the recipe to work. It'll definitely work with a fresh chisel - if not, you're doing something wrong.

Calories are covered by your main hunger meter. You run out, you start starving. I don't believe there are currently any plans to implement a need for drink, so a "water" measurement doesn't make sense. Implementing one and then having it only supplied through food is worse than not having it at all. You could still have meters for vitamins, protein, and minerals, sure. However, that loses you two out of five meters, so you lose variety. And then you could say okay, let's make up some more, but that still runs into a different problem: mixed nutrition from basic foods. Which doesn't sound like a problem at all at first glance, until you start considering the core game loop. Right now, each ingredient gives you one type of nutrition. Mixed nutrition is a perk you earn through progression. And even when you can combine ingredients into mixed nutrition meals, you need ingredients of all five types to satisfy all five meters. That means the player must actively grow and rotate two different kinds of crops, organize an orchard, engage in animal husbandry, mine or trade for salt, mill and bake and store things, and build appropriate spaces for all these things. But give a player the option to just eat the same two basic, uncooked ingredients over and over because the combination just happens to fill up all five bars if you spam enough of it, all of the above steps are no longer necessary, and you've given your player the tools to circumvent parts of your core gameplay loop. There are now fewer reasons to explore and acquire, fewer reasons to design and build, fewer reasons to interact with a wide variety of game systems... and much more room to sit in place and say "well, there really isn't that much to do around here, is there?". Like, I know myself. I used to play Minecraft with Pam's Harvestcraft installed. Even back then it supplied dozens of crops and over three hundred meal recipes from all over the world. I found one of those recipes, the first one I could make with whatever seeds I had at hand, automated the farming of ingredients, and completely ignored the entire rest of the mod for the rest of my playthrough. Because there's literally no need for any of it beyond fluff and roleplay; there is no actual gameplay loop in it. I don't think Vintage Story is a game that thrives on fluff and roleplay; I want it to be a game that makes each additional nutrition bar a goal for me to reach through progression. A bonus for advancing my level of civilization. Dairy may be a bullshit nutrition type, granted; but as a player goal, it is excellent. And when choosing between realism and having engaging goals and robust gameplay, I'd personally pick the goals nearly every time. So we should not just be asking what we can replace the nutrition meters with to make the game appear more realistic. We should also be thinking about how to maintain an engaging core gameplay loop related to food acquisition and preparation that includes progression-gated long-term goals in multiple steps.

This is a more complex topic than you might think. There is one game that implemented something like that, and it is kind of a mess. Popping open the character info fills like two thirds of the screen with a giant pile of graphs and numbers. While conceptually interesting, I don't think this level of simulation fidelity adds much to actual gameplay. You want a system that drives players to engage with the survival mechanics, and it's fair to ask the question if the current one is good as it is. But there is a point at which a system becomes so complicated that just reading the character info screen requires a video tutorial, and that starts defeating its own point. Players will engage less with it, not more, because it is so complicated. Nevermind the development effort...

One-track mind

It doesn't have to be long. It can also be wide!

You can absolutely play on your own in a singleplayer world. The client authenticates itself with a login server at startup. If this login is not provided, the client will not start. So you must launch the client online at least once. No ifs or buts. However, a successful login is cached by the client. If you start the client without a connection to the internet, and you have previously logged in at least once, then the client will skip the authentication step and let you play.

That's odd. Usually it doesn't take anywhere near that much effort. I mean, don't misunderstand - it does take effort, and that is intentional by design. I usually expend multiple ingame days on prospecting. But not multiple RL days/playsessions, or multiple worlds. I've had one single world out of the many I've played that acted incredibly stubborn and just didn't yield any copper worth mentioning in a kilometer radius around my base, and the best cassiterite I found was "decent". But in return it showered me in gobs of bismuthinite and sphalerite, and early surprise results like sulfur (which I had never found any of before). There is always some ore around, and if it's not the ore you need right now, traveling generally takes care of it. It's also important to have the right methodology, though. If you just move from chunk to chunk, that's going to take forever. Skipping a few chunks each time won't make you miss ore; most zones of abundance are at least half a dozen chunks across, and often larger. I recommend two approaches, depending on whether you run VSProspectorInfo or not. With the mod, pick a chunk to start in, and prospect it. Try to make the first sample you take be roughly in the middle of the chunk. After you have a result, pick a cardinal direction, such as north. Walk north and skip three chunks. Prospect the fourth chunk you enter, again trying to start in the middle. Then walk another four chunks, prospect. Another four, prospect. And so on. Eventually, when you're getting like a kilometer or more away from your base, return to your starting chunk, and do the same thing towards the south. Return to your starting chunk again later, and then walk four chunks to the east. Prospect that chunk, and then go north again. And south. Drawing a parallel line of samples to the first line. Then another parallel line another four chunks over. And to the west as well, of course. If you don't use the mod, the methodology is essentially the same, but you align yourself to coordinates instead of chunks. Pick a starting coordinate where X and Z are both divisible by 40, such as 280/y/-960. Any will do, so long as it's divisible by 40. Prospect that exact block. Now, walk 160 blocks north, and prospect that exact block. Walk another 160 blocks, repeat. Then to the south. Then parallel lines, as above. In both cases, you're drawing a large, sparse search grid that covers a lot of ground very quickly. And in both cases, the number 4 is important. 4 chunks, or divisibility by 40. Why? Because that lets you refine your search very easily. Once the ore that you're looking for pops up in your results during your sparse grid search, keep paying attention to it how it changes with every grid step forward. As long as the abundance keeps increasing or stays the same, keep moving forward with your large steps. Once it starts decreasing, stop and return to the previous step. From there on out, you will halve your step size: prospecting every two chunks instead of every four, or prospecting every 80 blocks instead of every 160. Look in each cardinal direction from your current best result to find the direction in which the abundance increases, and keep going until it decreases again. Then return to your new best result, and halve your step size again. Now you will prospect every chunk, or every 40 blocks, continuing to look for where the abundance increases. And if it stops increasing? That has a 99% chance to be the absolute local maximum. There's no sense in searching any further. You can then decide if the peak you have found is good enough to dig, or if you'd rather return to your large grid search in hopes of finding something better. There's a lot of experience that goes into making this call, based on knowing how various ores generate. For example, when I'm looking for cassiterite, and I encounter a "high" result, I will typically just dig there if I know that the middle rock layer is igneous. Even "decent" might be good enough in that case, if I can't find anything better. But if it's sedimentary or metamorphic, I'll not bother trying, and just move on and look for a higher result, or perhaps a different region of rock strata. For native copper, meanwhile, it doesn't matter what the rock makeup is. Each ore has its own little quirks. Quarz does not show up on the propick. That's related to how quarz generates. The technical reason is: the propick queries the ore map, which is an internal noise map of ore abundances specific to your world seed, and computes its output to you from what that ore map contains. This by extension means that it can only show you what the ore map contains. And quartz is not generated based on abundance on the ore map. It's spawned in through a different mechanism at world generation. Quartz is really more of a geological feature than an ore. This is not a problem in gameplay because there is so much of it. Stumble across literally any speck of quartz anywhere, and you will have enough for your entire playthrough.

You say "better", I see "worse" But beauty is in the eye of the beholder, as they say. Perhaps this mod gives you some of what you're looking for?

Welcome to the forums Much of this is in what I assume to be Russian, which I cannot read. But towards the end of the log, there is this line, which does offer a helpful tip: And it points out something important: sometimes just uninstalling software doesn't remove everything, especially if corrupted and potentially inaccessible files are in the mix. Sometimes you have to go and clean it up yourself. So I recommend that you: Uninstall VS using the Windows app panel Go to %appdata%/VintageStory and delete that complete folder and everything in it Go to %appdata%/VintageStoryData and delete that complete folder and everything in it Reinstall the game (and consider choosing a custom install path) See if that heps.

Yeah, uh... good luck with that. Respectfully, I think you've misunderstood the purpose of this forum. This place is not intended for you to discuss your ideas with the development team. This place is for long-form hashing out of ideas with other members of the community. A proper suggestions post will present something to solicit feedback on whether or not it would make sense to have it, or which form it could take. Here's a thread that exemplifies how this forum works. Threads like that are a useful resource for the development team, but they'll be read passively, and not always immediately. Especially since the vast majority (easily over 95%) of posts here discuss things that are not currently being worked on. The team cannot drop what they're currently doing everytime someone makes a suggestion post. Nothing would ever get done. If you actually want to run something by Tyron directly, ask yourself this: is it technical, or is it content? If it's content, just don't. There's a decade-long backlog already. Just don't. But if it's technical? Okay. With that, you'd go on Discord, into #gamedev. There, if you manage to start a discussion that shows that you know what you're talking about - in other words, you understand on a detail/code level how Vintage Story currently does things, and that you have considered how and why it would need to be modified - then you have a pretty good chance to attract the interest of the developers. Heck, I've seen Tyron flat-out ask for a pull request before. That's how you go from bystander to contributor. If you just go there and repeat what you have in your opening post, though? I'm giving you a 1 out of 10, and about that much chance for success, tops. The high concept of your suggestion is a good one, hence the one point; but you're not offering anything other than the high concept. That's just not enough. But you're a modder, so I'm sure you have more knowldge and can do better than that. Always keep in mind, though... even the most well-reasoned and well-received argument can still get a "no, won't implement" in case the required work is just too high.