radfast

My mistake, I've edited my post now

Regarding the future direction of the game, really it's all very well set out in the Development update. We are actively looking at adding some new mechanical power components to give players more options and scope for creativity and interaction, while staying in keeping with our mediaeval themes and our own rich lore. Personally I find any new mechanical power contraption exciting. We are actively looking at adding rivers, it's surprisingly complex to do them well and realistically in our style of world-map. The game is designed to be easily moddable with a comprehensive modding API and build-in mod manager and mod database and other modder support. The amazing mods people have made form an important part of the game's full potential. We certainly do not see any mod as a criticism of the base game - the opposite, really.

BMiBudzYT has been restricted from further posting, due to repeated violations of community standards, and a previous warning a week ago. Community standards require that the discussion is kept civil. Name-calling and personal attacks should form no part of civil discussion. I have removed what seemed to me the most offending and unnecessary posts, while retaining some of the posts to keep the overall flavor of the thread. We do not censor valid debate about the Vintage Story game and its future direction. It's okay to have different opinions and express them, and it's okay to write that some parts of the game currently are not what the individual poster expected or wanted. If anyone is significantly offended or upset by a post which remains, please do use the reporting system to report it and we can review again. Congratulations to all who helped to keep the discussion civil and on-topic. In general if this ever gets so heated again, I would suggest simply do not respond at all to individuals who seem like they are trying to be inflammatory. (And the Report button will get team attention, although it may take us a few hours to get to it)

@Pawels nobody from the dev team has the hardware you are using, I would not like to say whether the game should work on such hardware or not. In principle: the game is well-tested on common PC and Mac hardware (Intel, AMD, and Apple Silicon) we do not currently make an ARM64 native code version of the game, we hope to do that in future, it will be dependent on availability of some of the libraries we use we use many components of .NET 7 runtime (game versions up to 1.20) or now .NET 8 runtime (game version 1.21+). As a sophisticated multiplayer game written in C#, could be said we test .NET runtime to its very limits. .NET runtime is supposed to be cross-platform of course, but it may be that the .NET runtime is bugged on your hardware, especially if having to use a compatibility mode I do recommend try game version 1.21, and try updating .NET 8 runtime for your specific hardware, maybe Microsoft found and fixed some bugs Having made those general points, the reported crash looks specific to the OpenGL -> D3D 12 mapping, that is the module reported as crashing in the report you posted. That is not the game's fault, it's what we call a "3rd party issue". Meaning it's a bug in your GPU driver or OpenGL->D3D mapping. The GPU driver or OpenGL->D3D mapping is unique to your hardware, it's made by your hardware manufacturer I guess. You need to report the issue to them, not to us. The game definitely will not work unless it's on a system which has full OpenGL support. Specifically, your GPU needs to be able to support at least OpenGL version 3.3 without issues. Almost every other GPU manufactured in the last 10 years can do this, including integrated graphics on low-mid range CPUs.

Hey, thank you for all the research which went into your Github PR, your analysis was spot-on and so helpful in fixing this long-standing bug. In terms of the fix included in 1.21.2-rc.3 I was just looking to fix the specific bug (i.e. the negative hungerCounter) without changing the current game mechanics. Current game mechanics clearly intend to pause the "normal" hunger drain, when there is hunger drain caused by health regen. The bug was it was not only being paused but put into reverse, creating a potentially large negative hungerCounter which would then take ages to reach +10. Today's fix properly pauses the "normal" hunger drain but re-starts it 10 seconds after the health regen drain stops. Seems a sound solution to me. If both drains are running, an injured player would quickly reach starvation. If we want an IRL example, sick / convalescing people often lose their appetite ... @LadyWYT I don't see constantly damaging yourself as an exploit to avoid starvation, as the healing mechanic does also consume saturation. Likewise I don't see dying and respawning with a small healthbar as an exploit, as constantly dying is not sustainable although maybe some people might have to do it to survive on Day 1, if their base is extremely close to spawn.

Sounds like a good time to copy the world save file ... The bug I would think is a good 3 years old, though it's possible it became worse in game version 1.20 onwards when we changed various things in player physics. I have not gone back to older game versions to test them all! The bug relates to which way the player is facing at a corner. Before this fix, if the center of the player was facing up-slope then there was no bug, but if a line drawn forwards from the center of the player "missed" the slope then there could be the bug - in broad terms. On a step on a corner or the end of a row of steps, it was therefore possible to "miss" the slope if most of the player's body was away to the side of the steps.

One tip: if relevant to you, it may be important to enable the flag: "use dedicated gpu if available". Some people forget to do that ...

