Erik

I can see the problem with the grindy voxel mechanics, though I think they are part of the games identity, so removing them completely is out of question. For an accessibility mode, I recommend Skru's suggestion: Minus the skills that is. The idea is simple, just hold right click and the voxels will be placed/removed automatically. This perserves the visual identity of the crafting, as well as the balancing for material, tools and time. This should however not be the default mode but as I said just an accessibility mode for those players who need it. I think it belongs in the world configuration screen, but as this feature would work seamlessly in Multiplayer, the option could maybe be in the options menu instead, but then I fear the majority of the playerbase using it because it being slightly more comfortable. Maybe some chat command to enable it in multiplayer instead? While this accessibility option would "fix" the voxel crafting for those who need it, the mechanic in general could also use some upgrades to make it less tedious, because especially the clay working can get tedious. Knapping, personally, I don't find that tedious, since it is only early game anyway and is really quick compared to the other processes. Did you know that when you disconnect a piece of voxels from the recipe, that piece gets automatically removed so you don't have to knap every voxel, just the ones around the tool? This small change has made knapping even more comfortable, but not everybody may know it exists. The clayforming can be unbelievably annoying when the player doesn't know about tool modes. Just press 'F' and you can select 2 by 2 or 3 by 3 placement or an option to automatically copy the previous layer. I personally have a grudge against tool modes, because they are hidden to newer players, are unimmersive and annoying to switch. The 2 by 2 placement has the additional problem of only being centered on one of the 4 voxels it covers, could be "fixed" by 3 additional tool modes for every other corner, but that would probably make it even more confusing and hard to use than it already is. I feel like the tool modes for kapping could be easily replaced by a more powerful and slightly more intuitive mechanic: Click and drag. The player clicks on a voxel and drags a rectangle to another voxel and all voxels within that drawn rectangle get a preview while dragging and will be removed/placed upon stopping draggin. The size of the rectangle could be limited to make it not too simple, I think 9 voxels of content as a maximum would probably feel right. This especially makes drawing lines easier, as the player can easily place a long line of 9 voxels with just one click and drag. As some players don't can or like holding down their mouse to click and drag, an accessibility more could be implemented to make it two clicks, one to start dragging one to end it. The accessibility mode may be considerable as a default option, as it prevents the player from missing the feature, like tool modes, as he can't simply place a voxel by just right clicking once. For the mid game I could very well see a turntable for automated clayworking being implemented, like how there is a mechanical hammer for smithing right now. I feel for smithing it is kinda harder to make it less tedious and get rid of the tool modes. Since there is a way to partially automate it (mechanical hammer), I don't view it as such a huge problem. Especially forming ingots from bloom is kinda meant to be tedious, to make the mechanical hammer a more worthwile upgrade. I imagine steel, which will be added in 1.14, will be somewhat easier to produce in larger quantities, as it doesn't require working a bloom, so it would eliviate the problem even more. An additional tool mode to upset (the one voxel move) a line of three voxels (so it'd be like moving each of the three voxels individually one voxel forward) would be helpful in many recipes, making smithing a bit less tedious. I personally tested (modded) this mode as a replacement for the normal upset, which would also work fine and make smithing require a bit more thinking. For selecting tool modes I have some ideas, but they would generally make smithing a bit harder/skillful and thus may not fix the problem of being tedious and are not something for this thread. A simple way to make a lot of smithing less tedious is allowing starting a recipe from a plate, additionally to starting from an ingot. I have also easily modded this into the game. As the plate can be automated with a mechanical hammer, smithing things like chainmail becomes a lot easier. Additionally to changes to single voxel crafting processes, there are also two general solutions to make any/all of them less tedious. One thing that could be done would be to lower the resolution of the voxel grid, essentially meaning both fewer voxels to manipulate and bigger voxels that are easier to interact with. The drawback of this is needing to redo the recipes and losing detail and thus making it slightly less visually appealing. I feel like this could make especially knapping easier, but for clayforming I feel it would disconnect the finished models from the ones created in the recipe too much and for smithing I feel setting the voxel resolution any lower would produce some gameplay issues (3 wide/2 high ingots is already present and I feel like it is already the smallest the ingot should be). Another easy option to make knapping and smithing less tedious is increasing the tool/armor durability, meaning the player would just have to engage with the systems far less. There is already a world configuration setting for this, but I feel like setting the default higher would be a good decision.

For most mod creators such a tool wouldn't make creating mods easier, having a GUI based approach is simply just often slower than editing a JSON file. Furthermore, editing JSON files isn't really coding but more like editing a configuration file, it's a data format and not a programming language. So a "VSCreator" wouldn't really be that helpful in my opinion, as it would only be a differently formatted text editior opening the right json files for the things you want to add/change, just another json viewer/editor, something that already exists. Also, MCreator wasn't a great success or useful tool for existing modders either, as there wasn't any mildly successful or unique mod created with it. The resources that would need to be allocated to creating such a program would be much better spend on creating more content for the game. So, if you want to mod, learn the JSON format and experiment by editing the games json files, consult the wiki and ask for help on the Discord if needed.

Vintage Story's combat has some fundamental flaws, that need to eliminated before any new combat mechanics are introduced: This small clip highlights the two main problems: Disconnected attacks and wrong timing Wrong timing: This is the smaller issue of the two and is relatively easy to fix. The issue is that attacks hit after the animation has been completed instead of during the animation. This makes timed dodging or blocking of attacks much harder, as the visuals deceive the player. In gamedesign, attacks can be seperated into three phases: The windup that is used to notify the player of the attack and the type of attack, giving him some time to to react, the actual actual attack during at the end of which hit detection will detect if the player has been hit or not and the recovery, when the attack has either hit or missed the target, giving the player some time to act. The drifter attack animation has a short recocery, when the hit frame is seen is the swing at 90 degree angle to the starting position, having being the closest point to the player if the player would stand directly in front of the drifter. But the hit frame is, as seen in the clip, after the recovery, when it should be in fact before it. The drifter is not the only example of this, the problems described here apply to all NPCs in Vintage Story. Disconnected attacks: The second issue is that although the animation indicates that the attack clearly missed, the attack still hits. This is a huge issue for gameplay, as it makes dodging attacks sideways or into the enemy impossible, leading to the common technique in many games with bad combat system: backpaddeling. Getting distance from the attack is the only way to escape it, so players constantly walk backwards in combat, while trying to outreach the enemy. One extra thing to note in the clip is that the animated attack should not only miss the player because of the rotation, but the reach of the drifters attack is exagurated, hitting more than range the animation actually has. The animation reach at the hit frame and the actual reach of an attack must match not only for NPCs, but also for the players, which attacks have even more additional range, to ensure attack readability in PvP and PvE situations. The attacks of the drifter seem to simply check if the player is in range of the attack and are completely disjointed from the animation and orientation of the drifter. While actual weapon swing simulation with real time detection if a weapon hits a target is not required, proper hit detection, checking if the player is in the attack cone of the enemies attack, is. For the player, cone based hit detection would also make sense, making hitting targets easier and differentiating the sword from a short range gun. The design of many, if not all attacks in the game should also be fundamentally reworked: The enemies should generally not rotate during the attacks, so dodging sideways or into the enemy is possible, attacks like the bighorn sheeps charge should not be like a homing missile, but like an actual animal charge, first getting some distance to then charge at the player, either hitting on a collision or continuing for a while past the player on a miss. Drifters could use a forward lundge attack in addition to the swing, to close distance and force the player to force the player to dodge sideways rather than backpeddeling.

I think the town center/guide post is not really required, as it also strikes thematically with the game. Not every player would want to be major of a town, most probably want a simple farmhand to help with managing the crops or a mercenary to explore some caves or raid some villages. So I'd lean more on a room based system like in Terraria, which is already kinda supported as there are already cellars and greenhouses as rooms in the game. So you just have to build a small room with a door and a bed and you could hire an NPC and it would be assigned to that room, either automatically or maybe by some management menu. Recruiting NPCs to work for you should however not be without cost. I imagine there would be people you can hire wandering around in the world, at traders or in villages. Hiring should cost money, i.e. gears, and only last for a limited time. Maybe, if you hired somebody for long enough, they may be willing to work permanently at your place as a follower. Then he wouldn't cost any gears, but needs to be feed with food, or else he will leave again. Once you have an empty room, there could also occasionally some traveler coming by, asking for a nights stay and paying some gears or labor for it. This could also be a way to meet NPCs you could hire or just make some extra cash by also selling them some food or equipment.

Some of the hunting mechanics described are possibly a little too complex for a game that isn't a hunting simulator. I personally would like the animals being faster and more elusive, running away if having spotted the player. Sneak mechanics are definitively a must have. Bleeding should definitively be a thing. A bleeding animal should leave a blood trail and slowly loose health. This should make hunting a bit easier, most animals only needing one hit with a spear to get bleeding damage for long enough that they will die, but the player has to track down the animal after hitting it by following the blood trail. So hunting would ultimately come down to sneaking up on prey, successfully hitting it (probably by throwing spear), following blood trail to corpse. Simple but immersive.

Seasonal limitations on crops, however that would be exactly accomplished, would be awesome, probably some min-max temperature system. I feel like the player needs to get exact data about the time of year a plant can be grown in the current location provided on the tooltip. A "can't be grown here right now" when it is too cold/hot and an indication how long (days) it can be grown till it is too cold/hot if not. Since the temperature curve is deterministic, this should be easily possible. Obviously the whole system needs to be tied in closely with the food preservation mechanic, which seems to be already made with it in mind. Spring to autumn, food should be somewhat easily and very regularly obtainable by farming. Some food should be harvestable often and some less often or even only yearly. It should generally be balanced, so that the longer a food takes to grow, the longer it can be preserved. The player preparing for winter is of course rewarded with him getting the nutritional benefits of eating from multiple food sources rather than just one. While even an unprepared player can survive the winter by hunting, only those who farmed and preserved food will be able to eat meals that provide every nutrient. The foods are already balanced that they are harder or easier to preserve depending on the nutrient type. Meat, while also freshly obtainable in any season, can be cured with a bit of salt and will last for years. Grains, while already lasting longer than most preserved food, can be turned into flour simply by grinding it, making it last for over a year. Vegetables can be pickled when having access to salt, but even then won't last too long. Fruits, while easily obtainable during fertile seasons, decay extremely quickly and are hard to preserve by creating jam, requiring hard to obtain honey, but lasts for years if stored in sealed crocks. So with this in mind, looking at growth times and other factors, grain should take the most time to grow, probably a full season. The other foods like vegetables and fruits should however be much faster to obtain. Something I would like to see with fruits are the plants taking longer to grow, but the fruits growing rather quickly once the plant is mature, allowing harvesting the plant multiple times for the rest of the season, example plants being tomatoes. Some unique farming I would also like to see are hops and grapes, which are slowly grown on crop sticks and ropes, dying down to just a root in autumn but automatically regrowing from it in spring.

I'm sure team is aware of this and the system will still allow things like that. There will probably be different types of water: Flowing river water that will be location locked to rivers only, but allow operating water wheels and probably irrigate crops. Maybe you could also pump it with mechanically powered pumps and aqueducts to irrigate fields further away from the river and allow it to act for limited transport of for example logs. Ocean/salt water might be added probably acting a lot like Minecraft classic water, filling up any air spot lower than ocean level. So you could build channels for ships and harbors with ease, the water filling itself in by itself. Maybe on the ocean there could also be water currents, which would make for pretty interesting boat gameplay when wind simulation would also be a thing. Lake water may actually have volume simulation, as it would be available in much smaller quantities than ocean or river water. So any water you pick up in a bucket (maybe except for salt water) would default to lake water when placed. Lake water would distribute its volume equally over the available terrain, making it easy to work with for building you own ponds, baths, etc. It would probably be much less useful for irrigation than river water, maybe farm land would even consume it over time. These are just some ideas I could come up with and not things that are definitively planned, aside from river water for waterwheels, which actually is planned.

The dev team is not against automation to my knowledge, but wants automation to be hard to archive and make automatic systems like chicken farms not as simple as some water and a hopper. I'm sure there will be more complex automation further down the line, but currently the development priorities are on getting feature parity with TFC and installing general gameplay systems, like seasons or crafting systems.

Brewing alcohol is something that is planned for the game, specifically update 1.14, and without there being a hydration system, there would be very little gameplay reason for it. However the inclusion of alcohol brewing as a mechanic opens the game up a very interesting and fun idea: An alchemy system, in other words a potion and poison brewing system. The goal of the system is not only to allow players to temporally buff oneself for certain tasks, but also reward players for exploration and experimentation, offering them an amount freedom. The alchemy system should therefore also act as a puzzle, to offer enough depth that experimentation and mastering the system is actually useful, rather than there being an easy way to always produce a perfect potion. An alchemy system obviously starts at potion/poison effects with the status effect system. A status effect should have a variable duration and a variable magnitude. After the duration has expired, the status effect is removed from the player. The magnitude determines how big the impact of the effect is, what it actually does is dependent on the type of status effect, for a healing effect it would improve the amount of health restored per second. Instant effects are possible by having a very low duration. Some examples for status effects: Healing: The player regenerates X health every second for T seconds. Harming: The player loses X health every second for T seconds. Exploding: The player explodes with a strength of X after T seconds. Haste: The player breaks blocks X times faster for T seconds. Status effects obviously aren't limited to the player, they work on any living entity. The same status effect can exist multiple times on one entity, meaning that the player can drink two potions to heal faster. There needs to be a menu players can access that lists all active status effects, with their description, magnitude and remaining duration. So what has this to do with alcohol brewing? Alcohol acts as a solvent and base for tinctures, which carry these effects. To create a tincture, an alcoholic beverage must be aged inside an aging barrel together with any number ingredients of ingredients. Alcoholic beverages can be made in several ways, producing different types of wine, beer and booze. By oneself, they don't do much, they maybe provide some nutrients or saturation and certainly make you drunk. As the base for a tincture they have three stats that vary depending on the type of alcoholic beverage: Duration, magnitude modifier and base toxicity. The duration determines the duration of the effects of tinctures made with this beverage as base. The magnitude modifier modifies the magnitude of the effects of tinctures. The base toxicity determines how drunk you'll get from drinking this beverage or tinctures made from it. Toxicity is actually an important gameplay system rather than just a bit of fun. Consuming beverages and tinctures will raise the drunkenness of the player. A bit of drunkenness will just give the player a slightly blurred vision (a depth of field effect, never the nausea effect Minecraft has, because only the player character should get nausea, not the actual player). It will get more blurred as the drunkenness increases. Next thing would be slight camera movement without player input, making the player character harder to control as drunkenness increases. At some point player input will be delayed and then the player characters will move about a bit without player input. As vision gets so blurry that it's almost as if the player character was blind, at 100% drunkenness the player instantly dies. Drunkenness thus acts as a limiter to tincture consumption, so players can't just drink ten healing potions at once and be invincible for a minute. (And I admit, it's probably a little funny too, looking at Deep Rock Galactic) Drunkenness on the player constantly decreases over time, so if you don't become addicted to tinctures, it should be easy to manage. But how do you actually craft a tincture? Well it starts with the ingredients. Ingredients are a type of item that doesn't carry effects, but contain alchemical elements. There can be multiple elements on any ingredient and multiple of any element too. So horsetail as an ingredient may contain 3 aqua, 2 terra and 5 umbra. You can see the elements represented by icons with numbers representing the quantity on the tooltip of the ingredient. When you add ingredients to an aging barrel, they will be dissolved and the elements they contained get added to the beverage. You can dissolve as many ingredients as you want into a beverage, even dissolve multiple of the same ingredient, and all the elements get added up. So when dissolving two horsetail, the beverage will contain 6 aqua, 4 terra and 10 umbra. Adding sulfur (4 ignis, 1 umbra) to it, it will contain 6 aqua, 4 terra, 11 umbra and 4 ignis. If a beverage in an aging barrel contains the same amount of different elements, like the 4 terra and 4 ignis here, the tincture created after aging the beverage will get the combinatory effect of that combination. Any combination of two elements will yield an effect, so as long as there are two elements of the same quantity in your aging barrel, the created tincture will have an effect. This allows the player to experiment and discover the effects different combinations. Some effects may appear in multiple combinations, meaning it is possible to get tinctures that apply the same effect twice, which would make for a tincture twice as powerful. While you can add as many ingredients as you like to your beverage, the lower the amount of elements in a combination, the stronger that combination will be, or in other words, the higher the magnitude of the resulting effect will be. So a combination of 1 terra and 1 ignis will produce a more powerful effect than a combination of 4 terra and 4 ignis. Each effect on a tincture will also increase the toxicity it by 25% of the base toxicity. All elements that aren't included any combination also decrease the magnitude of the tincture by a small bit. This means that you want go get close to no unnecessary elements in your beverage for it to be most effective. Only when the aging barrel is sealed up the combinations are locked and after a set amount of time you will have your tincture. The tincture can be filled into bottles, flasks or water skins and consumed by the player by simply drinking from those. Alternatively the tincture can also be applied to weapons and will apply the effects of the tincture to enemies upon hitting them. Applying 10 portions of a tincture to a weapon will yield 10 hits applying it. For the earlygame there should also be ways to utilize the alchemy system before brewing: Paste Instead of an aging barrel a player can use a pestle and mortar and instead of alcoholic beverages he can use animal fat or honey as a base. Pastes are created with the same system as tinctures, but their big advantage is they don't possess any toxicity. However they can only be applied to wounds and are generally much weaker than tinctures, but last longer. To apply a tincture you don't eat it, you apply it to a bandage and wear that bandage on an armor slot. While the wearer doesn't have full health, the effects of the bandage are applied. Bandages decay over time, like food. After it is decayed, the effects will no longer be applied. When toxicity is the trade off for tinctures, bandages using an armor slot is the trade off for pastes. Good ingredients are hard to come by and they almost always have more than one type of element, however there is an endgame way of extracting certain elements in their purest form: The alembic. The alembic operates very similar to an aging barrel, in the sense that you need to supply alcohol to it and can dissolve ingredient into it. Instead of sealing the barrel, you light a fire under the alembic and instead of being able to use any alcoholic beverage as base, it needs pure alcohol, which is only obtainable by repeated distillation of beverages in a small distillation tower. The alembic, while similar to the aging barrel, turns the alchemy system on it's head. Upon lighting the fire, types of elements are of the same amount, and therefore would combine into effects, get evaporated with the alcohol. What remains is a fine powder only containing the remaining elements. This powder is an ingredient itself and can be used for creation of tinctures or further refinement in the alembic. Encouraging experimentation and exploration While the system would work, a quick look on the wiki could make finding the right combinations and ingredients trivial. To make this impossible, the effects that appear on combination of elements should be randomized per world, only the elements on the ingredients should not be randomized. Upon creating a tincture or paste, the discovered effects from used combinations should be added to a searchable list in the survival handbook, so players can easily look them up. Alchemical recipes, outlining the effects of element combinations should also be able to be found in ruins as loot, which are also added directly into the handbook upon reading. Pure alcohol, alembics and powerful ingredients could also be ruin loot. Eating an ingredient containing two different elements of the same amount should also discover the combination of those elements. Implementation discussion While I think the system is quite elegant and easy to understand (only the less equals better aspect may be a bit counterintuitive), there is a problem regarding the implementation: How many elements do there need to be? The number of possible combinations and thus possible different effects can be very simply calculated with this formular: nC = n! / (2 * (n - 2)!) nC ... Number of possible Combinations n ... Number of different Elements As the number of combinations would probably not always exactly match the number of effects, there would need to be duplicate effects, which is a good thing, as it makes more useful and general effects like healing more accessible. I'd argue each effect should at least have two combinations that produce it, many effects may even have more. 16 elements would yield 120 possible combinations, which would allow for 60 effects, if every effect would have exactly two combinations. As there likely won't ever be more than 60 effects in the vanilla game, I think this number is fine. Effects would have a weight value assigned to them that determines how often they appear in combinations compared to other effects, so the randomization process can assign the effects to combinations properly. Each effect is however at least assigned to one combination. This would make the effect system easily moddable, allowing the creation of new effects. However as there is the hard limit of 120 combinations with 16 elements, it should be possible to add new elements. Elements are assigned manually to ingredients, so this would also require new ingredients or edits to existing ones, which shouldn't be hard to do. What do you think about this system after you got to the end of this wall of text? Any feedback is welcome!

