AlteOgre

Building with readily available, unprocessed, cobble stones is as old as mankind's need for shelter. So is building with lumber, aka harvested wood. Obtaining timber however, is a different ball game. VS offers a decent set of mechanics to simulate that imo. If you'd really want to make a point about the game being unbalanced wrt building realism, you could argue about the lack of required constructive support for blocks made from cobble stones that can be magically applied in gravity defying arches and roofs. Building with lumber could indeed be expanded upon a bit and this has been suggested a few times before, a.o. in this thread. Btw, do note that this does not relate to the topic of this thread.

Eh, so, not if the net time for a player to break an entire block (this lasts a perceivable duration already atm!) is hardly or not affected and it only takes two consecutive actions of aiming and hitting to clear one block instead of one. In that case this concept idea will make mining much more immersive without it leading to unacceptable inconvenience and without it affecting the 'grindy' feel. If you'd then add the (small) chance of getting drops upon breaking rock blocks in agreement with the prospecting mathematics, the inclination for players to just mine long tunnels will be discouraged and they may be encouraged to use local prospecting instead, exactly as intended with the first post. Let the implications of my proposals in the post above sink in for a bit and then reconsider the 3 quotes above.

I'd also like to see a more immersive method to clear rocks and this proposal provides a very nice direction. I pondered about this for a bit and I think I may be able to add some concrete ideas on how to get this implemented and more acceptable for all who may oppose this. First, indeed define just two ways of interacting: 'chopping hits' (the same action used to now break an entire block, but with reduced impact volume, so a series of hits, but with reduced time span to adjust for reduced impact volume, see below) and 'heavy swings' as proposed above (which could be simulated by a few slower, but harder strikes). And second, restrict the number of 'break lines' from bare rock to a very limited number, as to ensure we get optimal immersion at minimal extra cost. Think 'chop off a face, edge or corner' versus break the core / remainders of an entire block. Dividing a block of rock for the purpose of breaking it with a pick or prospecting pick (see below), could be done by defining a limited number of functional actions which will result in breaking of 27 possible block parts (predefined chisel areas) that can be affected by a single action (either chopping hit or heavy swing): The 8 corner parts, each being 8x8x8 pixels in size and upon breaking they give a 'default chance' to drop a single piece of rock (the 'default chance' being equal to current chance for full block divided by 64 (= 4x4x4)). The 12 central edge parts, each being 8x8x16 pixels in size and and upon breaking they give a double default chance to drop a single piece of rock. The 6 central face parts, each being 8x16x16 pixels in size and upon breaking they give a quadruple default chance to drop a single piece of rock. The core part, being 16x16x16 pixels in size and upon breaking, which will only be possible with a heavy swing, and upon breaking this gives an octuple default chance to drop a single piece of rock. Either chopping hits or heavy swings will result in more than one part dropping, dependent on where the hit is aimed at. This results in these 4 functional actions: 1. Chopping hits with a pick on a corner will result in dropping of the corner part and 3 edge parts connected to it, resulting in a 7-fold default chance of dropping a piece of rock. 2. Chopping hits with a pick on an edge will result in dropping of the edge part, the central face part connected to the face where the pick aims at, and the 2 corner parts connected to it, resulting in a 13-fold default chance of dropping a piece of rock. 3. Chopping hits with a pick on a face will result in dropping of all 9 parts of that part of the block, resulting in a 16-fold default chance of dropping a piece of rock. Chopping hits on a corner, edge or face part with already part of the neighbouring parts removed will simply result in less parts being broken. 4. Heavy swings will be able to break the core part of a rock and results in dropping the core related drops. To keep it simple, this will also result in breaking and dropping of all other remaining connected parts. Note that with this proposal, either breaking a face or an edge of a rock block will already result in exposing the core, so players will only need to chop off a face or edge and then take heavy swings at the core to clear an entire block and harvest its drops while the time that takes isn't longer than it is now. This could be combined with the code needed to achieve part of this proposal by @Quentin Preik. The prospecting pick can then be used in a more immersive manner as well. Taking a sample will become either the result of hitting a corner, edge or face. Those picks should ofc not be effective in breaking the core of a block btw. As this will require increased usage of picks, durability adjustments will be needed. It may be worthwhile to make durability loss also a 'chance function' in dependency of the volume of rock broken, using the same maths as used for the drop calculation. To make this immersive way of mining more acceptable, and even more immersive, a chance of ore nuggets dropping from each face and core part breaking could be added, using the same maths as used for the drops of pieces of rocks and for the prospecting. This is proposed in this thread and the notion was triggered by @Omega Haxors himself. Finally, I expect that with the reduction of the number of 'parts' (predefined chisel areas) and the available time the game has to calculate the effect of the possible block interactions (during the player interaction sequence), the impact of this on game performance should be limited. Of course, it could be made more sophisticated by making all described block parts drop individually and successively, but that will come at the cost of player convenience, as they will have to re-aim their pick each time a part is broken and dropped.

