Erik

You're right that MultiMC doesn't have a browser for mods and modpacks included with one click install/update functionality. But you are not limited to Legacy FTB packs only, with the "Import zip file" option you can import any curse forge pack (apart from forge 1.13+ packs). Twitch Launcher however can't install FTB Legacy packs nor does it support Fabric. The twitch launcher is also unbearably slow and nowhere near as responsive as MultiMC, it is also loaded with a lot of features unnecessary for modding Minecraft, the whole twitch stuff. While it arguably provides the better user experience compared to MultiMC, but MultiMC is lightweight, fast, doesn't need a twitch account and has all the necessary tools to create and play modpacks. Sharing modpacks for private use is also easier imo, as you can just export a zip file. Switching to Steam for higher sales at a 30% cut would be a good business decision for most companies, but most companies turn out new games or dlc every year, generating new sales. Anego Studios however will probably only produce a tiny quantity of games (only Vintage Story for now, though Tyron said he wants to do a freelancer type game sometime in the far future), so the money from each purchase really counts, as I suspect most people will only buy the game once. Steam may be effective in short term, but in the long term, Anego studios loses out on a lot of money. Having created quite a few mods for VS myself, I think modding the games is quite easy and powerful already and I don't think rewriting the game to Managed Extensibility Framework is needed nor worth the investment, as you can already add/remove mods without restarting the game, as the game assets and libraries are only loaded on entering a world. Also not the right thread for such a topic.

Something that needs to be added is, that the launchers of those huge mod hosting sites like Curse and Nexus Mods are often just inferior to mod launchers specifically developed targeting a specific game. For Minecraft, twitch launcher is really bad in comparison to MultiMC. For Fallout/Elder Scrolls the Nexus Mod Manager or it's newer replacement Vortex is much worse from a feature and usability viewpoint than Mod Organizer 2. Using an inferior software doesn't actually sound that bad at first if it does what you want. But they often promote bad modding habits and thus result in a lot of mod compatibility issues, the user is unaware off. This is especially the case for something like the Steam Workshop. It's presented as a simple click to install service, but in games like Skyrim it really fails and causes a lot of issues because the user is unaware and unable to configure the load order, nor is the load order automatically managed with something like LOOT (Load Order Optimization Tool). Even the Nexus Mod Manager had a similar problem, while it allowed configuring the load order of mods (only manually though), it didn't allow configuring the install order and warn users about mods overriding files of each other. Vertex fixed both those issues and does a really good job at telling people of those issues and forcing them to fix them, but makes this unnecessarily tedious and lacks important features like manually changing your load order. Getting twitch launcher support for Vintage Story would just stick it in the Steam Workshop situation. Mod installation is easy, but things like conflict detection and resolution are not possible for the user, because the launcher is just too general and not specific enough to Vintage Stories needs. Also on a completely different note about Steam, why not release on Steam with a higher price to compensate for the 30% cut? Something like 22€ would still leave the devs with just over 15€ and provide regional pricing as well as more awareness and probably boost sames a bit. While not perfect, it seems like the best compromise.

