MKMoose

I don't see gameplay significantly changing as a result of a mostly arbitrary progression milestone. Especially if it changes sufficiently to actually enforce a different gameplay style, because that would all too easily make people regret or avoid crossing that progression milestone, which is the opposite of what you generally want. I could see a base defense sequence or a greatly elevated ambient threat level working very well, though, as a mostly or entirely temporary story event - implementing it in this way would allow more controlled activation, more satisfying in-world justification and greatly reduced incentives for the player to avoid it. Preferably, put the base defense in a story location, because free block placement and base defense tends to be an extraordinarily janky combination in 3D environments. The devs have been experimenting with a dimension system and have planned or at least considered to make use of it in upcoming story content in 1.23. The devs have also expressed intent to improve upon the existing temporal storms, to incentivize the player to go out and interact with them. As for what comes out of it, we can currently only guess. I've heard quite some people say, and I tend to agree, that allowing the player to conveniently move through rifts could largely break the mysterious and otherworldly nature of them. Something is practically guaranteed to be done with them at some point, though I personally wouldn't expect anything similar to e.g. Minecraft's Nether neither in gameplay nor in visuals, in the sense that it seems unlikely that it will be a separate, distinct world. It seems more plausible to me that it will be more reminiscent of the principal Chapter 2 story location. Beyond the story quests mentioned already by others, since this is ultimately a sandbox, it is even more imperative than in most games that you find your own fun in the available content. Building, chiseling, exploring, various activities like cheesemaking or animal husbandry, different starting climates, nonstandard world configuration like an island world, increased game difficulty, optimizing, speedrunning, self-imposed challenges and goals. Mods can offer a huge amount of variety as well if that is of interest. Multiplayer can be a worthwhile consideration, and there's a number of unique, often modded, sometimes RP-heavy servers which can provide a very distinct experience. As I see it, most games from a high-level perspective tend to roughly fall into three main categories: A self-sufficient, typically story-driven game with a defined structure and clear ending. A gameplay-focused content box that gives the player a large amount of stuff to do. Sometimes turns into a content treadmill. An environment that is intended to facilitate the player's creativity and give them the means for their own creative expression. Good games tend to include some of all three styles, as this generally creates broader appeal and better player retention. VS by virtue of being a sandbox tends to lean towards the last of these.

Aside from making sure that your friend actually enters the correct password (potentially has the Caps Lock off, has the correct keyboard layout selected, anything of the sorts which could make the password incorrect), you should contact support through https://www.vintagestory.at/support/ or by emailing office@anegostudios.com.

Feeling personally authorized to make a snide remark, I will say that if you want the issue fixed, it would be more effective to post it in the proper channels for reporting issues instead of the discussion forum. Ideally, that means opening an issue on the VS Mod DB GitHub and properly describing how to reproduce the problem, perhaps without swearing at your discretion. You could also post on the #vsmoddb channel in the Discord server if you don't have a GitHub account. Maybe then somebody will see it.

Are you sure that they are disabled for you? They are available just fine on his channel for me, at least on a couple videos that I checked in this playlist.

Even if we assume that the world did actually get scrambled (which seems to be a guess based on a single line of text more than concrete lore and it would seem more lore-accurate to say that the world has shifted, but anyways) this doesn't necessarily mean that all semblance to real-life climates besides temperature would be lost. Atmospheric circulation and ocean currents are largely determined by factors like the Earth's shape and rotation, so as long as we are still modelling roughly a sphere of the same size which behaves in the same way, wind and water won't really get scrambled, or if they do then they would stabilize again over some amount of time (I have no idea how long it might take, though), again producing the same conditions which promote deserts near the horse latitudes. If a region of the world were scrambled so hard as to end up in a significantly different climate zone, that would be easy to notice and it would take a long time to stabilize again (certainly more than a couple hundred years in many cases). While the world can be argued to be a mess, rough bands of similar fauna and flora are clearly maintained, so realistically, most deserts should remain mostly concentrated near the same latitudes as on Earth even if they get somewhat scattered about. If the world did somehow get scrambled globally, then that is a ripe place for some speculative worldbuilding - what would happen to a glacier in hot climates, a rainforest in colder climates, a bog or swamp which gets moved to a higher elevation or allowed to drain, a desert which lands in a very wet region, a river which loses its continuity. Not to mention the potential for more extreme scrambling like a piece of land or ocean water getting moved upwards and over land or something getting superimposed on something else or removed with a void left in its place, because we don't necessarily have any reason to assume that this scrambling should be purely horizontal and transpositional. This could be very interesting, but arguably even more difficult to implement believably than realistic geography, and it doesn't seem to me that anything of the sort is currently implemented or planned. Tyron has spoken I think around a year ago about wanting to implement large regions of distinct flora and fauna corresponding likely to continents (and it's also been on the roadmap much longer), which would further suggest that even if the world got scrambled, the effects were more local than global so as to preserve these large distinct regions.