Proposal Introduce a small chance of a nugget dropping upon mining any block of rock, with the actual chance and nature of nuggets to drop being dependent on an area 'prospecting result' around that 'one sample block'. Option Combine this with this proposal by @Omega Haxors to achieve a more immersive mining experience by making the use of a prospecting pick result in chopping off a face of a rock. The code required for implementation of this, kinda related, proposal by @Quentin Preik to assist easier chiseling may come in very handy to achieve this. Source Discord #suggestions channel: trigger + post + option.

No way man. The forced night experience is an essential part of the game. Prepare during the day to ensure you can survive the night. Whether that be by torch lit running through the wilderness on scarce provisions to explore in early game or find some resources to bring home, by hunting or by clay forming, cooking and establishing a base with some basic materials you collected during the day. Really. That is the game. Home page quote: "... uncompromising wilderness survival ...". That speaks volumes tbh.

Very nice, fitting addition to the game. A useful application of excess berries as well, especially with seasons coming. Brine is not vinegar ofc, and it may be nice if they would both get different purposes instead of them being interchangeable. Imagine them being specifically used to add to the shelf life of various food types and combined application resulting in the maximum shelf life, dependent on the type of food, and sealing ofc. Hope this mechanic will be part of the vanilla game some day.

Very nice concept! But ... eh ... why the physical appearance of a light image reflective mirror? What's light reflective on a temporal gear? Calling it a 'temporal compass' and giving it a corresponding appearance might make it a little more fitting to the theme imo.

That is a type of option that will only emphasize the differences between the single and multi player experience. I'd personally rather continue with the present system than such artificial 'fixes' to a specific inconvenience (aimed at food decay). But on the other hand, it might just be an 'acceptable' alternative, possibly dependent on the way seasons will be implemented. Still curious to hear Tyron's view on any options btw. What happened on your server isn't unique. More server owners have seen new players join their friends or gamer community server because 'VS is such a cool game, come join and try it out' ... to then leave after a number of unfortunate events / moments of early game frustration caused by the different impact time dependent mechanics have on the server experience when compared to single player. The main issue is that the multiplayer experience is much less predictable because of this and many more 'casual' players simply won't return to an unpredictable game, even when it involves their friends, family or gaming community. Instead, they will seek out 'easier' alternatives for their casual entertainment. The investment of € 15 is relatively low and can easily justify a quick 'nope' for many players who are a bit less determined than the average present VS veteran. For the game (including an active, supportive and cooperative server community), to remain successful until and after beta launch, I think that keeping new players who enjoy the multiplayer experience may be key.

The temporal distortion caused by temporal storms is temporary and only lasts as long as the storm causing it lasts.

More realistic would imply introduction of a 'cylindrical multi-block windmill head on bearings' that the player could turn in the horizontal plane in order for the wings to face the wind wherever that comes from, by manual (or beast of burden) force. Ye, if the wind direction would become variable. Ideally ... realistically ... if ... but it's a game.

Odd proposal. A spear-thrower aka atlatl is in fact designed to enhance speed and consequently range of a launched spear/javelin/dart. If implemented I'd expect it to result in higher piercing damage and longer range (requiring to aim lower than without the throwing device) at the cost of 'loading/charging' time and the limitation of no 'auto-recharge'.