It would probably best to use exclusively use English on the forums, so all players can understand, the Moin can should stay, though. I doubt it. The developers only want to include medieval and maybe steampunk technology in the game and flesh those out as much as possible. I think the uranium will probably be used as either just another metal for tools, alloys and steels (since uranium found in nature is mostly the rather unspectacular and less radioactive U238, which can't be used for fission reactors). As adding uranium to iron/steel (producing an alloy called Ferrouranium) usually drastically lowers the smelting point in the real world, I could see it used as some high end castable alloy. Maybe it would spice up the early game, before forging, as a very rare ore to produce some of the best alloys in the game. Another use I could see would be in steampunk nuclear reactors, could be a nice thing as an endgame goal for the type of player that loves engineering, when it would be made adequately complex to reflect that it is in fact a nuclear fission reactor. Maybe there are also some story reasons for it existing. The world was somehow changed by some temporal anomaly and the appearance of this anomaly is stronger in the underground. What's also in the underground? Uranium ore. And a long time ago, there was a lot more of the much more radioactive and fissionable U235 which decayed into U238 over time. The temporal anomaly could maybe have reverted this, or actively revert this. This could be an explanation of the origin of the drifters Milbenmenschen, as they were once humans seeking refuge in the underground, explaining the frequent underground ruins, that used the glowing and warming green rocks known as uranium as a replacement for fire (no wood in the underground, obviously). Little did they know that the radiation emitted gave most of them cancer and the few that survived developed mutations, evolving by radiation accelerated evolution into the drifters we know today. For gameplay reasons, it would probably be more fun to make the useful uranium 235 to not be present all the time, but just during temporal storms in high temporal flux areas. To harvest it as a powerful resource the player would need to take a huge risk and drive deep underground at the most dangerous time to do so to harness the most dangerous material, which sounds like a very fun way to get an endgame material. But most probably Tyron just added it because he thought it would be cool and he would probably come up with some uses later

I really like this idea, it gives the different plants some flavor and makes them more unique. It would also be a rather easy to add feature, so I think it would be possible to have both crop breeding and more realistic seed harvesting. The seed output of plants probably also needs to be adjusted to be higher when adding cuttings, so cuttings don't flat out replace seeds because they are easier to get. A cap on mutations would only be required, if all positive mutations at once added up to a ridiculous bonus, because the number of available mutations is finite. So just balancing the mutations would be required, so they don't give unreasonably huge bonuses. I'd aim for a fully decked out plant to have twice the growth speed and twice the yield and maybe half the nutrient consumption. It would very significant and reward the players engagement with the system, but also not too op imo. But something that may be required are general adjustments to the growth time of plants when seasons are added. That would obviously be balanced around how long seasons last, I think a plant being able to fully grow twice in a whole year would probably be a good spot and limit the speed of breeding quite a bit.

With the next big update 1.13 being set to be the seasons update soon starting development, it really makes sense to also expand on the farming experience in the game. I have some ideas on how to expand the already solid and comparatively deep system a bit: Seasonal requirements With 1.13 adding seasons, it only makes sense to make them interact with the farming system. The way this would probably be done is not through a plant a static timeframe of when it can grow, like in for example Stardew Valley, but the seasons changing the climate (temperature, humidity) of the area and thus interacting with plants via the already present limiters, slowing down growth if exceeding the limits or even dying if too far out of the range. While this system sounds fine on paper and could work reasonably good, the player isn't really provided with enough information for farming and has a much harder time planning ahead. I think it would be vital to give the player the range of dates the plant will be (efficiently) farmable in the current location on the tooltip. This should be doable, because the course of the climate over the year should be deterministic. It would also be very helpful to provide the player with an estimate of the growth time till the plant becomes harvestable in days, to provide the player with even more information. I think it's debatable how precise this information should be, if the precise dates should be given or rough timeframes, probably best to have this decision be a playstyle specific one. To allow setting much more precise seasonal and less environmental requirements for plants, it would make sense to add an additional layer, next to temperature and humidity: luminosity. Luminosity, the amount of light the sun emits, would change very predictably and smoothly over the year and would not be influenced by the climate, only by the season and latitude. This additional stat for plants would probably not be shown on the tooltip, but factored into the range of farmable days and growth time. Another feature related to seasonal requirements, I would like to see is "early harvesting". The idea is simple, plants being able to be harvested before fully grown, only yielding a fraction full amount of products. This feature would be useful for players who miscalculated their harvest or were given less specific time frames on the tooltip, at least being able to get some resources from their plants. Farming shouldn't be overly punishing for new players while also rewarding and allowing for careful planning, which is why I think these more user friendly features are required. Calendar GUI A small addition to the game, to encourage and simplify planning for the player: A context sensitive in-game calendar GUI. The calendar should not just be a regular calendar that shows which day of the year it is, but also allow for setting appointments, like sowings or harvests and show vital information about the days of the year, like the temperature and humidity on each day. Maybe the weather could also be forecast here, to allow the players to plan even better. Crop Watering I think the crop watering mechanic in the game is somewhat lacking, being still very simple just like Minecraft. I think Aira described it best here: While I agree with Aira on the problem, I have a slightly mechanically different solution in mind: Humidity being a soil stat like the soil nutrients. Plants would have a plants specific range of soil humidity where they grow at optimal speed. Plants consume soil humidity over time. The rate of consumption however follows a very important rule: Consuming water from the humidity maximum of a plant to the humidity minimum should always take two days. This is very important because of how watering cans would work: They should always fill up the humidity of the soil to the soil humidity maximum of the plant. This always makes watering required every two days, although watering the plants every day also doesn't work. The soil humidity should also effect the appearance of the soil, but this probably goes without saying. But why require such a complex system when all it archives is having to water plants every two days? Because of how water source blocks and climate now interact with the system. Soil has a humidity minimum, a value which the soil humidity won't drop below, even if a plant consumes some humidity. If this minimum is in the range of humidity a plant requires, the plant effectively doesn't need to be watered and will always grow at full speed. However if the humidity minimum and thus the soil humidity exceeds the plants humidity maximum, it won't be able to grow at full speed and watering not helping either (Oh no, the plant has too much water and adding more water doesn't fix it). The humidity minimum of the soil is dependent of the humidity of the climate (A swamp will have a very dank soil) and the distance of the nearest water source block. So the closer soil is to a water source block the more soil humidity it has. The effect of water source blocks and climate could be different depending on the soil type, with some soils staying relatively dry even when next to water and others becoming more almost liquid when next to water. The effect of this relatively complex system for the player is very simple: If the soil humidity (minimum) is lower than what the plant requires, water the plant at least every two days. If the soil humidity (minimum) is what the plant requires, be happy for your plant. If the soil humidity (minimum) is higher than what the plant requires, you shouldn't have planted here. The main benefit of this system is allowing adding even more diverse and unique crops, having different soil humidity requirements, like rice which needs excessive amounts of water or cacti which need almost nothing. Oh, and rain fills up the soil humidity. Crop breeding This is maybe the most complex mechanic I envision for farming, but also a very exciting one. The main idea is simple, allow the player to breed plants with better stats via abstracted genetics. This is also an entirely optional system for the player, who is not required to engage with it in any way. When a plant becomes fully grown, it has a chance to get one or rarely two random mutations. These mutations are drawn from the pool of possible mutations, which act like small perks for the plants and can either be positive or negative. These mutations could be a quicker growth speed, a higher yield, less nutrient consumption, but also negative things like slower growth speed or a new additional type of nutrient consumption. Maybe some more obscure ones like "makes rabbits close by very aggressive" would also be fun. Different mutations have different chances to appear, so there might be some very common and very rare mutations. Generally a positive mutation is as likely as a negative one. All the mutations of a plant are shown on the block info overlay. Negative mutations do however always come with an additional rarer positive mutation, so really plants have a chance to really get up to four mutations, but at most two positive. Most of these mutations are however useless on fully grown plants and the mutations don't carry over to the seed the plants drop. The be able to grow a plant with these mutations you need to take some cuttings. This can simply be done by right clicking the fully grown plant with a knife and will yield several cuttings, however also destroy the plant and yield no resource or seed drops. The cutting can be planted like a seed and will grow into a clone of the original, carrying over the mutations and not getting new ones at full growth. The cutting however has a slight disadvantage compared to seeds: it decays like food. This can obviously be slowed down or prevented in the same way as food. Cuttings with specific mutations are also sold at merchants. So now you can get and reproduce mutated plants with special perks, but how to actually breed them? It's really simple, if a plant (not from a cutting) reaches maturity, it will not only have a chance to get random mutations, but also has a 30% (50% if there apiary nearby) chance for each mutation a neighboring fully grown plant has to also get that same mutation, 5% if the plants aren't of the same species. Obviously plants have four neighbors, so a plant surrounded by fully grown mutated plants with the same mutations drastically increases the chances of mutations carrying on. A plant also can't have the same mutation twice, so no stacking of three "Fast growth" mutations, but different mutations effecting the same stat stack, so a "Fast growth" and a "Quick growth" mutation, is possible. This is actually the whole system, it's not actually that complex, but adds a lot to the game. There are no limitations on how many mutations a plant can have, the only real limitation in the system is time, as breeding plants takes as long as growing them and because randomness plays a huge factor in the system, getting to the point of having every positive mutation on a plant will probably take many, many ingame years. End even then, that would only be for one species of plant. The whole system encourages a bit of specialization on specific plants, as plants of different species don't breed well, and therefore really encourages trade between different players, as they may have focused on different plants. New crops New crops are definitively something that should be added to add more variety to farming. I would actually like many crops to have unique mechanics or twists to them, much like in Stardew Valley or the Growthcraft mod. Grapes and hops that will grow onto ropes above them, rice that needs a lot of water, plants that allow multiple harvests, etc. I would keep fruit trees for another update, as they will probably follow much different rules than the current crops. The new crops could also contain some new world crops, with a special way to get them: Only being available on climate bands other than the spawn one. So players would have to travel very far through the arctic to get them. This wraps up my collection of ideas for a farming expansion in 1.13, be sure to post your feedback and other ideas.

