jerjerje

I never really thought about it like this, but I definitely agree. This would be such a good change. It would certainly take some time to get used to it, but I think this would be a lot better. As a neat side effect, this would also remove the chance of accidentally picking something up from ground storage, when trying to place blocks. I had that happen, quite a bit in my play through and it was always annoying. Occasionally I also had moments where I forgot what exact key combo needed, and I just had to try all of them until it worked. This system would be a lot easier to remember. I hope this gets added to vanilla at some point. I can think of two small edge cases: 1. Equipping mounts: Adding equipments to mounts can just be done via right click. But for unequipping with left click, there would need to be some safety margin, so you don't accidentally punch your elk. Slightly missing the hitbox of the equipped item, should not cause you to hurt you mount. You won't usually want to punch your elk anyway, so this could likely be resolved relatively easily. 2. Using ropes on animals: The problem is essentially the same as with case 1. When removing the rope with left click, the "remove rope" operation should have priority over punching the animal. Neither of these cases are hard to resolve, but I wanted to have them mentioned, since they weren't mentioned in the post.

I like this idea. As long as it isn't available by default, this could be some nice customizability. Both for making parts of the game easier, if desired, or for even harder challenge runs! Since it wouldn't be available by default, it wouldn't really need to be balanced either. Would be a cool addition, but likely be a priority for the devs. For now this would likely be better as a mod. In fact, there is a mod for this: https://mods.vintagestory.at/sonitodynamictraits For it to work as you described, you would have to change the point config to be higher, so you can buy all of them. It also seems to need some additional config file, so all vanilla traits show up. I don't know how it interacts with modded traits though.

I generally agree that the current dungeons could be more interesting, but I can think of two reasons for why the devs might have wanted it in this update. (Note: This is purely speculative) The first reason: Maybe the devs didn't want to have yet another thing be postponed. We already had rivers and the status affect system postponed to a future update. Maybe the devs simply didn't want to have a third thing be removed from the roadmap. I could easily see players get annoyed at that. The second reason: Bugs! With a system as complex as procedural dungeons, it can be very difficult to account for all edge cases. There are so many variables that the dungeon generation can break in many unexpected ways. By giving modders access to this system before it's used (much), the devs can solve a lot of bugs before they become problems for vanilla. This is especially important since dungeons are a part of world gen. A dungeon that spawns broken won't be fixed by future updates! So it's important to get this right the first time. Overall I definitely agree that it's good the procedural dungeons made it into the update at all. I'm looking forward to seeing what they do with the system in the future.

I would like to make a suggestion to slightly alter the file structure for dialogue JSON files to make it easier to use JSON patches on them. Currently, these dialogue files look like this: { "components": [ { "code": "testhasmet", "owner": "tobias", "type": "condition", "variable": "player.hasmettobias", "isNotValue": "true", "thenJumpTo": "firstmeet", "elseJumpTo": "welcomeback" }, { "code": "firstmeet", "owner": "tobias", "type": "talk", "text": [{ "value": "dialogue-tobias-donttakevisitors" }], "jumpTo": "continuefirstmeet" } ] } We have a long list, that contains all the dialogue parts. When you want to patch one dialogue part from this file, you have to count which index in the list it has. (The above file is only a small excerpt. The full file has 115 elements in the list.) This is firstly quite tedious, and secondly has a lot of potential to get silently messed up. This could happen either through a game update that changes the file, or also when multiple mods try to patch the same dialogue file (Particularly since you cannot guarantee mod load order, except through dependencies). My suggestion for changing this would be to make use of the "code" component each dialogue part already has. We can remove the list, and instead use this "code" as the key for each element. Here is the above file rewritten in this manner: { "testhasmet": { "owner": "tobias", "type": "condition", "variable": "player.hasmettobias", "isNotValue": "true", "thenJumpTo": "firstmeet", "elseJumpTo": "welcomeback" }, "firstmeet": { "owner": "tobias", "type": "talk", "text": [{ "value": "dialogue-tobias-donttakevisitors" }], "jumpTo": "continuefirstmeet" } } In this version of the file, you can now patch each element directly using its key. This is easier to use and much less likely to break. Currently, the dialogue always starts at the first element of the list. In the new system, this could be done by having a required dialogue part with "start" as the key. Of course, implementing something like this is in no way a priority. But, I hope a change like this could be added at some point.

This generally seems like a sensible approach to generate rivers. But I don't think it would work well for a game like Vintage Story. (Assuming I understood your idea correctly. Please correct me if I misunderstood something) This is mainly, because Vintage Story doesn't generate the entire map at once, it only generates singular chunks at a time. More precisely: Your idea always starts generating the river from some "head". This may be fine, if the player first generates the chunk in which the head is located. But what if the player first loads a chunk in the middle or at the end of the river? How would the game know that there should be a river here? A naive solution to this would be to always generate chunks with rivers outside the normal render distance. However, this could very easily be a performance nightmare. The further rivers can flow, the further away the game would need to generate all rivers. I don't think this would be feasible performance wise (unless you only allow rivers to be very short). Figuring out how to generate large scale features like rivers is always a problem on these infinite open worlds. I'm definitely interested in seeing how the devs will solve this problem in Vintage Story.

