AlteOgre

Good thought. This apparently has been suggested quite a few times before though. Seems to be a broadly supported notion.

A very exiting and interesting future feature indeed. The potential complexity and dependencies on other planned features (like seasons) or current game improvements (like food decay on servers), may make this specifically fit for a modding effort in this stage of development though?

Thx for the constructive response Kaelty. I think you misinterpreted a bit there regarding 'losing' of skills. The 'losing skills' is not a thing. Muscles don't dissappear but their ability to excel in some action will decrease if they're idle for a longer period of time. That's why there are base levels and perks. And tuning to achieve a pleasant experience in both SP and MP will be a major effort (for any PCDS). Also, I understand your reasoning about skills and proficiency as it's mine as well. Yet we're dealing with a game here, not an exact real life simulation. I'm working out the contents of the second post and expect that will help illustrate some of the concepts. I actually just added some first indicative info there. if people feel forced into a 'role' on servers 'because of a the benefits of specialisation' with a system like this, that's their personal problem in their relationship with fellow players. A class system will certainly not make them better off, nor having no benefits of specialisation at all. I know the concept to use an exponential function (or just any asymptotic function) to make maximum levels unachievable. Setting a fixed cap does however still make sense knowing the grinders out there. They better be told when to stop. Simple and it won't hurt.