No, they wouldn't. Getting enough rocks or ore is not the problem, but building tunnels either for aesthetic purposes or to even get to said ore. I also don't see any gameplay reason for the chisel style mining, it doesn't offer any interesting challanges nor enables other interesting interactions in both Omegas original suggestion or AlteOgre's more refined one. I however like the "rubble" idea, think breaking stone would create gravel (which is effected by gravity) instead of dropping stone, which can be picked up with a shovel or destroyed by hand for stones. There would be a real gameplay effect with it which would balance the added grind and I feel it would be very fitting for the Wilderness Survival playstyle, however probably not the default one. I really, really like the "weak spot" idea. It doesn't make mining any more grindy, but even lets you mine faster (less grind) if you don't just blindly break blocks but pay some attention to where you are mining (more engaging). There could even be different types of weak spots to offer some diversity and player decision making: Break the block faster by hitting the crack or slower but have a chance to get a gem or nugget by hitting the glittering spot?

While the breaking of the block may be solvable in the same time as before, the rubble and getting rid of it makes the whole process take a lot more time. Things that are already really grindy in the game, like quarrying for smooth stone, would become unbearable for most players. Mining efficiently for ore in Vintage Story is significantly different from what you describe, as prospecting above ground and looking for caves in or rich areas or digging straight down is the best way to mine, not building endlessly long tunnels underground.