As an optional difficulty option, this seems like a very cool idea. But, I do see two main problems with this system. 1. Performance: A system like this would likely be quite performance intensive (particularly on servers). It might be possible to implement it with acceptable performance, but it would take a lot of development time to optimize this. 2. Development time: This system would have to be very complex to functions as you described. Implementing something like this would take a lot of development time. Just the new assets that would be needed are immense (The player would need to see that blocks need repairs, so pretty much every player build block would need to have broken states (preferably multiple broken states to show how broken it is).) And that's not to mention the time it would take to implement this system in code! The implementation, too, would be very time intensive. The needed development time is my main reason why I don't think the devs should implement this right now. I would prefer the devs deal focus on other things first, instead of spending this much time on an optional setting. With that said, though, I could see the devs implementing more optional challenges like this when the game is more finished (or maybe even after the game has left early access).

It's true, the RSS feed isn't linked anywhere. I was able to find it using the browser extension Feedbro for Firefox. The extension has a "Find Feeds in Current Tab" button, that automatically tries to locate all RSS feeds on a page. Using this while on the Devlog page, finds the correct feed. (It should work on the News Forum, too) If you need the RSS URL, it is: https://www.vintagestory.at/blog.html/?rss=1 There are many websites, that have RSS integration, but do not link it anywhere. For example, these include Reddit, Bluesky, any mastodon instance, etc.

I don't actively check the devlog, I have set it up to check automatically. For the News Section on the Forum, I just use an RSS Reader to notify me of updates. For the Discord, I use the Follow Feature to send any Posts from the "devlog" and "news" channels to a Private Server I made. This way I don't have to check anything myself and just get notified whenever something is posted.

Well the dev stream that is (as of posting this) still online was announced as "we are building the final version of a dynamic dungeon that'll (if all goes well lol) will be in 1.22!". So it seems procedural dungeons are already quite far along.

This isn't really true. Some alcohol is lost, but far from all of it. How much alcohol remains heavily depends on the cooking method. To Quote the Wikipedia Article Cooking with Alcohol: alcohol added to boiling liquid and removed from heat: 85% alcohol retained alcohol flamed: 75% alcohol retained no heat, stored overnight: 70% alcohol retained baked, 25 minutes, alcohol not stirred into mixture: 45% alcohol retained baked/simmered, alcohol stirred into mixture: (see table) Time (h) Alcohol retained[5] 0.25 40% 0.5 35% 1.0 25% 1.5 20% 2.0 10% 2.5 5.0% So depending on the cooking method, a lot of alcohol can stay in the meal. That's very important for people who can't eat/drink alcohol at all! But the quantity of alcohol used in meals tends to be (comparably) low. That is why most don't tend to get noticeably intoxicated by it. So it does make sense that you wouldn't get drunk from alcoholic meals in game. Remember that seraphs always drink an entire liter of wine at once. From that, it does make sense to me that you would be drunk very fast. As for the actual point of this forum post: I unfortunately only have two ideas for additional uses: 1. Alcohol inhibits the growth of bacteria. So adding it to a meal, would allow that meal to last a lot longer (Source (Source is in German) 2. Alcohol (Aqua Vitae) can be used as a fuel source. This could be implemented as a new type of stove. I'm not sure if this would really be helpful, though. Maybe sprinkling some alcohol over a fire pit could temporarily increase the heat of the fire pit and allow ingredients to get to temperature faster? Reading through the Wikipedia article for Ethanol and Alcoholic Beverages, I couldn't think of any other real life use cases that could be implemented.