Reserved to add my own sauce regarding concrete attributes and skills in VS. Alright, let's spam some more detail here. Assume this post to be WIP. Attributes & Skills Attributes are player character qualities (physical and mental 'muscles') that can be trained through performing actions, or in other words 'through effectuating skills'. Improving character attributes will help to enhance the efficiency or effectiveness of these actions. In principle skills are directly related to in-game actions a player can perform. Their success depends on the player characters attributes. Effectuating skills by performing their connected actions is considered training and therefore contributes to improvement of the character attributes required for executing an action. So there is a clear, hard coded, interaction between attributes and skills. Not all attributes contribute to the success of each skill and not all skills contribute to the training of each attribute. ATTRIBUTES I’d distinguish between physical and mental attributes and make sure there are not too few of each so the entire PCDS can provide for (future) variety and flexibility in agreement with the abovementioned starting points. A broader range of attributes also adds more ‘flavour’ to characters, providing each with a more ‘fingerprint’-like, unique feel of the character each player developed. Oversimplification would undermine those aspects. Physical Attributes These all reflect a measure of characters physical ability regarding specific qualities. · Agility: Manoeuvrability and flexibility of the body. Determines the ability of the body to change position when commanded. This can affect the speed to turn, jump and climb but also the chance to deflect or avoid incoming danger (in combination with Reflexes). · Constitution: Hardiness. This is covered with the present value for the characters maximum health (the length of the health point (hp) bar), which is the sum of a base value plus 4 nutrition attributes. · Dexterity: Capability to perform accurate actions on a smaller scale, requiring good eye-hand coordination and fine motor skills. This can affect the speed with which ranged weapons are aimed, the accuracy of ranged attacks, but also the speed and efficiency with which tasks like mining, logging, panning and butchering are performed. · Endurance: Capability to perform long lasting straining tasks. It factors the characters nutrition processing efficiency. Endurance can have a base value of 1.0 and be increased to values in the order of magnitude of 1.2. The effective saturation decrease in time will be divided by the character’s Endurance after correcting for strain factors in dependency of the type of activity the character engages in. · Fortitude: Capability to withstand damaging impact to the body. This is independent of Constitution and defensive armour worn by the character. Fortitude can have a base value of 1.0 and be increased to values in the order of magnitude of 1.2. The effective damage taken will be divided by the character’s Fortitude after correcting for armour protection. · Might: Physical strength. Capability to hit hard, run fast, jump high, carry much, etcetera. Any action requiring muscular strain can contribute to improved might, and improved might can contribute to any force the character exerts on their environment, resulting in higher speeds and/or higher impact. This is a physical attribute that can be trained in many ways and have very broad impact, affecting many practical skills. Might can dwindle though, obviously by being idle, but also while just wandering around (not sprinting), roleplay chatting, or performing low strain tasks like cooking. · Reflexes: Capability to quickly respond to rapidly changing circumstances. Hunting and fighting typically train ones reflexes. But hunting chickens will not be as effective in building excellent reflexes as fighting wolves or nightmare drifters. Mental Attributes These all reflect a measure of characters mental ability regarding specific qualities. · Caution: Degree of a character to take higher risks for higher rewards. The higher the caution, the more accurate and precise a character operates. High caution can result in better rewards from mining and harvesting activities, but also reduce their visibility for predators and monsters. · Intelligence: Problem-solving ability. Higher intelligence is achieved by performing tasks with a high degree of complexity and/or that require much focussed attention. Forging and hunting contribute most, but cooking does too. High intelligence can lead to improved efficiency of a number of activities and combined with knowledge, unlock new insights. · Knowledge: Insights in cause and effect relationships. Knowledge of the environment is built on experience through interaction. All activities aimed at extracting resources from the environment lead to increased knowledge. Mining, digging, logging, panning, farming, butchering and collecting lore information all contribute to this attribute. The way knowledge expresses in action in-game can be quite different than for other attributes. Knowledge hardly wanes and has the potential to unlock new insights, especially when combined with high intelligence and wisdom. Knowledge will typically enable acquiring perquisites that allow for special recipes, or even allow for the character to find resources others cannot perceive. · Perception: Awareness and alertness of a character’s surroundings. Interacts with other mental attributes. May get more relevant as VS introduces more player dependent mechanics like quests and tracking. · Presence: Combines charisma, charm and social characteristics. Affects the interaction with NPCs on various aspects, like price levels with traders, the potential to hire NPCs / have them perform tasks for you, the accessibility of quests or just speech bank usage. For future major mods or expansions bringing factions/civilisations to VS, this may also affect character ‘alignment’, ‘fame’ and/or ‘reputation’. · Resolve: Mental resistance/hardiness, determining the degree to which they can fight fear and pain. Resolve strengthens the more a character hunted, fought foes and has endured temporal instability. · Wisdom: General degree to which a character reads other sentients’ intentions and is aware of long term and long range effects of their own interactions with the world. Will get more relevant as VS expands long term and range mechanics and adds more NPC interaction, including quests. If ever VS would include magic in some more or less advanced form, and/or alchemy and/or more advanced technological concepts, the mental attributes will get more relevant and get more distinct functionality. SKILLS I’d distinguish a number skill classes related to the type of player actions connected to them in-game. Mining Skills Breaking or taking of full block items like rock, dirt and gravel. · Digging: Dirt and Gravel in any form while using a shovel. · Stone mining: Any type of rock while using a pickaxe. · Ore mining: Any type of ore while using a pickaxe. · Prospecting: Any type of stone or ore while using a prospecting pickaxe. Picking up loose stones, boulders or nuggets does not contribute to any attribute or skill. These activities typically contribute to attributes like Agility, Endurance, Might, Caution and Knowledge. HOLD: To be completed. Harvesting Skills Extraction of live tissue from plants and animals, including fishing, logging and the separation of potential valuables from sand and gravel through panning. · Fishing: Any type of fish while using a fishing rod. · Logging: Any type of timber while using an axe. · Clearing: Any type of grass and branches while using knife or scissors. · Crop harvesting: Any type of crop, regardless where they grow. · Planting: Any type of seed, root and sapling. · Butchering: Any type of animal while using a knife. · Panning: Any type of sand and gravel while using a pan. Picking up loose sticks does not contribute to any attribute or skill. These activities typically contribute to attributes like Agility, Dexterity, Caution, Intelligence and Knowledge. HOLD: To be completed. Building Skills Placement of structural elements to erect housing, infrastructural elements and other structures. · Wood building: Any type of wooden structural elements. · Stone building: Any type of stone structural elements. · Finishing: Any type of shingles and glass structural elements. · Assembling: Any type of technical structure consisting of more than one component. These activities typically contribute to attributes like Dexterity, Might, Caution, Intelligence and Perception. Training in each of these skills leads to increased deconstruction speeds. The more stone elements you place, the more easily it will be for you to remove them. Fast placement leads to rapid tiring, so for these types of actions, the nett training effectiveness will relatively rapidly decrease with increased training intensity. Note that any ‘building’ action aimed at placing devices, containers, light sources or furniture is excluded. HOLD: To be completed. Crafting Skills Conversion of resources into intermediate or finished products, via usage of the crafting grid and barrels, knapping, clay forming, cooking, smelting, casting and forging. · Knapping: Any type of stone and product. · Tool making: Any type of tool. · Reed working: Any crafting activity where reed is used as an ingredient. · Clay forming: Any type of clay and product. · Grinding: Any grinding process involving a quern. · Linen working: Any crafting activity where linen is used as an ingredient. · Leather working: Any crafting activity where leather is used as an ingredient. · Wood working: Any crafting activity where log or planks are used as crafting ingredient. · Stone working: Any crafting activity where rock or stone is used as crafting ingredient. · Cooking: Any cooking process involving a firepit and food ingredients. · Food preservation: Any crafting activity resulting in a food item with enhanced shelf life. · Hot processing: Any baking or smelting process involving a firepit, a forge or a bloomery and non-food ingredients. · Glass working: Any crafting activity where glass is used as crafting ingredient. · Casting: Any activity involving the casting of molten metal (alloy) in baked molds. · Forging: Any activity involving the conversion of molten ingots into finished metal (alloy) products. Note that any ‘crafting’ action aimed at either packing things together for storage purposes is excluded. And crafting of firewood and fire starters does not contribute to any attribute or skill. These activities typically contribute to attributes like Dexterity, Caution, Intelligence, Presence and Wisdom. HOLD: To be completed. Combat Skills Interaction with live entities aimed at inflicting damage. · Melee combat: Any melee combat interaction with monsters or other players. · Ranged combat: Any ranged combat interaction with monsters or other players. · Melee hunt: Any melee combat interaction with animals. · Ranged hunt: Any ranged combat interaction with animals. These activities mostly contribute to physical attributes like Agility, Endurance, Fortitude, Might and Reflexes, but mental attributes like Caution, Intelligence, Presence and Resolve can also be notably affected. HOLD: To be completed. Non-combat interaction Skills Interaction with live entities not aimed at inflicting damage. · Animal feeding: Feeding animals from a trough. The player that last filled a trough is registered as having fed the animal that fed on the trough’s contents. · Animal breeding: Any animal breeding that was fed by a player (via a trough). · NPC trading: Any trade interaction with NPCs. These activities typically contribute to mental attributes like Caution, Intelligence, Perception, Presence and Wisdom. HOLD: To be completed.