Mentioned subjects have been discussed in Discord on a few occasions, but there is no thread here mentioning these. And as the game now has vertical slabs, I think there may be good reason to reconsider the introduction of both wicker fences and wattle-and-daub walls as flavour adding, theme fitting additions to the overall game experience. Concrete proposals: Add wicker fences and gates that can be placed in the same fashion as plank based fences and gates. Both would also have the same block height, but the wicker gates would only be an effective barrier for animals, not for drifters. That is, they would 'automatically switch to open position' when a drifter comes within the hit box of the gate and drifters would perceive them for their path-finding AI as if they were grass blocks or similar (hoping this will be possible). The recipes for each would be the following: Wicker fence: 6 sticks in the lower 6 slots plus 4 reeds in the top center slot to produce 6 wicker fences. Wicker gate: 4 sticks in the slots to the bottom and center left and right plus 2 times 2 reeds in the bottom and center middle slots to produce 1 wicker gate. Add wattle wall (elements) with the qualities of vertical slabs and only placeable as such. They have a slight 'see-through' texture: light partially passes through them (like, doubles the light intensity reduction per block) and both predatory animals and drifters will be able to notice a player on the other side of these wall elements. Their recipe: Wattle wall: 1 wicker fence in the central slot plus 2 sticks above and below that to produce 1 wattle wall block. Add wattle-and-daub (wall elements) in two variants: a vertical slab and a full block. The properties of these are similar to plank blocks of comparable size. Their recipes: Wattle-and-daub single wall: 2 wattle wall elements in the central slot plus 1 cob block in the slot to the right to produce 2 wattle-and-daub single wall blocks. Wattle-and-daub double wall: 2 wattle-and-daub single wall blocks next to each other to produce 1 wattle-and-daub double wall block. Would be nice if it would be possible to also create them by placing a wattle-and-daub single wall block in the same block space as an already placed wattle-and-daub single block. Make the wattle-and-daub double wall blocks reinforcable with the plumb and square, but only with a very limited number of materials. Any type of stone, brick or metal should not be effective. Make the wattle-and-daub wall blocks 'paintable' with a limited number of dyes after placing them. The 'vanilla' blocks should have a 'cob' like appearance, but application of specific dyes will change that on the face where it's applied. This may be done in the same fashion as the way salpeter deposits are placed in the world. Upon breaking of a dyed wattle-and-daub wall block the paint (plaster) layer will dissappear. Proposed dyes: Lime, blue clay and fire clay. Applying these to a wattle-and-daub wall block results in layers of plaster with colour schemes that are mixtures of cob and the used powder. Specific lime types created from the various sea shell types available in the game, if ever they will be added. All will have their own specific hue variant. I hope these will be considered for a future update as I think this will greatly enhance the options for early game building and they will add a lot to the flavour of various, more utility like, builds. Any constructive feedback is this thread appreciated and may be used to further improve the above proposals.

Wow. Original, specific and concrete.

Nice work. It think the vines climbing should be included in the vanilla game.

Whoah, surely making a lot of vintage quality immersion improvements there! All fit to ensure players will love the game for many years to come, get inspired to create mods, expansions and numerous of their own or adapted vintage storylines, and spread the word to invite many others to enjoy numerous varied single and multi-player worlds and adventures, with friends and future friends and friendly foes. Do take your time and enjoy the quality of real life besides this life project ... while pondering which faces and edges of your marvellous shiny gem to work on before it will enter the world as a brilliant beta. Cheers!

