jerjerje

I don't think the devs have talked about VR support. So probably not any time soon. Maybe once the game is closer to being finished. For now there is someone working on a vr mod. They haven't uploaded anything to moddb yet, though. They have shown some teasers in this thread:

This is wrong. In order to make blasting powder you need black coal. No other coal works in vanilla. Black coal can only be mined by bronze pickaxes. It is not possible to make bombs before bronze*. (Not to mention the need for a bronze anvil to work iron) The only ores you cannot mine with bronze are: meteoric iron, pentlandite (nickel), rhodochrosite (manganese), uranium, ilmenite (titanium), chromite (chrome) - Meteoric iron requires an iron anvil. - Nickel is the only one that could be worth skipping, as this allows you to start making Jonas Tech slightly earlier. But Jonas Tech also requires jonas parts. I don't think most players will have enough jonas parts to craft something with, while in the bronze age. So, I don't think this skip is a problem. - Rhodochorsite and Uranium are useless. - Ilmenite and Chromite require steel pulverizer caps to be usefull. No point in mining them before steel. The only skip here is nickel. But like I said, this isn't really a problem due to the jonas part requirement. *Technically you can buy blasting powder from commodities traders. This allows you to make ore blasting bombs in the stone age. But due to the anvil requirements, you still cannot skip the bronze anvil. This could allow you to get quartz, silver, gold, olivine, cinnabar, black coal and and anthracite without a bronze pickaxe. That hardly seems worth it. You can also just purchase a bronze pickaxe from a trader and mine these ores normally. (You still cannot skip the copper age though, since you need a copper hammer and (probably) a copper prospecting pick, before you can make the bronze anvil)

No? Botanical Fruit has a precise definition: "in botany, a fruit is a ripened ovary or carpel that contains seeds"(Source). This does not apply to all vegetables. For example carrots, parsip, cabbage and turnip are all vegetables without being botanical fruits. Cucumber, Eggplant, Peas, Beans, Bell Pepper, Chili, Zucchini are all botanical fruits and culinary vegetables. As for pumpkins: The wikipedia article on fruits says this: "Examples of botanically classified fruit that are typically called vegetables include cucumber, pumpkin, [...]"(Source). In game they are also considered vegetables. To be clear: The above examples are not "fruits that should be vegetables". They are botanical fruits AND culinary vegetables at the same time. They are simply both. These are not mutually exclusive categories, because they are completely different system of classification. One system cares about the structure of the plant, the other system cares about how the plant is used in a culinary context. These are two different system with different use cases. In Vintage Story these classifications are relevant in two ways: 1. What meals you can cook with the plant 2. What nutrients you get The culinary system of classification is all about cooking. So this system is much more sensible for the game, than the botanical system of classification

This attitude is the exactly what annoys me. Simply put: There are multiple ways to categorize plants. Tomates are bontaical fruits AND culinary vegetables. They can be both, depending on the system of classification used. The game is currently using the culinary definition. So implementing Tomatoes as vegetables makes more sense here. If you want to argue that tomatoes should be fruits in game, than that argument should extend to ALL botanical fruits. A lot of people only know about tomatoes, but there are much more botanical fruits, that aren't culinary fruits. For example: Bell Pepper, Pumpkin, Cucumber, Beans, Peanuts, Corn, and also Grains are all botanical fruit. (Yes, all grains are fruit) So unless you are going to argue that Vintage Story should reclassify ALL grains as fruits, then I see no reason why tomatoes would be fruits either

In my opinion, the temperate climate zones already have enough plant varieties for now. I would love to see more plants exclusive to the tropics and arctic (especially the arctic). Since the roadmap also mentions "Regions of distinct flora and fauna", I would hope we will eventually see large scale differences in the flora when travelling east to west as well. That would be a good way to eventually introduce more plant varieties to the temperate climate, too. Regarding Bell Peppers: I suspect the reason these are not fully implemented right now, is because they are perennial (meaning they live more than one year). The game doesn't currently support crops with multiple harvests, so maybe bell peppers will get added once we get other perennial crops. Note: If you live somewhere where the temperatures drop below 0°C, then bell peppers can only be grown annually. They cannot survive cold temperatures at all. (Fun Fact: All of this applies to tomatoes, too!) (Personally I feel tomatoes could be pretty annoying if added. Not in game, but I suspect the forum discussions on whether they should be fruits of vegetables would be really annoying and never end, lol)

I think it would be great if we got some poisonous berry bushes added to the game. We already have poisonous mushrooms, but all berries are edible! I would like it if there were some more poisonous plants in the game, so you would have to pay more attention to what you stuff in your mouth. Since berry bushes have recently been reworked, now seems like a good time to add these. I do understand that this is a time investment, so I understand if the devs would prefer focussing on other things for now.

You can mine Chromite and Ilmenite with blasting bombs, but you can't use them without steel pulverizer caps. Mining them early with bombs is pretty useless

While I am not against having more content for the Brone Age, I personally feel that Iron and Steel need would need additional content more than Bronze does. Let's take a quick look at what each metal tier unlocks (not counting their respective tool/armor sets): Copper: Pickaxes, Better Food Preservation (via Salt) and Pies, Leatherworking (and thereby Backpacks), Buckets (allowing you to make better Farms), Throughs (allowing the start of proper animal husbandry), Better Storage (Chests, Crates, Barrels), Most Mechanical Power (including Windmills, Querns, Chutes, Grinding Wheel, etc.), Prospecting, not to mention the new decorative options available Bronze: Mining Bags, Quartz and Glass, Bombs, Helve Hammer, Pulverizer, Greenhouses Iron: Beehive Kiln, Waterwheel, Door for Charcoal Pit, Coke Oven Steel: Sturdy Backpacks If I missed something, please tell me and I'll edit the post to add it. From this, it seems to me that Steel in particular could use more content Aside from the (very good) tools, it doesn't give you much additional content to do. Being able to make glass is pretty important for decoration. In my playthrough this is roughly the time I started building nice houses and such. Additionally, bronze benefits from its closeness to the copper age: Since bronze is relatively easy to get (either via tin or via bismuth and zinc), it is likely that many players will reach it before creating everything they unlocked from copper. I would assume most players will still have plenty of Copper Age stuff to do during the Bronze Age (At least, I certainly did. For me the Bronze Age was significantly longer than the Iron Age). Also, I don't think it is particularly easy for most players to "zip to the iron age" (as you put it), because of how rare iron is. I know I was searching for a couple of hours (counting both prospecting above ground and actually digging shafts to try and find the ore). I disagree with this. Iron already doesn't unlock much. And the Beehive Kiln in particular mostly gives more options for decorative items (and mass production of decorative items). Being able to make a permanent charcoal pit is nice, but it doesn't really affect much either. I certainly wouldn't call any of this "paradigm-shifting". I don't think taking things out of the Iron Age would be good for the games pacing.

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.