INTRODUCTION As part of the future RPG elements of the vanilla game a Player Character Development System (PCDS) may be expected. When pondering what such a system should entail if it were match with the vanilla game, I thought of the following concepts and starting points that I wish to bring forward for consideration. The vanilla game leans on the principle of ‘no grinding to max player capabilities’ and I am personally a huge fan of that. I think the way the players max hp is managed in dependency of a balanced diet (nutrient intake) in time while making use of moving average ‘intake’, should also be the template for other systems affecting player capabilities. Therefore I propose to use this same concept for a future PCDS. So, which appropriate starting points could further be considered for such a system? TRAIN, SUSTAIN ... OR DRAIN Player characters can improve their skills through practise ('training'), but if they do not sustain them, the effects of any training gradually decreases, or ‘drains’ off. Any 'muscles' of both body and brain weaken through lack of activity. This implies a ‘moving average’ record is to be kept of character ‘training’ (executed actions that contribute to some level of skill). This concept is very similar to the way health is implemented. PLAYER CHARACTER SPECIALISATION Players should be able to specialise, i.e. to maintain a high level of skill in specific pursuits through focussed efforts. This will offer interesting dynamics on servers where a cook can prepare the most nutritious meals, hunters and livestock keepers can produce the most animal products from any ‘harvest’, a forester can get the most usable timber and saplings from logging, and a miner can get the best and most of breaking ore containing rock. CLASSLESSNESS Despite the use of names of 'professions', I do not suggest to implement a system using 'class' or 'profession' identifiers in any way. I’d rather recommend to not use such ‘artificial, immersion breaking tags’ at all. Players should be free to develop whatever combination of specialisations for their character. It would be nice-to-have if somehow NPCs and/or players in the environment of a player character can recognise specialisations. ATTRIBUTES AND SKILLS An attractive PCDS would consist of a set of physical and mental attributes ('muscles') that can be trained to get better at a set of in-game specific skills who all relate to player actions like breaking and placing blocks and items (‘mining’ and ‘building’) and processing resources to ‘craft’ products (‘crafting’). Ideally, every activity contributes to training a specific skill and improve one or more attributes (as to reward the player for their in-game performance), even if the effects would just be hardly noticeable on short term. Also ideally, each attribute can be trained with multiple activities and also affect multiple skills, but improving an attribute through training in only one specific activity will not allow for the same specialisation for all attribute affected skills as all skills require a different mix of attributes to be put to use. Such a system could lead to the following example. Imagine a melee specialised warrior with formidable might (a physical attribute) able to chop down trees and break rock faster than any cook can, but their friend specialised forester or miner will get a better yield from logging or mining (specific skills) than said melee warrior. This would be due to the fact that in melee combat (sword wielding) the warrior player's training mainly affects their attributes might, endurance, reflexes and resolve, while through logging the forester player's training mainly affects their attributes might, dexterity, knowledge and caution. As only the improved might attribute will effectively contribute to the warriors ability to cut down trees, he will not be as effective and efficient as a forester, even if their might would be superior to that of the forester. This part will require a lot of thorough thinking in order to design a fair and balanced system of attributes and skills in agreement with all other starting points addressed here, but the basic mechanics can be implemented in a quite straightforward and well-known manner. 1) For clarification, the present set of nutrition values and the resulting maximum health value of a player can be considered as 4 specific 'constitution' attributes of the character that each add to their maximum health. This maxium health value of a player can therefore be considered a 'skill' that can be trained. The proposed attribute-skill system can be implemented in the game code in much the same manner, with values of attribute increasing and decreasing dependent on the (in-)activities of the player and these values being used to calculate the effects of player actions in the game. THERE'S ONLY SO MUCH ONE BLUE MAN CAN DO To suppress any ‘mindless’ grinding of players trying to continuously keep up their maxed levels, the effectiveness of training shall be restricted. To ensure this, training effectiveness should be reduced in dependency of the training intensity (‘training per measure of time’). The more a player trains per measure of time, the less effective their training becomes. Assuming skill training and ‘experience’ is calculated in the same way as health now is, the time dependency will be taken care of. Additionally, the ‘experience gain’ will have to be dependent on the training intensity. Simplest way would be to have a linear dependency where above a certain threshold training intensity, the experience gain per action linearly reduces to some minimum value (say 10%) when reaching the practical maximum training intensity. Smart setting of sample time periods (for moving average intensity calculation) for each type of activity will be essential. This mimics the realistic limited ability of characters to train their ass off while still resulting in improved level of skill. No, characters get tired after some intense training and will have to recover before being able to get better at something. And the nett effect of training reduces at some point when physical, and mental, limits are met. This also implies that players shall not be able to ‘max all skills’ and they will have to choose what to train dependent on what they wish to achieve in-game. Each trainable skill will also have capped maximum ‘experience’, see below for more on that. Nonetheless, ‘Grinder’s gonna grind’. Duh. IN REALISTIC MODERATION Another starting point should be that characters cannot develop super-hero like capabilities. To both ensure the game maintains a feeling of realism and to ensure the capability differences between players with maxed skill levels and other players (servers!), and their environment (also in single-player!), it would seem appropriate to ensure that maxed capabilities do not exceed a base capability with a performance factor of 50 to 100 %, i.e.: players can train to get 100% better reflexes and/or more agile resulting in double the chance they can avoid a blow to the nose, or they can get 50% faster at whacking a pick axe into a wall of igneous rock, but no player can get better than that. As a rule of thumb, I recommend to aim for the relative ‘strength’ of highly specialised characters to be maximally twice as high as that of untrained characters in any (set of) skill(s). LEVELLESSNESS In line with the spirit of the game and the above, I propose to not distinguish '(experience) levels'. Instead, players will be able to view a scale from 0 to some maximum value (or percentage), indicating the degree of mastery they achieved in any distinguishable skill. HIGHER UP, THE SLOPE GETS STEEPER In line with both realism and most RPG games, improvement gets harder with higher 'level' of skill. This simply implies that the mathematical relationship between skill 'level' and effect will have to be non-linear, possibly some exponential function with an asymptote approaching 'max effect' for high skill 'level' (or 'experience points'). PERKS Finally, perquisites aka ‘perks’. Based on the above starting points, player skill can degrade due to inactivity and that can be quite discouraging for players. To counter this effect perks can be used as lasting rewards from intense specialisation. These can for instance be special abilities for sword wielding warriors to develop a chance to cripple their adversaries (chance to impose a 'slow effect') or for smiths to acquire the ability to create a special tool. When those warriors and smiths turn to farming for a while, they may respectively lose part of their attack strength and ability to recover nuggets for re-smelting after forging. But they will not lose the perks they acquired when they were active as warriors and smiths. So the once-warriors still have a chance to cripple their foes with a sword and the once-smiths can still use that special 'recipe' they learned. 2) Perks can be unlocked upon reaching a threshold value for an attribute or a skill. TRAITS On top of that eventually also traits can be added to the PCDS sauce. Traits would be related to a player character's intrinsic mix of pre-set attribute values, or 'defaults' they would have. This can be considered to reflect the genetic map of a player character which can be a result of their ancestry, inherited when they enter the game. This may add another interesting feature for future VS (whether or not part of the vanilla game, some specific expansion or only in mods), as this can support introduction of player character races, each with their specific subset of pre-set base attribute values. A possible additional way to express 'traits', next to using pre-set attribute values, can be by using trait-dependency in attribute learning rates ('experience gain'). TAKE IT STEP BY STEP A complex PCDS requires careful functional design specification and a stepwise approach to realise the code and roll out the implemented features. Not all has to be released in one update and not all will have to be optimally tuned between two. There’s a logical hierarchy in the system’s features determining what should have to go first and what last. So, that's about it. I think the above starting points could provide an appropriate foundation for a 'Player Character Development System' for VS. I hope the VS team will find some of the above useful for their plans. Any constructive feedback is highly appreciated. If useful, I will adjust the above based on feedback provided and further discussion in this thread. The next post is reserved to add my own sauce regarding concrete attributes and skills in VS. Edits: 1) Added explanation regarding relation between nutrition - hp and the proposed system of attributes - skills. 2) Added remark on the possibility to connect perks to both attribute and skill levels.