Proposals 1) Add a recipe to use bonemeal instead of quicklime for the creation of slaked lime (for mortar). Instead of quicklime, bonemeal can be used in a barrel with water to get a mixture with properties fit for mortar preparation. As bonemeal contains less calciumoxide than chalk- or limestone (notably more fosfates), it would seem justifiable to make slaked lime from bonemeal require a little more calcium containing compound 'volume' than slaked lime from chalk- or limestone would require. A liter of slaked lime would then require a liter of water and 6 'units' of bonemeal. Optionally, bonemeal may be used to only partially replace quicklime to create slaked lime. For that purpose a recipe could be added that uses 3 units of quicklime and 2 units of bonemeal to create a liter of slaked lime. This may be more realistic, but also be a bit too circumstantial and partially undermine the motivation for this improvement proposal (see below). It's a game after all. 2) Add an extra conversion step to create bonemeal ash as intermediate product by 'baking' bonemeal in a firepit so the resulting bonemeal ash has increased calciumoxide content. In that case a recipe for slaked lime from bonemeal could then require 5 'units' of bonemeal ash per liter. 3) Add a recipe to use bonemeal ash instead of quicklime for the creation of plaster. If bonemeal ash would be added, this product can directly be used instead of quicklime for plaster preparation. Bonemeal ash contains less calciumoxide than quicklime, so it would seem justifiable to make plaster from bonemeal ash require a little more calcium containing compound 'volume' as plaster from quicklime would require. Two blocks of plaster could for instance be created from 2 blocks of sand and 3 units of bonemeal ash. Motivation Use of bonemeal for these purposes is a real practical possibility as the functional use in both mortar and plaster can be derived from the bone calcium content and composition. Practical realism might make the final product be of different quality because of the bonemeal composition. This may justify creation of different quality products based on the bonemeal content in the ingredient mix (pure bonemeal mortar can result in reduced strength properties, but only partial replacement of quicklime in mortar can even lead to improved mechanical properties of the final product) ... but that may also just be something to be considered in a later stage, if ever. It adds to the variety of development options players have by having additional routes towards specific products. Limestone and chalkstone can prove hard to find for unlucky players in both sp and mp worlds, so bonemeal may be an interesting alternative resource for them. At some point in the game players may find they have excess bonemeal and/or a lack of other sources of lime. Both in sp and mp, players may simply end up with maximised agricultural output and a pile of bones they have no application for. Introduction of seasons may result in revaluation of bone meal as a fertiliser though, but still, any end-game optimised farming and livestock business will eventually end up with a nett output of bones. At the moment this is especially valid for servers. On servers the progress of time continues while players are absent, which results in rapid crop growth and soil refertilisation. This makes the functional use of bonemeal for fertilisation of farmlands much less valuable. Result is that the effective application of bonemeal for soil (re-)fertilisation is devalued and players leave more bonemeal unutilised.

