KSP2 is spamming the Windows Registry until the game stops working (opens in new tab)

Are you sure it isn't based on number of instructions retired by the CPU? or the number of pixels rendered by the game?

> what is the windows registry and why do things need to write to it?

It's a centralized, high-performance small key value store that's the alternative to writing a million config files in random places.

It's arguably much better in my experience. E.g. one of the never-ending headaches I always have on Linux is updating config files when a package updates. There's no automatic file merge in general (hence .pacnew and such) so you gotta do it by hand (and not everything is available with the foo.d/ hack). The registry already operates at the value granularity so it bypasses this kind of issue.

And as a developer you don't have to worry about some things you might not think about, like the trade-off between corrupting your config files with in-place updates vs. having to create a new file and replace the old one after every config change.

Imagine every setting in ~/.config and /etc is stored in corresponding SQLite database, and you have common interface to access both.

Now imagine this database is not a great engineering product like SQLite but really, really REALLY fucking sucks at being database, and slows down quickly with sizing up.

Now imagine there is no sensible way to get obsolete data out of it, and as every program uses same file it just gathers, and gathers, and gathers...

The database-backed configuration mechanism makes a ton of sense, and if you squint, the filesystem is really kind of a database anyway. With the registry, there’s a lot you get for free—you can set defaults system-wide, you don’t have to deal with parsing, you can get new values without re-parsing a file, etc.

A lot of the horror stories came from earlier versions of Windows which had problems with reliability.

If you spend time as a Windows sysadmin you can start to appreciate it, because it does make certain administration tasks easier. Like “I need to change 10 registry different keys on 50 different machines” is easier on Windows. On Linux, I’d do the same with, like, Ansible scripts which can be a lot more error-prone to write.

It’s /etc but harder to browse and edit.

Or, from the contrary perspective: it’s the 500 places config lives on Linux, but in one place instead.

(Except it still has a deep hierarchical structure, so that second one is kiiiinda not entirely true, in that you can run into exactly the same issues as scattered config files on Linux)

The windows registry is both of those things.

It has a "hive" which is part of the user profile. User preferences are stored there ("HKEY_CURRENT_USER").

System-wide preferences are stored in a "hive" for system apps ("HKEY_LOCAL_MACHINE").

It allows applications to mix and match system-wide stuff with user-specific stuff, which only differs by which "hive" it wants to query against. It has several data types for different types of records. There's conventions for how to store things (although apps can do whatever they want), so apps usually store their state and config data under HKLM\SOFTWARE\MyCompany\MyApp for system-wide stuff, and user specific stuff will live under HKCR\SOFTWARE\MyCompany\MyApp.