Generally yes, though do keep in mind that atmospheric circulation and ocean currents are strongly dependent on latitude, so latitude by proxy can still be a reasonably reliable predictor for climate. While there are deserts pretty much all over the world, all of Earth's major deserts are concentrated at ~15-35° latitude (North Africa, Arabian Peninsula, Australia, and a couple others) and to a lesser extent ~35-45° latitude (often referred to as cold deserts). I will note that the terminology here can be a bit of a mess, because the classic sandy dunes or rocky flatlands are just the most extreme kinds of deserts, but you can also have a variety of drylands, shrublands, grasslands, steppes, savannas and other arid climates which qualify more or less as deserts. They can be classified and grouped in a variety of different ways. So to be fair to @DeanF's suggestion for large deserts, I don't think that it's appropriate to assume that the "desert band" should constitute of purely generic desert and nothing else - you can tell by the mentions of savannas, sky islands, river deltas and other details. Notably, though, the ~20-35° latitude band is closely associated with humid subtropical climates, and includes primarily South-East US, South-East China, and South-East South America (notice the pattern - this is influenced heavily by warm ocean currents). This climate is mostly excluive with hot deserts and would have to be included in roughly the same climate band to make a realistic system. I find that the root issue is kind of just a low level of variety in the world. While yes, having smaller patches of different biomes can be more interesting than huge climatic belts, even small patches ultimately quickly get boring if you keep seeing the same couple patches everywhere. That is why I was describing a bunch of factors which could make the world more varied and interesting, and this is also why more distinct features like rivers deltas or sky islands as mentioned earlier can be very important. If we were to imagine a world composed of e.g. 3 simple biomes (which is what VS sometimes feels like, frankly - dry biome, wet biome and freaky mountains), then I don't think that discussing the ideal scale of these biomes is particularly meaningful, because whether you arrange them into huge climate bands or small regional patches, a couple simple biomes is just not enough to make an interesting world. Ideal world generation needs to have ample variety at all scales, from the overarching climate, through various small and large terrain features and specific biomes, and all the way to the specifics of how individual plants are placed into the world. It is not difficult to find plausible ways to improve world generation at each of these levels, but they ultimately generally require that something is added to the game, not just that something is rearranged.

Not sure when exactly you edited it and when I posted, but somehow I didn't see it at all until after writing this reply, so that's on me. May be that your edited post didn't update for me until reloading the page? I will leave this in a spoiler, because it was written prior to reading your full earlier post. There's still an answer to what you've mentioned in there, just keep in mind that I could as well have been replying to a different person. I didn't think of a map viewer, frankly. That can be pretty useful. And TOPS stands for The Official Public Server, run by Anego themselves. It loops around smoothly with multiple "equators" and "poles". The VS wiki has this image, which should illustrate the point quite appropriately. Frankly, this world size is almost entirely pointless - almost nobody ever leaves the starting "hemisphere" either way, because why would anyone? The vast majority of landmarks on the current TOPS are within a roughly 50k x 50k area.

