MKMoose

I have some doubts about the proposed gastraphetes. It feels to me a bit too much like a middle-ground between the bow and the crossbow with nothing that makes it particularly stand out - I would be interested to have the two extremes first of all, and then the gastraphetes seems potentially redundant. Regular wooden crossbows could be made pre-iron just fine, so I don't see the need for a special variant there. Mechanically, I don't see the need to keep the gastraphetes significantly different from crossbows. The reload mechanism, while somewhat unique in reality, would easily end up the same as many other crossbows in gameplay. Using arrows instead of bolts is kind of interesting, but ultimately changes almost nothing and risks being more confusing for newer players. Being unable to store a loaded crossbow in the inventory is a given as I see it, so I don't quite see any difference from regular crossbows here - some difference could be added, sure, but it doesn't seem to me that there is anythign inherent to the gastraphetes that makes it different from crossbows in this regard. While I'm certainly not opposed to it, it doesn't seem to me that it is distinct enough to warrant significant gameplay differences - it could work just fine as a "heavy wooden crossbow". The clockmaker would probably be better served by a self-cocking crossbow, or a firearm, or otherwise something more technologically advanced, while the hunter should arguably remain mostly focused on bows to keep them more unique instead of devolving to "the ranged class". In terms of combat mechanics, I would find it interesting if the primary difference between them was skill. While I would be careful to avoid gamifiying it too much, it is undeniable that one of the biggest advantages of the crossbow is that it's easy to use compared to a bow, so it could be interesting to reflect that difference in the game in some way. That aside, this seems like a very well thought-out set of distinctions relative to the bow. Broadly, I would frankly prefer to see the bow and sling brought up to a better standard before any new weapons are added, or concurrently - the present mechanics are extremely simple and arguably just unfitting for a game which seemingly makes an attempt at immersion or realism. Either way, given that we are getting a combat-focused update with 1.23 and we've heard promises for various improvements to combat and for new weapon types, I would expect that some work should be done on ranged weapons as well - crossbows perhaps among them.

This is correct with a few caveats, and that's also why I said "generally" and "in normal circumstances". Most animals despawn after 300 s at light levels of 7 or less, as long as the player isn't close-by. Deer and grubs don't seem like they despawn at all, though I'd need to verify that in-game to be sure. Wolves and bears seem a bit confused, but they still only despawn in darkness. Fish and worms seem to be are the only animals which can despawn when far away from the player with no light level restrictions. The big caveat is that the despawn code doesn't care about time of day as far as light level goes - as long as it is exposed sufficiently to the sky, there is no need for artificial lights to prevent despawning, even at night. Your animals will never despawn unless they are is some deep cave or a completely enclosed, dark room.

The materials mentioned so far are roughly something like: 8x copper, 2x bismuth bronze, 3x tin bronze, 4x black bronze, 3x brass, 8x molybdochalkos, 5x bismuth, 2x meteoric iron, 1x silver/electrum/gold, 1x steel (modded). I feel like it's safe to say that there is no clear community favorite, though it's no surprise that copper and molybdochalkos are the most common as they are probably perceived as the cheapest while being aesthetically no less than decent. The popularity of bismuth has surprised me, personally, as I'm not a big fan of its colors - not to mention the 271 °C melting point, which is extremely low for anything which is supposed to carry fire. Brass with its melting point of ~900-940 °C (920 °C in-game) is generally considered to be around the minimum for safe and reliable fire handling with candlesticks, lanterns or whatnot, so while realism is naturally not the be-all end-all here, I find the ability to use bismuth for lanterns somewhat comical to say it lightly. Myself, besides the "I need a lantern now, out of whatever I have" lanterns, I tend to prefer tin bronze, as it is still cheap while being quite aesthetically pleasing and universal. For building applications I may also choose some other flavors, especially brass, iron or silver, depending on what suits the specific build.

