radfast

The TOPS announcements could very easily be copied to a thread here. Any community member who is on Discord could do that, it does not have to be a core VS team member.

I don't think this is likely to happen. Discord is one of the most commonly used communications platforms for gaming. Discord suits most VS players just fine. It's by no means essential to participate in Discord though. For anyone who does not want to or cannot use Discord for their own specific reasons: all major news announcements are on https://www.vintagestory.at/blog.html/ self-evidently, people can post questions and comments about the game on this forum and participate in the community that way there's also a fairly active subReddit and I guess other ways to participate, like comments on YouTube or Twitch streams The fact that Vintage Story has a Discord server is no endorsement of anything else that goes on on other parts of Discord or Discord's own policies. Every large online communications system has issues of some kind, every means of communication will be exposed to people who want to troll, make political comments, etc, and all online activities on any platform (except maybe something highly secure like Signal) are potentially viewable by governments if they want to put resources into that. All the large platforms are trending towards age verification which obviously requires some kind of personal data - it's because of well-intentioned laws in several countries intended to protect children online. From what I've read, Discord is also now planning an opt-out for age verification which will still grant access to a large part of the service. For the avoidance of doubt, I'm sure the VS team has no intention of doing anything to break the Discord TOS.

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

The installation files are digitally signed for Windows of course. Even so, Microsoft Defender sometimes produces false positives, for some people, when we update to a new game version. The dev team are actively working with Microsoft to stop this from happening at all, it's a slow road. Anyone affected by this (assuming it's a genuine download from vintagestory.at and no other source) should simply allow the file as safe.

This issue is fixed in game version 1.20.12. Apologies for the extra adrenalin while that was an issue...

If you are referring to mass-spawning after pausing the game, this is fixed, see notes: Fixed: Large numbers of fresh spawned entities after pausing the game for a while in SSP If it's a different issue, do you know if it's on Github issues list and if so please provide a link.

This older thread, the discussion of optimus-manager, might still be relevant and helpful?

You may find some useful pointers here: https://wiki.vintagestory.at/Framerate_and_Performance In general, though I cannot see your system: The framerate is normally GPU-limited, not CPU-limited. You have an i7, so that should be fine. Unless you have something like 10k entities spawned or farmed, that should be ample. Hardware faults such as faulty RAM are rare, but if they happen they will have an effect, for example due to hardware interrupts or other OS type issues In the vast majority of cases, the issue is GPU-side We provide a wealth of graphics settings which control what the GPU is doing. I would suggest start with low-spec settings (small view distance, shadows and SSAO off, etc). See if you can get stable framerates. Then slowly and gradually increase the settings and see if things remain stable. If you changed configs in clientsettings.json or servermagicnumbers.json, go back to defaults (if necessary, delete those files even, so the game will recreate them with defaults) The Chunk Upload Rate Limiter setting in graphics settings is potentially relevant, though usually has more impact for Radeon than for Nvidia. I recommend set it in the middle of the range, for testing Observe what game actions cause stutter - for example if you stand completely still, if you rotate your head? If you look straight up into the sky you should be able to get 150fps There is a command .debug logticks 20 which will show the potential reason for any drop below 50fps (20ms frame time = 50 fps because 20 x 50 = 1000, you can try other numbers). However, if the issue is GPU-side it will not show any useful information For Nvidia specifically, try the things discussed on this forum thread - there are some Nvidia Control Panel settings discussed there which might still be useful and relevant, even though I guess Nvidia have changed things since that was first written. Some other things to try: Use a good quality hardware performance monitor to check that your CPU and GPU are maintaining high clock rate and not thermal throttling. Open Hardware Monitor is good, and free You are playing on Windows 10. If you didn't carefully clean things up already, you likely have a lot of processes running, both from Windows itself and other software you have installed. I would strongly recommend take all possible steps to 'de-bloat' it and disable unnecessary startup processes, before looking to blame your game software. Especially if you have similar issues in multiple games. For a start, OOSU10 allows you disable many of Windows own annoying and unnecessary elements. Personally I have almost no other software running when I play games, except for Nvidia Control Panel and an audio control panel. So I stop the VPN, the antivirus, the auto-updates, the drive scanners and search optimisers and all those types of background processes Re-read and fully apply the above bullet point. Especially, do not have Discord running (not even in background), nor any browser, nor any VOIP process. Use your phone or another PC if you need to read internet guides while testing things. Try playing the latest game version 1.20.11-rc.1, it has the highest performance Test without any mods