It is a sandbox survival game, not just a sandbox game. It should force you to do things. The default survival game mode should not have a completely skipable night imo, as it defeats a lot of the purpose of the night. Being just able to skip the night defeats the purpose of building up defenses, a simple fence and permanent light. It degrades the purpose of crafting armor. The bed is what ruined the Minecraft survival experience for a lot of people, as the game became too easy with it. And players can do things at night time, it's the best time to do the crafting and smelting, prepare food, decorate the interior of your base. Once a player crafted some basic wooden laminar armor, the night isn't even that scary anymore as drifters are not even a threat anymore. Quality of life features are generally a good thing, but this wouldn't be a quality of life thing, it would be a major gameplay change, that would also only effect single player. I'm however not against some world creation setting or mods that allow you to sleep through the night, this is just about the default survival mode.

If you play hard mode, you get hard mode You can however tweak the difficulty settings at world creation to fit your liking, player health and damage can be individually modified in the customize world screen. As Streetwind pointed out, wolves in the normal mode are pretty well balanced. I still remember a time when wolves would be much more dangerous then they are now, a few major updates ago: Wolves wouldn't sleep/rest, they would be on the lookout night and day, they would spawn everywhere, hunt you down for hours and two hit kill you, for the entire game, because there wasn't any kind of armor. Now the only problem I have with them, is them making no step sounds, which can make them quite sneaky, but if you craft a set of wooden armor and a weapon, you are able to easily kill a wolf, if you dodge some of its attacks.

