Jump to content

All Activity

This stream auto-updates     

  1. Today
  2. Smithing overhaul 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.
  3. Nach vielen Stunden auf der Suche nach Bienen bin ich endlich fündig geworden. In einem seeehr grossen Eichenbaum hoch oben in der Krone. Von unten hörte man nur ein ganz schwaches Summen und wenn dann noch ein Wasserplätschern gewesen wäre hätt ich es nicht gehört. Jedenfalls will ich eben jetzt nichts falsch machen und den Wildbienenstock mitsamt Bewohner zerstören Brauche ich ein spezielles Werkzeug um den Bienstock abzukriegen (z.b. Messer?) . Überleben die Bienen eine längere "Heimreise" ? Wollte "daheim" schon eine "empty Beenade" vorbereiten, jedoch ich bekomm ich den Honig nicht in die Schüssel !? Habe schon 2 Honigwaben (Keine Ahnung woher) gefunden. Eine Blumenwiese ist auch schon vorbereitet . Wie auch immer, ich wills nicht verka....n und wäre sehr dankbar über ein paar tips von allen Vintage-Imkern ....Ceronthis - (AZUBI Imker) Oh...hab eben einen Beekeeping Link gefunden....
  4. Thanks for making this wonderful mod! Your doing good work!
  5. Last week
  6. 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.
  7. redram

    Food decay

    That's like saying there's nothing illogical about math. No, there is nothing illogical about math. But applying math in certain ways to certain situations can be. Food is not uranium. It doesn't decay like that. So you say that one of the strong points about this system is that the math is simple but when it's pointed out it's not simple past the first iteration, you hand-wave away the non-simple part? The rate of the tick-down changes over time. There's a real potential there for the player to feel mislead and confused. That's because it's a logical system with respect to food. irl if you pick 100 fruits, they're all probably going to rot around the same time. Each fruit is individually spoiling the moment it's picked. Not half at X time and a few at 7X. It's made quite clear in the cliff system, and the player doesn't have to question it. In this half-life system, the more work you do, the more you lose after the first iteration. In the cliff system all that food is available for you to use right up till near the end (I'm presuming, I don't know what the ratio will actually be). But one of your criticisms of a time-stamp system is that is clutters inventory in early game. If the player eats all of it in a short timeframe, then that is also not a problem. As for your last several points, I'm not sure what you're getting at. It seems like you're criticizing the cliff system at times, but you also refer to halving, which is not a thing in the cliff system. If you're talking about a half-life system with time stamps, then ya I agree that's probably the worst of both worlds. Tyron stated in discord that current plan is indeed to simply weighted average combined cliff stacks. And that does indeed effectively 'extend' the life of the lower stack. I would perhaps have went with an average that weights the 'more rotten' stack more heavily. Perhaps as if it was double it's weight or something. But, a straight up average is only going to benefit the player, not punish them. So it's not the worst thing in the world. I'll say this additional thing for the cliff system - it's easy to balance. You know exactly how long that food is going to be fresh. The half-life system, you gotta do the maths.
  8. 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.
  9. redram

    Food decay

    I was exaggerating when I said infinity. I didn't think it would be actually programmed as infinite; obviously we'd cut it off, but it would create a - what, logarithmic? - distortion. Cutting off at .1 doesn't change the fact that those first 20 apples lasted only four days, but that last apple went for 28 days before it was entirely gone. And I realize you'd eat it before then most likely, but this is not a logical system, and I think players would not enjoy it. I feel like saying it's easy to understand is oversimplifying. It's easy to know how much food you'll have in four days. But 20 days? Not so easy. Not only is this system illogical, and a constant needling of the player with continual food loss, but it scales in a deeply unfair manner. No player is going to enjoy that they lose 20 apples over the first four days, and 10 the next. That's a communist system of decay - you produce more we take more. I don't think this system would be intuitive to a player. Why did those first 20 apples decay faster than the next 10? At best it would be disguised from the player to a degree by the constant rate change. I think any reasonable person upon first seeing the tooltip or whatever that the stack would decay by half in X days would reasonably assume they'd have nothing in 2X days. At least the surprise would be on the pleasant side I guess. I think you're overly concerned about minimizing exploitation of stack management, at the expense of the fundamental system. This system will penalize the early game most, when you have less than 1 stack of a given food. And it will always penalize in that fashion, for the entire game, and even for preserved foods (that aren't infinitely preserved). Compare that to the cliff system - you have all the food for a long time, and then it decays quickly at the end. You allow the player to combine stacks manually if they want. Don't just average, weight the rottener portion. Exploits handled. No needling of constant food loss. Logical. And I would argue that a system that is logical will rarely be considered unfair. I do agree that it may be an annoyance in the early game, for those who can't stand to combine stacks and lose a bit. Though I could also see it being annoying in the frame of not automatically picking up a food item because your inventory is full and the game won't auto-combine. That would possibly be confusing and annoying. But again, probably more an early game thing. In the later game, you'll likely mostly be harvesting your own crops at your base with plenty of storage, so it should not be a problem. Nevertheless the early game is indeed the first impression and you don't want it to go badly. But I think it's worth trying. That's my take on it.
  10. 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.
  11. redram

    Food decay

    These statements seem a bit contradictory? Or are you talking player's inventory vs in a container? But so ok, I've never claimed to be good at math, but are you saying that the per-piece decay time is dynamically adjusted for any given stack based on the size of the stack, such that the decay of half the stack at that time would take X days? How does this stack of Zeno's apples not end up stretching into infinity? I see what you're doing keeping two separate stacks with the same result in X days as you would if they were in one stack, that seems to be the issue you're focused on. But ok now your 40 stack is down to 20 after 4 days. Well now your 20 will be 10 after 4 days won't it? Losing 10 apples in 4 days is clearly better than losing 20. And losing 5 in 4 days is better yet. That seems to me like you'd be penalizing the player at the front end; the larger the stack the larger the penalty. All this assuming you're not tracking an initial start time, which it seemed like you said you were not. Forget about multiple stacks issue, can you just explain what happens to the single stack of 40 apples at 4-day intervals?
  12. There are technical hurdles to having globally visible way-points that are under current development.
  13. Erik

    Food decay

    I mentioned Tyrons method of automatically combining stacks in the tolerance frame. Obviously making it possible to combine stuff with very different dates leads to all kinds of issues and the player will need to worry about these if he wants to combine stacks. And that's the problem, the player shouldn't worry about potentially wasting freshness of food when combining stacks. So yes, they can theoretically be combined, but that makes the whole method very prone to exploits and hard for players to predict behavior. No, the half-life would be handled constantly in real time. Half the stack of apples isn't removed every 4 days, but the stack gets smaller in real time. It doesn't even have to be constantly tracked, you can just calculate the state of an stack with the time of the last time the stack was updated, so there is not even a performance loss compared to Tyrons method. So to get back to the apples: A stack of 40 apples with a half-life of 4 days will be a stack of roughly 28,3 apples after 2 days. Any yes, it looks a lot like the ark system, because it is a lot like the ark system, there is a constant food loss. It is a problem, at least in ark. When storing multiple larger stacks in a chest in ark, they all decay into smaller stacks. The rate of decay is constant for each stack, so two stacks decay twice as fast as one stack. So when some time passes and the 40 full stacks turn into half full stacks, the rate of decay will still be the same. But if the player were to constantly restack the stacks, so there would only be full stacks and be less stacks, the rate of decay would lower. This encourages micromanagement on the players side, which is a problem. It may not be as realistic as Tyrons approach, but it is much more usable and I value usability over realism in this case. I don't think adding food poisoning is a good idea. Spoiled food is useless enough in Tyrons system, having lower saturation and nutrition. Making them potentially harmful will just cause players to get rid of them as soon as they become spoiled. In that case, it wouldn't make a difference if they were just removed from the inventory if the timer expired, with no stages of spoiling.
  14. redram

    Food decay

    In the context of Tony's expiration date method, I'm not sure why you say they can't be combined. As I recall, Tyron said that the game would *automatically* stack them within a range, but you could still manually combine stacks of very different dates. This would alleviate much of the problem. How that combination affects the expiration is an issue. Averaging effectively allow the player to 'refresh' old stacks, it would at least need to be weighted. Possibly with bias. The stricter way of having everything go to the worse decay value would probably raise cries of being unfair. As for the half life idea, I'm not clear how that's not just a different form of expiration date. You're still tracking the date when the stack starts decaying aren't you? If your stack is already 2 days into it's decay and you pick up more items and the timer is the same, then you are strictly disadvantaging the subsequent pickups. If instead you're averaging new pickups into the pile, so they increase the half-life on a weighted average, well that's just like manually combining the expiration date stacks and weighted averaging them. Either way, you're still creating a situation where the player is losing food over time at a rate. It's just not smooth, but stepped. Also your graphics confuse me, as they make it look like just an ark system. Ark system is workable, but not realistic. Also, I don't see a case of 40 small stacks at a problem. Players naturally want food to stack. I can't even think why they would ever want a bunch of tiny stacks, quite aside from any decay issues. The advantage to the all-then-nothing expiration system (cliff system?) is the player has all their food for that a long time. As I understand it, the current plan is the decay would occur relatively quickly at the end. This is pretty similar to how a lot of foods - especially fruits and vegetables - decay irl in my experience. Once that banana starts to go bad, it goes bad pretty fast. I think generally the softer the flesh the quicker that last stage of decay happens. Other food like bread and cheese takes longer, but still, relative to the time it is good, once that mold starts being visible, it spreads really fast. And I could even see that final decay stag being of variable time based on the food, or maybe proportional to the initial good time. Some foods might have an advantage like that (preferably certain cooked ones). The other think I like about a more a more cliff-like expiration is that it would make the possiblity of food poisoning more tolerable I think. You'd get the vast majority of the time risk-free, but if you must eat that food in the last decaying stage, maybe there could be a chance for some kind of adverse effect (not without herbs to counter it though).
  15. Erik

    Future updates

    Added "The Hunted" update, focusing on a potential stealth mechanic
  16. Erik

    Food decay

    Previous threads relevant to the dicussion: For those who don't know, the next major update will introduce a new feature: Food decay. Food will rot and become less effective or turn into compost after a certain amount of time. Don't worry though, there will be methods of preservation introduced, so you can keep your food fresh for longer or even indefinitely at the price of more work and probably also lower nutrition. This feature is planned to be introduced alongside season, where the winter makes farming impossible. The players will have to household and plan food usage and conservation to make it through winter. Players will also be able to deactivate the spoilage mechanic, so don't worry if you are not a fan of the general concept. However this new decay system has some problems that I want to outline and how they could potentially be fixed. I'll first introduce the system as it is currently planned/started to be implemented: Food items/stacks each get a timestamp when they have been created. As time goes by, they will eventually start to spoil. When spoilage reaches 100% they will turn into a pile of rot an be uneatable. Eating items with a spoilage value will reduce the saturation and nutrition gained by that percentage, so you ideally want to eat your food when it still is fresh. The spoilage of a stack represents the spoilage of each item in the stack, and they will all turn into compost at the same time. Items with different timestamps don't stack, there will however be a certain tolerance for value differences, so stacks only a few seconds/minutes apart will still stack, probably gaining the average spoilage/timestamp of all items in the two stacks. The problem: The real problem with this system is the stacking limitation. It can easily result in the players having different stack of the same food, but with different timestamps, cluttering their inventory. This is a huge issue, because inventory space is already very limited in VS and micromanaging the different food stacks can quickly turn into a huge pain for players. This will be most exaggerated in the early game, because players have almost no inventory space then already and no option of storage either, as well as living from several types of berries they usually pick up some time apart from each other. As the early game is the most important part to get right from a marketing perspective, this is unacceptable. Possible solutions: TonyLiberatto suggested having the timestamp only record the day of harvest. This will lead to all food being harvested on the same day stacking and while not fixing the problem, makes it much less noticeable. But this workaround comes with its own problem: Players are rewarded for harvesting their food at the beginning of a day and are punished for harvesting them at the end of the day. This may not sound dramatic, as food harvested at the beginning of the day will only last a maximum of a day longer compared to food harvested at the end of a day. But as a day is 40 minutes in VS, that is a quite considerable amount. A real solution to this problem would be to implement decay in the same way as Ark Survival Evolved did it: Food stacks have a spoilage meter constantly ticking down and when it reaches zero, the stacksize is reduced by one. Combining stacks would also combine the values of the spoilage bar. This system of decay works very differently and constantly spoils some food into compost rather to spoiling it all at once. Stacks can now be combined without limitations, so that problem is eliminated. The system however also has a huge problem: Splitting your food into two stacks makes it spoil faster than having it as one stack. This forces the player to micromanage his stacks again. This is because the rate of decay in constant and not relative to the size of the stack. There is however a way to fix this: Rather than having a constant decay rate, stacks would just need to have a half-life. The half-life of the stack describes the time it takes for a stack to loose half its food. This half life would be the same on each stack of the same type of food. Example: Apples have a half-life of 4 days. A stack of 40 apples will a stack of 20 apples after 4 days. Two stacks of 20 apples will be two stacks of 10 apples after 4 days, so still 40 apples turning into 20 apples. With a half-life, the sizes and number of stacks don't matter, the same amount of food will always decay after any time. This completely removes the need for micromanaging your stacks and makes combining them possible at all times. There is however a small problem: That if you have 40 stacks of 1 apple? Won't they just all be gone after 4 days? This problem stems from stack sizes being whole numbers and not having any decimal or lower values. This can however also be easily fixed by emulating the decimal point with a durability bar: Decay will slowly lower the bar over time, until it is empty: Then the stacksize gets reduced by one and the bar is filled up again. Eating half an apple will obviously also only give half the saturation and nutrition of an apple. This would also have other benefits, such as showing the decay in real time, having players be able to eat half an apple if they are almost saturated or crops dropping not 1 or 2 food items, but any number of items between 1 and 2 items, like 1.6 carrots (representing a carrot and a smaller one). Problems with a half-life system: While the player only needs to understand one thing (Half your apples will be gone in 4 days), the system is definitively harder to explain and understand. Confusing the player is never good and this system might also potentially confuse players. The bigger problem however is, that the compost resulting form the rotting food has no way to go. In Tyrons system, it just takes the place of the food, as the food gets turned into compost at the same time. This flaw in my design will also lead to cluttering of inventory space by compost. This however isn't the big problem, as all the compost from all food stacks, but when there is no inventory space, the compost has nowhere to go. It would probably need spill on the floor, which isn't good. Fixing all problems of both systems with one change: Making inventories weight based would solve all problems, as there wouldn't be a competition anymore over inventory slots and better inventory management features could be implemented.
  17. The biggest issue that I see right off the bat, is that it just looks like a stand alone version of TerraFirmaCraft. There isn't anything it is currently doing different than that mod that I can see. That is just based off the features I have read about, and the videos I have watched. Nothing has convinced me that it is something I would want to purchase however.
  18. Vielen Dank für die Unterstützung... Eine komplette Neuinstallation der mono-Pakete brachte dann endlich den Durchbruch.
  19. Hi, ich habe hier einen Server mit Debian 9.x. Den Vintagestory-Server habe entsprechend dem Wiki installiert. Portforwarding Port 42420 auf der FW zur ServerIP eingerichtet. Eine FW auf dem Server gibt es nicht. Auch ein Test in einer DMZ schlug fehl. Der Server wird als öffentlicher Server gelistet [Watnu-Vintage-Story-Server]... Es ist kein PW gesetzt, die Fehlermeldung über den öffentlichen Server ist die gleiche Meldung, wie beim Versuch im LAN. Die Logs sind sauber. Im Log sehe ich meinen Login-Versuch, es wird versucht etwas herunter zu laden, dann bricht die Verbindung ab. Nun weiß ich keinen Rat mehr und drehe mich im Kreis, deshalb bettel ich um Hilfe Vielen Dank für eure Mühe!
  20. I love these little half cave things.
  21. Earlier
  22. Thank you very much redraM for your answer. At least this gives me a new starting point for a problem solution and could already give a hint to my second question.
  23. Oh, hey! Thanks, redram. I really just want NPCs as decoration, so that kind of works for me. It would be great if they didn't all look the same, but beggars cant be choosers. This is good enough for now.
  24. @xhodan I think you'll see many things progress in ways you'll like as we go along. Many shortcuts must be taken in these early stages, until better systems are in place. Brick making is going to be changed eventually for instance. But until then we have the mechanic we have, which above all else is easy for Tyron to code, being just a grid recipe and a firepit cook time. A couple years ago when I first started following VS Tyron had just introduced the ability to make ingots, iirc, and at that time tools were crafted in the grid just like in minecraft. There was no smithing yet. I don't recall if there were animals back then, or if they simply didn't drop anything, but you couldn't get meat. I don't think you could farm either. So food was basically impossible to find. You simply started the game and explored till you died of starvation. Later, after it was possible to survive for more than a couple days, Tyron actually did try out a fat reserve mechanic. I think the general consensus was that it didn't really add much to the game so it was removed. Of course there were just a handful of people playing the game regularly back then. I think that with the upcoming seasons update, we might be able to finally start balancing crops and food in general in a good and challenging way (get off the berry crutch). I don't know if automation of farming will ever truly be a thing or not. It is intended that eventually there will be a 'survive and automate' mode for the game, and it's my understanding that that mode will go whole-hog on automation. But the default survival game mode, it would not surprise me if farming could never be truly automated in the way minecraft does. I guess what I'm saying is that it's process of refinement of mechanics. The bad part about the detailed and custom crafting mechanics in VS is that they take a lot of Tyron's time to code. And you have to have certain frameworks in place before the next can come in really. That said, some design decisions are intentional, such as the lack of need to drink water, as I understand it. It makes sense; in TFC water drinking was just a nuisance. It added nothing to gameplay or the tech tree. You could drink with your hand, or with a water jug. That was it (without mods). It didn't encourage any use of metal, or other resources or tech aside from clay. That's not worth putting in the game imo. I would want to see a much more considered mechanic, and the world would need to support it, by drinkable water being far less common (again, imo), so that it had meaning. As for RPG and skills, not sure what the plan on that stuff is. If the game does delve into rpg territory in terms of npcs and interaction, I would expect it to be very light, or very far in the future.
  25. If you're doing single player, you can always jump into creative mode ("gamemode creative") and place a trader. They're a searchable 'object' in the creative inventory. I just wish there was randomized one, so it doesn't feel as much like cheating picking your own specific one. Some are more desirable than others imo.
  26. @Stephan OrtolfI thougth someone more knowledgeable than me might have responded to this. I know that the game creates one or more 'texture atlases' that are a composite image containing a large set of textures. These atlases have a defined size. If you're making a resource pack using individual textures that are larger than default, you will quickly outgrow the defined texture atlas size. I'm guessing you need to increase the allowed size of the atlases. Unfortunately I couldn't tell you how. Perhaps try asking in the mod topic on the discord forums - people are more active day-to-day there.
  27. I also feel the game could use a bit less micromanaging, especially when it comes to the inventory management. Constantly having to eat food is a nuisance and I think it could be fixed by having a bigger focus on the nutrients: Food saturation lasting longer, but the player can only eat when he is hungry and most food don't give much nutrients, so to max out nutrients, the player would not need more food, but better quality food. There could be less of a danger of starvation, but less nutrients weakening the player more. Regarding the RPG aspects, I'm entirely against them. While such aspects are an easy way to make systems feel more rewarding, it also often leads to the player having to grind. Mastery of the games systems doesn't come from playing well, but from playing long enough to have a leveled up character in character skill based game systems. I rather support a focus towards player skill, where not the time playing and the amount of grind done is the deciding factor in success, but the players skill and knowledge. Instead of the characters farming skill leveling, the player should have to learn how to effectively breed plants. Instead of the character smithing skill determining the quality of the sword crafted, the players skill at forging and knowledge of creating good steel should determine the quality of the sword. This obviously requires to design game systems with a lot more depth, but that is also the point of it. Game systems shouldn't be reduced to skill checks and level-ups, but systems with a learning curve and a high player skill cap.
  28. Will update this as development progresses. Hey guys, I've put in a solid 12 hours into the game so far and I've absolutely fallen in love with the game. I'm super excited to see how things evolve in the coming months and years. My current thought's on the state of things are as followed. 1. Crafting: I was pleasantly surprised at how unique the current crafting system is, it's familiar, but different, definitely a refreshing take on the genre. 2. Graphics: Not the most important aspect of the game to me, I would like to say though I've been taken back by some awesome breathtaking vistas in my travels in Vintage Story, I love the fog effects and I'm excited to see the potential for other weather effects and seasons. Okay with that out of the way lets dive into my suggestions. It is my understanding that Vintage Story is supposed to be a survival RPG. I wont talk much about the RPG element as it seems to be the core game-play right now is mainly crafting/building, and surviving so I will focus on those three areas. At the end I'll give some thought's I had as far as RPG game-play and mechanics. Survival: Right off the bat this game does a fantastic job at making the beginning stages of the game actually challenging to a degree. You don't just instantly start gathering all the materials needed to make a home for yourself or tools, there's a process to this which I like and is super refreshing from Minecraft. However, I believe there could be some major improvements as far as what it means to survive and how you do it in this game. I personally do not like how much micromanagement is involved in keeping your character fed. Now I think this is an essential game-play element that needs to stay, but can we move away from the traditional (and by traditional I'm referring to how Minecraft does it.) You smack a sheep or whatever else and boom you have your food, it's relatively easy to get and maintain. It doesn't feel rewarding and the game-play is a bit monotonous and it always feels like a bucket list chore that you eventually have go out and do. Now this doesn't mean we should do away with having to eat and maintain nutrition levels. I actually really like that touch, it can be improved. Add stamina and water, make it so food satiates water needs, slow down the rate in which the player needs to eat. Maybe add a fasting mechanic similar to Wurm Online, maybe there are benefits to not eating short term, and negative effects the longer you go without, eventually leading to death. I think you guys are going in the right direction as far as farming goes, I love that I can actually intelligently see how long it will take for something to grow. There seems to be a good solid foundation for farming as far as fertility goes, I think these things need to be developed more and other ideas should be explored. In the discord lately there were lots of talks of automation for dealing with these things. I half agree with some of that. I don't think automation would be needed as much for things like farming wheat if the process of farming itself were more of a pass-time activity that required an hour, or several hours of real time to complete. I feel this sort of game-play lends itself better to a RPG game. Usually in RPG games there's more emphasis on character progression. Minecraft is all about item progression and getting diamonds quickly so you can get the best gear. Maybe in Vintage story our characters could have stats, and these stats would affect our effectiveness at performing various activities like farming, mining, etc. Crafting: Not much to say here. There are some maybe nit-picky things that come to mind. Brick making for instance seems too tedious to me, maybe I'm wrong. That's just how I feel. Above I mention that this game's strongest suits right now are it's Minecraft like game-play. I love building things. Will update this section when more crafting content is implemented. RPG game-play idea's: I want to see more RPG mechanics that directly involve our characters I mentioned above maybe having skills that affect our performance in doing various things in the world. Like mining, chopping wood, farming, etc. I'm hoping that in the future the addition of a story of some sorts to follow will be built into the game. I love a good story, even quests if they're good. Maybe player made quests, someone should write a quest scripter for the NPC traders or other potential NPC characters.
  1. Load more activity
  • Newsletter

    Want to keep up to date with all our latest news and information?

    Sign Up
×
×
  • 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.