@Stroam, thanks for the radical input. Let me first respond to your use of the designation 'wrong' before I get to 'reasonable' and finish with assessing your radical alternative proposal. Qualifying expectations as potentially 'wrong' in this respect is not appropriate imo. A qualification of 'different' would be totally acceptable though, so I'll assume that is the point you were addressing. Ultimately, what the developer thinks about what players of their released mp game version should expect, will become the standard. Alternative expectations may be designated 'wrong' going by that standard, but as the game is still in alpha, and some major multiplayer experience affecting mechanics have only just rolled out, I'd recommend to not use such 'framing' qualifications in this stage. Note that one could also qualify the current implementation of time progress in multiplayer VS as 'incomplete/imperfect' or even 'wrong' by stating that the system lacks a player AI character when the player is not in-game. Such an AI character would eat the foods a player prepared while they are away, restock any food supplies, tend the livestock and acres, replace any torches that burnt out and meanwhile fight off enemy mobs and animal competition for his food sources while reaping the fruits of their labour. An example for such an alternative multiplayer experience is detailed out for the 'offline player characters' in Chronicles of Elyria. I discarded the option to add 'offline player characters' as 'likely unfeasible' and 'serving an overall different purpose'. I didn't see that as a reasonable alternative when considering the proposal brought forward in this thread. So, I'd rather wish to designate alternatives as 'different' multiplayer experiences instead of 'wrong'. Until a beta-release all sets the main mechanics in stone, it would be best to focus on the differences between options that are on the table in terms of benefits and costs when assessing them for their impact on the total potential player base. And ultimately, it's on the developer (team) to decide which experience best fits the game they intend(ed) to turn into a viable business. Now on 'reasonable'. Indeed, VS progress is tied to one clock and that should be the main starting point for the multiplayer experience. I may not have explicitely expressed that in the first post, but that is a starting point for me as well. Whereever players in a multiplayer world gather and either work with or against each other, that should be a primal mechanic. Now I believe the change I proposed does not negatively affect that experience. With the proposed changes the multiplayer experience for most veteran and cooperative players on servers will hardly change. The progress of time in any intensely used combined player food production, processing and storage area, and that of any other time dependent mechanics in areas where more players are active will still be in agreement with that primal starting point. For new and more casual type of players on servers the changes will have a much more noticable effect in that their experience will much more resemble the single player experience. Investing in long term food storage, animal husbandry and improved farmland productivity will be meaningful on a server just as it is in their sp worlds and they're not 'forced' to continuously adjust their in-game priorities for having to take into account that time progresses at tremendous rates before they log off, whether that be for a few hours in early game, or for a working week in late game. No, it would not be reasonable for new players on servers just trying out this game to expect that the multiplayer environment behaves in exactly the same manner as the single player environment. That is not a starting point for my improvement proposal and I don't think it's reasonable to assume it would be. Nor do I think it would be a reasonable expectation that VS would implement an 'offline player character' mechanic as mentioned above to counter the inconveniences of progress of time when they are offline. But I would think it is reasonable to expect a developer to consider potentially feasible options to improve the multiplayer experience for many of their potential new customers, those who can effectively expand the playerbase and business volume. Now on your radical alternative. I think you provided enough (implicit) arguments yourself to counter that as a potentially acceptable alternative, going by those presented in the first two paragraphs of your post. Your radical alternative is not an acceptable alternative option for the proposal brought forward in this thread as it goes against some basic starting points regarding the multiplayer VS experience. Within the scope of this concrete and specific thread the aim is not to ensure full single player experience in a multiplayer environment. So as an alternative to my proposal here, it would simply miss the point. Creating multiple single player worlds instead of one multiplayer world, would create an entirely different multiplayer experience, even more different than the one with 'offline player characters' I just referred to. In my view it is implicit to 'multiplayer' that all players share the same world, and even though I may have not explicitely expressed that, I believe it would be reasonable to assume that was the case. Moreover, I would guess that any multiworld-multiplayer option would not be feasible in the context of the VS business because the potential nett effect on the total active player community will likely concern small numbers, and the obvious related coding efforts and server expenditures will be high. So, just as the proposal to add offline player characters to the VS multiplayer game would be unreasonable and unfitting within the scope of this thread, your proposal to have multiworld-multiplayer servers would not be an acceptable alternative either. Finally, one could easily argue that both radical alternative options simply serve different purposes than the proposal central to this discussion thread.

Ye, well, that will tackle a small part of the issue, a part mostly experienced by new players on servers during their early game exploration and early settling efforts. It doesn't tackle the issues for more casual players finding their processed foods rotten after a long week of real life work, or for any player who had to stop playing before they planned to and when they return all their freshly harvested bush meat or berries, or cooked roots have gone to rot, nor the fact that any time dependent process on servers can hardly be experienced in the same way as in single player (... like what is the added value of Terra Preta on servers anyway?). Yes, food decay is the process new players on servers have most difficulty with dealing (not because the process is a thing, but because time progress while absent is a thing), but no, it is not the only major difference between the multiplayer and single player experience affected by the different ways servers and single player games deal with the progress of time in a players direct environment. It only requires a few additional stored data and checks to the already much valued and code-effort requiring various processes in the game to ensure mp and sp experience are more comparable, making the game more enjoyable and immersive for both new and casual regulars on servers.

Note that 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. It also occurred to me that many veteran server players have already been active since before the introduction of various time dependencies so many of them have in fact hardly experienced to what extent the player-independent server time progress affects the early game experience. Just something to keep in mind for anyone considering the issue brought forward and the proposal on how to improve the game to deal with it. Adjusted the first post accordingly.