All in all, my experience has been that on average its usage is a bit more standardized than config files. Of course on windows, apps (particularly C# apps) ship both with config files and a boatload of registry entries.

Lastly - by design, HKCR (the user profile hive) is assumed to sometimes have orphaned data. If a program is installed per-user, and you uninstall it as a different admin user than who installed it, the other user profiles cannot be loaded and modified by the installers thereby orphaning any other user data.

I believe there is a Registry of sorts in Windows 3.1, but is largely empty. It was only in the Windows 95 era that it ballooned into what we have today. Coming (at the time) from an Amiga perspective I was bemused to realize that if 3.1's progman.ini file was damaged, that the program groups in Program Manager (think of each group as a node in Start -> Programs, basically the user-oriented files and executables from a software install) could just disappear! While there's a slight performance hit, one would think it would be more robust to scan the disk for .grp files every boot and build this data dynamically in memory. I have always assumed this was done because 3.1's memory management was complete crap, necessitating that Microsoft "write everything down". Ditto for 95, and being a much more ambitious OS, there was that much more to write down. Then the third party vendors jumped on board. Fast forward to 2023 and this legacy still persists when it doesn't have to.

I could be blowing smoke, but this has always been my thinking. An old joke: Registry was derived from the Latin word registratum, which means "put all your eggs in one basket".

Based on the follow-up questions, it sounds like you already know what it is and just wanted to advertise your allegiance to the Unix way of doing things.

It's kinda like a system wide dconf

> Coming from a Linux background, what is the windows registry and why do things need to write to it? All I ever read about it seem to be horror stories.

The Windows Registry is the NT Kernel's system config/preference store. The closest Linux equivalent is dconf. Like dconf it is built to be a read-mostly/read-optimized database. It's not as strongly focused on a service-bus architecture as dconf. It tries to heavily optimize for an MRU on-disk order (somewhat like redis) and optimize for strong write consistency (unlike redis which is happy to do more in memory between flushes to disk). Any writes at all generally thrash the Registry "hive" database files some. Heavy amounts of writes will murder it. It was optimized for reading not writing.

The Registry was side-ported to Windows 95 from the NT Kernel, in part because COM (it became the central spot for registering COM components), and a lot of mistakes were made in the messaging about it. It was intended to be Kernel-focused and mostly never used by user-space applications. That unfortunately wasn't made clear enough, and needing to register COM components in it certainly muddied the message. So Windows apps have a long history of storing a lot of things to the registry, much of which they should probably use user config files for.

> Can't you store stuff alongside the install? Or in some user data location?

In Windows due to a complicated dance with anti-malware efforts and secure binary memory mapping it is generally frowned upon to store stuff alongside installs (in the %ProgramFiles% or %ProgramFiles(x86)% directories). Many programs (especially well written ones) don't even have write permissions at all to their install folder (similar to how many distros lock down /bin and sometimes /usr/bin and/or /usr/local/bin to superuser accounts only). For backwards compatibility reasons with applications dating all the way back to Windows 95 some app installer are allowed to still re-ACL their install directory to give back write permissions to the application. Also, in modern Windows (since Vista), depending on a number of factors Windows will actually lightly sandbox the app when that occurs and redirect ACL changes and writes to an "overlay" directory, allowing the app to believe that it still is writing to its own install directory but it is actually writing to a machine or user directory outside of %ProgramFiles%.

On the other hand there are plenty of user folders available for config storage: Generally the suggestion is %AppData% for most such files. (This is the "Roaming" app data that may be automatically copied to other machines for some users on some networks, mostly enterprise/corporate accounts/users.) Some apps may prefer %LocalAppData% which doesn't roam for larger config files or more machine-specific transient things (like window positions or caches). It's also common enough to see cross-platform apps use Unix-style dotfiles under %Home% and even sometimes XDG-style dotfiles under %Home%/.config/. That's not generally recommend and especially because of roaming behaviors the general preference is to use the appropriate %AppData% or %LocalAppData% and avoid cluttering %Home%. Though many Windows users don't even really use or see %Home% for a variety of interesting reasons, so its not entirely frowned upon as wrong. (Unlike storing config files under %Documents%, an ancient mistake of many Windows apps not as terrible as storing things in the Registry they shouldn't, but more visibly obnoxious to Windows users that want tidy Documents folders and feel that folder should be entirely user-controlled.)

Also, there is a machine-wide config location, somewhat akin to /etc, named %ProgramData%.

It's just /etc

It is some combination of /etc and /var. a hierarchical key-value data store shared by the whole system used for configuration management mostly.

The windows registry is a hierarchal data storage system. Yes, basically a filesystem.

like dconf, but strictly worse (eg, doesn't have schema)

I would say, using something that doesn't belong to you as a primary key considered harmful. Create or update is a good pattern for robustness (eg so a troubleshooting user won't brick the app by deleting or renaming the key), if you can guarantee the uniqueness of the primary key. You can't constrain some identifier from a different system.

I can understand not noticing the extra writes; but doesn't this mean that they were never loading the proper value, always loading the default, if the new key was always unique?

It wasn't found in unit tests. /s

Incorrect on nearly all counts:

* The GAME (KSP) and the IP was purchased by Take-Two, not the company itself.

* The IP was then given to Star theory (MNC/SMNC/Planetary Annihilation guys) to develop KSP2

* Star theory failed once to deliver on the budget they promised, they got extra money

* ST failed second time,T2 didn't wanted to give them more money, so ST wanted to sell out to T2

* T2 went "fuck it", took IP from them

* Take-Two was one to poach developers from Star Theory (not Squad!) to make new studio to make KSP2. IIRC they basically made blanked statement "if you want to work on KSP we will hire you" to their devs, a lot of them came over.

I assume the last part happened because T2 went "hold on, you failed to deliver then want us to buy you ? Why would we buy company with incompetent management in the first place ? Poaching devs is cheaper".

> You are better off installing better graphics mods on KSP.

Well, at least you got that right.

> should have been developed in it's own engine since it's so unique among other games

with my limited technical knowledge about game programming and much less limited technical knowledge about software development in general this seems quite wrong

because while the game is somewhat unique in some point, in many many(1) other technical points it's not, so by using a game engine you can save a lot of time/problems with all the points it's not unique in and just either replace or adapt the parts where it is

so while Unity might very well have been a bad choice

the general idea of using an existing game engine was not

(1): Like window handling, input handling, asset loading/packing/bundling/compression, parts of game saving, most parts related to the rendering pipeline, menus, statistics/crash reporting, installers, and probably more.

Through this is also how game engines rot: By not maintaining many of the build in components leading to any non very simple game needing to replace them all the time. I think Unity had been going into that direction.

Not sure, but isn’t unity in this case covering your need for some tools, like rendering, assets management and so on, but maybe not all - i.e deferring to them the physic. Or so would I say assume ?

I'm assuming that the "Squad" you're talking about has nothing to do with the "Squad" multiplayer tactical FPS game developed by Offworld Industries.

As someone not familiar with the KSP ecosystem that threw me for a loop.

not an expert here, but there are thousands of variations of this.. the amount of effort and unique-whatever'ness that it takes to bring a product line into profitable maturity includes lots of people, places and things.. most of those are costs. If capital and their attorney buy the entire operation, with all the layers, the focus changes to the accounts and balance sheet, where lots of happy positive things are mercilessly cut. An unpredictable second part is, willing buyers for some of those parts. What happens from the consumer point of view after that, may or may not appear to make sense. Communicating to the customers costs money and risks reputation. Quite a lot of what happens in decision making is business-secret, some of the bad parts are forever hidden. $0.02 in America

Are you suggesting KSP2 is quality? It is decidedly the opposite.

KSP1 however ARE and have created decent returns.

Stock KSP1 is superior in almost every way. Less buggy, more game features, and a mature mod community. KSP2 has all of that planned but it’s still struggling with very basic gameplay. Problems that were solved a decade ago with KSP1.

Most of the interesting mods have already been integrated into the core KSP1 game. About the only ones worth mentioning are ScanSat (adds planetary observation sensors) and EngineerEverywhere (or something. It adds the thrust-weight-ratio display info without a part). The graphics are enhancements are just pretty pictures, that do nothing.

The first KSP game is still a stellar experience, if you pardon the pun - especially if you install a few graphics mods to make it prettier.

KSP2 has a lot of potential, and is very pretty, but unfortunately also requires a pretty beefy machine to run well - and even with a beefy machine, it can still stutter quite a bit. I honestly am not sure if I own KSP2 or not - my Steam library is like most people's, and I often treat game purchases a just a "you did a good thing, here's some money" - but I certainly can't run it on any hardware in my house.

The most recent version/patch level of KSP 1 is fine, it's been a pretty solid game for a while. There's not much reason to play older patch levels unless you want to use older mods that no longer work on newer versions.

I recommend CKAN for installing and maintaining mods for KSP 1.

It has jank, but I don't know anyone who stopped playing because of it.

In particular, taking a leisurely stroll through /etc is quite a treat if you enjoy a well planted and diverse bed of configuration cultures.

Over on one end you have papersize, a file containing a single word with seemingly no relation to any installed software. In httpd.conf we have a sort of SGML that’s mostly line oriented CDATA. aliases and many other mail files are all members of the Berkeley DB lineage of key value stores. default/ feels like it’s also a key value store but one suspects that one could probably put a command in there and something would execute it. rc.d is 99% code but with semantics in the symlinks too (see also Debian’s alternatives.) A very large number of files look like braced C code; named.conf even requires terminal semicolons!

There’s no value in either consistency or diversity of the underlying implementation be it a registry — the registry, or a gconf thing — or a filesystem smorgasbord of config languages. Without the discipline (authoritarianism?) of a social structure — for example a “company” with a hierarchical leadership that can promote/fire you — you will get diversity in any system.

I just reminded myself of the time I used ansible YAML Jinja templates to control EdgeRouter config files that programmatically built config in /etc. Time for a leisurely stroll in a real garden I think, far away from a computer.

No, because the filesystem is one layer of abstraction lower than the registry. There's nothing with less bottleneck to the filesystem besides raw device access. The registry runs on top of the filesystem. If you wish to use the registry for filesystem-like purposes (eg storing startup config specific to the app or user state), just use filesystem. If you wish to use it like a database for system-wide information, that's a better use-case, but the registry isn't quite a proper database.

Windows programs proliferate $HOME junk, too. And that's an issue in its own right, which should be addressed by platform-specific application dirs (e.g. the platformdirs library for python).

No, but I imagine it's a bit easier to catch an unwanted proliferation of files vs unwanted proliferation of registry keys.

> Does Linux have mechanisms to guard against that?

Sure. ulimit or cgroups can.

I think the "central" part is where you lose me with this argument. What advantages does the registry have over application-specific KV stores... besides the potential to interfere with other applications and the OS itself?

Those sound like exactly the use cases the registry should be used for. However in practice all kinds of state ends up in there that does not need to be accessed by anything other than the game process.

How is that different from accessing $HOME/.config? It does exist on Windows too, but I don't want to Google it.

I believe in Windows there's even $SHARED/.config

I still haven't seen a non-handwavy method for orchestrating a transaction across microservices. That means I still can't use them. Although I don't think I ever wanted to particularly.

Global objects in react are almost universally an anti pattern. The only way to do them right is through a context, ensuring the state lives in the context. But most people hate writing the scaffolding, so a non reactive, non FP singleton gets to work and fails at integrating correctly with the react ecosphere.

You still need to store variables somewhere.

The equivalent of "separate microservices" is making sure multiple programs don't share registry keys, and that's already the case 99% of the time for this kind of key.

Well, the file system, too, is a global variable. Concurrent reading/writing of a single file has about the same racy behaviour as concurrent reading/writing of a global variable.

Yeah, I had to unsub from the subreddit during the development years since everyone was eating up the hype videos and any attempt at questioning the lack of actual meaningful info was just downvoted and flamed.

I still check the sub every once in a while though, and it seems like nowadays the hopium/copium is mostly gone. Player numbers are embarrassingly low and even the "most of the game is already done, they just want feedback and will quickly add in the promised features after refining" argument from launch is also undeniably dead with the total lack of new content.

In terms of content creators, I very much appreciated Scott Manley having been up front with saying that he didn't recommend buying the game at launch given that he was THE original KSP-tuber.

Subreddits for corporate products are almost invariably shit. Run either by the company itself, one of their contractors, or a team of corrupt 'community' mods. In any case it becomes a corporate propaganda space. Reddit's usefulness peaked many years ago.

Watching Matt Lowne’s KSP2 videos just makes me feel better about not buying. It’s just buggier and less.

While I was interested in the surface colony stuff they promised for KSP2, the addition of another star system you could travel to was very disappointing. Not so much another system, but that you could travel to it. One thing I liked was that KSP was somewhat grounded in real physics. Practical interstellar travel just isn’t. (“bUt WiTh ALcUbIeRrE dRiVeS…” smack Shut up. They’re a fantasy.)

To be fair, the users didn't ask for much by and large. They wanted better graphics and good physics with more game world to explore.

That's not really a huge leap. The issue really is, as it is with many things, scope creep. In KSP2's case, it's scope creep to such an extent where, they have long forgotten what people loved about the original whimsy rocket building game.

Like, better graphics really just needed to be better textures, and to make round things actually round. Good physics just needed to be "stuff doesn't randomly explode or become unstable while at rest". They absolutely could have done this... they just... didn't.

This is the first time I'm hearing it uses the old code base - do you have a source? I thought in the initial marketing they were big on saying it's a full rewrite.

I'm pretty sure it's not using much if any of the old code given how many bugs it had/has that don't exist in KSP1.

KSP1 has actually atrophied quite a bit, as many of mods that are essentially necessary for serious play no longer work with the newer versions.

The only complaint for modded KSP1 I have is loading times. I'm surprised devs didn't properly optimized that part.

> KSP2 is made by TTWO, who is a publicly traded AAA studio of notable fame and decades of legacy and domain expertise.

KSP2 was made by indie devs (Star Theory) hired by T2

They just... failed.. they negotiated budget, failed to deliver, negotiated another bigger one, failed to deliver again, and T2 said "fuck it", took IP from them and created studio to develop it.

ST actually wanted to sell out to KSP2 after that disaster but they basically chose to poach ST developers instead, because why you'd buy a company where management now failed to deliver on promised goals twice.

My guess is ST either bite more than they could chew or purposefuly lowballed T2.

I don't give a shit about T2, really. I only care about the concept of Kerbal Space Program, the mere fact it is getting attention at all is shocking, let alone from a AAA game studio (for better or for worse there). The heads of some of the best mods of KSP1 are in the dev teams, it seems to be getting the attention it needs to succeed in the long run.

it was (althought hired by take2 to make it)

they failed

But it's not just about the game being bad. There is a huge difference between a poor game which was made with an effort and care, and a completely soulless, effortless cashgrab.

This is the later, that's been obvious from how Take-Two handles things, with the game even changing developers midway through development.

From my armchair I'll add that throwing away the KSP1 engine and replacing it with, based upon the number of bugs, a new implementation of the same basic idea seems like a terrible idea. My understanding is that most of the original Squad team (i.e. the only people in the world with experience building a successful orbital mechanics game) weren't kept on for KSP2. Take Two should have done everything possible to keep them as core KSP2 developers.

All that said, I don't think the game will be left unfinished. All costs are sunk and Take Two has a (reportedly) somewhat functional, nicer looking copy of KSP1 with, presumably, at least base elements of interstellar travel and colony systems in place. It's probably worthwhile trying to get the project over the last few hurdles, as it's a potential goldmine if they can pull it off.

> KSP2 isn't an enshittification play, imo. It's literally just bad project management.

It is also MBA decisions (kicking the game out for full price as an early-access game that was nowhere near close to being ready for that).

The combination of PM and MBA decisions that have screwed it up are definitely enshittification-adjacent, although they may just lack enough competency.

The first point is incorrect IMO. They just needed a really solid core of unjanky physics for an MVP, which was why a sequel was needed in the first place - KSP 1 engine limitations. Couldn't even deliver that.

The root problem with KSP2 is that they needed to make the core of the game perform much better than KSP1 in order to pull off the scale of what they intended to achieve. And then the they shipped into EA with significantly worse performance than KSP1.

> KSP1, for example, or No Man's Sky

Those are two very different examples, though. NMS was improved heavily but in many ways never approached the features and qualities that people were expecting. KSP2 feels more like NMS than KSP1 in that regard - people have expectations. They've been sold a specific vision which doesn't look like the game. Further, unless it's great... why not just keep playing KSP1 with extensive modding?

No, you cut the crap.

/etc can be entirely readonly to most apps, many of them also either wont start from root or drop permissions right after loading.

That is not the case for registry, far more ways to fuck up.

Read my answer below

I macOS you can’t delete system files, even with root privileges, unless you disable system integrity, which requires a restart.

Not the same at all.

Just because current OS suck at protecting themselves, that doesn't mean that it is acceptable.

You're surprised Microsoft doesn't replace the registry with SQLite in Windows?

If so, you might not be aware quite how many millions of entries are in the hierarchical key value database that is the registry, and quite how critical read-write latency is.

sqlite can do clever things like multiple indexes and full text search, but won't beat the windows registry on the performance front at the narrow usecase it was designed for.

You can still do it manually, but you need a bootable disk to do so:

https://learn.microsoft.com/en-us/troubleshoot/windows-serve...

More saliently they did all that but also set a full retail price on the EA game as well.

That kind of performance is fine for a pre alpha.

Its pretty clear the dev team did not want to push it out so soon. The game was not ready for Early Access. But they apparently did, and here we are.

Yes - it reminds me that despite any overbearing corporatist or draconian protections on games in this very modern "service game" era, people are still clever enough to not only reverse engineer them, but resolve issues that cost some people thousands of hours of pain.

I still game an awful lot, GTAVs loading screens is one of many examplea that have juat caused me collectively hours of pain. I hate the anti-consumer world in which games are now made, but individual hobbyist brilliance fills me with joy.

He did say "unreasonably"

windows is a collection of thousands of rooms each with their own mess

that is pretty sad in 2023