Jump to content


Very Important Vintarian
  • Content Count

  • Joined

  • Last visited

  • Days Won


Erik last won the day on June 18

Erik had the most liked content!

Community Reputation

37 Excellent

About Erik

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. 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.
  2. Erik

    Food decay

    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.
  3. Erik

    Unique armors

    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.
  4. Generating a world with ocean borders is actually rather easy to implement, but there are some problems with the heightmap part. Having the heightmap either greatly limits the landfroms elevation changes or makes the heightmap useless, as 255 blocks world height don't allow for great variation. I think a much larger overhaul would be needed, involving changing the way chunks and chunk-loading works, which would be certainly be incompatible with the current worlds or at least require a decent effort to fix: Have chunk heights vary. Not just the blocks in the chunks, but the actual chunks, or chunk columns to be exact. This would allow for highlands, kilometers above sea-level, and oceans, kilometers below sea level, without needing to change the landform system, the 3d-noise system, in any way. To make the system work one additional feature is required: Infinite depth and height. Chunks below or above the chunk column would not need to be generated with the columns, since they are not dependent on the landforms. They are just empty chunks above and stone/ore/cave filled chunks below and are generated when the player is close enough to them. Infinite world height/depth would also sound cool for the marketing and is really something people expect with cubic chunks.
  5. I think the way it's done right now, with repeating a north-south pattern covers both variants if the width of the climate bands and the world were configurable and also allowing for more than two poles. Oceans are something currently not possible in VS (without exploiting the system by creating hundreds of ocean landforms), because all landforms have the same size and changing that seems to be really complicated. I have an idea on how to allow oceans without it and a whole bunch more things, but it's most probably even more complicated.
  6. Couldn't the sun/days just work normally on the eyeball planet just for the sake of gameplay? It just wouldn't be realistic, but so is turning the earth into an eyeball planet I also don't really see the gameplay benefit of the eyeball earth compared to the current repeating climates, other than that it's more finite. A finite world could also archived by just lowering the world size and widening the climate ring, the map would only visibly cut off at the poles and the sides. Other than that, I enjoy the idea of a wrapping donut-shaped world a bit more, it doesn't suffer from the corner problem and just needs tileable noise, like any wrapping world would.
  7. Erik

    Unique armors

    While that's true, I think this concept is a bit harder to develop as a mod for me, because I need to create art assets for the different types of armor and their combinations, which I'm not good at. I also don't really see huge benefits of making a mod for this suggestion, as balancing can't be done in a representative way and the concept is not as hard to grasp as many of my other suggestions.
  8. Erik

    Food decay

    The most straight forward option would be to remove the whole rot mechanic and replace it with a proper composting mechanic, where you have to put your unwanted food in a composting bin or something, but implementing this new mechanic would probably require a lot of work.
  9. Erik

    Unique armors

    Armor is something many players are wishing right now and I have some unique ideas for the armor system, so here they are: Most games handle armor in a very simple way, with every piece of armor having some arbitrary "armor value" and all "armor values" of every piece of armor the player wears get added up and damage gets reduced in some magical way dependent on the total armor value. While this system works, it only allows for linear progression and provides no choices for the player, higher armor value always equals better. Because the armor value is arbitrary, the amount of protection the armor provides is not clearly presented to the player. So my idea is to throw that all out of the window and provide three different types of armor, which all function differently, allowing the player to choose how he wants to protect himself. Three different armor types with unique systems for each may sound daunting at first, but it's actually really simple: Padding: Padding is the first type of armor the player is likely to acquire. Leather, wool, gamberson all are early game materials this type of armor can be created from. Padding armor subtracts a percentage value of the damage. That means a piece of leather armor may give 30% damage reduction, resulting in attacks only damaging the player by 70% of their damage value. Mail: Mail, unlike padding, requires metals to craft. Crafting a iron chainmail armor piece is also significantly more time intensive than a piece of gambeson. It may also provide much more protection, especially against weaker attacks. Mail armor simply subtracts its damage reduction value from the damage. A piece of mail with 12 damage reduction will reduce the damage the player takes from attack that does 15 damage to 3 damage, or a 10 damage attack to 0 damage. Plate: Plate also requires metal to craft, but in greater amounts that mail armor. While being the most expensive type of armor, it also arguably provides the most defense, most of the time. It is really an all or nothing type of armor. Plate armor has a deflection value which determines the chance to simply reduce the damage to zero. A piece of plate armor with a deflection value of 60% reduces any amount of damage the player takes to zero, 60% of the time, while 40% of damage don't get reduced at all. All types of armor have their purpose, unique advantages and disadvantages. The player should be able to equip two types of these armors on the same armor slot, effectively combining their defense. The damage reduction by padding is calculated after mail, to prevent it from being overpowered. Armor weight: To make armor even more interesting, pieces of armor should have a weight, which slows the player down a bit. Padding is generally lighter than mail and mail is generally lighter than plate, which is the heaviest. Different armor materials may also have a different weight, steel being lighter than bronze. This also makes using single armor types more viable, as they now have a speed advantage against using two types. Armor slots: A thing this system doesn't really allow is adding all armor values together to form a total armor value which determines damage reduction. Instead, attacks must always hit one armor slot, which could be determined by chance, like in TFC, or by detecting where the attack landed on the player. For PvP combat the latter makes more sense, it however requires there to be few armor slots. For PvE chance based makes a lot more sense, as for mobs aiming at specific body parts is no challenge. Implementing both ways is most likely the best way to go, as it allows for more exciting PvP, by placers having to target specific, lesser armored body parts for maximum effect and mobs don't always hit the unarmored spots. For mobs, mob specific hit chances make a lot of sense: Wolves should be way more likely to hit the legs than the head of a player. Ideally the system would also take the position of the attacker and target into count, if the wolf is at head height, it's most likely to bite the head and least likely to bite the legs. The armor slots that should be provides are imo: Head, body and legs. The head should have the smallest hitbox, the body the largest. Ducking should also lower the heads hitbox, so dodging attacks this way is possible. Being only limited to three armor slots however significantly lowers cosmetic player customization. To remedy this, different cosmetic variants of armors may be able to be crafted, like plate body armor with or without pauldrons. (Technical implementation stuff) Significance of arbitrary armor values: While not shown to the player, the armors should have arbitrary armor values in the code/json, instead of the flat reduction values or percentages the player gets to see. This has one important reason: Armor scaling. While a 90% damage reduction armor seems only 10% better than a 80% damage reduction armor, it's actually twice as good, letting half as much damage to the player. I.e. it has twice the survivability. And that is the problem, the survivability scales hyperbolic with linear scaling of the armor value. To fix this, arbitrary armor values need to be used in the code/json, which get calculated into the displayed armor value to scale linearly with the survivability. So 10 arbitrary value is exactly twice as good (twice the survivability) as 5 arbitrary armor value, which may account to 90% damage reduction and 80% damage reduction in the game for the player. Why is linear armor survivability so important? While the armor values can be balanced correctly to have a linear survivability curve, modifiers to the armor value that may be added in the future, like smithing quality, would still scale wrongly. While this can also be solved by programming the smithing quality system in a way that improvements increase the survivability linear, mods may not do this correctly, as the may not know of the problem. Armor penetration: While this system makes armors more unique, it doesn't really make certain armors much less effective against certain weapons. This can be easily archived by having armor reduction modifiers on specific weapons. These modifiers reduce the armor value of their type by their percentage: 50% padding armor penetration reduces a 80% damage reduction armor piece to 40% damage reduction for the damage calculation. The survivability scaling here is not linear on purpose, to make armor penetration more impactful than just having a weapon that does that percent more damage. Although, that is debatable and maybe having it lower the survivability (the arbitrary value) would be a better choice.
  10. I don't think that the space requirement is such a huge issue. Especially with tongs, when rotating the working metal is possible, it would only require two accessible sides to rotate it in all directions. So slapping your anvil in the corner would be possible, but having it worked into the wall (only one accessible side, why would anyone even want that?) not. On another topic, I updated the prototype, no new features, but the timing is much more consistent, making it feel much better.
  11. I don't think it would be too hard, it doesn't require perfect timing to get things done, maybe just to do them the best way. And even then, the timings are something anybody can learn with enough practice. Having different values for different metals would keep the system from being too simple. It doesn't really make different metals harder, just different and makes each a new learning challenge. Varying heat however would make things harder, maybe too hard, but that remains to be seen. To get the timing right would be the main challenge of the system so rewards should be based on that. How exactly the times needed to reheat and the hits needed influence the system is however very variable, it could even be different per metal, which would make each metal a unique and different challenge to master. To get some of the randomness from TFC, having to relearn smithing on every new world, the timings and quality variables could be randomized for each metal per savegame. That would make it a lot more replayable and a journey of discovery each time, but would also allow for less direct and purposeful design and make the game harder for beginners, as they can't rely on the wiki. As the system is not hard to implement, I have made a mod implementing the basics, so people can test out the idea. The mod is only a very basic implementation, it doesn't have a lot of features I suggest, but it has: Replacement of hammer tool modes with timing strikes The three described smithing techniques: Upset, cross and flat Stronger punches cool the metal a lot more, too weak punches also have a heat penalty What it lacks: Metal based timings Heat based timings A quality system Tongs Still has the pixel system in place Nice animations (They look stupid, but they work) My current implementation however has a big problem: The timing value is determined server-side. There is a rather significant, and most problematically varying, delay. It's not a problem of the system in general, just a problem of my implementation. I'm sure there is a way to fix it (making synchronization based on the client), however I'm not the most experienced modder. (Attention: Prototype updated and now on main post)
  12. Smithing overhaul Attention: Prototype mod of suggestion attached Vanilla smithing, while visually great, is very shallow and quickly gets dull. This overhaul aims to fix that while also allowing for it to be more skill based and the crafted items having quality levels based on the skill of the player. No annoying tool modes anymore One button to rule them all Based on player skill Simplistic and minimalistic Actually also very realistic Master each metal separately No huge changes required No frustration by randomness The changes in this overhaul don't really effect the anvil or the recipe, it only really affects the "tool modes" or smithing techniques. First, we need to reduce the techniques to make this work, the only techniques required are: Upset Using upset on a pixel will make a pixel appear above that pixel. Only one type of upset now, the other directions are removed. The player has to move around the anvil now to perform upsets in different directions. If using upset on a pixel with an pixel above but none below, the pixel will be removed. Cross Using cross on a pixel will make 4 pixels appear adjacent to the pixel. Flat Using flat on a pixel will make 8 pixels appear around the pixel Now about how I plan to implement them without tool modes: Holding right click down on the hammer will charge up the power of the strike. Very low to low power strikes will do nothing at all to the hot metal. Low to medium power strikes will perform an upset. Medium to high power strikes will perform a cross. High or higher power strikes will perform a flat. In other words, the hammer progresses through the techniques, the longer the player holds the button. The player also can't tap the button to definitely perform a upset. With this simple mechanic change, the smithing can be easily made a lot more engaging. The player should not be able to see which technique he is currently on, the player should have to develop a feeling for the timing of each technique by himself. To spice up this, the power required and therefore the timing for every technique should be different for each metal. So players have to learn and master smithing each metal individually. (The progression of the techniques should however remain the same for each type of metal) Item quality can now be calculated from the number of strikes the player required to finish the smithing and the number of times the player had to reheat the metal. The heating system should also be tweaked a little: Cooling down should happen a lot faster, currently it's so slow that the player has to never reheat the working metal. Strikes should also cool down the metal, depending how powerful they are. This encourages players to make strikes only as powerful as they need to be, only holding down the button as short as possibly required for the needed technique. Instead of becoming suddenly unworkable at a certain point, the power requirements of techniques could begin to increase at a certain (metal dependent) temperature point. This lets experienced smiths still work colder metal and allows for some much harder to work metals with much more heat dependent smiting required. Further extensions of the system: Tongs. Hot metal should no longer be movable by hand, but require tongs. The tongs also let the players grab the worked metal on the anvil and place it somewhere different on the anvil or with a different rotation (No tool modes for rotating, the player has to move around the anvil with the tongs having picked up the metal). There should also be a preview of where the tongs would place the metal on the anvil. Instead of the working metal being finished automatically, the player would have to grab it with tongs and quench it in water or other liquids to finish it. The type of liquid could have an effect on the tool (quality or durability). To make the moving around of the metal actually useful, only metal on the anvil body should be workable, like RedRam suggested in his original proposal for the system. Changing up the anvils surface to be more interesting would also be a good addition for higher tier anvils. The player could use this to save himself doing some strikes. Finishing notes: A removal of the "metal pixels left" system would be appreciated, as it only makes things more complicated, while not really adding anything interesting. Prototype info: The prototype works, but it does only have the minimum features of the suggestion: Replacement of hammer tool modes with timing strikes The three described smithing techniques: Upset, cross and flat Stronger punches cool the metal a lot more, too weak punches also have a heat penalty What it lacks: Metal based timings Heat based timings A quality system Tongs Still has the pixel system in place Nice animations (They look stupid, but they work) smithing_v1.1.0.zip smithing_v1.1.1_for_1.10pre10.zip
  13. Erik

    Food decay

    The half-life system is not realistic, but not illogical either. I understand what you're getting at and Tyrons system is better in that regard, but it still has the stacking problems. There is a difference between losing a tiny amount of food and having the inventory full because of food stacks with different harvest dates. The player might not have a lot of food, but he certainly has a lot of different food types with different harvest dates. Yes, I though you were talking about a half-life system with time stamps, which would be the worst. Well, it can punish the player if he combines his small stack of very fresh food with the big stack of food, close to spoiling. The then would have lost the freshness of the small stack only to have the big stack last a tiny bit longer. So combining stacks still requires thought, so while it is a solution, it is not ideal. I wouldn't say that the half-life system is harder to balance. The relations between the half-life of different food would still be the same, double half-life means lasting double.
  14. Erik

    Food decay

    There is nothing illogical about a half-life system. Then radioactive decay would be illogical... Does the player need to know exactly how long his food will last? That would be pointless with this system, it doesn't help the player to know when he will have no apples, because he will have almost no apples long before that. He already has a good indication for the near future: Half the stack is gone in X days. It's not that hard to understand, as the player can see that it is ticking down in real time. The system is not scaling deeply unfair. In Tyrons system, no matter how many apples you farm, they would all be gone after 6 days. In my system many of them will be gone by then, but not all of them. Tyrons system punishes players for overproducing, making every apple overproduced a waste. In my system, every apple overproduced practically makes all the other apples last longer. Disguising the system with adding a constantly changing rate to the tooltip of stacks would confuse the player a lot more and give him false assumptions. The simple "Half the stack is gone in X days" is a much less confusing way to introduce the system. And if the person first thinks the system is a cliff system, he will shortly after see that A: The tooltip never changes, because it is always accurate. B: Food is going down over time. It will be least problematic to player in the early game: They don't store food, because they eat it all within a short timeframe. The system penalizes players for storing food for long times, that is correct and also what a decay system should archive. I think it's valid critique to say that it penalizes the player regardless of him having done a wrong thing and storing food for a long time, because the system constantly and actively takes food away from the player, while Tyrons system only punishes the player when he has been storing the food for a long time. Non-indefinite preserving obviously doesn't make the penalty go away, it just lowers it by having a longer half-life and therefore the penalty. The cliff system doesn't work. There would have to be a time stamp on stacks to keep track of when the stack will half. That would not allow combining stacks without issues. There are several ways of handling combining stacks here: A: Average the date between the two, weighted on stacksize. Works, but lets player safe food about to be halved by throwing it into a bigger stack in time. The whole system then also becomes much more confusing, because the time when the stack will be halved changes whenever the player combines stacks or even when new items get added to the stack. The player will have no idea when the stack will half, because that changes with every apple they pick up. This is obviously therefore a very bad idea and would make the system seem very illogical to players. B: Spoil what would be spoiled when combining stacks. Also works, but punishes players for combining stacks or picking up new items that would go into the stack, because then it would be updated and some food be lost prematurely. This obviously is highly problematic and hides the constant food loss by only making it appear when players do edit the stacks. This is also properly illogical: Why should combining stacks cause food to be lost? C They don't stack. This would work, no exploits possible, easy for player to understand. But it spams your inventory. It would be Tyrons system, a bit more complicated because food doesn't completely spoil, but gets halved when the timer runs out and then the timer would reset. So it would be worse than Tyrons system, because there is no huge gain from the half-life mechanic, other than making it a bit more complicated, because the timer resets.
  15. Erik

    Food decay

    Both. You can calculate in real time or with just a timestamp of the last update in an event based way when trying to minimize performance impact. Yes the infinity-problem is a thing with using a half-life. It can however easily be fixed: Just have the stack disappear if it only has 0.1 apples in it. The more food the player has, the more is going to rot. This is not a penalty for larger stacks, if the player would split all his stacks into smaller ones, the resulting loss in apples would still be the same: Half the apples after four days. For clarity, this is not tracking the start time in any way. The only thing that can be tracked is the last time the stack was updated to reflect the amount after rotting. From that point the size of the stack can be calculated. This will be useful for long term storage, where the stack doesn't get updated for a long time. 40 apples (It doesn't matter how they are stacked) will be 20 apples after 4 days, because apples have a half-life of 4 days. Half the apples will however not suddenly disappear at the 4th day, but they will get less at all times and they will be exactly 20 apples after 4 days. And after yet another four days they will be 10 apples, then 5, then 2.5, then 1.5, then 0.75, then 0.375. then 0.1875 and then they will finally be gone.
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.