Chances of finding such rares items are simply very small, most < 1%. I think I got a TG once, a few pieces of jewelry, some metal scraps, metal gears, a few gold nuggets and a nugget of lapiz lazuli from a total of about 8 stacks I processed in my SP game and on 2 servers I played on in past months. All fun surprises to get as by-products from an otherwise tedious task in early game. At some point panning isn't that useful anymore but it can provide a nice distraction, especially if you don't fancy fighting drifters during a temporal storm. The quiet of a panning spot in the middle of a lake can be a quite relaxing and effective way to pass the time while a storm passes. I always keep a stack of gravel or sand in stock for such occassions.

After about 6 weeks of intensive playing and especially experiencing the early game both in SP and on servers, I think I may be able to throw in 50 cents in this conversation. It may be that my insight will change in the course of coming months or years. If so, I will update this post and bump it in some way if deemed relevant enough. Here's my current view on VS and its priorities for further development. First, my view on short term priorities, as expressed in Discord in two messages (1 & 2) : In the current state I think it's wisest to prioritise enhancing the appeal for new players, both in sp and mp, in order to gain a broader playerbase and expand server and modding communities. That would imply focus on enhancing exploration with more environmental features (flora, fauna, food sources and chains, organic resources, and structures and NPCs + interaction), and enhancing early game experience with more alternative (not easier!) ways to get going on your first explorative adventures in both sp and mp. I think it's not of much use spoiling the veterans in the community yearning for more end-game content as that need can already (at least partially) be catered for by the present modding community. Think addition of trees/bushes like yew, juniper, beech, walnut, chestnut, almond, hazel and holly, and vines for an alternative for twine, the possibility to create wickerwork for simple walls and wattle and daub, fishing and trapping, more herbivores and carnivores, herds, birbs and fishies, more significant inland seas, simple canoes or rafts to navigate larger bodies of water, mast as additional food source (proteins, in season!), additional edible roots (yam, cassave, peanuts), usage of resin and/or rope to reinforce tools as to enhance their durability, fruit trees, orchards with an orcharder, acres and pastures with a farmer and a simple shack, traveling NPCs like hunters and herders, maybe even bandits, various other small, humble structures of fellow survivor NPCs, possible animal companions like jackdaws, geese and small dogs, horses, donkeys and mules, etcetera. All additions that spice the early survival and exploration game and both broaden and deepen the experience for new players. Needles to say that anything added to enhance the early game will also have added value to late game, through various recipes and mechanics connected to later development stages, whether that be via adjustments/additions in the vanilla game or through the creativity of the existing modding community. Second, my thoughts on 'When will VS be finished for beta-release?': Realisation of a significant part of an early phase experience expansion as described above. This to ensure the game attracts a sufficienlty broad audience that actually keeps on playing in both new sp and mp worlds (multiple server activity) because they enjoy the early phase of the game because of its attractive diversity. Improvement of the early game experience on servers in line with these two suggestions, both aimed to ensure it will be appealing for players to try out new servers, to broaden their horizon, expand their network within the VS community and feed new initiatives for servers and mods, which on their turn serve to expand the VS player community (and business!): Progress of time reference: world-chunk-player Options for server management to ensure pleasant new player experience Expanded the 'lore' of the game and the rewards related to unravelling it in-game to such an extent that most players experience a persistent urge and joy to keep exploring the world until they discocered it all, even after they fully completed the technology development tree and started building and chiselling their ass off. Made sure that creation of mods/modpacks aimed to create alternative Vintage Stories are sufficiently supported with the mods API. Relevant features to think of in this respect are: Easy VS modding through adjustment of anything that does not require code modifications: textures, speech banks, item names, recipes, addition of structures, NPCs and interactions, and similar features. This also enables the less gifted coders to modify the game in order to create their own 'Vintage Story' based on the foundations of the vanilla game. World generation alternatives like alternative biome configurations, additional flora, fauna and structure types, and additional NPCs. Preferably also supporting some form of 'map based world generation' in the same manner as that was done for the LOTRmod for Minecraft. This enables modders to create their own fantasy worlds, which can tremendously broaden the storyline options for players in both sp and mp to enjoy. As noted, I may get some more/altered insights later on, but for now, this should do. Hope this may help a bit in getting this already great game and brand reach new heights. Cheers!