A 640k world is absolutely humongous. The default polar-equator distance is 100k, so I see no reason to change that. Aside from this, the proportion between these climatic bands seems generally reasonable. It's already a huge dice toss in terms of where the game spawns you. I had one 200x200 island spawn where I had clay, chalk, copper, cassiterite, iron, goats, sheep, pigs, chickens, four fruit tree species and six crops including flax, among other things, all on that tiny piece of land. And I had plenty of spawns in the middle of a granite wasteland with very little in terms of food or valuable resources within some thousand or more blocks in each direction - not to mention the empty island spawns. I've seen a person wander for two hours without finding any cattails. The solution is to control the spawn area better or to introduce alternative resource sources and less linear progression, not to just avoid features which could make the already-existing problem potentially worse. Not to mention, this change may actually help to avoid frustrating or difficult spawn locations, because the assumption that the player could just randomly get spawned in a huge desert is not necessarily justified. If this desert is only confined to a specific rough climate band, then the player would only spawn in the desert proper if they choose that spawn location, which could be appropriately advertised as difficult during world creation. Overall correct, with the caveat that there aren't really any strict climate bands and it's more of a continuous gradient which ends up mostly producing five rough regions: polar (a lot of glaciers), cold (basically temperate but worse), temperate (the baseline), warm (redwoods, bald cypress and sandy areas), and hot (acacias, tropical forests). Besides this, it's just a repetitive small-scale patchwork of dry, grassy and forested areas. Looking at something like the TOPS map can give you a good idea about how the world actually looks at large scale. I would note that excessively rigid climatic strips (and especially large, uniform strips) would also likely be quite boring. There is a number of additional factors like ocean currents, continentality, air circulation, water systems and mountain ranges which can greatly influence climate in much more varied and interesting ways than just latitude. Even relatively simplistic climatic approximation could be much better than . I tend to refer to the Köppen climate classification and OneEarth ecoregions for a general overview of Earth's climates. I don't really have any good references for more details regarding climate-shaping mechanisms at the moment, though. On this specifically, there is a kind of debate between Minecraft-like and VS-like climate and biome generation, and I would actually argue that Minecraft gets closer to reality in principle in certain aspects. Minecraft defines unique biomes based on climatic conditions first, which then determines the biological makeup of the region, whereas VS only allows defining broad matching conditions for each plant individually and the emergent patterns can be described as biomes, so the causality in the two approaches is directed in opposite ways. Realistically, very similar climatic conditions can still produce different biomes based on a large variety of additional factors - Minecraft largely reflects this by adjusting the entire world generation depending on biome, so that each small region always follows a cohesive formula, whereas in VS a lot of world parameters are independent, which can feel much more samey and indistinct as well as sometimes contradictory. Neither is perfect and both can work fine, naturally, and in-between solution may provide the best results. In that vein, some things which I personally would like to see in the long term. Spoiler because it's a bit of a long tangent to an already excessively long post.

Under normal circumstances, the game caches a valid session key and only asks you to log in if the key gets in some way invalidated or removed. If you have to input your credentials each time, it is most likely caused by something about the way your PC or network connection is set up, or perhaps some kind of nonstandard game installation or launch configuration. I don't really know the specifics of what could cause this, and the only minimally plausible cause I can think of at the moment would be a VPN which changes your location or IP address each time you launch the game. You'd likely need to share more details about how you've got everything configured for anyone to be able to say much more.