In the vanilla game, the only method seems to be commands: /e remove l[] - the simplest way to remove the entity you're currently looking at, /e remove l[alive=false] or /e remove l[type=locust*,alive=false] - safer methods which prevent you from accidentally removing something which is still alive, optionally prevent from removing anything besides locusts specifically, but still only the one entity you're looking at, /e remove e[type=locust*,alive=false] - nuke all dead locusts in range. There's a couple mods which may be useful, notably Locust Harvest, and maybe (I haven't verified what they do exactly) something like Rust Drops or Instant Temporal-Mod Drops could work.

There are some emotes in the game, though they can only be activated through commands as far as I know. The available emotes can be previewed with the following command: /emote and using an emote requires that you specify its code, for example: /emote wave You might want to try setting up macros to make using some specific emotes a bit more convenient: or use the Emote Menu mod, which adds a more convenient emote wheel. If that is of interest, there is the Emotes mod as well, which seems to even include a few two-player emotes and among them "smooch" and "kiss (intimate)" as well as a couple one-player emotes which may match what you have in mind. Would love to see at least some features from both of these mods in the vanilla game, though I can't imagine it's a high priority for the devs.

Animals in VS are generally persistent, so coming back to the same area where you've previously found animals will lead you to find the same animals in the general vicinity. There is no code which can make them despawn under normal circumstances - that's also why domesticated animals don't despawn even if you're absent for a long time. If you do come to an area and find that animals which were previously there are no longer there, the most likely cause is that (1) you've chased them off, which is especially likely for your boars, or (2) they've just wandered off and are a few chunks away. This may be caused by the area's conditions not matching the animals' spawn conditions. Hares and foxes, for example, tend to be most common on the edges between bushy or forested and plain areas, with soil and not gravel/sand as the top layer. Also, regarding the question in the title, the game iterates over a 3-chunk taxicab range - for each chunk: chooses a random location within the chunk, iterates over all entity types - for each type: generates a herd associated with the entity type and assigns a each entity a spawn location within 5 blocks taxicab of the original position, attempts to spawn each entity if the spawn conditions match and no other errors or issues are encountered along the way.

The maximum dimensions for a room, and by extension a greenhouse as well, are 14x14x14 on the inside, so your greenhouse is too long. It looks like separating it into two rooms by adding a wall in the middle would be a viable course of action.

Reminds me of #8246. If it is indeed the same issue, then it should be possible to fix it by placing and breaking a block in these pockets.

This especially seems like an appropriate direction to go into with hyperthermia, primarily as a risk more localized to hot climates. In most climates, hydration wouldn't then be too critical, but in hot climates or on hot summer days, especially when intense physical activity is involved, adequate hydration could delay or outright prevent otherwise dangerous effects of overheating. Meals are already usually a 2.14-2.79x satiety multiplier (1.5x base satiety plus additional satiety loss delay), and not realizing how huge value meals provide (or being unable to make them because of the lack of clay) is one of the primary causes why new players often struggle with hunger. The most obscene current case which even goes well beyond that is fishing, which can in certain cases provide the likes of 30x satiety multipliers with very little additional investment, from bait (especially bushmeat) to finished meal, but that's another matter. Adding more bonuses for doing the right things or debuffs for doing the wrong things could easily start getting out of hand and further contribute to the game seeming overly difficult or inaccessible to beginners, so I do think some care is necessary to keep the game reasonably easy on newer players. I think there are a couple changes which could work very well for this, though - spoiler to keep everything cleaner: I've seen the Novelty! mod recommended for this purpose. There's also a bunch of food mods like De Artibus Rusticis or a couple of the more popular ones, though while they undeniably do they provide a lot of variety, it can be subjective or debatable whether they actually provide appropriate incentives to use that variety. I believe that one grossly underappreciated factor which would contribute greatly to practical gameplay variety is drastic differences between food categories useful for distinct purposes. In essence, this would allow the player to use food in some capacity as a problem-solving tool, so that the payer would be incentivized to choose different food types depending on what they need. As things stand, all food just fills the bar in the same way and differs only in nutritional categories and sometimes spoil time, so it could be interesting to introduce meaningful distinctions like: Dry foods which get little to no benefit from cold storage, to be used especially as travel foods, as opposed to foods which have to be kept in a cellar to extend their spoil time and as such are more preferable for a stationary lifestyle. Major macronutrient categories, best implemented as subcategories of satiety that fit into the existing bar with a shared capacity and not as separate nutrition-like meters, of which the two most notable ones are: Fat-heavy foods, most useful for long-term sustenance and potentially playing a factor in protecting against cold temperatures. Sugar-rich foods, which provide short-term benefits lilke accelerated recovery from damage, or potentially somethng like reduced debuffs from starvation, increased stamina regeneration rate. Drinks as well as potentially cold and hot foods more broadly, in the simplest implementation primarily as a method of cooling or warming the body to protect against the effects of high or low temperatures.

