Live data from Hacker News

KSP2 is spamming the Windows Registry until the game stops working

forum.kerbalspaceprogram.com

201–210 of 306 posts

Re: KSP2 is spamming the Windows Registry until the game stops working

#201
post #104

Earlier quoted context omitted.

What's always annoyed me with many operating systems is this need to organize based on function instead of domain. If I install an application named "Bob" then I want ALL of Bob's configuration to live within Bob. I don't want it split between different registry keys or /usr/local, /etc/, /var, /lib, etc. I'm fine with there being conventions and categorizations, but I'd like to root node to be the application itself…

[dead]

And Microsoft knows corporate is where the reoccurring revenue is.

Re: KSP2 is spamming the Windows Registry until the game stops working

#202

Earlier quoted context omitted.

I heard from someone who actually works in the industry (as engine developer) that companies usually don't use Unity out-of-the-box and write their own tools and extensions (e.g. memory management) and change parts of the engine as the needs vary greatly depending on the game they are making. Not sure how common that really is though.

> write their own tools and extensions (e.g. memory management) I've been using Unity since 2009, and have been a lead developer and CTO in several different companies. I have never heard anyone writing their own memory management for Unity. May be you're talking about object pooling?

It's kinda what ECS is, depending on how loose you want to get with the term memory management. And studios have implemented their own ECS in Unity long before Unity's official ECS framework.

Re: KSP2 is spamming the Windows Registry until the game stops working

#203
post #161

Earlier quoted context omitted.

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?

How do you find it? How do you install it? Do you need root/admin permissions to create it? How do you provide access control for it? There's a lot of value to having something like this "built in" where the plumbing isn't something you worry about. You don't have to worry about the state of your users' file systems (User deleted 'My Documents', User doesn't have a $HOME folder, you don't have write permissions for %…

> I think if someone went off and redesigned a global KV store for an OS they'd probably require authentication tokens for mutations, so your app would only be able to communicate with the subtrees of the store that it has permissions to (but also, kind of like a file system?)

If I had to design an OS from scratch, this is basically what I would do. I'd provide an API for a prefix-tree based KV store with specific data types (eg bytes, utf-8 string, bool, int, float, datetime...) with some mechanism for namespaces and path access controls or the like. Processes would always have their own space to use ad-lib, and would have controlled access to system-wide or cross-process spaces.

This sort of implementation lets you optimize access patterns so that basically each process gets its own KV/db (if it wishes) which should be roughly as performant as rolling its own kv running on the filesystem. Vs all processes all competing for the same data structure, all the time.

Re: KSP2 is spamming the Windows Registry until the game stops working

#204

Earlier quoted context omitted.

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 trave…

I don't think FTL drives were ever going to be in KSP2. Interstellar travel was going to be via torchships. You can argue _those_ are unrealistic, but they're at least feasible without needing to break the fundamental laws of the universe.

I thought it was warp drives, and possibly stargates. (See the arches with the carvings on Mun). Regardless, we're talking travel time in hundreds of years. Even with time warp, that's pretty boring.

Re: KSP2 is spamming the Windows Registry until the game stops working

#205
post #168

Earlier quoted context omitted.

Are you suggesting KSP2 is quality? It is decidedly the opposite. KSP1 however ARE and have created decent returns.

KSP1 took 5 years of development to get to 1.0, at a non-software company. Take-Two then bought the game in 2017 and is responsible for ports and KSP2. So while KSP1 likely generated returns of Squad-magnitude with a few resources... that doesn't mean KSP2 is capable of generating Take-Two-magnitude returns from a full team. Dwarf Fortress sold a lot of copies too (finally), but it's also been in development for 21 y…

But their point is for that to even feasibly be an idea to consider, KSP2 would have to be good. It's practically a downgrade from KSP1 in every way except the graphics. Entirely a downgrade if you're willing to install graphics mods in KSP 1.

Re: KSP2 is spamming the Windows Registry until the game stops working

#206
post #123

Earlier quoted context omitted.

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 trave…

Well, it's natural extension to endgame and players already liked mods doing that

Generative or alternative systems are an extension. Traveling between the stars is fantasy.

Re: KSP2 is spamming the Windows Registry until the game stops working

#207
post #8

It feels like the Windows Registry is one of those well-intentioned ideas that ended up being a tremendous mess in actual implementation. "Let's use a central database to store things that the OS, drivers, and UI need to access" somehow became "half assed KV dumping ground for every process and their dog to litter with whatever while acting as a singular bottleneck". See also: https://news.ycombinator.com/item?id=322…

It's developer error. It'd be the same as a game on Linux filling up a conf file or a database with duplicates. Does Linux have mechanisms to guard against that? Didn't think so.

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

Re: KSP2 is spamming the Windows Registry until the game stops working

#208
post #193

Earlier quoted context omitted.

> "half assed KV dumping ground for every process and their dog to litter with whatever while acting as a singular bottleneck" Doesn't that describe disk filesystems too? And Unix file namespace in particular (a single hierarchy unifying several block devices, just like registry is composed of several on-disk files)? What about all that junk in one's $HOME?

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, th…

> No, because the filesystem is one layer of abstraction lower than the registry.

That doesn't prevent it from becoming a KV dumping ground for every process and their dog to litter with whatever, at all. Not in the least because it's already that, which a cursory look through /tmp and /var supports.

> There's nothing with less bottleneck to the filesystem besides raw device access

I thought there was considerable effort from the Linux kernel team spend on parallelization of the inode and buffers management but if you say that the main bottleneck is the raw device speed then sure, I'll believe you. It's not like NVMe protocl has design with 64K command queues each 64K command long because the OS simply can't saturate the device's bandwith otherwise, right?

Re: KSP2 is spamming the Windows Registry until the game stops working

#209
post #123

Earlier quoted context omitted.

Well, it's natural extension to endgame and players already liked mods doing that

Generative or alternative systems are an extension. Traveling between the stars is fantasy.

I mean an orion drive multi-generational ship could probably do it with established tech, it's not so much a fantasy as it's just hilariously dangerous and expensive. Easier so with kerbals since they don't need to bring any food along and don't have nuclear test ban treaties.

Re: KSP2 is spamming the Windows Registry until the game stops working

#210
post #76
post #4

One of the comments mentions this: "Alright, doing some investigating it seems that they are saving the Pqs preferences based off of the instance ID of the pqs object, which, according to unity's own documentation, changes between runs of the game, hence why its saving 10 trillion different copies of the same data" So, somebody didn't notice a "changes every game" instance ID was in the path and/or data. They thought…

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. Can't you store stuff alongside the install? Or in some user data location?

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".

Post reply on HN