It's a strange thing to report! Do you think you are playing VS for very long periods without a break, like several hours continuously? Maybe longer periods than other games? [Disclaimer: I am not a doctor, this is not medical advice] For any game it is strongly advisable to take a break from the screen sometimes: first to rest the eyes instead of holding them at a fixed focus for a long time second for ergonomic reasons, because you probably hold your hands and shoulders forward to operate mouse and keyboard, can give you 'mouse shoulder' etc third for cardiovascular reasons - literally you could get DVT if you sit with your legs down and still for many hours, it's the same reason why people should get up and walk around at least every hour when taking a long flight (or else do ankle pump exercises or similar), otherwise you are risking this life-threatening condition I am wondering if VS has an additional effect, for you, because the game is so immersive, and simulates the open world with nature etc - maybe your eyes are "tricked" into thinking you are outdoors with a long focus when you are actually sat at a desk? Try making small changes like change the FoV slider

Dear Extraordinary Survivalists v1.20.11-rc.1, an unstable release, can now be downloaded through the account manager. This release has no new gameplay features or fixes compared with v1.20.10. Its only change is to improve performance, especially for larger multiplayer servers. A large multiplayer server running this release should perform up to approximately twice as good - twice as many ticks-per-second - when large numbers of players (more than 30) are online Different results may be seen with adjusted servermagicnumbers.json, different creature numbers compared with the vanilla defaults, or modded games, but all servers should see some improvement This release also uses approximately 10%-20% less RAM, in both single-player and multiplayer games. In multiplayer, v1.20.11 is network-compatible with v1.20.10. A player with v1.20.10 can play on a server which is running v1.20.11-rc.1 (or the other way around). Therefore, generally we suggest that large servers could update to v1.20.11-rc.1 for better performance, even if their players do not update. It is possible that v1.20.11-rc.1 will cause mod breakage for a very small number of coded mods. Mods which only add content using JSON or patches should all be okay. We have tested some of the most popular coded mods with this, but we have not tested them all. If you experience any new mod issues (not present in v.1.20.10), please do report them and meanwhile continue using game version v1.20.10. [Note for mod coders: we did not change the API, but if your mod references ServerMain.Clients with VintagestoryLib.dll as a dependency, you will likely need to recompile against the 1.20.11-rc.1 version of VintagestoryLib.dll. Harmony patches which make code changes deep within VintagestoryLib might also need attention, most of the entity physics, animations and general entity ticking code in the engine has been changed.] Screenshot by Extra Ram, shared on #screenshots on Discord Game Updates Tweak: Multiplayer server performance substantially improved in many areas Improved TPS from entity ticking (especially if MaxPhysicsThreads exceeds 1: on large servers please experiment with setting that in the range 2-5, in servermagicnumbers.json) Improved TPS from entity spawning (testing of spawn positions now runs on a separate thread) Improved TPS from player and entity physics and animations updates on the server Reduced peak RAM requirements for server packet sending Reduced peak RAM requirements for server game autosaving Tweak: Map and minimap performance improvements (client side changes) Map now drawn up to 10x faster when panning or zooming into previously mapped areas Areas of the map which are moved off-screen are now preserved for longer without re-draw Reduced heavy multiplayer lag after panning in the world map (greatly reduced client-server network traffic from panning) Tweak: Reduced RAM requirements on both server and client for animations Tweak: Thrown stones, snowballs and other thrown projectiles now have smoother motion Tweak: For hardware constrained servers, new optional VintagestoryServer.exe command line argument --reducedThreads to reduce the number of threads used overall (detail: may help servers which have hardware thread count limits, at the cost of some worsening of ticks per second and game startup time) View full record