I'd rather first see donkeys or mules introduced to the game to do the heavy burden kinda transport.

I agree with the main sentiment that it can be quite devastating for 'unlucky' player experiences that some specifically valuable rock types are hard to find. But I do support the main starting points related to survival and exploration, based on the realistic approach of the game. So, I'd not support a major change. Instead, in order to improve the average player experience (some get lucky, some don't), I would propose is to just tweak the occurence and average area coverage of instances of chalk, limestone and halite. Make their deposits occur a tad more frequent (a tad less rare) compared to other sedimentary resp. special deposits, but also reduce their deposit area/volume sizes, so their overall global average relative presence isn't affected.

For a majortity of players, the survival fun in early game is to explore and set up base by yourself. Such a container will really not mitigate the issue brought forward. No that is not the main question here. This thread goes by the assumption that food decay is part of the vanilla VS experience and is not to be discussed. If you wish to asses this feature as-is, please move to another thread. The topic of this thread is focussing on improving the experience of players on servers using the vanilla VS game features related to food decay and other time dependent progress mechanics.

As far as I can tell, currently any food decay progress is simply related to the server (or client in case of SP) timer. If a server is online, time proceeds and decay and growth proceed. This is independent on whether or not a chunk of the world is loaded. As soon as a chunk is loaded, decay and growth of any food items, flora and fauna are adjusted for the progress the 'server world' has gone through ever since the chunk was unloaded. It may not be the most charming way to make 'ownership' and related decay time reference be determined by the player who last 'touched' any food item or the containers they are stored in, but it seems to be a possible option and as far as I'm concerned, it's an acceptable option that will effectively tackle the main issue brought forward. No other effective alternative options have been brought forward yet (not in this thread anyway). If a new type of container would be introduced that would only be accessible for late game stages, then it would not contribute to tackling the issue at hand, namely regarding the food decay progress for players on servers when they are not logged in. So, no, that wouldn't solve anything. The food decay issue is the main aspect, but I think it would be wise to consider plant and animal growth in this respect as well. As mentioned in my first post, these could be addressed with a slightly different approach. We discussed 'ownership' / 'tagging last player who handled a food item' in relation to food decay, but for plants and animals that wouldn't make much sense, and there also is no direct need to implement such a system for those time dependent item/entity states. It would be nice if plant and animal growth would only proceed in chunks when they are loaded, much like the way it functions in Minecraft. But, in the spirit of this game, I understand it would also be justifiable if plant and animal growth proceed as long as a player who last loaded a chunk holding them, would be online, so independent of the loaded state of the chunk. This could work by correcting the time progress of a chunk upon reloading with the time a player who last loaded the chunk has still spent time online while the chunk had been unloaded again. This still seems an acceptable option to me, and an improvement when compared to the current situation, where any plant and animal growth just progresses as long as the server is online. I tried to explain this in my first post. I hope it may be clearer now by explaining it in slightly different words. Btw: Yesterday I had an additional realisation regarding this. Part of the player community loves to play on more than one server. The food decay issue makes it less attractive for them to do so, resulting in a nett lower average playtime. Just added this as an addtional remark to my second post.