Sorry for the late reply, had to deal with studying and writing exams first. Thanks for the liking the suggestion, I guess I don't think this is a very good idea, as that makes the stamina system very present outside of combat, punishing more relaxed playing or just AFK-ing. Being able to brew beverages and potions that increase the maximum stamina would probably be a better and more fun/involved, although less realistic and more game-y, way to do it. A damage boost after a parry sounds like a very good idea, I really like it. Although I think it would better fit the attack blocking, as it's much harder and riskier to pull off and lends itself more towards a hyper-aggressive style of play. Also like this idea, but would limit it only to the axe (and maybe a dedicated, stackable throwing knife), because encouraging players to play with a knife and a shield would make them look kinda weird imo. The regular knife could do extra damage and ignoring armor if attacking a target from behind. Absolutely. Definitively. Yes.

The return of the combat suggestion It’s been a while since my last combat mega suggestion and I think it’s time for a refresh to end this trilogy. This one is a bit more specific and tries to present a (theoretically) fully functional combat system design. I’ve had even more time playing melee combat oriented games like Mordhau, which released into early access last year. While it has some of the best, if not the best, first person melee combat in games, the general design would be very unfitting for Vintage Story, as it requires real time sword simulation, more accurate hitboxes, high tickrate lagfree servers and procedural animations and multiple metric tons of balancing to be somewhat serviceable. But it has some ideas Vintage Story could really benefit from, like some other games like Mount and Blade, Dark Messiah and even Skyrim. Combined with some of my own ideas, I’ve come up with a melee combat system for Vintage Story that meets these requirements: Melee combat rather than a short range first person shooter This is the biggest problem of Minecraft combat, the long attack range makes hitting other players really difficult, as they can easily move out of the cross-hair of the other player. The game becomes more about aiming and clicking at the right moment, resembling a FPS much more than a melee fighting game. Enough depth to enable a large degree of player freedom Having a combat system with a high skill ceiling and many viable playstyles makes the combat much more replayable. A large amount of player freedom aims to archive this and have players evolve their own styles, emotionally connecting them with the gameplay. Little complexity for easy use without need of a tutorial Complexity is the evil brother of depth. It would make combat much harder to learn, understand and even implement for the developers. Having combat be easy to learn is essential for the new player experience, as combat is a major part of the game. Simple mouse based control without need for extra keybinds This is a good way to limit complexity and make it easy for new players to learn the system, not having to look up controls and being familiar to many other games. Working with ray traced or cone based hit detection This keeps the implementation effort much lower than real sword swing and collision simulations would require, as well as having a much lower potential for issues (no potential inverse kinematics, etc.) and exploits and being much more performant. Allowing for both engaging PvE and PvP combat The game allows for both PvP and more prominently PvE combat and the combat system should reflect that, being fun and providing depth at both levels of gameplay. No turning combat into a waiting game for cooldowns Minecraft 1.9+ combat has annoying cooldowns, making the players unable to perform any action directly after attacking. This makes for boring unengaged combat. First Person use doesn’t give players big disadvantages Vintage Story is primarily played in first person because of the focus on the building elements of the game, having the player switch perspectives for combat seems like a very bad idea and lowers the overall immersion dramatically. Therefore the combat should be designed primarily for first person use. Combat system not majorly interfering with other game systems The combat system shouldn’t effect other game aspects much, like exploration, as to not make these aspects less fun or more frustrating, by for example limiting running or destroying blocks outside of combat with a stamina price. More player skill based than character skill or gear based While gear progression and character skill should have a significant impact on combat, as to allow for more PvE progression, the most important factor for combat should be player skill, to allow for an engaging PvP experience and progression of the players skills. Effective reaction for every action and reaction This is a core piece of the combat design, the player should be able to react to any combat action and if doing so successfully forcing a new reaction from the opponent. Ideally there would be more than one possible reactions, to allow for player freedom. The goal is to never have the player in a situation where he is unable to do something helpful, making the game never feel unfair. Easy readability to allow for reaction based actions To be able to react to an action, the player has to be able to read which action he has to react to. The first person perspective and limited animation system can make this hard from just animations alone, requiring very expressive and clear animations and sound effects. Playability with higher latency and lag While the combat gameplay benefits from a lower latency, the combat system shouldn’t break at higher latency and therefore shouldn’t rely solely on precise player inputs and reactions and keep being playable even with lag. Stagger There are basically three types of actions in the system, the offensive attack triggered by the left mouse button, the defensive block triggered by the right mouse button and the evasive dodge triggered by the movement keys. Fitting those actions, there are also three types of stagger, fitting each of the actions. Attack stagger hinders combatants to attack for a variable duration. Block stagger hinders combatants to block for a variable duration. Movement stagger hinders combatants to move, but not to dodge. These staggers are mainly used as a punishment for those effected, very but short staggers are also frequently used as a way to limit spamming certain actions and allow for more dynamic combat. A key thing to note is, that the player should almost never be effected by all three types of stagger at the same time and only very rarely by two, as to not limit the players actions completely. To prevent the player being “stagger locked”, dodging can always be performed to break out of a stagger, providing the player has enough stamina. If he doesn’t, he screwed up one last time. During the stagger, distinct stagger animations should be played, to convey which type of stagger the player or his opponent is effected by. Stamina Speaking of it, stamina is also a major aspect of the combat system. It’s a limiter for the player’s defensive and evasive actions. The player has a large pool of stamina, which could almost be seen as a second health bar and certainly is that important, often quickly resulting in the death of the player if empty. Stamina regenerates over time. Most actions in combat consume an amount of stamina to balance them and punish players spamming some actions, while not explicitly preventing players to do so like with stagger. However, while many things consume stamina, only three actions are prevented by having not enough stamina for them: Blocking, dodging and running. Combatants can’t block if completely out of stamina, making him very venerable. Combatants can’t dodge if the stamina remaining is smaller than the cost for doing so. Combatants can’t sprint if completely out of stamina, making them unable to flee from combat. While all actions effecting stamina will be outlined later in this suggestion, there are two existing actions interacting with stamina, sprinting and jumping. Jumping just prevents stamina regeneration for a short duration. Sprinting is only possible when not out of stamina and prevents stamina regeneration, but only consumes stamina if stamina is below two thirds of the total stamina. This makes stamina normally not limit sprinting, only if the player was already engaging in combat. This makes stamina only have a relevance in combat and not limit the player outside combat. Stamina is required for not having to result to more limiting ways of preventing players spamming certain actions. Without some way to punish spamming, the PvP combat would result in the same problems the Mount and Blade combat (i.e. feint spam) has, which resembles this system in a lot of ways. The attack The most important part of the combat system is always the attack. The player can attack simply by pressing the left mouse button. The player won’t regenerate stamina while attacking. The attack can be split into six distinct phases: The start By pressing the left mouse button the player begins his attack. The movement direction of the player during this decides the type of attack the player launches: If the player moves forward, he will launch an overhead attack. The overhead attack is the slowest attack and has also the least reach, but does the most damage. For hit detection it uses a vertical cone, making it easy to dodge by stepping sideways. If the player moves backwards or sideways and backwards at the same time, he will perform a stab attack. The stab attack has the most reach and is the fastest, but does the least damage. For hit detection is uses a ray cast, making it the hardest to aim and easiest to dodge. If the player moves sideways or forward and sideways at the same time, he will perform a swing attack. The swing attack strikes a middle-ground of reach, speed and damage. For hit detection it uses a horizontal cone, making it the hardest to dodge. The direction of the swing depends on the sideways movement of the player, moving to the left will cause the attack to come from the right and moving to the right will cause the attack to come from the left. The swing direction is only important for attack blocking, which is described in the third attack phase. If the player stood still during the attack, the last movement direction will be used to determine the attack direction. During the attack, the player will be slowed down when moving in any direction other than the direction starting the attack, making movement more important. The wind-up As long as the player keeps holding the left mouse button, the attack won’t launch, only the wind-up animation will be played. During the animation, the player slowly looses a bit of stamina. If the animation is finished, the player will hold in the last position of the animation until the mouse is released. The player can release the mouse at any time, even during the animation, to immediately launch the attack into the swing phase. The further the animation progressed, the more damage the attack will do. If the player just tapped the left mouse button a very small wind-up animation will be played and then continue into the swing phase. During the wind-up phase, the attack can be cancelled by blocking. The swing The swing phase marks the last phase of the attack the player has any control over it. When the swing phase starts, the player looses an amount of stamina, dependent on the weapon used to attack. A swing animation is played and the attack will progress to the next phase when it has ended. If the player presses the left mouse button during this phase, the attack will be cancelled and he will immediately start a new attack (returning to the start phase), but gets block staggered for a small amount of time, meaning the player can’t cancel his new attack by blocking if he doesn’t wind it up for some time. This is called morphing. If an attack hits the player during this phase and it has the mirrored direction of this attack (i.e. overhead when overhead, stab when stab, right swing when left swing, left swing when right swing), it will be attack blocked, meaning it won’t do any damage and let this attack continue. During the swing phase, the attack can be cancelled by blocking. This is called fainting. The commit The commit phase marks the phase the attack can only be cancelled by the player getting attack staggered, by for example being hit by an attack himself. The phase starts by the player making a short scream, making it clear to his opponent, that he can’t cancel his attack. The players camera is also locked during this phase, meaning he can’t aim his attack in a different direction. However the player can still move. The commit animation is played and when it ends the attack transitions into the next phase. The hit detection The hit detection is ran. When the player has successfully hit an opponent, that opponent gets movement staggered for a tiny amount of time. If he wasn’t blocking he also gets attack staggered, causing any attacks of the opponent to cancel. And well, the opponent gets damaged. The recovery The recovery is the last phase of an attack and plays right after the hit detection. The player gets attack staggered for the duration of the recovery, but the player can cancel the recovery by blocking (however not cancelling the attack stagger). This phase can be of really different length and animation, depending on how the last phase went If the attack misses, a long animation is played where the sword continues travelling and then hangs in the air for a bit. If the attack hit an opponent who wasn’t defending, a short animation is played where the weapon first stops for a small while on the opponent (hit-stop) and then goes through the opponent. The hit-stop conveys that something has actually been hit and the player isn’t just swinging through the air. And a nice meaty hit sound plays. If the attack hits a block, a medium length animation plays where the sword is stopped and lingers at the shield for a while. A fitting sound is played. If the attack hits a parry, the a medium length animation plays having the sword bounce of the parry. A fitting sound is played. If the attack hits an attack block, a very short animation where the sword is bounced of the enemy sword is played and a metal on metal grinding sound is played, maybe some nice spark particles get also in the mix. The sound and animation of each should be very distinct, to make it immediately obvious to what happened to preserve readability. In summary: Directional attacks (overhead, stab, right swing, left swing) Holding the attack for increased damage (wind-up) Cancelling attacks with blocking (feinting) Changing attack direction by restarting attacks (morphing) Directional blocking with attacks (attack blocking) After you scream, you lose control over the attack (commit) Attacks getting cancelled when being hit by one (hit detection) Different animations after the attack hit or missed (recovery) The block Blocking is much simpler than attacking, just hold right click while not being out of stamina to hold your weapon or shield in front of you. Players can block as long as they want and when they release the right mouse button the block immediately stops. Stamina however doesn’t regenerate while blocking, but blocking does actively deplete a small amount of stamina. When out of stamina, the block is cancelled. This makes hiding behind a block extremely ineffective, it’s best to block only when about to be hit. When an attack hits the front of a blocking player, the blocking players health doesn’t get damaged. However the blocking players stamina gets damaged depending on the health damage the player would have endured. After lowering a block the player get block staggered for a while and thus can’t block again immediately after and stamina won’t start regenerating for that duration. Up to two seconds after the block has been hit by an enemy attack, this drawback is not active, so the player can block right again after lowering his block and stamina regeneration will also start immediately. If the player presses the left mouse button while blocking he will perform a parry. A parry is an active attempt to deflect an enemy attack. A short parry animation gets played and if an attack hits the player during this animation, the attack will be blocked without giving any stamina damage to the parrying player. After the parry animation ends, the player will get block staggered for a short while if no attack hit the parry, forcing the player out of blocking. This makes parrying a dangerous but rewarding action, if timed properly. In summary: Holding a block costs a small amount of stamina Attacks hitting a block cause stamina instead of health damage Can’t block again directly after blocking Parry negates the stamina damage from blocking but must be timed The dodge Dodging is a simple and effective way to, well, dodge enemy attacks. The dodge costs a medium amount of stamina and the player won’t regenerate stamina during the animation and a short while after. Just tapping the sprint key while having enough stamina to cover the cost will cause a dodge in the current walking direction, without changing the looking direction. A short dodge animation gets played and the player quickly moves a few meters in the walking direction, smoothly moving over up to one block high ledges. While dodging is a very effective means of evading attacks and leaves the opponent in a venerable position after having missed an attack, being in a long recovery animation, it also leaves the player venerable right after dodging, suffering a short block stagger and very short movement stagger. Combined with the comparatively high stamina cost, this makes dodging a supporting means of defense to be used in conjunction with smart movement and positioning in PvP, but a very important defensive measure in PvE. The gear With an armor system now in game, the system can be easily adapted for this combat suggestion. With active blocking, the effectiveness of armor needs to be reduced a bit, to not make fights last centuries. Furthermore, the move speed penalty of heavy armor should be reduced for significantly for balance and comfort reasons, adding new negative modifiers to heavy armor like reducing stamina pool and raising stamina costs for certain actions, like dodging. Shields should be introduced, lowering the stamina consumption from blocking, but raising the cost of other actions like attacking or dodging. Spears should also only block, when the player has a shield equipped, retaining the throwing ability otherwise, giving them a very unique playstyle focused around evasion and attack blocking. Stamina modifiers could be added in many places, however they shall only change stamina costs and the players stamina amount, not the speed at which stamina regenerates, as that would be too big of an advantage or disadvantage. Stamina costs act as a new balancing factor and would be applied to any weapon and also to drawing a bow or throwing stuff like rocks and spears. The balance I did not add any numbers to stamina costs or action/effect times on purpose, but some wording describing the relative length of effects, because providing hard numbers isn’t exactly useful, as only extensive testing will find the right numbers. But generally speaking, offensive and defensive actions should be somewhat equal in stamina costs, to not make super aggressive or super defensive playstyles superior, although giving offensive actions slightly lower costs than defensive actions seems like a good idea to give incentive for active offensive playing. Overall, the block and attack staggers are setup in such a way, that the attacking combatant and defending combatant are always switching, as there is a block stagger after blocking and an attack stagger after attacking. Conclusion I hope his system is easy to understand and fun. Other than that, replacing the red flashing when landing a hit with a proper hit animation would be a wise decision. I invite anyone to provide any kind of feedback on this. Did you understand the system, do you dislike is, think it's too complex and complicated or maybe too shallow or do you think it's just total and utter garbage? Every type of (hopefully constructive) feedback is welcome!