Assuming trees generated by the world don't grow and there is no natural reforestation (i.e. trees planting saplings without player input), the performance hit would be limited to world generation only. Only player planted trees would cause a performance hit, but that should also be fairly manageable, as the trees would grow quite slowly, probably taking a few ingame years come close to the size of "naturally" generated trees. The difficult question is how to efficiently handle a tree as a entity. Having one "tree entity" assigned to every tree seems to be the most straightforward option. Trees generated by the worldgen don't have a tree entity, because they don't need it, they don't grow. The tree entity itself would be stored inside the block that was originally the sapling. The entity would store the positions of all blocks belonging to it and would only update those the tick before a growth tick or the tick when part of the tree or part of the tree is unloaded. Tree destruction should still be done by an algorithm on the axe and should not utilize the data structure on the tree entity, as that would require the data-structure to store the coordinates of the tree blocks in a tree data structure instead of a simple list and the tree entity belonging to the chopped tree would still need to be tracked down by an algorithm on the axe, as well as trees without a tree entity still having to utilize the old search algorithm on the axe, so the whole endeavor would not be worth it. The one tree entity per tree approach however comes with some negatives, like having to check the tree positions every now and then, at least before the growth of the tree, as any of them could be destroyed/removed. Finding and updating the tree entity whenever a tree block is destroyed is also a possibility, however there may be ways to exploit this, such as possibly just moving blocks with pistons in the future or using save game editing tools. Then there are always the problems that could arise with trees lying in more than one chunk, being partially unloaded. Another way to handle tree growth would be to have multiple moving tree entities on one tree. These "tree runner entities" would only simulate growth at their position (and maybe surrounding blocks for leave generation). On a growth tick they grow the branch and move to the next further from the root until they hit reach the end of the branch and then either extend/grow the branch or grow branching. A runner also deletes itself when it reaches the and of a branch or a branching, however at a branching it also spawns new runners for each of the child branches. A new runner entity would be periodically spawned at the root/origin of the tree. They would essentially allow running the tree growth algorithm over multiple ticks, preventing stutters at growth ticks that would maybe be possible with a "one tree entity" model, when it has to check the positions of all blocks. It also has the added benefit of having a lower memory impact, as the tree block positions don't need to be stored on the entities. The downside of this approach being that there is some additional overhead, as there are a lot more block entities that need to be taken care of. Block entity visualization would also be needed to allow efficient debugging, but this also allows for much better debugging of the growth algorithm and modding of custom trees as they would visualize the growth algorithm itself. Problems with multi chunk trees and unloaded chunks can also be handled quite efficiently, as loaded runners can run as usual until they are either destroyed by reaching the end of their branch or hit the border of an unloaded chunk, when they would, instead of deleting themselves, just wait until the chunk becomes loaded, potentially stacking many runners at the chunk border to be released and quickly running in a single tick when the chunk gets loaded. I personally prefer the second approach, for its more intuitive solution for issues with partially unloaded trees and being less prone to lag spikes.