Thanks radfast, much appreciated, Those are exactly my thoughts now as well. I originally didn't go into much detail although the essential thoughts were already in my first post. After pondering about it some more while playing on servers that would indeed be a way to go. Regarding the hopper: In the spirit of the game I would expect any food product to be put into any storage container via a hopper to not get reduced decay time until he hopper is disconnected from the container and/or the container is sealed off. And only from that moment on the stored food item should have 'gained shelf life'. Until that moment ownership can be with the person who last handled the input. Any player performing the 'secure container' action would be assigned ownership for all food items in that container. As soon as the container is then reopened by another player, ownership will transfer. Anyway, ownership of containers should consequently be a thing in the game if this were to be implemented. Does that make sense?

Thanks for replying Streetwind. The issue does exist and is real for new players on a server. And dependent on a players luck in the biomes they start in, and whether that environment hasn't already been stripped to the bone by players who got there before them, the issue can persist for quite a long time as it can take quite some time before players actually can enjoy the fruits of sustainable food supplies. Yes, the issue will become ever more of a problem when seasons are introduced. Seasons will make both coders and players face with many new challenges anyway, so let's not get into that too much for the sake of focus on the topic at hand. Regarding food decay I already tried to explain that food decay timers should be player dependent anyway, and not chunk determined, for the exact reason you worry about potential exploitability. Let's move on and focus on the response of radfast as he goes into such matters in more depth.

