KSP2 is spamming the Windows Registry until the game stops working
forum.kerbalspaceprogram.com
forum.kerbalspaceprogram.com
"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 they were overwriting a single key.
Can't you store stuff alongside the install? Or in some user data location?
Some files in /etc have manpages.
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.
I think it's silly to compare the two.
I'm fine with there being conventions and categorizations, but I'd like to root node to be the application itself. Yes, I even want this for multiple users.
I know there are design arguments to / for the various different ways of organizing configurations, but IMO they are just inferior from at least this user's perspective.
We're just suffering from backwards compatibility for things made over 30-years ago.
No.
Or, if you really do want something so insane, well great news, you have snap and flatpak. If those are not complete enough examples of this shining vision, go ahead and show us how it's done.
The binary for my app could live in a hypothetical /apps/bob.
Its config could be in there too.
There's no need to duplicate dynamically linked system libraries in there.
If the app need a different version of a library than the one provided by the distro/os, it could vendor it (or link statically). Optionally it can vendor and still try to use OS version if they version is satisfied, but this is just a memory optimisation (disk isn't that expensive).
There's also no need to place firewall rules in there. I'm not sure where you got that from. Firewalls are beyond the scope of a single application?
As for making thing system-wide available, there's already a few solutions for this (symlinks being a very backwards compatible way of doing this on nixes).
For all its faults and poor UX execution (albeit, maybe things improved since I last used them) flat pack and snap have some good ideas!
> For all its faults and poor UX execution (albeit, maybe things improved since I last used them) flat pack and snap have some good ideas!
Hum, flatpak says hello.
Unlike the kernel, Linux userland is a not-backwards-compatible hell so the only way to make sure things don't blow up in a spectacular fashion is bundling the whole world that you need with your app, or hopefully that someone bundled the things that you need with a Flatpak Application Platform for you..
> There's also no need to place firewall rules in there.
> As for making thing system-wide available, there's already a few solutions for this (symlinks being a very backwards compatible way of doing this on nixes).
I'm pretty sure that if you're proposing a "app is a folder" specification, any application that has some system-wide rules it needs to install or suggests or toggle, need to live somewhere in the application folder. Icon customizations, firewall rules, mdns, upnp, those sorts of things.
If the application folder is the end-all, then it need to have some form of "$sysconfigdir overlay" folder if it wants to modify $sysconfigdir without actually being able to modify or spill over the actual $sysconfigdir (and therefore not being contained in the folder at all).
That is in fact how flatpak works: you're never supposed to write anything at the host /etc, you overlay things in your application folder XDG_CONFIG_DIRS and flatpak-aware applications read flatpak XDG_CONFIG_DIRS folders.
That is in fact how nix works: nix packages are supposed to be read-only self-contained folder in /nix/store/$hash-package-$version, and /etc happens to be a non-persistent cache thing that will be overridden sooner or later by a nix expression.
But that of course means that now you have several XDG_CONFIG_DIRS/$sysconfigdir lying around in your system.
I get that the actual ugly details are hidden away behind automation in the form of the special dsl and highly specified framework/structure, and maybe sane enough to use, and maybe adresses some pain point or two better than other arrangements.
Just remarking that I've seen 'everything is a symlink' before, and it's the exact opposite of a new idea.
Whether that means nix shares a bad idea with another bad system or this was one of the good ideas from an arguably successful system (for a time) I won't try to say.
We might have differing opinions about that. (I've got experience for example in Windows kernel mode drivers and service development.)
Also note that performance isn't just speed either.
First... where are you getting this from? I just spent half an hour writing a an incredibly simple benchmark and all I see is SQLite being something like 20x slower than a registry query, seemingly caused by repeated locking & I/O system calls. This is on a trivial database with just 1 table with just 1 row, vs. a registry that's on a machine that's been running for years. If you have a benchmark that can disable the locking and get comparable performance, I'd love to see it. Not that it would mean anything though, given the next point.
Second, even if it were somehow faster... you'd be comparing apples to oranges. The registry has a bunch of things SQLite isn't designed for: security integration with the rest of the OS, a hierarchical structure, OS hooks for monitoring & interception, multithreaded access, etc. Have you tried doing these with SQLite before praising how fast it is?
> That said, on Windows you kinda have to use registry, especially on the kernel driver level.
Is it common for drivers to use SQLite to store configuration information in any OS? I dare say I've never seen this.
It's not. You're going to use your assigned registry hive for it.
But they have to be well-written installers (many aren't). And anyways, lots of installers are written by companies which want to leave their footprint behind even if you do uninstall.
Finding orphaned registry entries is hard - it's not always clear what application put them there, and how to determine that the application is still installed.
nix solves this
The registry is almost never a good choice for storing...anything outside of the operating system itself, unless the data is somehow tightly coupled with a specific Windows install (e.g. an activation key). The idea of storing instance data in the registry is madness.
it gets around this issue by creating a gigantic systemwide or per user bucket of crap that inevitably ends up inconsistent.
since it is custom there is no good tooling for doing diffs and many developers treat it as quasi private so the config values are often not human readable.
there are management utilities that work ok, until they don't. then you have to start over because who knows, it's all just crap.
it's literally like a jerry seinfeld joke. you think configuration should be sensible, then everybody just sees this bucket and goes wooopty woopty woo and then it's just filled with crap.
bill gates probably sent emails about it. "i tried to look at the registry, but then it was just trashed."
that is the registry. a little shadow filesystem with a bizarre layout with weird and incomplete tools that is filled with crap.
It is also all in the spin. What if I told you over on this side of the OS table we too keep all our configs in this great single tree database, not only that, we keep our data in the same database, everything is accessed using the same simple unified interface, the api has about five calls, it is pretty great. It also has the amazing feature that physically separate devices can be merged into the same tree.
Preposterous! some would say. All in the same tree! Why you would get everything muddled up. you must have a separate tree for each device. and a special tree with it's own special access patterns just for configs.
But for real, people keep trying to reinvent the registry over in linux land. (cough) gnome (cough) and it is terrible.
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.
I thought ReFS was a failure. /s
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...
This is over 20-years out of date.
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)
Editing, sure, you've got essentially a single GUI application and CLI or programmatic access. Your options are certainly more limited than the plethora of text editors available.
You can export a registry path as a text file, make changes in perferred editor, then import it again. It's annoying but I've done it before when needed.
PS> cd HKLM:\Software\Microsoft\Windows\CurrentVersion
PS> ls
[...bunch of stuff...]
PS> gp Themes DesktopBackground
DesktopBackground : c:\windows\web\wallpaper\[...default system wallpaper...]Pwsh is pretty neat in that regard. Besides the actual filesystems drives, many systems have "providers" that allow you to treat their objects as files: the registry, environment variables, the functions defined in your session, the variables, the aliases... Unix's "everything is a file" became "everything is an item".
* a uncorrupted registry hive is supposed to be Directed Acyclic Graph, (while a modern filesystem can have arbitrary cycles with symlinks and bind mounts and junctions) and;
* the registry has more limited name length limits, even assuming Windows somewhat low filesystem name length limits.
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%.
One of the things that made a work computer more complicated than it needed to be was that part of the network setup redirected %Home% some of the time to a network drive (Z:) (a "Home" drive) and other times %Home% was still on the default drive in the default user folder location. I'd constantly have to copy files like npm's .npmrc from one folder to the other to make sure that every use of npm found a right copy of .npmrc.
That "home drive" setup is a relatively common in my experience ancient Windows corporate hack for hand roaming some user files (sometimes including %Documents% which was likely the real intent but %Home% used to be easier to redirect than just %Documents%), so there is a sense of irony in some tools using %Home% as a non-roaming storage only to have it haphazardly roam due to some ancient corporate policy. It's also funny that it is possible for there to be two %Home% folders on Windows in competing locations with different contents, because the %Home% redirect seems buggy.
I think part of it is that there is a growing sense on Windows that %Home% is for "non-roaming, developers might to text edit this" configuration and %AppData% is for more UI-driven config that is less expected to be edited. A lot of developers learn %AppData% just fine, but there is some cross-platform convenience for developer life if you can always in PowerShell (or bash) just vim `~\.somercfile` and expect that to always work. But I still think using %AppData% more consistently is possibly a better thing for Windows apps to do.
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 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".
Actually I kind of do believe this, but separating the two doesn’t always solve the whole problem if you’re creating on every startup rather than only once on, say, profile creation or new game or something.
Becsuse messing with Windows registry is a recommended action. /s
What's wrong with game config files ?
More on topic: I have no idea why one would want to use the registry to store this information.
FWIW my experience in gaming has been that Unity is exceptionally powerful and allows game developers to create games that would otherwise require an entirely separate dev team to support the engine. When I first learned game dev, the code sections were almost entirely devoted to interacting with the underlying graphics libraries (OpenGL or DirectX) and hardly any to creating powerful features in a game. Now, using something like Unreal or Unity is akin to using a web framework like Ruby on Rails or Laravel.
* The source is available to view and modify
I’ve known people who worked on some games where they hand rolled a physics engine in c# instead of using the unity one.
I think you might mean that unreal is "source available" which doesn't confer any of the rights of open source, but does allow you to view and modify the source code subject to a commercial license (which might be free for personal, small scale use. I don't know unreal's pricing structure).
Unreal is not open source (cf. the Open Source Definition: https://opensource.org/osd/). It's just that the licencee is allowed to view and modify the source code within the limits of the licence.
Although, I don't even know if the KSP2 studio is big enough to afford it, let alone if they are actually doing it
> * The source is available to view and modify
“source available”, and then you are using common terminology in a non-controversial way and don't need an explanation that is longer than the term.
But if you want to do something a bit more complex, like modifying 3d objects in flight based on unit interaction, not only are you fighting an uphill battle, but the documentation is all out of date and mostly wrong. Because Unity isnt just an engine, its a set of default addons to that engine, and each of those addons was written to be just generic enough, but mostly just enable people to start making FPS and RTS games really quick. If you want to step outside that paradigm you are basically just engine coding again.
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?
* 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.
As someone not familiar with the KSP ecosystem that threw me for a loop.
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.
developing games is cost and time constrained
if you can use a existing engine and not wast resources on all the things which are not the main selling point and in turn spend more resources on getting the main selling point right, why should you not do so?
AFIK few, probably non of the more successful established game engine force you to use their physics engine
this still leaves quite a lot of parts you do not need to replace
Of which the consequence should be "Don't turn labors of love into businesses that demands market-leading returns"
KSP1 however ARE and have created decent returns.
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 years!
The expectations for both these games were low. It was a small team working on both of them so we don't expect much, and since they're indie, they are actually gamers like us and like to play their games.
Being bought by a AAA publisher and having billions at their disposal increases the quality expected by unprecedented levels. And they are just showing that they are even worse than the indie team (HarvesteR) that started KSP. And they have budget and can get more personnel if they want.
You can have hundreds of millions but no match for a small number of software engineers in what they are good and enthusiastic at.
I wouldn't go that far. Its not KSP2, but KSP1 has plenty of jank and bugs.
Take Two and KSP2 have none of the same forgivable qualities.
Then KSP2 is like, still on Unity? Despite massive amounts of budget and like no compelling reason to stay on Unity with the backing of a real game company.
One benefit of Unity is moddability.
But yeah, thats not really worth the drawbacks for something like KSP.
making games (and also a bit on money on the side)
making money (and having to make some video games so the money will come)
I recommend CKAN for installing and maintaining mods for KSP 1.
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.
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 ideas how to progress the game were great! And players liked it!
But after failing the deadline twice (I assume they lied to take2 about funds required) T2 kicked them off the project and poached developers that did it (basically "if you still love KSP come work for us).
And again, it looked great! The improvements they wanted and presented were received positively as it was basically "KSP1 but MORE! And with MULTIPLAYER!"
But in the end it turned out that passion cannot replace competence and the developers of this game are not very good.
Like, buying Palm and reselling cheap Android phones, buying KSP and releasing KSP2 as it is don't seem to make a lot of financial sense. Or does it? It's always assumed "they" make a lot of money by ruining a brand. How and how much?
https://www.gog.com/en/game/kerbal_space_program
I don't know what other companies have screwed up GOG titles, maybe paradox (like stellaris?)
Some times it is a relaxation of requirements though. Some people might want/need account deletion to also remove all the content related to the account transactionally, etc, and if that's a requirement, everything account related must be in a transactionable system.
If you can be more flexible on that, separating account management from other data is pretty common in my experience.
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.
I think it would actually be quite useful to have an /etc/conf virtual file system that could be programmatically accessed by user space processes and used as a "dumping ground" just like /etc already is.
There are a lot of problems with software "shotgunning" their junk across the system. This isn't exclusive to the Registry or even a specific OS unfortunately. Just go look at what configuration files are located between applications on Linux for example, it is not consistent at all.
I'm not knowledgeable enough to know why a culturally enforced folder is far worse than the database that Windows has. Care to enlighten me?
"ProgramData" is like /Library.
"Program Files" is like /Applications.
Home is a bit more chaotic but most applications follow the XDG specs. Mostly. Less so with cache and state files (vscode, for example, dumps tons of cache/state files in .config instead of .cache and .local/state). And weird things like Flatpak shoving everything in .var.
I’d say things generally behave about as well as windows apps which often treat documents as a dumping ground for all kinds of files. I always have to go to pcgamingwiki to find game data locations without having to check half a dozen places.
For administration I really like the /usr and /etc divide. Vendor files go on /usr, and overrides for the running system in /etc. It’s useful to be able to peek in /usr to see defaults.You don’t really get that ability with the registry. With some more modern setups /etc is bootstrapped from /usr (for example, with systemd-tmpfiles) and you can “factory reset” a system by clearing out /etc (with some asterisks around restoring state for a few of the legacy state files still kept in /etc if the system is has manually created users/groups).
I would put that in the same directory as the executable so I can have more than one executable of the same program or the path is simply passed as a command line parameter in the systems unit file.
Compare that to hardcoding the registry key path in the executable...
They're multi-user Operating Systems. Each user needs their own.
Storing .INI files in the .EXE's directory has been a no-no for many years, and nobody should be arguing for that. But the central registry concept makes even less sense. Use .INIs in your format of choice, and store them in the appropriate user-specific application data folder. Additionally, they should be created when the executable finds them missing, not by the installer.
The latter practice alone solves a multitude of problems, ranging from multiuser support ("Whaddya mean, install for everybody who uses the computer or just me? WTF?" -- your users) to the issue of requiring admin rights at installation time that are not really needed by the program itself.
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 %AppData%, etc...).
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.
The thing I'm not sure about is how you'd implement secure initialization/registration of a new app on first run.
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?
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).
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?
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.
Sure. ulimit or cgroups can.
But this thread is getting distracted. That's a separate issue, and the applications in question can still pollute all they want within their container.
For instance, most EA games from the early 2000's standardized the store of the CD key in ~HKLM:\SOFTWARE\<Game Name>\ergc. This would let one install the game to any drive and still have access to the CD key.
Games also use the registry as a way to point to where the game is installed. In the worst case scenario, it's used as a dumping ground for the game's preferences/settings and save states. With the shift to 64 bit and the introduction of WoW64 and most recently the shift to VirtualStores, I would rather nobody ever stores anything in the registry.
I'm currently working on a compatibility shim geared towards games that will redirect winapi filesystem and registry calls to a custom location. Hopefully it'll result in being able to make more portable installs of games that may require access to the registry.
I believe in Windows there's even $SHARED/.config
If you need to start manipulating configuration files, then you need to deal with all the complexities of that.
The registry is great for exactly this sort of config info. And on Windows, HKLM (HKEY_LOCAL_MACHINE) is for system-wide stuff. If it were per-user config it'd go in HKCU (HKEY_CURRENT_USER).
The real issue is that this is known since Win 95 days , yet some people don't get it.
Which means they've ended up in an awful state where even if they were competant (which they are not), best case things might not be much better.
You're right they marketed it as a full re-write to avoid the problems ("Slay the Kraken"), but what was delivered was trash.
Even the youtubers that got to play the prerelease version pulled out every excuse in the book to not present what they saw objectively.
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.
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.)
What they did so far showed they have nowhere near skill to pull it off
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.
I don't think that's the case. They clearly want to re-create the KSP1 things before going into more advanced stuff, the problem is that they can't even do that.
Like, from the pitch it does seem that they know what players want, like starting from the get go with procedural wings, VAB improvements etc. but from results it's clear they don't have the chops
I don't understand what they are trying to do with KSP2 to begin with. Skeptical from the start and it somehow turned out worse.
Ofcourse, it is unfortunate to have bug here of all places, but it looks like people don't like KSP2 devs in general (maybe even for good reasons, I don't know) and try to exaggerate this issue as some kind of proof, when in reality there is none
Bit tangential but I'd like to remind everyone that this is the game where the lead designer (?) said that wobbly rockets and physics bugs are adding to the fun of the game, and they are implemented deliberately. This is doomed.
That said, I cannot be sure of that, so I will not buy it until it is actually good.
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?
Asking who? From what I've seen, the typical sentiment is that they've gone far past the expectations they set.
For KSP2 I think the main expectations were eventual new content (starting with a good chunk less than KSP1 and adding more later) and better performance. And they sure haven't delivered performance.
I enjoy the game a lot more now, but the original E3 "gameplay" trailer still feels like it overpromises. Comparing the current state to that trailer there are quite a few things that have fallen short:
I've never encountered a planet which was as lush as the one shown initially. You don't find animals packed that closely together. I don't think semi-aquatic animals like the sauropod-looking things in the trailer are supported in the game either. You don't see animals running around in packs like they showed either. The closest thing you see is about five identical animals spawned into the same small area.
The video also shows you being able to fly swiftly above the surface of a planet. I may be misremembering, but I don't think I've ever been able to fly quite that quickly, but the biggest difference is that the game suffers from very noticeable object pop-in (it can even be noticed when moving at low speed).
I think you can fly with wingmen now, but I've not tried it.
This might not sound like much, but the existing game just looks far less interesting than the original trailer even if many rough boxes have been checked since then. Also, I'm not even looking at any other pre-release announcements or videos for reference.
> Asking who? From what I've seen, the typical sentiment is that they've gone far past the expectations they set.
I'll note that anybody still playing the game probably likes it, and anybody who doesn't like it probably stopped playing years ago (except to perhaps check out new updates and continue to feel disappointed).
Some specific things:
- planets feel lifeless and very samey: there's nothing to really explore because the depth of geology, biology, ecology is not there. I suspect that's why they added so much base building, which was never a significant part of the early hype/marketing.
- even features they implemented feel incomplete and shallow, such as player customization and base building, compared to many other games which do those things better.
- the game was described as allowing the player to navigate an actual star system, and instead it's just a skybox densely littered with pirates and asteroids. If I want that, X4 is a hundred times better. For exploring stellar systems, Elite Dangerous or just SpaceEngine show that it's possible to do well.
This is the later, that's been obvious from how Take-Two handles things, with the game even changing developers midway through development.
I'll list their sins from my armchair:
- remaking a beloved, established game that has a prodigious base of features and extremely extensive modding support. you have a HUGE hill to climb just to get to your "MVP" - you have to supplant the existing game plus its modding community, and this is already a niche audience of ["people who find orbital mechanics as a primary gameplay loop to be fun"]. They were always going to need to really fucking knock it out of the park on their first at-bat to make this work.
- doing so on a short time-frame
- trying to be all artsy about it too. not that that's a bad thing, but it does position you to take your time rather than going fast. and like I said, they already had a steep hill to climb.
- standard-issue development hell. it happens.
- special-issue development hell where TTWO did some fucky-wucky stuff where they hired away a ton of the staff from the studio they were contracting with, cancelled the contract, and brought it all in-house with the poached team. Hardly an encouraging sign.
- with all the delays adding up, I suspect they were given the ultimatum to either ship their current state into EA and start recouping money, or get scuttled. People have allegedly looked into the code and found extensive additional systems that were basically hastily commented or hacked out so they could ship some vaguely-functional core.
I was really, really looking forward to KSP2. KSP1 but with good graphics, a non-unity engine (it was always a miracle that squad had gotten such good large-scale physics out of unity), and promises of official support for non-kerbin bases and interstellar travel? Yes please, sign me up!
But honestly, my mental model for how this would be successful was "they'll reimplement the existing base game in a new engine. big task but doable for TTWO's money, it's not indie anymore, and they obviously already understand the product. Then, with the base game ported, people will be willing to buy in EA because they see the promise of 'KSP but more!!!'". And that last bit was going to be critical, they'd need people bought-in if they wanted TTWO to keep funding them / them keep funding themselves.
So when they launched this scrap heap into EA, I knew it was doomed. And look at the, what 8ish months between then and now? They've released a few quaint patches that ignored all the huge issues and done basically nothing else.
I fully expect them to now slowly wind the EA down with a skeleton crew and people will just forget it to an ignoble death. I mean, TTWO can hardly be keen on continuing to pour development funding into this EA, right?
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.
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.
claiming they did this on purpose is just acknowledging that they are good developers. They aren't and they keep proving it day by day.
Wobbly rockets and physics bugs were fun and interesting in KSP1. What they did in KSP2 is not even close to how those bugs were in the first game. It's inherently worse. You can read a lot of reviews and people will say that even though these bugs existed in KSP1, they weren't as bad as they are in KSP2.
I wonder how in the Year of Our Lord of 2023 someone feels confortable using the Windows Registry like some kind of blackboard.
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.
Registry hives expand but don't contract again. The registry is effectively held entirely in RAM. You are therefore effectively wasting 322 mb of RAM even when KSP isn't running.
https://learn.microsoft.com/en-us/troubleshoot/windows-serve...
NIH I guess. Or maybe some old fart in company doesn't want to let go off their abomination.
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.
Ofcourse, it is unfortunate to have bug here of all places, but it looks like people don't like KSP2 devs in general (maybe even for good reasons, I don't know) and try to exaggerate this issue as some kind of proof, when in reality there is nonw
Why would this be used for player data in a production game? It's frustrating to port playerprefs data between systems for testing purposes. Is there something I'm missing?
I think the community and reviews would be different if the parent company hadn’t outright screwed the original developer of KSP, which was a beloved game. The drama around that poisoned a lot of community good will, because the original developers clearly had a love for the game and the community and made something unique, then were unceremoniously dumped and cut out of what was supposed to be a well funded effort to build KSP “right.” Then they release this as “right” and it’s a huge disappointment.
(as per another comment)
> having 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
This looks like someone copy-pasted something off of Stack Overflow (wouldn't be the first time)
Take2 killed the KSP franchise and they continue to do so. From less and less frequent updates (KSP2 has received only 3 "major" patches since it was released in February, taking 2 months between updates), to useless hotfixes that take a week to be deployed to fix just a single bug, to them taking 6 months to try to find out the reason the rockets are wobbly, to them releasing a game in Early Access which wasn't even ready for EA, it was an alpha prototype, completely broken down, and just trying to milk the franchise lovers for their $40 for an INCOMPLETE PROTOTYPE (which will be raised to $70 once the game leaves EA), I wish they just abandoned KSP2.
KSP1 with its modding community has produced so much and it's a much better game than its sequel. The charts don't lie, right now 1k players on KSP1, 67 on KSP2.
Now someone's going to tell me "this is not how game dev works". Well. They have billions at their disposal and a predatory publisher on their back. And their dev team consists of a lot of modders from the KSP community which I particularly don't blame them for not delivering, but Nate and the team that was poached from Star Theory by Take2 because the former didn't agree with the time frame Take2 gave them to release a working prototype, they are really incompetent.
They are "building the game from ground up" using the same engine as its predecessor and amazingly they came across the exact same bugs that KSP1 had fixed like 8 years ago. This is not even newbie game dev, it feels like they're just a bunch of people that just started to learn how to write software.
I have an opinionated website tracking their lies and deceptions (based on Web3 is Going Great), if anyone is interested: https://nokerbal.space
I'm not sure what's common, but clearly not many programs are dumping large data into my registry.
This was way more common in the old Unity 5 days, though
[0]https://docs.unity3d.com/ScriptReference/PlayerPrefs.html
It took a looooong time for KSP1 to get where it is now, it will also take awhile for KSP2 to be as polished.
Chill out.
KSP1 had (AFAIK) a cheaper dev team with no demanding publisher and a good reputation that brought a steady stream of money during alpha. If they progress at the speed of KSP1 from this point, they are going to get cut.
they failed
The two releases are nothing alike and if KSP 2 intended to use the same release model it should have either been dirt cheap or not released for many years. As it stands now it comes off as a massive grift and deserves the hate.
KSP2 is made by TTWO, who is a publicly traded AAA studio of notable fame and decades of legacy and domain expertise.
If Squad sold KSP1's IP to TTWO and then went and made "KSP2" under a new name with their squad-sale money, that would be a different story. But even with that goodwill, I would still not be believing in the current KSP2 ever being a success story.
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.
Furthermore, looking at the demos presented in 2019, it's not clear that much progress was made between then and now.
The complete stall since early access release (7 months with just a handful of hotfixes) and lack of feature delivery suggests that IG don't have the competency to deliver.
That, or they moved all their staff to their other "unnamed title" they're hiring for and have KSP2 on the most minimum of developers to pretend they're making progress toward their roadmap.
Huh, didn't knew that. I only heard that "most" people came over.
But yeah full price EA into absolute shitshow of a game doesn't bode well.
> That, or they moved all their staff to their other "unnamed title" they're hiring for and have KSP2 on the most minimum of developers to pretend they're making progress toward their roadmap.
That would be weird, what makes the Take2 management think they can deliver something else competently ....
We could even just look at reentry heating, which was supposedly almost done, over 6 months later and even just that is nowhere to be seen. If that's taking them so long, how are they ever going to deliver the rest of their promises? Many of which there are serious technical questions about the feasibility of (eg multiplayer).
Until KSP 2 achieves feature parity with KSP 1, I don’t see any reason why I should buy it.
Speaking form a software development perspective, I don't see it improving beyond that point, or if that's even possible at all. For all KSP2 promised to improve the physic engines of KSP1, it has seemingly came up with a foundation that is significantly worse, not sure what you can do when your underlying engine has severe limitations.
Stop defending the billion dollar corporations, please.
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.
You gotta love Windows.
Not the same at all.
If you need kernel extensions you should look for a different solution, at least on the Mac.
> If you need kernel extensions you should look for a different solution, at least on the Mac.
In 2023 sure.
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.
To delete things in /etc you will be asked to gain root privilege. It's usually one click (You might be asked to confirm your password).
Deleting things when admin/root can break things in both cases.
Let's just admit it and move on.
The paragraph you quoted is in context warning the user about MANUAL intervention in the registry, that requires privileged access. So we aren't comparing it to "what can random app do", but what can super user do.
Holy fuck those guys are clueless, no wonder KSP2 launched in such shit state.