Sorry if it wasn't clear enough. I'll change the thread a bit later to make it a bit more clear. Torches are basically ignited by right clicking a (stack) of torches on the campfire. The player can only reignite/ignite placed torches with other torches and torches in his inventory with a campfire. Ignited torches stay ignited when placed. Hope this clear up things a bit. If burn time is inherited, this would be the case, players would be encouraged to light their placed torches manually and only bring one burning torch. When burn time is inherited however, then it's irrelevant if the player lights all torches at the campfire or lights placed torches later, the burn time would be consistent between inventory and placed form. Without the inheritance, it would separate the burn time of placed torches and in-inventory torches. This system would of course work, but it would lead to the exploits I described, with players being encouraged to place their torches as late as possible. The ability to "refresh" already burning torches with other torches (not sure if you mean placed or inventory or both) would make fire not a resource, but just a timer the player has to refresh every now and then. The campfire should imo be the only place to refresh torches, it represents the source of fire and new fire, meaning burn time, should not be allowed to be created without it. It's not realistic, but it makes sense from a game design view. That would not make fire the resource and make the whole system obsolete: When a torch in your inventory dies out, it is turned into an unignited one. So two torches, one ignited one unignited, in your inventory would make an infinite loop of reigniting. When however torches would be removed from your inventory when burned out, the system would essentially be "the more torches you carry the more light you have" and as players can easily carry two stacks of torches, which would yield enough light for an eternity, the whole system would also be irrelevant.