In past week I've been playing on a server mostly and together with the group of players on that server, many of whom are new to VS, experienced more of the effect of food decay on server gameplay. I now think the projections I made in the first post seem quite careful. The effect of food decay while server time proceeds but players are absent themselves, can be quite devastating for new player motivation and their willingness to keep on playing and truly enjoy this splendid game. Even for more veteran players with adequate acres, livestock pens and cellars in place the effect of food decaying when they've had other daily distractions than playing on a VS server can be very disturbing as they find themselves spending much of their time restocking their food supplies before they can resume building, exploring or whatever they had planned on doing. I believe this to be of profound effect on player loyalty and long term viability of the player base for VS, especially on servers. And as servers are a very relevant cradle for game improvement and long term player loyalty, I think this should be a high priority issue. So, this is a strengthened plea to consider the above proposal or think of other ways to tackle the issue brought forward. Please don't mistake this for a nagging complaint of someone who cannot deal with the options provided in the game or who doesn't get the point of the hardship and gameplay focus, because it's definitely not. I manage quite well playing games like this as they totally fit my style, and also don't have a hard time surviving and patiently developing my base, exploring new terrain, unlocking new technology etcetera, even with the food decay issues related to servers. Yet, I think many players will (eventually) find this issue wasting their gameplay experience on servers and this seriously undermines the viability of VS servers. I am very curious to hear other people's views on this. Edit: Had an additional realisation regarding this. Part of the player community loves to play on more than one server. The food decay issue makes it less attractive for them to do so, resulting in a nett lower average playtime.