Please provide a screenshot of the 'blank vague square', it sounds like a bug. Which language version are you using? It's supposed to be a square with the letters "Ctrl" inside but that might be language-dependent.

Don't disable the authentication check unless there's a specific reason to like the auth servers went offline (which hasn't been the case for a good long time now), or Anego Studios stopped supporting the auth server completely (which is unlikely ever, unless there is Armageddon in which case we'll all have bigger concerns than the VS auth server...). @WinnieTaylor Can you please be more specific about the "security issues" ruining things for you? I start the game tens or hundreds of times a day while testing things, and have not encountered any security issues. @LadyWYT Normally the game stores the player's password (more precisely, a token generated after the player enters a valid username+password) inside the clientsettings.json file in the VintagestoryData folder. There are 4 situations where the password might need to be re-entered frequently: 1. deleting that settings file (or the OS deleting it, for example because it's kept in a temp folder or a RAM drive or other place where it can't stay permanently) 2. manual Log Out, e.g. so that another person can play on the same machine using a different game account 3. (most likely) one person using 2 different PCs to play on the same game account (e.g. home + college) - that's totally allowed by the way! 4. a person has multiple installations of the game which have also been manually configured to use different data folders In situations (3) and (4), there is a solution. One working clientsettings.json file can be copied to other data folders or to VintagestoryData folder on another PC, so that then the password does not need to be re-entered. Note it must be a "working" file: I mean copy specifically the clientsettings.json file immediately after a successful login and exit the game to save it. As a side-bonus, this will also copy any custom key bindings or macros etc to both places. It will also copy the graphics settings and other settings of course, those might need to be adjusted if there are different graphics requirements for the 2 different game installations.

Thank you for a considered and measured response, which made me smile. I think the "no extra cost" phrase was meant to be conceptual/abstract, not financial - I think it was supposed to mean, at no cost or harm to Vintage Story game development, including in terms of his own personal development time. If you knew him IRL, you'd know that Tyron is an incredibly, unusually, decent guy - motivated by his own love of certain legacy games and his own vision to make Vintage Story the best game we can, and at the same time wanting to see the vision of Saraty - his wife - completely fulfilled. Tyron mostly likes nature, world systems, the feeling of immersively exploring an interesting world. Saraty's vision is darker: think obscure things crawling underground, abandoned places, challenge, trepidation; she also has an amazing eye and is all about VS keeping a consistent look. There is basically no way that those core parts of the vision will ever be compromised. At the same time, Tyron has for years had a thought to make a separate adventure / RPG type of game using the VS engine, the engine is designed from the beginning to be capable of running other voxel-type games not only VS, only nobody has done that so far. "Adventure mode" is how he would have described it long before 2025. Because of this year's developments, Tyron is now in a position actually to do it, and to do so by setting up a small separate team, instead of doing it himself. I'm sure he recognizes that if he were ever to work on a different game himself then that would have a "cost" to VS by taking some of his time away from VS, but the significant thing which has occurred is now he doesn't have to do it himself. That, in a rather long nutshell, is what "no extra cost" is supposed to mean. I think. I would add that from my point of view the community often doesn't fully realize that VS is made by a medium-sized team now. There are more than 20 people involved. I often see people on Discord writing "Tyron should do X" or "we like how Tyron made X" etc. It's not always Tyron! One of the incredible things Tyron has done is hand-pick over the years a group of misfits devs who, in their own specializations, have skills to match his and Saraty's, and at the same time the humility to work in accordance with his original vision instead of trying to change anything (that's possibly the more difficult thing to find, if you've ever tried hiring anyone!) In 2024 and 2025, a large part of the contributions added to the game have been made by other team members, not by Tyron and Saraty personally. The fact that the community is not able to notice that multiple other people are involved, means we are doing it right! In terms of game development, this has meant that as a team we are much better able to develop Vintage Story at a good steady place now, and to implement the things we have planned, for example the things seen on the roadmap.

