Jump to content

Search the Community

Showing results for tags 'growth'.

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


  • Vintagestory Discussion
    • News
    • Discussion
    • Suggestions
    • Questions
    • Multiplayer
    • Bugs
  • Creative endeavors
    • Builds
    • Videos, Art or Screenshots
    • Story
  • Vintage Story Modding
    • Mod Releases
    • Modpack Releases
    • Mods & Mod Development
  • Off Topic
    • Other Games
    • General Offtopic


  • News
  • Community Spotlight
  • Stories

Product Groups

  • Game Account & Game Servers
  • Game Server

Find results in...

Find results that contain...

Date Created

  • Start


Last Updated

  • Start


Filter by number of...


  • Start



About Me

Found 3 results

  1. Noticed that my Rye crops are no longer growing on the dedicated server I play on. No server mods are installed. I am in an area with farm land that existed during v1.15.0 which previously grew crops. Now that we updated to v1.16.0 no crops have progressed passed the first stage. The entire world seems to be effected by lack of crops growing. This world was created during 1.15.*. I haven't tested if trees are having the same issue.
  2. Given this game's focus on realism, and taking inspiration from a number of Minecraft mods, I wanted to bring up a mod I find essential in most of my playthroughs these days, which I think it'd be really cool to try to emulate to an extent, or at least take some notes from it, because currently trees look a bit, for lack of a better term, plain. The mod is Dynamic Trees, and it overhauls how trees generate and grow, with a focus on more realistic shapes and sizes. Some features include: -Trunks that get thinner higher up -Branches that extend and, well, branch -Leaves that constantly grow, regrow, and change -Trees growing from a small sapling over time into a full-sized tree naturally -Trunks that can be over 1 block thick, but under 2x2 in size -Trunks that can be under 1 block thick -Falling tree physics (to an extent) -Larger trees generating aboveground roots -Branches being far quicker to break than trunks -Tree disease/lack of nutrients from soil causing stunted growth and tree-death -Saplings planting themselves when leaves naturally decay -Trees growing taller to fight with other trees for more sunlight under the canopy -Emergant forests that live, grow, and wane on their own -Unique generation for each tree type -Surprisingly minimal performance hit, even in Minecraft, for all the tree updates happening constantly in wooded areas It makes trees gorgeous and vastly improves their generation, look, feel, and functionality. I feel like this style of tree, and a lot of the functionality, would feel right at home in Vintage Story's more detailed look and mechanics! I can even imagine thinner branches being affected by the wind... It would look beautiful- Of course I'd suggest crediting Ferreusveritas if you were going to take inspiration from the mod.
  3. Hello, When playing on servers, you notice progress of time can both be quite crippling and boosting at the same time if you compare the mp experience with the sp experience. When you're not in-game while others are, time progresses to affect food decay, plant & animal growth and reproduction, torches burning out and barrel aging/ripening processes (and crop decay as of next update) in the chunks you are in, even when your whereabouts are nowhere near the place where other players are active. So, when you rejoin the server after some period of absence, you can find all your food (and crops) decayed, the torches you placed burnt out and all those saplings you planted the day before fully grown. This is not encouraging nor adding to the intended immersion for any player in early game, for players who play less frequently or on a more occassional/casual basis than the more fanatic ones on any server. The food (and crop) decay aspect is the most discouraging one in this respect, obviously. Many experienced veteran players have hardly experienced this as an inconvenience as they either hardly played as a new player on servers since many time dependent relationships were introduced, or are already aware of how to deal with the odd inconveniences, as I experienced myself as well after a while. Still, it does not seem right in various ways that the mp experience differs so strongly from the sp experience, for any player, in any in-game development stage. I think any game ready for beta release should strive to provide similar mp and sp experiences to its (new, cash-flow generating) player audience especially when it comes to mechanics that strongly affect what a player does or plans to do on an in-game-daily basis. The time progress mechanics connected to food decay, crop growth (and decay) and all of the other time dependent processes are referenced to a server timer, and calculated based on 'world time progress' as soon as a chunk is loaded. I wish to suggest to consider to add chunk and/or player based time referencing for those mechanics and make this configurable for servers. This would imply adding chunk and player time stamps, respectively updated every time a chunk is unloaded or a player logs off. These can be used as reference for calculation of food decay state every time a food item is loaded/accessed by the player who last touched/accessed/processed it and also for calculation of any other time dependent states each time a chunk is loaded. Progress in time will resume normally once players (incl. their inventories) and chunks are loaded, just the progress during the time they were not loaded will have stagnated. When a player is online and moves from one chunk to another, and eventually chunks they started in are unloaded and when they return and load chunks back again, you would want time for both food decay, crop growth (and decay) and other time dependencies to have progressed during the entire time that player was online. So, player online time duration should be leading in any case. This implies a server must store the last login time of a player and the duration they played since then, for chunk progress mechanism updates to be referenced. Then, upon a chunk reload, the progress for said mechanics shouldn't be adjusted by just accounting for the timestamp left in the chunk, but corrected for player playtime since last unloading event of that chunk and until recent loading event as well, and that for the player who last left the chunk before it was reloaded. This implies a chunk would also have to store 'last player who was in the chunk before it unloaded'. For food decay one could consider two variants. One where a prepared food items decay is calculated based on a timestamp connected to a player and their nett playing time, and another where food decay is calculated based on the time the chunk where that food item is stored has been loaded. For multiplayer servers this can make a huge difference in areas where many players are active in the same or overlapping areas for many possible reasons. For instance, for hardcore PvP servers, where player competition can have quite a devastating character, players can force load chunks of other players' bases and consequently make their food (and crop) storages go to waste. For such servers it may be recommendable to use 'player playtime referenced food decay'. For strict PvE servers where many players are building their own and in many cases only visit each others habitat for direct interaction, 'chunk loadtime referenced food decay' would be an acceptable alternative. For cooperative food production and sharing it will be worthwhile to 'retag' a food items decay time reference with another player as soon as the item is handled by a different player than the one that originally 'created' the item. In case of 'player playtime referenced food decay' there can be a potential 'tavern exploit' where one player processes a lot of food in single item containers (crocks) in one area to leave it for others to use when they need it and the producer player logs off for an indefinite period of time. Chances of players actually doing this may be relatively low, but it is not an unthinkable scenario and it therefore justifies a counter. On servers where this possible exploit is deemed a serious risk, 'chunk loadtime referenced food decay' may be considered. An alternative is to add a 'claim ownership/access permissions override'. Any food item in a claim accessed by anyone with specific privileges in that claim, will have decay progress dependent on the in-game time of any of those players. If a 'tavern' has food stored produced by player A and player A shares the access to the containers in that tavern with players B and C via the claim system, in-game presence of players B and C will also ensure decay progress of any of the food items in the claim. Also with this scenario in mind, the desirability of any option can strongly depend on the type of server, so configurability seems required. For PvP/faction focussed servers the claim override option may be best suited. Another alternative may be to have a setting per player that determines whether the food decay for items produced by that player will be 'player playtime referenced' or 'chunk loadtime referenced'. That can then be set at the moment a new player joins the server, either defaulted or left to the player to choose. Any food item will then get a tag indicating how food decay progress is to be calculated. As soon as a different player handles an item or a food holding container, the tag of the affected item(s) can be made to irreversibly switch to 'chunk loadtime referenced'. Seasons are planned to be introduced in a next game update. This will enhance the effects offline time progress will have on individual, new and/or more casual / less active, players on servers, and will therefore only increase the urge to address the issue brought forward here. Overall: For food decay, calculate the actual shelf life progress of any item based on the playtime of the player who last processed/handled/stored it: 'player playtime referenced progress of time'. If a player creates a processed food item and stores it in some container, the shelf life progress will be equal to the time that player is in-game. As soon as another player 'takes over', the in-game time of that player will become determinant for the shelf life progress. For all other processes, calculate the time progress based on both the time the chunk where the affected items/entities are located and the time the player spent in-game who was the last to load the chunk: 'chunk loadtime referenced progress of time'. This may also be useful as an alternative for food decay, dependent on server/community playstyle/goals. For food decay a combination of both calculation methods may also be considered. The proposed changes will not lead to an 'ideal fix of the issue' (which may simply be non-existant or not achievable), but it will improve the situation considerably for a lot of players on servers. For new and/or more casual players on servers who value the experience of the various sp game dynamics next to having company while playing, the situation will become much more pleasant and inviting. For servers where most players are involved in joint efforts, focussed on one or only a few locations, or where most players spend their time 24/7 on the server, it may be worthwhile to leave the option to not use this alternate time referencing method and just keep using the present method. There may be more aspects to address when considering this suggestion. Any progressive insight will be processed in the core text above. This will obviously not be of any added value for single player worlds, but for multiplayer worlds this can have profound impact on the experience of individual players and on their motivation to continue playing, and consequently on long term server and community viability. I hope the above makes sense, you will be able to find a suitable way to tackle the issue brought forward and my suggestion is worth considering. Cheerio, Alte Edits: 1) After more pondering it became obvious that for food decay on multiplayer servers the aforementioned 'timestamp connected to a player' option would be the way to go. In other words this would concern a system where each food item is time-tagged with the player who last handled it. This could also be seen as an 'ownership system' as worded by radfast in one of his constructive comments below. This post summarizes this view and some additional thoughts related to hoppers. 2) This also concerns the burning time of torches, and the aging/ripening times for various recipes in barrels. For these processes I would also recommend to use time referencing based on a combination of chunk loading/unloading and player activity. 3-5) Various rewrites. Added remark related to potential 'tavern exploit' that could affect mass produced food in single item containers, as discussed with Saraty on Chrometech. Included 'crop decay'.
  • 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.