Thanks for sharing those thoughts. That's some more 'thinking opportunity'. The plants issue is a good point. And yes, the gorgeous scenery is one of VS's unique selling points so it would be a pity if that were to go to waste. Recoding base block height could indeed do the trick, but I wonder if the potential benefits would justify the trouble and (performance) cost. Also, sand and gravel don't have high chances of grass or other plants growing on them and if only to a maximum of half of the top blocks in any terrain would be grass slabs, one may compensate for the reduced plant coverage by tuning the chances of plants growing on full blocks, and finally, sand, gravel and grass slabs could come with (a) variant(s) with grass half a block high on top of it, so as part of the block itself. So, it may actually lead to an 'acceptable' result, even though it may not be 'ideal'.

It can be done. Mevans, maker of the LOTRmod managed to pull it off for the roads generated with his mod. I don't see why it wouldn't be possible for larger terrain generation tasks. Matter fo smart coding, finding fitting preconditions and getting sequences right. The inventory argument isn't really valid imo. Players have to continuously make choices and going by what is planned for the game, that won't be getting easier anyway lol. I'd not opt for an alternative with blocks consisting of two slabs. That would just create excessive instance load and be very impractical anyway, as you already indicated. From a coding and overall game development pov, I'd consider to make slab gravel, sand and dirt only generate on altitudes above the base water level and some maximum height above that (possibly just 5 to 10 blocks, or 8 as that is a magical number ), just for the sake of creating smoother landscapes on lower altitudes. So, it will be fit for purpose without causing excessive crap. From a realism pov that would be justified as well. It makes sense geologically as wind and downfall flatten the surface, especially on larger, lower lying plain-like terrain.

Ye, I'm also one of those people who always toggle auto-jump off. So, if it would be up to me, I'd prefer the slab additions for make more smooth terrain.

I agree that this would be a nice addition. Preferrably configurable though. This has been introduced in Minecraft as well. Some people use the 'auto-jump single block steps' but others really don't wish to use it. Possible alternative, or just as a neat related addition, could be to add slabs for all sand, gravel, grass and stone blocks and use them in world generation. Especially on relatively flat terrain this will then result in much smoother terrain that can be walked and sprinted on without having to jump every full block step. This principle was used in the LOTRmod for Minecraft to make roads that are generated by the mod much more easy to travel on foot.