Funny thing is, there is, but it crashes the game. The command /e cmd l[] setattr bool entityDead 0 should do the trick, but it causes an EndOfStreamException. Your best option is to spawn a new elk with one of the following commands: /e spawn tameddeer-elk-male-adult 1 /e spawn tameddeer-elk-female-adult 1 or by entering creative mode with /gm 2, finding the elk in the creative inventory, spawning it that way, and going back with /gm 1. While it is purely optional, in case you don't want to harvest the corpse and instead you want to cleanly remove the corpse of the previous elk after getting a new one, you can do so by looking at the corpse and using: /e remove l[] but remember to take all of your items off of it before you do so, and be careful that something else doesn't wander into the center of your screen.

One might say that any mechanic would be a good addition if done correctly, but what that exactly means and how difficult it is to actually achieve for the specific feature can vary tremendously. But that aside, I generally tend to feel that thirst would generally be a good addition as long as it doesn't make the player excessively go out of their way to hydrate. The game feels to me like it has a long-ongoing identity crisis of sorts between the advertised (somewhat overused) "uncompromising wilderness survival" and the arguably more mechanically supported "immersive homesteading sandbox", but hydration can actually reinforce both of these fairly well depending on a few factors which could be customizable and vary between playstyles. For the more survival-focused playstyles, thirst has almost no disadvantages as long as it's reasonably well-designed and well-tuned, because maintaining survival meters is half the essence of those playstyles. Implementing it in some way more interesting than just a bar to keep filling would be very valuable, though - thirst could be integrated more tightly into the game together with hunger and general health whenever status effects roll around. For more casual playstyles where another bar to keep up easily becomes the opposite of fun, thirst would have to be designed much more carefully, but it also can be quite immersive and engaging. There's a lot of things in the game which are technically just maintenance, but they can also be cool and fun to do in moderation. I would personally propose a rule of sorts, simple in concept though potentially more tricky in implementation: the player shouldn't have to go out of their way to hydrate unless there are clear indicators that hydration should be a significant issue in a specific context. Dehydration could even be very quick, especially in hot weather and possibly as a consequence of intensive physical activity, but it should also be very easy to counteract without disrupting other gameplay, except potentially in hot climates or in deserts or whatnot where water is intentionally scarce. This means, among other things, that: The game would likely need a number of changes in order to accomodate a hydration mechanic in the first place. Safe water sources should be plentiful in most regions of the world where the player is likely to want to spend time in - this would primarily require adding freshwater streams thoughout the world. They should be plentiful in regular grasslands and forests, but can be less common in regions like swamps and deserts. Obtaining drinking water should be easily accessible and straightforward, even conditionally in regions where safe water is not immediately available. No arbitrary technological barriers and no tedious, costly or overcomplicated processing. Ideally, this would require improvements to firepits and fluid handling to make all of it more intuitive and less annoying. Water storage should be convenient, as well as safe for an extended period of time if not indefinitely. Overhauling barrels into something that actually feels like real, proper barrels would be very nice for this purpose, and Hydrate or Diedrate does some of that very well. Portable water containers should be convenient and easily accessible, and they shouldn't require the player to clutter their inventory with a bunch of containers or other items at all times just to ensure that they don't accidentally run out of water. I was considering a dedicated water bottle slot for this, similar in implementation to the bag slots. Most story locations need reasonably accessible sources of drinking water, for relatively obvious reasons. Ideally, the game should always ensure to spawn the player in an area with accessible drinking water, and areas without it may need additional incentive to enter them. I feel like an option to disable it would be borderline necessary (the other route is probably that modders would immediately do it instead), but also I think the best way to go about the mechanic is to specifically avoid a boring meter. The specifics of how to achieve that may not be straightforward (though I think what I've described above would be a solid start at least), but the general idea is simple - make it fun and make it fit the game. Make hydration engaging and immersive while ensuring that it doesn't feel forced or intrusive. Whether that is deemed worth the design and implementation effort is another matter. In a the context of a medieval wilderness, major industrial or chemical contamination is very unlikely, but some risks (especially microbiological risks) can always be there even in crystal-clear mountain streams. Rivers and especially clear streams can be safe, but drinking untested water without a filter is always a dice toss even if the risks are statistically very low. Barring other indications, generally risks increase as the water becomes more stagnant (that's why swamp water is generally not advisable) and comes in contact with more potential contaminants (that's why rivers downstream from settlements or pastures are generally less safe, and why rainwater is often quite safe as it can fall directly into a container with very little potential contamination along the way). Regardless of the source of water, boiling is probably the most reliable way to render it safe, provided it's not chemically contaminated. Various methods of filtration can be useful, also done before boiling, especially for water from stagnant sources with a lot of sediments, or if nothing else as a standalone treatment option though it doesn't actually eliminate many microorganisms. Disinfection is also an option, ideally combined with filtration and generally redundant for boiled water, albeit most methods of it are probably either too modern for VS (e.g. chlorine or iodine), or too gimmicky (e.g. solar disinfection or silver liquid vessels). It could be considered a bit odd from the perspective of realism or whatnot, but it is absolutely reasonable from a gameplay perspective. I've seen people suggest and have suggested in the past myself that hydration could be implemented as something more akin to the nutrition bars, and not the hunger bar. More about long-term accumulation and buffs, rather than short-term drain and debuffs or death.

Once you buy the game, you ought to be able to install it on as many PCs as you wish. If you can't find it after moving the files, you can download it again from https://account.vintagestory.at/. You won't have your worlds or mods or settings unless you move them over, but you can play the game just fine.

If you go into the game files (you can copy the path into Explorer if on Windows, on other platforms you'll need to adjust it for your system): %AppData%\Vintagestory\assets\survival\textures\block\plant\berrybush\cloudberry\berries you will be able to find that among the three subfolders, \bountiful, \healthy and \struggling, the bountiful berries are missing three textures, floweringinside*.png. That's the bug - missing texture files. Only affects flowering bountiful cloudberries. I've taken the liberty to report it in #10069.

So you want it so that you have to travel 50,000 blocks before seeing redwoods instead of 10,000. Brother. When a person is saying that it would be cool for the world to reflect something akin to a planet instead of having multiple climatic stripes, that is usually exactly what they mean. There is zero information in that statement about travel distances. It would be healthy to avoid assuming what was never said and instead assume that distances should remain as they are until stated otherwise - especially given that distances can be quite critical to gameplay, while reducing the world size (an ultimately much less meaningful variable than Polar-Equator distance) is a perfectly suitable alternative. Even on large servers like TOPS, very nearly all players unsurprisingly remain within the center climatic band (you can see the TOPS map yourself), so reducing the world height to that value would change very nearly nothing in the grand scheme of things. Hydrate or Diedrate includes notably more content than just thirst, and does have a quite flexible config. Most of its content provides little besides immersion or vanity when thirst is disabled, though it does have a few very cool features. I tend to agree that thirst in many implementations is just a tedious bar to keep filling. The challenge it provides can be fun in the early game, but over time it tends to provide little in the way of meaningful variety, even less so than regular food. I would say that the most important factor to make hydration make sense - very simple in concept but less straightforward in implementation - is to ensure that the mechanic feels intuitive and natural, almost incidental to regular gameplay when water is available, without being disruptive and without forcing the player to go out of their way to stay hydrated. I'd strongly consider adding a lot of freshwater streams throughout the world, and a convenient water container which can always be accessed with a dedicated button instead of forcing the player to juggle it in the hotbar with other items.

To add on to what @LadyWYT has mentioned: aside from the special lore item related to Chapter 2, progression is only gated by information. You can skip all but two of the current locations, but then you won't even know of the existence of the other locations let alone how to find them, unless you know something from prior playthroughs or external sources. Your estimates are close enough for most practical purposes, so I don't even feel like I need to give the exact numbers. If one wants to know the exact numbers, though, also in the future when new locations are added, they can be found in the game's assets: %AppData%\Vintagestory\assets\survival\worldgen\storystructures.json The distance is defined for each structure as the minimum and maximum distance in the X and Z axes (e.g. minSpawnDistX). The direction in the Z axis (North-South) is purely random for each structure, whereas the direction in the X axis (East-West) is the same for dependent structures - if the first location of Chapter 2 is to the East, all of the other ones in that chapter will also be to the east relative to the structure they depend on, and vice versa. This also means that if the first and second location of Chapter 2 are to the East, then the third and fourth should also be on the East half of the world relative to the second Chapter 2 location, and the same goes in the West direction. Overreliance on maps and waypoints is a quite particular pet peeve I have with games in general, and is a large part of the reason why I kind of hate many maps and virtually all minimaps. They are too reliable and they remove a huge part of the need to actually look at the game world. Minimaps are fine for some games, but I believe they are actually largely harmful to most RPGs. Navigation with directions and landmarks in a procedurally-generated world could be quite tricky, though, especially in a world like that of VS. It would likely need to be added only as part of a significant world generation overhaul, and may create issues with the more advanced worldgen mods - it's certainly not impossible and I generally would love to see it, but it would need a lot of fine-tuning and would almost inevitably produce some confusion or frustration. Alongside this or alternatively, I'd be interested to see simplified maps generated based on terrain but visually reminiscent of a hand-scribbled map.

While VS can and does use multiple cores, the bulk of the game tends to run on a single thread as far as I know. A quick glance at my resource monitor on world load: Lazy garbage collection, perhaps, as I've mentioned? Just like in thousands of other games? If it has some issues and causes performance issues then maybe that's a bug or some other problem, but the general idea of lazy garbage collection is extremely common and basic. I can see the exact same RAM usage behavior you're describing - minus the freezing - in multiple other games I've briefly tested as well as in VS. I would propose that this could be a matter of .NET or the operating system, not something specific to VS. I'm not getting the freezing, though, as my RAM usage seems to neatly and gradually get cleared up with no obvious performance impact when reaching very high values, or just cap out and start struggling when playing with jacked up render distance - I wasn't able to have it cause any meaningful performance issues otherwise, even after creating new worlds several times. Your predicament may depend heavily on the specifics on your system and your VS configuration with mods, which I am unfamiliar with currently and likely unable to meaningfully help with even if I was.

This seems to be an unrelated fullscreen issue (may also occur on maximized borderless in some cases), at least on Windows but I'm not sure about other systems. Windowed mode doesn't seem to have this issue. You can also check whether you can Alt-Tab out of the game and back in to get the screenshot to be what you had on the screen when Alt-Tabbing out. Is there actually a problem, though, or is it just that you don't like how it looks? Does the RAM usage keep climbing and affecting performance? Does it prevent other apps from using that RAM? Do keep in mind, also, that if there are any actual problems, they could be caused purely by mods. Apparent RAM usage remaining high when it is no longer in use is perfectly normal, as there is no need to clear RAM right the moment it's unused - the same behavior occurs in many other apps. This is often referred to as lazy garbage collection - releasing memory only when it is actively needed. Some systems apparently also deliberately keep data in memory to be able to reuse it immediately if it's needed again instead of loading it from scratch, though I'd need to double-check that to be sure. Either way, RAM which is being actively utilized is not the same as RAM which is no longer in use but not yet cleared out. Additionally, some of the data stored in RAM may be data which intentionally persists between worlds, like maybe texture atlases or shader data - I don't know whether this is actually the case and how much it contributes if it is, but I wouldn't dismiss the possibility. Running a different RAM-heavy app alongside VS seems to cause VS to release most of the memory it's holding. I can also get it to release most of the unused memory by just... waiting.

If bees are your target, then you don't need to go far, if any distance at all - assuming you're on default world configuration and a temperate start, you should be able to find bees in your general vicinity quite fine. Temperate spawns start in the ~4-12 °C average yearly temperature range, whereas bees spawn at temperatures of 5-35 °C. You might want to go slightly south to ensure that local cold spots are less frequent, but you don't need to go all the way to the hot climates. When it comes to finding bees, the more difficult part tends to be to actually hear or see them when nearby - plenty of stories in the community about only realizing a beehive was right under someone's nose after chopping down the tree it was in. A common piece of advice is to turn down music and increase ambient sound volume, or sometimes to just turn to mods for a little help.

Broadly speaking, rope ladders are preferable for descending, whereas regular ladders are preferable for getting up places, so my assumption was that regular ladders would be better suited for pillaring up to break leaves off of trees. But if you're able to get where you want using rope ladders then by all means, you can use rope ladders just fine - you will have to attach them to the tree or hang it off the leaves, though, instead of just placing a standing ladder anywhere you please, which may be more or less practical depending on the tree. Regarding the part about going up and down a few times, that's just a general remark to point out that you can't do the same with full-block pillars - you'd have to build a new one each time you need to get somewhere again. Ladders are freely climbable and as such may be more convenient as something akin to scaffolding, especially for example when building something with a lot of verticality.

As far as I can tell, you can: Rebind Sneak to something other than Shift. Uncheck the "Mouse click modifiers locked to Sneak/Sprint keys" checkbox in Settings > Controls. Keep in mind that this will also return the Sprint modifier to the Ctrl key, if you have it rebound. Unfortunately, I'm not aware of a method to rebind the modifier keys while keeping Sneak bound to Shift.

In BlockTorch.OnAttackingWith() at BlockTorch.cs:239. There is actually a very interesting if strange interaction there as well - the chance to ignite increases to more than half during temporal storms, potentially all the way to 100% during heavy storms. public override void OnAttackingWith(IWorldAccessor world, Entity byEntity, Entity attackedEntity, ItemSlot itemslot) { base.OnAttackingWith(world, byEntity, attackedEntity, itemslot); float stormstr = api.ModLoader.GetModSystem<SystemTemporalStability>().StormStrength; if (!IsExtinct && attackedEntity != null && byEntity.World.Side == EnumAppSide.Server && api.World.Rand.NextDouble() < 0.1 + stormstr) { attackedEntity.Ignite(); } }

Should be, based on the code: 0.5 damage on the initial hit, 10% chance to ignite under normal circumstances: 0.5 fire damage every 1 s (or possibly a little less frequently), 12 s fire duration, for total fire damage of 5.5. This would confirm your findings and result in an average of 0.5 + 0.1 * 5.5 = 1.05 damage per torch hit, though that is assuming the fire goes out before it's applied again. Frequent hits may slightly reduce the effective damage per hit.

At the default world configuration, the Polar-Equator distance is 100k blocks, which means that the average yearly temperature changes at a rate of 6 °C every 10k blocks. From the default spawn coordinates, you should usually start seeing appreciable climatic differences after travelling ~10-15k blocks south, as that is generally where the warmer climates ought to start, and where you might start seeing redwoods and bald cypress. Travelling ~30k blocks is usually around the minimum to start seeing proper tropical climates.

Known issue (#8349 on GitHub), resolved for 1.23.

Cob has a 15% chance to drop nothing when broken. If you're curious, the most useful blocks for quickly pillaring up are generally: hay, because it breaks very quickly by hand (several times faster than soil), regular soil or strewn straw for general purposes (the latter is preferable if you're playing with soil instability; packed dirt can also be used but it breaks a bit slower), cob, only if you need to quickly get a lot of blocks in the early game, but it gets annoying due to the material loss, ladders - regular ladders are preferable, crude can work because it currently only needs attachment at the base, but rope ladders will not do for this specific purpose - for when you need to go up and down a few times (and they also break very nicely from the base).