You can still place ignited torches, they also stack like food, I didn't say anything otherwise. If igniting placed torches with a torch from your inventory would not inherit the burn time, it would make placing already ignited torches less effective, as they would suffer from the burn time, otherwise that would ofc cause your problem, so placing unlit torches and lighting them would be more effective. that's another reason why igniting torches should inherit the burn time.

I'm also a bit on the fence on this point, but without it, it would be encouraged for players to light their torches as late as possible when exploring caves. just before the torch used to light them burns out. With the tweak however, it's irrelevant when the player lights the torches, they will all extinguish at the same time, when the torch used to light them extinguishes. It also makes light a bit easier to manage, as the the time left till the torches on your cave diving extinguish is even indicated on the torch used to light them. It would probably just be best to make it a world configuration point, so the player can choose and everybody will be happy.

Currently in VS, fire is something that just happens when you throw fuel into the campfire. Torches need to be lit and will burn infinitely long in your hand or burn out a while after placing them, without any way to relight them, they just have to be replaced by new burning torches. In VS 1.12 we will have a fire starter to light the campfire and relight torches and campfires extinguished by rain, but not burned out torches. I think there are a lot of gameplay and immersion opportunities regarding fire, by making it actually a resource you need to manage. Instead of making starting and maintaining fires easy, it could require some skill, like described in the firepit overhaul thread: With world setting we now also have a way to make the feature difficulty configurable, so more casual players won't be effected. But not only the campfire would be changed, also torches would be: Unignited torches can be crafted with a stick and some tinder. The torches can be improved by crafting them together with tree resin. A stack of torches can be ignited by holding right click on a burning campfire. Ignited torches decay/burn out even in the inventory, similar to food rotting, and have a durability bar to indicate their burn progress. Ignited torches can be used to ignite campfires, but will be consumed in the process. From here, two systems are possible, either unifying in-inventory and placed burn time: Unignited and ignited torches can be placed. Placing ignited torches will inherit their burn time (if the torch would last two minutes in your inventory, it will also last two minutes placed). Unignited and burned out torches can be reignited by right clicking with an ignited torch, but inherit the burn time of the torch used to ignite them. Placed ignited torches will drop ignited torches when destroyed, inheriting their burn time into item form. Burnt out torches (placed and in inventory) revert to being unignited ones. Right clicking a campfire with ignited torches will reset their burn time. Or separating them: Unignited and ignited torches can be placed. Placing ignited torches will reset their burn time. The burn time of placed torches can be reset by right clicking them with an ignited torch. Placed ignited torches will drop unignited torches when destroyed. Burnt out torches (placed and in inventory) revert to being unignited ones. Right clicking a campfire with ignited torches will reset their burn time. These changes makes managing torches and therefore fire much more interesting. As they now always have a set burn duration, even when in your inventory, players have to plan ahead when for example exploring caves, maybe bringing wood and tinder to start a campfire in the cave to get fresh ignited torches. This also makes caves much more scary, as there is a real chance that your light will go out and you'll succumb the darkness. In addition the feature makes using torches also much more convenient, as they can be quite easily reignited in your home or already explored cave segments.