This post is my personal view, not an official view. Vintage Story in 2025 is progressing very nicely: we have a perfectly sized dev team now, full of amazingly skilled and creative people, and everyone is busy working on Vintage Story updates according to their specialty If you've looked at the -rc versions of 1.21.0, you'll see that the 2nd story chapter is now considered finished. We are a few days away from 1.21.0-stable, and it's looking lovely. We managed to make this update in less than 6 months. Could even say it's been less than 3 months if you time it from the last stable release of 1.20.12, which was June 2025. Work has now started on 1.22. As announced: > Forging ahead We'll now slowly shift to working on version 1.22, which we in the Team are all extremely excited about. We plan to focus primarily on game mechanics this time, especially mechanical power The group who will be working on the new game will be a separate group of devs, not the current Vintage Story devs. They will likely work completely independently. My expectation is they will make an adventure style voxel game, using the Vintage Story game engine but somehow more colorful and adventurous. But that's up to them, note the word "independently" here. Because Vintage Story itself right now is a mod on its own game engine - I mean, the current 'Survival' gameplay with all the thousands of blocks, items, worldgen, creatures, mechanics, story is all one giant mod - it's possible for a separate adventure style game, using the same game engine, also to be one giant mod. That separate game can be totally different in look and content. Not the same game. Not what people normally mean by a mod, not even a 'total conversion mod'. The analogy with Portal and Half-Life is a good one. Best to read the official announcements for any plans about how the adventure style game will be released (which is probably many months / years away), but my understanding is that to start with - so think of it as a playable alpha - the first releases of the adventure style game will be through the Vintage Story ModDB. So like third-party mods it will be free to download, but will require Vintage Story to be installed because they will require its game engine. The adventure style game will not be "part of" Vintage Story, instead I think of it as something extra, available to the Vintage Story community as an option. Just like mods made by the community. At that stage, each individual player can choose whether to try it or not, the same way that they choose whether to try a mod or not. If they choose not to try it, they are not in any way missing out on the intended (vanilla) Vintage Story experience. I also expect that eventually, in the longer term, the adventure style game will stop being freely available and (at least when it's in a more finished state) will require a separate purchase - but this is just my own guess. Just don't expect it to be "free forever". That new separate group of devs are talented human beings who will need incomes to live on just like anybody does, and those incomes will have to come from somewhere. If it is eventually a separate game, that will not be breaking Vintage Story's ethos of "no marketplace, no paid DLC, no hidden fees". It's not breaking the ethos because the adventure style game will not be Vintage Story, it will be a separate game which just happens to use the same game engine. (Footnote: that worked OK when Unreal did it: the Unreal game engine grew out of the actual game, Unreal.) I just don't understand what's not to like here. Vintage Story will continue to be updated, like it always has been, until it reaches the team's final vision. Nobody in the Vintage Story community is going to lose out on the Vintage Story experience. In addition, in due course the community will also be able to be the first to try the new game. I agree that language like "adventure mode" is a bit confusing, but my understanding / expectation is that will not be a different mode of experiencing the Vintage Story gameplay or lore: it will have its own lore. It's intended to be a different game. Which uses the same game engine.

Guys if you're having problems getting things working in Linux, please use game version 1.21.0-rc.4 which is built for .net 8. Not 1.20.12. 1.21 should be trouble-free, that's our intention at least. It also has a flatpak. Obviously it's super hard to cater for every possible variation or customisation of Linux, but if it doesn't work by default you can ask for help.

Thanks for comments so far. The purpose of the poll, as with other polls, is to inform us so that the team can then, with luck, take the best decision for the player community as a whole. For example if no mod is currently using .obj and .gltf models, or hardly anybody and those who are can migrate easily enough to the .json shape files, then the decision is clear. In general Vintage Story development aims not to break mods unless absolutely necessary. This benefits players of course, because plenty of the playerbase uses at least a few mods. Each new game version if we change something in the engine we make efforts to include backwards compatibility features so that most mods will continue working. We appreciate the hard work that goes into creating a mod, and we want to minimise the ongoing 'maintenance' version for modders. (Unlike certain other games ...) @Dark Thoughts, it would be possible for any skilled + motivated coder to write a command line tool to convert .obj / .gltf to .shape - though only quadrilateral, rectilinear faces can be converted, not bare triangles nor rhombuses. I'm not sure that it's worth a dev team member spending many weeks writing it, as depending on poll results here, I guess very few mods are using .obj or .gltf in practice. So spending a lot of developer time on such a tool would be a good example of a disservice to the player community as a whole. But it could be a good project for a student or someone who wants to increase their knowledge.

The Vintage Story game engine partially supports loading of .gltf and .obj models but it was never fully&properly implemented. We in the VS Team use JSON shapes only. Keeping support for OBJ/GLTF has significant maintenance cost for us, especially so for the planned 1.21 performance updates. Dropping support for it would allow us to work at greater efficiency, so we would like to end support for it unless our modding community has a great need for it. [Edit:] Poll text rewritten by Tyron.

This is a known bug in 1.20.11, only happens when the game is paused. The bug is fixed in game version 1.20.12