This statement clearly suggests that using steel casings could be considered for the game even if it's not the most preferable option. The word "often" implies that it would be historically common, but it doesn't convey the fact that the transition to steel shells only occured in the second half of the 19th century and as such is virtually irrelevant to the vanilla game from a historical perspective. You only stress that early blast furnaces wouldn't have a steel casing (and an earlier sentence mentions that they had stone/clay lining), but fail to explicitly mention any other differences from the modern blast furnace that you've otherwise described. The first use of a proper charging bell seems to come from 1850. Granted, some early experiments may have been occurring earlier, but the proper bell-and-hopper system only comes into the picture in the middle 19th century. The first mention of "cooling metal plates", whatever that is exactly supposed to mean, seems to date to around the 1880s in the context of water cooling systems, which makes it doubly impractical for the game's limitations. Carbon lining was reportedly first used in the 1930s in Germany, and saw more widespread adoption after WW2 - while you did mention that early blast furnaces had stone or clay lining, your earlier phrasing could be easily seen as implying that carbon lining was a typical for blast furnaces potentially much earlier than the 20th century. The intentional use of titanium in blast furnaces was apparently only introduced in the late 20th century. When you mention at least five modern blast furnace innovations from the 19th and 20th century without noting the timeframe when they were introduced or at least noting that they are modern, and only state two of them as missing from early furnaces, then that doesn't give me any confidence to assume that you actually know what those early blast furnaces ought to look like. A reader who doesn't necessarily have the time and inclination to extensively fact-check everything wouldn't get an accurate idea from your post either. The blast furnace in the refinery actually has a closed top, which could suggest experiments from the 18th century or so, and that is alongside the reverberatory furnace which seems to come from the late 17th century at the earliest. Keep in mind that Tyron has said (here in an interview with Mahjong Blonsky) that the current plan is for the main technological progression line to stop at the Newcomen atmospheric engine, which was designed in 1712 - still well over a century before the primary modern design innovations in blast furnaces. Even if we were to mostly ignore the historical concerns, I wouldn't personally expect any of the more modern furnace features except maybe a top hopper or hatch to make it into the game for the simple reason that they could make the furnace much more complex for little practical benefit - I would rather put most of the budget into making the fundamental process more engaging. Keep in mind, also, that 19th century blast furnaces could reach around 20 m or more in height and output counted in tons per day. Personally, I would start from looking into simple European furnaces from roughly the 12-13th century, perhaps intermediate designs and not really blast furnaces in certain cases. Main structure made of refractory bricks with a 3x3 footprint and ~5 blocks of total height. Hearth at the bottom probably carved from stone. One or more special refractory brick blocks for the main iron tap, for slag, and for tuyeres. Additional infrastructure includes primarily: bellows - possibly alternating paired piston bellows, though a lot of options are plausible, a casting bed for pig iron - it could potentially be made of a variety of different materials, but the most notable option seems to be sand, likely a slag pit - just a hole in the ground to prevent it from spreading out, no special implementation required, likely a separate finery hearth for refining pig iron. Regarding details of operating the furnace: A single cast could probably be made every ~8 in-game hours or so, and produce up to ~16 ingots worth of iron. At five blocks of height, there would be space for three blocks of charge in the furnace. The furnace could be allowed to operate in a process consisting of startup, an arbitrary number of batches, and shutdown, to better accomodate multiplayer servers by allowing convenient single casts. Startup and shutdown would just mean adding fuel with no iron - this additional cost would produce a preference for continuous operation. Alternatively, a perhaps even simpler implementation could involve reduced amount of fuel required to add to the charge while the furnace is partially full, to represent the partial reduction in higher parts of the furnace and incentivize more regular maintenance. Damaging the bricks may only occur when the furnace is operated improperly (e.g. no fuel is added for proper shutdown). If the furnace gets damaged during runtime then it would presumably need to be designed in a way that doesn't cause the furnace to just die arbitrarily at random points. If at any point the furnace cools while there is still iron in it (primarily when the air blast stops, which is why water power would be very valuable), the remaining charge could solidify into a salamander, which could be mined out - it could be useless, or it could potentially be chiseled down to recover materials. Slag produced as a byproduct could potentially be used for some building applications and as a P fertilizer. Regarding iron processing: The default output of the blast furnace is pig iron. Casting cooking pots and other cast iron items would ideally need a more controlled process, which would also save the implementation effort related to making all the molds integrate with the casting bed. Direct casting is possible, but would be more implementation-heavy and inconvenient in practice because it doesn't allow mass production of raw material and gradual processing as it's needed. I would strongly consider requiring to remelt pig iron in a crucible to make cast iron, and using individual molds in this way at much less implementation cost - it's not really historically accurate, but it's easy to implement and convenient in gameplay. Some furnaces, including a reverberatory furnace given that it is present in-game in the refinery, could be also considered for this purpose, though that's a largely separate proposition and it shouldn't be the only way to produce cast iron products. Processing pig iron into wrought iron would ideally require a separate finery hearth to cook out the excess carbon and let it form a bloom which would then be hammered. The hearth could probably just be a single new block roughly similar to a forge. Simplifying it and allowing to directly work pig iron wouldn't be entirely unreasonable, especially to make it more competitive with bloomery iron, but I would be very interested to see the full process reflected accurately regardless.

