LuuBluum

Unless the wiki is mistaken, that seems to already be a thing.

Right now out of the large number of ground storage options out there, there are none for small rocks. I don't know about you but small rocks tend to be the item that tends to accumulate in my inventory more often than not. So, simple suggestion: ground storage for small rocks. Nothing fancy, just a pile of rocks.

Ah, fair enough. I suppose it'd require other changes to make it more cohesive with plaster-before-metal as a concept. Oh well; I suppose I'd be better off doing things like this with mods of my own.

Right now lime, oddly enough, requires metal production (hammers) to produce and doesn't require anything beyond crushing some limestone. However, this seems both oddly limiting (lime certainly was produced before metalworking) and also just not really able to get the sort of volume of lime production that existed back in the day. After all, quicklime was both useful in plaster and mortar. Also of course realism concerns (lime requires cooking limestone, not crushing) but that's more of just an added perk to this proposal rather than the underlying goal. So, doing this would be simple enough. Dig a reasonably large pit in dirt, line the sides in cobblestone so the dirt doesn't fall in (or not; all that matters are that the sides are fireproof). Leave a hole in one of the sides of the bottom that leads out to open air, so the fire can burn without issue of airflow. Line the bottom with firewood blocks, cover on top with limestone (just the straight stones. I don't recall if stone piles are a thing but they'd probably have to be made a thing for this, but that seems reasonable as a way to store stones?), light fire through the bottom channel hole, and then simply let burn until the stones start to glow red. Takes a few days, ideally would require some stoking of the fire but that can be omitted for the sake of making it easier to do. Then the fire is simply left to burn out and the stones to cool off. What's left, besides a bunch of ash, is a bunch of brittle rocks that, if broken up (can be done by hand, or just make it that when collecting the burned rocks you just get lime powder in inventory) and mixed with water, turn into quicklime. Putting it simply, rather than have lime be the product of smashing limestone with a metal hammer, replace it with something that's a mix of a firepit and a charcoal pit that can be done without the need for metal tools. Neater, more realistic, and brings the benefit of lime without needing metal tools first.

int charCoalQuantity = (int)(logQuantity * (0.125f + (float)Api.World.Rand.NextDouble() / 8)); That's how much charcoal you get per pile of logs.

Having sufficient artificial light will also keep wolves from spawning.

Another option is to simply have berry regrowth time be more reflective of actual berry regrowth time, which is to say roughly once or twice a year. Though I think that would only realistically be an option once fruiting trees are also added.

At least from what I gather having done some quick Wikipedia summarizing is that the only thing the water did was cool it off faster.

Ah, you are actually right on that. I guess that's to prevent tall grass spam, since otherwise over time fields of grass would become completely overgrown with tall grass. Perhaps that really means that we just need more wildlife to eat the ever-growing tall grass?

Simple. public override void OnServerGameTick(IWorldAccessor world, BlockPos pos, object extra = null) { base.OnServerGameTick(world, pos, extra); GrassTick tick = extra as GrassTick; world.BlockAccessor.SetBlock(tick.Grass.BlockId, pos); if (tick.TallGrass != null && world.BlockAccessor.GetBlock(pos.UpCopy()).BlockId == 0) { world.BlockAccessor.SetBlock(tick.TallGrass.BlockId, pos.UpCopy()); } } Whenever it receives a server game tick, and specifically is told to grow grass in that tick, then it grows grass. Of course, that begs the question: when should it receive a server game tick? public override bool ShouldReceiveServerGameTicks(IWorldAccessor world, BlockPos pos, Random offThreadRandom, out object extra) { extra = null; if (offThreadRandom.NextDouble() > growthChanceOnTick) return false; if (growOnlyWhereRainfallExposed && world.BlockAccessor.GetRainMapHeightAt(pos) > pos.Y + 1) { return false; } bool isGrowing = false; Block grass; BlockPos upPos = pos.UpCopy(); bool lowLightLevel = world.BlockAccessor.GetLightLevel(pos, EnumLightLevelType.MaxLight) < growthLightLevel; if (lowLightLevel || isSmotheringBlock(world, upPos)) { grass = tryGetBlockForDying(world); } else { isGrowing = true; grass = tryGetBlockForGrowing(world, pos); } if (grass != null) { extra = new GrassTick() { Grass = grass, TallGrass = isGrowing ? getTallGrassBlock(world, upPos, offThreadRandom) : null }; } return extra != null; } Which is to say, first it rolls a die to see whether it should even grow, based on growth chance. Then it checks whether it should be getting rain and, if it should, whether it does. If all of that is met, it then checks whether or not the grass should grow or die (die if smothered or in darkness, grow otherwise). If in fact it should, then it does. So, if you want grass to grow, make sure it is exposed to rain and not smothered, and is in good lighting. Then wait.