Make a pickaxe and a hammer. When there are copper rocks on the surface, there is always copper ore underneath. With a bed, you can sleep half the night.

Admittedly, the list is quite big and should probably be split up into separate more fleshed out suggestion topics, but things like the list for flora and fauna seem to be a good place for the devs to draw inspiration from imo. I'd suggest to reorganize this thread to be a more organized list of those, maybe with a little more info about each one, highlighting the interesting or very common ones. The other suggestions should then go into individual threads once more fleshed out. This would make the whole thing a lot more readable and prevent single suggestions from being overlooked as well as allowing for better, more focused discussions about the suggestions.

I've been playing "theHunter: Call of the Wild" a bit recently, which is as the name suggests a hunting game. I think a simplified version of its hunting experience could really fit VS. However, for allowing hunting to be more fleshed out, it needs to be more rewarding. Alchemy ingredients are one thing, like Kealty already suggested, another could be bigger meat and hide drops. I however think trophies don't fit, as I see it being rather unfit for a survival game thematically. Hunting should also imo be required for hunting down any creature, not just some "elusive creature" which only spawns if you have been following tracks for long enough. Creatures in general would be much more shy, running away at seeing the player. A simple stealth mechanic would be required, which would be effected by the players stance, immediate surroundings (i.e. is he hidden behind a tree or in a bush) and the sounds he makes, different ground types producing differently loud step sounds. I think the best use for a tracking mechanic would actually be for tracking down damaged animals who flee a great distance. Rather than just regenerating health over time, they would have an bleeding effect that causes them to loose health over time till they die. While doing so they loose blood, allowing for easy tracking. This tracking is especially rewarding because there will be a price at the end of the track, but the track might also lure in predators if not followed immediately. Full tracking of undamaged animals would probably be a lot harder to implement (How to generate animal tracks in newly loaded chunks, i.e. players would only come across tracks of animals they scared away, because they would have no tracks prior to spawning) and a lot less useful as a gameplay mechanic, even if animals are very shy. Some need zone system for finding animals without only sneaking when hunting would be a much better fit in my opinion, where animals return to certain areas, like their sleeping place or drinking spot. Animals just returning to their spawn position would probably be enough though.