Right off the bat, changing existing textures is most likely a no, because it disrupts existing builds and it's generally not advisable to modify things this long after they've been released unless there is very good reason to do so. Adding new blocks or in-game means of changing a block's color are much more plausible. While the color selection certainly isn't perfect, almost every option can be someone's favorite or a good fit for a specific palette. You can find a large variety of preferences in the community, for example in this thread: Note, also, that player preference is influenced by more than just the aesthetics of each type in isolation, which can introduce a lot of additional bias, since some people may just use whatever is most convenient for any of a number of reasons: Plenty of colors can be chosen depending on how well they match with other colors, e.g. purpleheart is not a bad color in isolation but it can be tricky to make it work with the game's color palette. Oak is the color of blocks which aren't wood-typed (e.g. shelves) which causes people to gravitate towards it more. Specifically for trees, a number of reasons unrelated to aesthetics can also be a factor: Several tree species are very common and accessible, making them a common default choice. Pine is extremely efficient (e.g. for charcoal production or large-scale building) because it can pretty much be chopped down without touching leaves and still drop enough seeds. Some trees are woefully inefficient due to a small number of seeds which often makes it tedious to plant at least as much as you harvest to maintain a reasonable reward for the investment (and aged wood types are also extremely tedious to obtain in any decent quantity). Oak is very efficient for sticks, since it has a lot of tightly-clustered leaves. Acacia and oak can be used for tanning, which makes them extra convenient as general-use trees. Pine and acacia also provide resin. For stone, some similar factors which may affect popularity can be found, especially the easy availability of granite. While easy dyeing of all blocks similar to e.g. Terraria could be a bit overkill and somewhat unfitting for the game's style, I do generally agree with the suggestion - it could be implemented in some less freeform ways, and it could be used to supply both vibrant and toned down colors. For wood, the devs have spoken about some kind of finishing (reportedly that's one of the reasons why linseed oil was added despite currently having no use) which could provide a variety of new colors. More species can be just fine as well, and we've had willow trees teased a few months ago. For stone, changing color would be less straightforward, although there is also a large variety of new rock types and colors which could be added for greater variety - and as long as they don't introduce an excess of inventory clutter, new rock types have pretty much no drawbacks - but being able to "dye" them is less plausible. For general color variety, I've always thought that some kind of plaster or stucco (applied on blocks as an overlay similar to wallpapers) would do wonders for builders. It can even reasonably be made be completely historically accurate to Europe in the Middle Ages and Renaissance. This would strongly benefit from overlays and pigments being generally improved upon and expanded.

You've got the rough equation pretty much right. The relevant information can be found in WgenTreeSupplier.GetRandomForClimate, in TreeSupplier.cs: float suitabilityBonus = GameMath.Clamp(0.7f - val.Value, 0f, 0.7f) * 1 / 0.7f * val.Key.SuitabilitySizeBonus; float size = val.Key.MinSize + (float)rnd.NextDouble() * (val.Key.MaxSize - val.Key.MinSize) + suitabilityBonus; and TreeGen.GrowTree: this.size = treeGenParams.size * config.sizeMultiplier + config.sizeVar.nextFloat(1, random); The val.Value in the suitability size bonus is the distance calculated depending on how well the tree matches its conditions (and all that is done individually for each tree variant), so that trees with perfectly matching conditions will generally be larger: fertDist = Math.Abs(fertility - variant.FertMid) / variant.FertRange; rainDist = Math.Abs(rain - variant.RainMid) / variant.RainRange; tempDist = Math.Abs(temp - variant.TempMid) / variant.TempRange; forestDist = Math.Abs(forest - variant.ForestMid) / variant.ForestRange; heightDist = Math.Abs((y / worldheight) - variant.HeightMid) / variant.HeightRange; double distSq = Math.Max(0, 1.2f * fertDist * fertDist - 1) + Math.Max(0, 1.2f * rainDist * rainDist - 1) + Math.Max(0, 1.2f * tempDist * tempDist - 1) + Math.Max(0, 1.2f * forestDist * forestDist - 1) + Math.Max(0, 1.2f * heightDist * heightDist - 1) ; if (rnd.NextDouble() < distSq) continue; float distance = GameMath.Clamp(1 - (fertDist + rainDist + tempDist + forestDist + heightDist) / 5f, 0, 1) * variant.Weight / 100f; As for how that size value gets translated to actual height in blocks, or any other details, I'd need to look further into it. You can also look at the code yourself in the public GitHub repos - tree generation should be in vsessentialsmod, I think.

For proper pixel art: Aseprite ($20, though open source so you can compile it for free) - the gold standard for pixel art. LibreSprite - closest completely free alternative to Aseprite. Piskel - web-based as well as desktop, not particularly great but very accessible if you just need to doodle something quickly. For general use, not dedicated to pixel art but still sufficiently suited to it for many purposes: GIMP - image manipulation program - my personal favorite for most purposes, though it can be quite unintuitive. Krita - drawing app. All of the above besides Aseprite are free and open source. A quick web search will allow you to find a whole lot of other options if you're looking for something more specific.

Abraham Darby did indeed introduce a new method for producing cast iron with coke-fired furnaces, which allowed to produce thinner and cheaper pots, although cast iron in general was introduced much earlier than that, especially in China (see e.g. cast iron history, or more generally ferrous metallurgy). His cast iron was likely less brittle than that made with earlier methods, but cast iron as a whole is regardless generally brittle relative to wrought (forged) iron and to steel. This is a fairly modern use of titanium. For refractory bricks specifically as it's used in the game, ilmenite is as far as I can tell not useful at all due to its relatively low melting point of ~1400 °C - proper refractory materials tend to favor melting points of at minimum ~1600 °C, and some go above 2000 °C. I have no idea why ilmenite is used as a refractory in the game, but it should have no effect on whether high-tier refractory bricks should be required for the blast furnace because it's not a direct use of titanium. You're speaking about fairly modern furnaces in general. Specifically metal reinforcements and cooling systems seem to only appear in the late 19th century as far as I can find, so it is entirely irrelevant for the game's purposes. For simplicity's sake we can pretty much even skip the lining and just use refractory bricks for the whole main furnace structure and stone for the hearth, to stay close to the game's existing mechanics and style. The tall furnace on the right is explicitly named a blast furnace in game files. The one next to it is almost certainly a reverberatory furnace which may be used for a number of metals including copper and copper alloys, tin, lead and pig iron starting from the 17th century and in this case has solidified iron in the hearth. From the late 18th century it has also been used for processing pig iron into wrought iron in a process referred to as puddling. I don't quite see where those nails would be useful. Frankly, I feel like the best way to restrict the blast furnace in progression is just through setup costs and infrastructure. It would be a bit strange, even for a significantly simplified process, not to require: the main blast furnace structure, probably made from any refractory bricks (realistically you don't even need fire clay, but I guess it's fine for game purposes) which requires a pulverizer, large bellows, which means a lot of leather, almost certainly mechanically powered and ideally powered with a water wheel to ensure continuous air blast, specialized casting molds for some items including cookware (potentially with a special ladle or something of the sort to pour the iron in a more controlled way), and a rough casting bed for pig iron, ideally a separate finery hearth with its own bellows for remelting pig iron to make it into wrought iron. A lot of simplifications are naturally possible, but in general I feel like just the complexity and setup cost of the whole process seem like they are enough of a progression gate that we really don't need any additional restrictions on top, be it steel or high-tier refractory bricks. The greatest easily justifiable hard restriction is iron, I think, since it would probably be preferable not to allow the player to skip bloomeries entirely, but there's no real way to use it for the furnace itself that I can find - maybe for the tuyeres and bellows, which would still be a pretty arbitrary restriction but probably much more defensible. Frankly, as I'm looking into it more, I'm getting the impression that it is ultimately a pretty obscure topic. Making the mechanics fully realistic and historically accurate would naturally be impractical (if you can even find properly reliable sources to base some of the smaller details on), but trying to simplify it for better approachability while retaining historical accuracy can also be a fool's errand. Historically, a blast furnace can only be used to smelt iron, because that's what it is specifically designed to do. A proper blast furnace needs to run continuously with no breaks - simplifying this is entirely possible and likely preferable, but then that would be more like an 11-12th century intermediate furnace. A blast furnace naturally needs a lot of setup work as mentioned earlier. It can be tricky to make the blast furnace actually worthwhile for mass production of iron unless greatly simplified, since the process has a significant extra step relative to the bloomery process: smelt iron and cast into pig iron, remelt pig iron in the finery hearth to burn out the excess carbon and let it form a bloom, hammer out the impurities out of the bloom to make wrought iron. Making the blast furnace require additional maintenance would make it further difficult to let it naturally outcompete the bloomery. I've had the thought to make it only take damage when operated improperly, to make the mechanic more interesting and allow the player to reduce costs with some skill or care.

The quantity is rounded randomly depending on the fraction. The pseudocode for it would look like yield = floor(avgQuantity) + 1 if random() < (avgQuantity % 1) else 0. The small berries which have 2.75 average yield have a 25% chance to produce 2 berries and a 75% chance to produce 3 berries. Reducing it by 15% gives ~2.34 average yield, which means a ~66% chance to produce 2 berries and a ~34% chance to produce 3 berries. Funny thing is, since you can get a new cutting from young bushes right as they grow from a cutting, you can actually still propagate them really quite quickly. Even starting from a single bush, you can get one new cutting every 3 months on average for the first year, then two every 3 months in the second year, then four and so on. That's a bug, #9943 on GitHub. If you're able to consistently make them lose traits, then having concrete reproduction steps would be useful.