Sure, you can scale-up the panning equipment and process, make it a tad smarter and more efficient, and add some coarse sieve functionality to separate pebbles, flint and quartz chunks from ore rich sand for instane. All that could be possible with crude timber, sticks, rope and resin. And that may make the work a little less time consuming and laborious, assuming medieval realism is kinda a leading gameplay constraint. So, yeah, if that is the core of the proposal you got my big ogre . Imagine selecting a large number of small diameter sticks that you bind in a densely packed sheet together clamped between larger sticks or thin logs, and place that on a slope. Think bamboo stick mat. That would make for a very basic, primitive sluice box. It will be inefficient as part of the smaller high density particles will easily pass through the non-closed slits in the bottom, but that efficiency loss could be countered by filling up any holes with resin or be partially countered by placing another one underneath, possibly with smaller diameter sticks (and narrower slits), and so on. A coarse sieve function could be added by placing addtional sticks at the inlet at the top of the device. In any case, the operator will have to manually feed sand and gravel and also manually remove any potentially valuable high density particles left in the small troughs formed between the sticks (and possibly valuable chunks caught in the coarse entry sieve part). Flowing water is required to provide the motive force for particles moving top-down the sloped bottom and removing any lower density solid particles. A crafting recipe for this could for instance be: 4 logs in the corners + 2x2 resin on the sides + sticks middle top and bottom + 1 'stick mat' in the center. The stick mat could be made with: a load of small sticks in the center (preferrably bamboo for instane) + 4 ropes in the corners + 2 resin on the sides. The resulting device would be one block and have a diagonal orientation. To be operational it would have to be placed with the upper side facing flowing water coming down (... hmm, which may indeed not be that easy to find). It will have one input and 3 output slots: input for sand or gravel and outputs for coarse product, high density particles and sand or gravel. Entering a couple of blocks per charge leads to the desired reduction of time spent. The output slot for sand or gravel would require a new block (sub-)type for those blocks, like 'panned' or something as currently the game doesn't yet produce leftover sand and gravel after panning, which is a bit of a pity imo as that would encourage players to think about doing something with those sideproducts. Just like with the quern, the outputs slots could overflow and spew out their surplus.

A sifting table for the purpose of sieving hard materials like stone would be an iron age device, not something available in early game. Same for a sluice box or similar sieving unit operation. Crafting a proper sieve is quite the challenge. And it's a different separation process than panning anyway, so I don't see the logic. Late game sifting would require both decent (small) sieves and either manual, wind or water powered actuation for the sifting movement. Such a feature could give a huge boost to ore refining, maybe. So, I'd not consider it in relation to early game convenience boosting, but only for late game refining purposes if that would befit related features. A way to reduce the annoyance of gathering copper for an anvil with only panning is to first craft a propick and pick and use those to get access to larger quantities of ores for an anvil.

Eh, no, not at all. I think you're needlessly using hyperboles just to stress your point of view. I disagree that this concerns a 'slippery slope' feature for the reason I mentioned in my third post in this thread: I think not being able to sleep through a temporal storm should be the default. And if players would wanna make it easier for themselves, they should be granted the option to toggle that. Anyway, it's up to the developers to determine whether this specific and concrete proposal would cross a border they set for the game regarding this and similar features. Just like it's up to them to decide whether or not a proposed change would be in agreement with 'in the spirit of their game'. We can merely bring forward potential improvement options. The game mode you describe would justify a separate suggestion thread. I don't think it adds to the discussion of this very specific and concrete suggestion.

Yes, there is. It disables the player to avoid them. That is a similar type of benefit as those that any other setting provides that allows the user to make a SP game harder. Would you object against those with similar arguments? As a matter of fact, I think it would be in the spirit of this game if by default players wouldn't be able to 'sleep through temporal storms'. So, if it was up to me, it should be optional to be able to sleep through them, and not the other way around.

You're addressing a different subject. And finish with stating the obvious. The fact that sleeping is optional is the reason for my suggestion: to make it a hard coded option in a game to ensure it's no longer optional.

Currently one can sleep through a temporal storm. I think it would be a fitting option to not be able to do so as those warning messages to prepare are in the game for a reason, and preparing for such events and going through them seems to be a signature part of the VS experience to me. So, I propose to add the functionality that blocks sleeping after the message 'a light/medium/heavy temporal storm is imminent' has been sent until the message 'The temporal storm seems to be waning' is sent. Obviously, as not all players would appreciate this, this would be configurable and possibly set to disabled by default. For SP instances this would function in a very straight-forward manner, but for MP games this may require a bit more pondering. As there already are a lot of suggestions regarding sleeping on MP servers I will refrain from going into more detail on that aspect. I'm sorry if this may have been suggested before, but I didn't get any hits for "sleep through" & "temporal storm" in this forum.

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'.

And I'm gone.

Can I please be allowed to contribute to the Wiki? I registered as AlteOgre. Additional question: Is there a communication platform where wiki contributors exchange info on to-do, actions, moderation and other usual wiki related talk? Like a dedicated part of this forum or a dedicated Discord server? Edit: Nevermind, found it!