There are already teleporters in the game, but their locations are fixed. I don't really see any benefits or need to add fast travel into the game.

One thing I always found odd about VS is how many "hold mouse button" interactions there are. What first comes to mind is obviously breaking blocks, which adds a processing damage layer over the block you try to break and after the maximum damage drops the item. Another similar interaction is picking berries. You simply hold the button and after a small amount of time, berries get added to your inventory. Or skinning/butchering a dead animal. After some time a small inventory opens with some meat and skin. However picking berries and skinning/butchering lack one thing compared to breaking blocks: Progress feedback. This may seem like a small thing, but it makes the interactions feel much worse in comparison. It makes it feel like an endlessly long meaningless interaction. So, how to fix this? Simply add a progress indicator. I would just prefer something simple on the HUD, near or around your crosshair, like the drawing the outline of a circle around your crosshair. Another thing that annoys me about these interactions is how inconsistent they are: They provide the player with items in three different ways: Breaking blocks drops the block Picking berries adds the berries to the players inventory Skinning/butchering an animal opens an inventory containing the loot I personally would prefer if they all just added the blocks/items to the players inventory (with the pickup sound playing), as it is the most convenient and logical interaction, only dropping things onto the ground when the inventory is full. To make skinning/butchering an animal even more satisfying, instead of providing all drops at once after the process is finished, only one drop is provided and the process is repeated (restarted, so new progress bar) until there are no drops left in the animal. This makes the rewards more gradual and adds a bit tension, as the animal may provide another piece of meat after one the player is currently butchering. The player not only gets rewarded a piece of meat or skin after skinning/butchering an animal, but the chance for another one. As a side effect, also allows for multiple players to skin/butcher the same animal at the same time in a shorter amount of time. Accessibility options: One thing that should also be noted about "hold mouse button" interactions is, how many players dislike them, because they have an affection or disability that makes holding the mouse button for a long amount of time really discomforting. It was even the main point of critique a certain developer gave for my smithing mod :P. However the issue could be very simply fixed by adding two keybinds for a "toggle left/right mouse button press" emulation or just having a setting that turns all "hold mouse button" interactions into interactions that are started by a simple click and canceled/ended by one (or looking away from the interaction).