It does. The wiki is wrong in this regard; grass grows and regrows over time just fine.

Given that "mountable" entities are already a thing (that's how beds work), I imagine horses and whatnot are already intended to be worked on at some future point.

I'd have to dig up quotes, but from what I gather almost every change to the game made at the moment is made to the components that are open-sourced. Specifically, the "essentials" mod and the "survival" mod, which both work as mods on the engine base. With the mod patching system, you can make mods that do whatever changes you want to the game, fixes or otherwise. Hell, I imagine if you presented it to the devs they might even just pull said "fix" mods directly into the base mod, with some credit in the changelog. Though of course, it can't hurt to ask the devs themselves about that directly; I'm just someone who spent a lot of time reading the code for fun.

Dry stone is an alternate form of cobblestone, made with a stone brick in the middle instead of clay. It seems that that, specifically, was removed, rather than the stones themselves.

Depending on the implementation this would be perfectly fine. If it's just "branchy leave blocks can fill adjacent empty blocks with leaves", that'd be both easy (you'd just override whether or not branchy leaves should receive server ticks on that condition, and when they do fill a random empty adjacent spot with a leaf) and computationally lightweight (every single dirt block in the game is constantly getting server ticks (or checking whether they should) to work out whether grass should grow on them, and performance hasn't slowed to a crawl; clearly it isn't that costly). Hell, could even apply this to branchy leaf block or leaf blocks adjacent to branchy leaf blocks, etc. Though I suggest perhaps a lower limit, lest forests become incomprehensible overnight with all their leaves.

I like the idea of the materials that you use for construction actually having significance beyond aesthetics. I just think that this is probably both too mild and too inconvenient at the same time. The two-step downgrade, with the potential to repair the "damaged" door with a stick, and a damaged door breaking just yielding a stick or two (not sufficient to rebuild the door), alongside a lower chance of this happening, would be more functional to me. Then again, I'm also the type that would prefer (slow!) degrade of building blocks exposed to particular elements depending on the block, with the option to repair. It'd be interesting to leave a base behind and watch it be overtaken by the elements, y'know?

For what it's worth, this is doable but not quite as easy as it sounds. In VintageStory, blocks don't have any sort of "memory" without a blockentity. This can be cheated a little bit (use block variants and orientations in clever ways), but generally speaking any time you want a block to store any amount of data other than its mere existence, you need a block entity. Doors do a cheat with this- when you open a door, it literally replaces the closed door with an open door. The code as it stands simply provides a chance, on that interaction, to instead break the door. Having it do a "count" system would require a block entity to keep track of the number of times you interacted with the door, which would be... well, not that much work, but it wouldn't be quite as easy as just modifying a value in a JSON to be, say, 5% instead of 10%. The idea of having there be a "it's about to break" version of the door is easier, but still requires some effort. Namely, the "bad roll, break" portion of the door-opening code would have to also check for a "if being broken from opening and there's a value of 'broken door to replace with', replace, if not then break" condition. Then of course you need to model the "about to break" door and all of that. Probably just easier to modify the percentage in the JSON. In blocktypes\wood\door: breakOnTriggerChanceByType: { "door-log-*": 0.10 } Modify that to be whatever percentage you want it to be. You'd be spending more time setting up the boilerplate for a mod than you would be making the change.

So, few things to note since I've been staring at tree code as of late. Firstly, the world generation of trees is actually quite nuanced and complex. Specifically, it actually is doing a grow-and-branch iteration that goes in arbitrary directions. The tree code isn't actually working in block logic, but gets simplified down to block logic to embed into the game once the tree is generated. Secondly, every single one of those details evaporates into the ether the moment those blocks are placed- trees, in the game, do not exist. Axes do some basic logic (break everything upward in a vertical square cone starting from the base, only cut the same kind of tree, only progress from log to branch and from branch to leaf) to ensure they "cut down a tree", but there's nothing coming from the tree itself there. In terms of what's "easier to implement", the first suggestion (random-chance unique leaf blocks) would actually be easier. Hell, I could tell you how to implement it right now. There's a function, public int GetLeaves(float width) { return leavesByLevel[Math.Min(leavesByLevel.Length - 1, (int)(width * leafLevelFactor + 0.5f))]; // width < 0.1f ? leavesBlockId : leavesBranchyBlockId } The array is indexed rather simply- the first entry is a leaf block, the second a branchy leaf block. Simply check if that value works out to be 0, and add logic to account for the random chance to have one of those "guaranteed seed" leaf blocks. Take the logic of this function: internal bool TriggerRandomOtherBlock() { return rand.Value.NextDouble() < otherBlockChance * config.treeBlocks.otherLogChance; } Replicate it, except now with "otherLeafChance". Apply that function similarly to how TriggerRandomOtherBlock() is called here: public virtual int getBlockId(float width, TreeGenBlocks blocks, TreeGen gen) { return width < 0.3f || NoLogs ? blocks.GetLeaves(width) : (blocks.otherLogBlockCode != null && gen.TriggerRandomOtherBlock() ? blocks.otherLogBlockId : blocks.logBlockId) ; } Additionally, you will want to replicate this statement for your new leaf type, inside ResolveBlockNames: if (otherLogBlockCode != null) { int otherLogBlockId = api.WorldManager.GetBlockId(otherLogBlockCode); if (otherLogBlockId == -1) { api.Server.LogWarning("Tree gen tree: No block found with the blockcode " + otherLogBlockCode); otherLogBlockId = 0; } this.otherLogBlockId = otherLogBlockId; } Then there's just the standard boilerplate stuff for introducing a new block that you'd do. Of course, I say all of this without having written a mod myself, but from what I gather everything I pointed out is the functionality of resin blocks in pine trees, and how to extend that same logic to leaves. You'd similarly have to update all the tree JSONs to include the desired variables, of course. The alternative, the "chance counter that increases until a success", is actually much harder. Generally speaking, tracking persistent stuff like that is a lot harder than it seems. The best you could manage there is specifically tying it to breaking trees with an axe, because that specifically nabs every block in the "tree" in a loop during the breaking process. Just modify the while loop in OnBlockBrokenWith. The problem is that you have no way to know whether or not a block actually dropped its given drop this way, so even then you can't count successful drops, just total sum of broken leaves.

Already fixed for next update. As for bell peppers, it is intended that they spawn despite not being plantable, to ensure that when they get finished (which according to that should be soon!), players don't need to generate new worlds to obtain them.

At least taking a look at the API and whatnot, if wolves are spawning right next to you then that is a bug- they should, at a minimum, spawn at least 18 blocks away. Additionally, they are blocked from spawning too close to block light sources- anything brighter than light level 7, and they should not spawn. If they are spawning regardless, this is a bug. These restrictions also apply to drifters, though drifters are barred from spawning due to any light brighter than light level 7, not just block lighting. A torch has light level 14, meaning that no drifters should be spawning within roughly 7 blocks (by Manhattan distance, presumably) of a torch. If they are, this is a bug.

A very minor detail, but given that hay blocks are flammable, should the thatch roofing blocks that they can be made into not also be flammable?