You underestimate the work required to implement your suggestion quite a bit. It would not be terribly hard, but just changing some recipes is always done in a matter of minutes. However, I've looked a bit deeper into it and how the recipes are setup and just changing a number on them isn't possible, because the durability consumption for tools is hardcoded in the api to 1. For removing durability from Tools, Collectible.DamageItem() is used, which thankfully has an optional argument for the amount of durability to damage an item. The method gets called when Grid-Crafting with a tool by the method Collectible.OnConsumeByCrafting() and in the code for the BEAnvil.OnUseOver() for smithing. A simple solution would just be to add an exception when grid crafting with a hammer by simply adding something like: if (stackInSlot.Itemstack.Collectible.Tool == EnumTool.Hammer) { stackInSlot.Itemstack.Collectible.DamageItem(byPlayer.Entity.World, byPlayer.Entity, stackInSlot, 100); } else { stackInSlot.Itemstack.Collectible.DamageItem(byPlayer.Entity.World, byPlayer.Entity, stackInSlot); } replacing line 558. It would obviously not be an elegant implementation, but recipes would not need to be changed, including modded recipes. Replacing to tooltip would just be a visual thing that would indeed be a bit harder to do and is not exactly required. However making a special case for the hammer in the tool code is not something I would like to see. To be entirely honest, the best and simplest way to fix the problem is by modifying the smithing code rather than the item code, like you suggest. However, instead of involving chance and storing data on the hammer, but by having the "entropy counter" stored on the anvil and always changing it by a set amount. So every hit the counter gets decreased by one and the hammer only uses durability when the value reaches 0, which also resets the counter back to a hardcoded value describing how many hits it takes to lose one durability. To avoid exploits, the counter is set to 1 after the anvil has been placed, to always have the first hit cost durability. A similar thing is already in the game when it comes to clay consumption by clayforming where AvailableVoxels is used as the counter.