Joining a server for the first time can be a very unpleasant experience for new players. The experience can be much different from that in single player in various ways (a.o. the progress of time). In this suggestion thread I wish to focus on the first in-game day or days of playing on a server. I want to address the fact that when a new player joins, they tend to be in urgent need to gather a lot of stuff that can help them settle for a safe passage of the night and/or go out on their first main adventure, to find a nice place to settle. This first experience can be quite hindered by the fact that players cannot see whether it is dawn or dusk, day or night on a server before they join. Also, a heavy temporal storm could just hit the moment a new player has just gathered their first resources to craft something simple as their first axe. It would be very helpful to ensure new players aren't set back too much from their first attempts to join a server if server management could have one or more of the following options at their disposal: Show in the server listing info what the time of day is on a server. The format for the displayed info could be made customisable for server management. As soon as 'seasons' are implemented, season info may also be very useful for new players (any player) to have in the server listing info. Make the server time of day get adjusted to dawn as soon as a player joins the server for the first time. The exact time could be made customisable for server management. Make the temporal progress timer reset as soon as a player joins the server for the first time. I'm not sure what variables need to be considered for this, but I can imagine the exact 'shift' could be made customisable for server management. Provide new players with essential gear, a.k.a. a 'starters kit', as soon as a player joins the server for the first time. Server management obviously would want to be able to provide new players with anything they think fitting, including armour already donned, and mobile containers possibly already filled. All dependent on how they and their community would want a new player to experience their server. With seasons, a season dependency may also be desirable. More favourable seasons may require less of a starter boost than a fresh start during the dark of winter. ... Some of these options may have been suggested before and there can be more options to be considered for this purpose. I just wish to list them here and want to stress that whatever may get implemented of these options (if any) they should be considered as 'options' for server management to decide on using for their specific purpose and use any related settings at their own discretion. The view of server owners/staff/communities on how their server best be set up can differ quite dramatically. I'm curious if there may be additional options the VS team could consider for this purpose. Please do not hesitate to add any in a comment below, nor to provide any other feedback on the above. Note that this excludes any options like 'provide a pleasant spawn environment with plenty of food and what-have-you', because that is obviously already an option for server management.

In addition to the guidelines already provided above, based on experience of moderating thousands of suggestions for the LOTRmod for Minecraft, I wish to suggest the following : Urge people to: only post concrete and specific suggestions. Concrete as in addressing the what, why and how. Not just "Add edible nuts to drop from some trees", but provide information on which trees, under which circumstances and give an indication on how many, how nutritious they could be and if they could be processed or have other further uses. And specific, as in no wish lists on collected random, unrelated topics. stay on-topic in suggestion threads and in their original posts. Good on-topic feedback and discussion may lead to deviations and derivations that can initiate other new useful suggestions, so don't be too strict in it. Avoid derailing though, as that is counterproductive to anyone with an interest. not hesitate to update original posts with any valuable insight gathered, whether that be from feedback obtained in the thread or elsewhere. focus on suggestions to improve current features and/or well fleshed out suggestions regarding (explicitety stated) planned features. Create and maintain a What-not-to-Suggest (WntS) list, which may include: anything mentioned in FAQ or planned features posted by or on behalf of the developers. any subject specifically listed in the WntS list. anything that first requires planned features to be implemented. easter eggs of any kind. They're the developers joy. any imaginable real life addition unless of specific potential added value to the existing, and planned features. Vintage Story is a game with limited scope, a creation of its makers who can draw near limitless inspiration from the world. They don't need players to cough up the obvious and spam either this forum or the Discord #suggestions channel. The more noise, the smaller the chances developers will notice any useful gems hidden in the suggestion flood. anything too obvious. Possibly consider active moderation and/or record keeping of categorised subjects where the records are available to anyone and to be referenced by anyone considering to add a new suggestion to the bulk. Yes, that would require dedication.

Ye, good idea. Just put "Add the world" on your to-do list, Tyron. Who would have thought of that? I sure hope he will gradually add some more flavour in various ways, but please don't expect the world.

Ye, obviously, what Sengorn_Leopard says. Until that time, practise your spear throwing skills early in the game, and use the terrain to your advantage. Happy hunting!