I think just having the rule simply be that knappable voxels sides need to be exposed on at least on side would have a very similar effect and would allow every recipe to work. Another change that might positively influence the new player experience would probably to reduce the grid size from the 16 by 16 to an 8 by 8. This would require new recipes, but make knapping less time consuming and fiddly, as the player will probably have to knap a lot of tools in the first hours of the game.

Enemies having multiple different attacks is certainly a necessary addition that I hope gets added soon. Maybe combat actions other than attacks would also be a good thing, like certain enemies being able to heal or summon things. For them to make sense to have animations, they should be able to be canceled by the player, by for example attacking the enemy during it's healing animation. I however don't think that multiple damage types would be a good idea, as the only thing it really adds for the player is needing to bring more weapons, however these are forged and handle very similar to each other, just having different damage types. I think normal damage and anti-armor/armor bypassing/armor reduction/whatever to counter armor damage would be enough to differentiate most enemies, being either heavily armored, a bit armored or not armored at all. It could also have a bigger effect on the playstyle, having slow heavy attacks bypassing (more) armor, rather than always needing to bring a warhammer. Other than that, some enemies could have very strong armor that can be partially/fully removed by using pickaxe on them, not needing players to bring another weapon type, maybe even having to target armored spots with the pickaxe to reveal weak spots. That would however require a location damage system, which I also think would make a great addition to the combat, especially ranged combat (headshots, etc.).

There way never a tree felling animation, you must have confused it with some Minecraft mod (Dynamic Trees maybe?). Or you come from the far future. Or you remember a bug that caused the log items to fall in a straight line, because the random number generator was broken.

I generally really like the idea of a more even playing field, where player skill is more important than the tier of equipment, but I'm opposed to adding a sharpening system that encourages constant babysitting of the weapon. I don't think the durability cost is enough to discourage people from doing it, but balancing it to avoid tedium may be possible, with very significant durability costs. But then you're at a point where sharpening it pointless, because sharpening is not worth the cost. The sharpening topic has also been discussed twice before, so you can get some players opinions and ideas: I'd rather see a system with minor damage differences (the best sword doing twice as much damage as the worst) and significant durability differences, as it would also make player skill more significant while not adding more tedium and a tool repairing system where you trade maximum durability for durability (as suggested by Luk).

I agree with this, hunting is too dangerous and tedious and not rewarding enough on top. Animals should drop a lot more meat since it spoils so quickly and animals should take fewer hits to kill. To make hunting not too easy, I think some simple stealth mechanic and animals trying to run from the player would be enough and incorporate throwing spears and bows better in the early game. Farming is supposed to be the only reliable source of food, which I think is a good design decision. As it takes long for crops to grow, it's however not really viable early game. Picking berries and hunting chickens seems to be the best early game way of getting food, but to be effective you aren't allowed to settle down, you must be on the move to find new berries. Like Stroam stated, cooking also helps significantly. The normad playstyle has the additional advantage that you will be gathering copper nuggets the whole time, which eliminates a lot of grind. Don't waste your copper on axes, they break far too quickly to be worth it, in fact, only use your copper for a pickaxe and an hammer, which allow you to mine and process ores from the underground. I personally think having to use two tools only to use ore is a bit too grindy, ore chunks should be smeltable without hammering them at lesser yield. Never mine in VS like in Minecraft with the hope to hit an ore out of pure luck, or you will waste a lot of pickaxes. Stick to caves, maybe use a propick to get a sense of the resource density in the area. Getting to copper tools can be done in less than an hour, but finding the minerals for bronze, which only spawn underground can be quite time consuming and is very dependent on luck. I think the game could use an overhaul of the ore generation and the propick to make it less dependent on luck and more dependent on mechanical knowledge. This is actually quite a common and valid critique. As the early game can take a long time, knapping should be faster, which could be rather easily archived with less but bigger voxels in the knapping process, maybe a 7 by 7 of voxels. For clay forming there are already "tool modes" which allow you to form a bit faster by selecting different tool modes by pressing 'F'. It's still very fiddly and many shapes don't benefit from them, I think a being able to draw a square by holding the mouse down would be a far better option.