While an interesting concept, I don't see a need for it to be used for hammers. A much simpler solution would be to just have the durability be higher and allow non-smithing actions to substract more than one point of durability. The extra durability could also be scaled down just on the tooltip by just dividing the values, so it doesn't seem higher than other tools, although it technically is.

I like the general idea, but instead of a sifting table, a sluice would be a better thematic fit, being a bit more realistic (sifting tables filter by size, not weight like panning or sluices). Mechanics could remain roughly the same, but it would also need flowing water.

I thing the healing efficiency debuff for armors is a good think, but I think it could indeed be better designed: How about making healing, aka using bandages, take more time. Like three to four seconds. And being attacked during the healing animation cancels it. Healing in combat would be a lot more tactical and the armor healing debuff could just make the healing animation slower, in turn making it easier to get interrupted while healing. That makes the debuff only really relevant when in combat, which I feel would be a good thing. Honestly, taking off armor should also take time and be canceled when interrupted, making mid combat armor swaps virtually impossible. With the introduction of stamina (as a combat only resource, i.e. used for attacking/blocking and only for sprinting when stamina is not full), the speed bebuff on armor could also be changed to a max stamina debuff. This would make the debuff also only matter when in combat and not punish the player so much for wearing expansive heavy armor outside combat.

Currently, the ore distribution is not designed to suit building mining infrastructure like minecarts. I just think the game could gain a lot by having ore distribution that at least encourages and rewards building mining infrastructure. Ofc the game is currently working as intended, as there isn't any infrastructure right now, but that could change in the future, especially seeing as transportation (boats, minecarts) is a highly requested feature for 2020. More options are always great, but I think the game should focus on the more realistic, more interesting option. This isn't Minecraft, the target audience aren't kids, having Minecraft like ore distribution as a default would probably only harm the game, as it makes the "Minecraft-clone" arguments much more valid. Maybe a middle ground would work best, with most ores generating like they currently do (aka, small clusters with quality depending on the stone type and quantity depending on the ore map), but more advanced ores like iron or some types of coal generating in rare, long, thin veins with low quality ore that go on for miles and warrant construction of infrastructure, as iron and coal are very commonly used materials. It would spice up the system and give a good bit of variety. Maybe making only copper ore generation more like Minecraft would also help, as it is the starting material. It would certainly help new players, while not taking away from the prospecting, as any other ore requires it. Another supportive way of encouraging infrastructure would be to lower the stack size of ores and make turning ores into nuggets require an anvil.