Rivers in real life tend to carry sediment with them. I suggest that (if and when rivers are added) we could use rivers to find out what (sedimentary) rock types exist upstream of the river. I’m first going into how this system would work and then how it would improve gameplay. Finally, I’ll explain a rather massive problem, that could potentially prevent this system from ever being added to the game. 1. How would this system work Using either a sieve or a wooden pan on the riverbed would allow the player to see what (sedimentary) rock types the river has flown through. Rivers (mostly) carry sedimentary rock types, thereby other rocks likely shouldn’t be shown. The easiest way to display this information would be via a chat message. For example if the river had crossed a sandstone, a bauxite and a claystone biome upstream, then the chat message could look like this: Found traces of Bauxite, Claystone and Sandstone Optionally the chat message could also mention how much of each rock type was found. The further away the rock type is, the lower the concentration for that rock type would be. For example if the river had crossed a sandstone, a bauxite and a claystone biome upstream (in that order), then the chat message could look like this: Found 3 rock types in this river: High Claystone Poor Bauxite Minuscule amounts of Sandstone 2. How does this improve gameplay Currently, it is common to see posts on the forum where players ask for help finding bauxite and lime. There are also many posts complaining about how hard these can be to find. This system would allow players a (limited) way to search for specific rock types further away from them. If you get a reading for limestone from a river, then you know that this river has definitely crossed a limestone biome before. So you just need to follow the river upstream, and eventually you will find limestone. I am assuming rivers will be able to be many thousands of blocks long, so it may be quite a journey to get to the limestone. Currently, your only chance of finding limestone and bauxite is by walking around aimlessly until you stumble upon them. It can happen that these rocks don’t spawn very close to spawn or that you simply haven’t walked the correct direction. Since this system would allow you to check rock types at a distance, this would massively reduce the RNG aspect of searching for a specific rock type. Even if you can’t find a river with the rocks you want, then you still know that you likely won’t find the desired rocks upstream of the river, so you don’t need to search that direction. 3. The big problem with this system When it comes to programming, the question is never whether it is possible to implement, but whether it is possible to implement with good performance. Unfortunately, this system I propose may be impossible to implement without destroying the games' performance. In order for the river to know what rock types it has flown through, the game would have to generate the entire river at once. This is, to put it mildly, not feasible performance wise. The amount of chunks this would need to generate would be absurd. Of course, you don’t necessarily need to generate the entire chunk, only the parts necessary to know the position of the river and the rock types would be needed. But this may still be much to complex for the game to handle. However, I don’t think it is possible to definitively say whether this system could be feasible or not, right now. We don’t even have rivers in the game yet, so we don’t know how complex they will be. (That is assuming that we will get rivers at all). I would love to hear your thoughts on this suggestion! If you have knowledge of procedural generation, I would like to hear your thoughts on the feasibility of this system. Can you think of any good performance optimizations?

I definitely don't think a generally usable booster should be implemented, but I think there could be a way to implement a booster with enough limitations, that it wouldn't be overpowered. My idea would be to make this booster a block that would launch you upwards. This way, the booster would be limited to the spot you place it in. You couldn't use it and also take it with you, and you also couldn't use it while in the air. If the block is pricey enough to make (e.g.: requiring jonas parts) you also couldn't just use them for general purpose travel. This booster could then be used to quickly reach areas close to your base with the glider, (You would still need to walk back home, though) without trivializing large scale travel. If you're willing to invest a lot of time grinding the materials, you could build enough boosters to cover larger distances, too. That would likely not be feasible in singleplayer, though. I think this would be a decently well-balanced addition. Particularly since you can achieve the same thing (albeit with a slower ascent) with just soil and ladders. It would just be a faster (endgame) method to get height, without requiring a very tall pillar in your base.

Ultimately, this is an early access game. Both nerfs and buffs have to be expected. The devs for this game have frequently patched out unintended behaviors and I don't see why they would stop now. I never heard of this ice elevator before reading this thread. After some research, it doesn't seem like this is a very well known trick. Looking on YouTube, I was only able to find one video on it here. The video only has 3k views. It doesn't seem to me that the vast majority of the playerbase was even aware of this. Additionally, the creator of the video tests the speed of the elevator (at timestamp 3:55) and it doesn't even seem that fast compared to the elevator without ice. But aside from that, this is clearly unintentional, so it was bound to be patched sooner or later. The hyperspeed mechanical power contraptions and the physics-defying quad windmills have always seemed unintentional to me. I figured they might get patched at some point. Aside from that, the patch notes clearly state "We hope to still add to 1.22.0, second tier, sturdier mechanical power parts to counteract this change", so the devs literally want to add a way to reduce this problem. Additionally, they added the large windmill, which can likely be used to replace the previous quad windmill designs. Though, I haven't tested how much mechanical power the large windmill produces compared to the previous quad windmill. It feels really weird to me to complain whenever the devs remove unrealistic features, while they are also adding ways to make similar things in a more realistic way. I don't see any issue with these changes. There is no logical reason you couldn't hammer iron and steel into a spear, so it makes sense to add them. Unfortunately, game balance is a thing that must be respected. The devs felt that iron and steel spears would have been too powerful, so either they never add iron and steel spears (and there are constant complaints and suggestions about them) or the devs add them, but nerf the previous spears (might cause temporary complaints when this one update comes out). Personally, the nerf for previous tiers seems like the best choice.

The "Micronutrients" Bar you suggest sounds similar to this mod: https://mods.vintagestory.at/novelty But generally I don't think the nutrition needs to be more complex as it is. What you're suggesting might make for an interesting mod, but I don't think vanilla needs that complexity. I would say the current system is a good balance between requiring players to eat a varied diet, while also being simple enough to be easily understandable.

While a full set of black bronze gear is unrealistic, you can make at least one or two pickaxes for the faster mining speed. That could be worthwhile when searching for iron. I wouldn't go out of my way to find gold and silver for this. But since you can get both as a byproduct of mining quartz or panning, you might have a few nuggets lying around. And you don't need much gold and silver to make a couple ingots of black bronze. (See the ratios on the wiki).