Instead of iron ingots, the bloomery should give you one piece of iron bloom. The piece is unstackable and has a "ingots contained" value, indicating how much iron is contained in the bloom. When it comes out of the bloomery, it is very hot, but cools down if not taken out of it immediately after the bloomery has finished (Instead of destroying the bloomery, tongs could be used to get it out). The bloom can be reheated with a forge. The hot bloom now needs to be taken to an anvil, to be turned into iron ingots. Placing it on an anvil is just like placing an iron ingot on the anvil, however no recipe needs to be selected. The recipe outline of a ingot will appear on the anvil and the iron bloom voxels will take a random circular shape. The player then needs to reduce the shape to the ingot outline, with the default smithing mechanics as they are present in the game right now. Taking the bloom form the anvil to reheat it will give the player a worked bloom item, which can be place on the forge. The forge only accepts one worked bloom or iron bloom item at a time, with no place for (worked) ingots. When finished, a stack of hot ingots will drop, the size of the stack is dependent on the ""ingots contained" value of the iron bloom. The mechanic could also be extended to work with a quality system, resulting in fewer/more ingots dropped and it would work flawlessly with my other smithing rework suggestion. Crafting ore with a hammer seems like a very lame way of processing ore for me, so I offer a alternative solution: Ore chunks can be smelted directly without having to crush it, but it only returns half the metal value. This makes creating the first anvil, required to get all the metal value from ores, much less grindy. Placing a ore chunk on an anvil will result in some ore voxels on the anvil, in a random small circular shape. Hitting any voxel with a hammer will result the removal of the voxel and dropping of nuggets. The total nuggets from one ore chunk should have a total metal value equal to the its metal value. Taking an unfinished ore from the anvil will result in an unstackable worked ore item. This makes the anvil a much greater achievement, as it effectively enables ore doubling and smooths out the progression as the player doesn't need to craft a hammer from surface ore to make ore chunks usable. A doubling of the metal value of ore chunks would however be recommended, to make poor ore chunks usable. Both the bloom and ore processing are rather work intensive (especially the ore processing) this way, so they are perfect candidates for automation. A mechanical hammer powered by mechanical energy could be implemented with the mechanical energy system that crushes the ores and bloom automatically, giving further incentive for progression.

A lot of good ideas here, but I see one problem with some of them: Their focus on time as a balance factor. I don't think any crop should take one year or more to yield, that would be ludicrous imo. Neither should the year be 144 days long, that's 96 real world hours with the current day length. These things may work in multiplayer but for singleplayer they are simply not feasible. Crop growth times should remain to be only be a few ingame days, as even that is a relatively long time. It's not even that servers would greatly benefit from longer growth times, it would just make replanting rarer and put less focus on the nutrient system. I would like to perennials implemented similar to how Stardew Valley did it, with them being harvestable multiple times a year. There are a lot of ways to balance them other than massively longer growth times (although their initial growth time should be a bit longer but the regrowth times a lot shorter), like greater nutrient consumption, smaller temperature tolerance, less seeds, less nutrients or faster decay for the food, etc. These things pose actual gameplay challanges for balance and help to differentiate the crops further instead of just adding larger wait times.

Yes, I'm wrong here, you're right, assuming the DC increase rate is still linear (which still means a non-linear DC increase) your system would work without any stacking issues. But the system has still the issue of of there being no place for the rot to go when eating with a full inventory, which a deterministic version of the system wouldn't have. However the deterministic version needs a constant decay (i.e. DC increase) rate or eating will cause food to spoil faster, which is clearly not wanted. So it's a choice between a more realistic chance based system with a minor gameplay issue or a less realistic deterministic system without gameplay issues.

While I really like the general idea of your system, this last piece ruins it from a gameplay perspective. It does not only not fix the issue with a linear decay rate, but amplify it: 64 stacks of one potato still decay much faster than one stack of 64 potatoes AND combining/mixing stacks with a high DC with stacks with a lower ones (but not too low ones, because that would waste some decay rate) is vital because the lower weighted average DC lowers the decay rate. It's micromanagement hell and exploiting the system correctly is hard, which leads to more micromanagement. With a half-life decay rate this system would work however and would be the best system yet, having no gameplay issues. I especially like how it avoids the rot problematic, by giving you the rot when you find it (failing the DC check when eating). The issue is minimized (so not fully eliminated) to the rot having nowhere to go only when the player eats with a full inventory. The issue could be fully eliminated however, by making the system not based on probabilities, but having the bar represent the actual rotten potatoes in the stack. So when the player eats the last non-rotten potato in the stack, or it decays, the stack turns into a stack of rot. I.e. the half-life system, but decay doesn't decrease the stack size, but adds to the "rot bar". BY THE NINE DIVINES, A SYSTEM WITH SEEMINGLY NO ISSUES (apart from it not being fully realistic).

50 blocks seems like an acceptable range, if the landforms get updated to it. But some things, like the big open caverns created by landforms below the surface wouldn't be possible, as landforms would only be possible to edit the upper fifty blocks. Landforms being able to fill out all the remaining area would ofc make the whole system irrelevant, because it would make oceans impossible again. Probably. The terrain generation would require minimal changes, but a whole new terrain generator for the stuff below the column would need to be added. Chunk loading would require an extension or replacement to have 3D chunk loading. The terrain saving structure may also be needed to be overhauled. And the lightning engine would need some changes. The good thing is that chunks are already cubic, so it wouldn't be a total redesign, but it would probably still take a month.

It would fix the issue. It would just put the rot/compost into a very different position, as a resource the player has to actively produce if he wants it and not something he gets if he screws up his food storage. Think of it more as a removal of rot and addition of compost. Doing this, not keeping the rot mechanic and replacing it, would imo be better than trying to keep the rot system and making it work in some weird hacky way like the extra slot you suggested.

I think splitting the three reduction types is actually less confusing, helping a player to distinguish the types of reduction and remembering them easier, because they associate them with a type of armor. That is what makes the system consistent, because the player can see from the type of armor the enemy is wearing, which type of damage reduction he gets. As for 'tier vs tier', this is like the polar opposite of it, going completely against a linear progression. Instead this system offers a lot of different options to the player, all with their own distinct advantages and disadvantages. The thing I personally dislike about a 'tier vs tier' system is that it's not the players choices that would win a battle, but how long the player played and thus progressed in armor tiers.