Please only post in English in the future, so everybody can actually read the thing. There will be more automation, according to the roadmap: https://www.vintagestory.at/roadmap.html/ Energy will however be limited to mechanical for now. A watermill is planned iirc, but will only come after the implementation of rivers, which will probably take a while. More ingame explanations will surely come sometime.

Only true if time and monetary restrictions are not a thing. Nope, mods are a big sales point. Easy installation is just a bonus. And currently there just aren't many mods available. I'm not against CurseForge support, I think it's not a bad idea, as it provides free hosting and easy installation for mods. But making it out to be a "must-have" and a "valuable business decision" that has to be done "right now" is just plain false. Right now, new features and extentions/reworks of existing game systems is what the game would benefit most from, long term. When there are a few more mods available, it may be time to think about mod hosting and installation.

CurseForge support alone won't generate any new sales nor awareness, they aren't doing free advertisement. And integrating into the Twitch Launcher on the same level as Minecraft might not be as easy as it sounds. And it won't provide features, like auto-download of mods on joining a modded server, which I would personally rank much higher than third party one-click-install services. The most user and modder friendly way will therefore always be to offer first party mod management directly integrated in the game maybe with support for a variety third party mod hosting services. First party hosting would probably also be very nice, like with Factorio, but comes with additional work and costs. However, at the current point in time where there are only very few mods available for Vintage Story, it generally isn't worth it to put so much effort into a feature only very few people will use.