231–240 of 306 posts
Earlier quoted context omitted.
The only complaint for modded KSP1 I have is loading times. I'm surprised devs didn't properly optimized that part.
that's a reasonable trade-off, to make a game that is so extensibly mod-able.
Earlier quoted context omitted.
The jank was also forgivable when it was a one man effort or a very small team. Plus it was a relatively novel idea for the game being created for the first time. It also made no grandeur promises of what was to come, and continually made improvements. Take Two and KSP2 have none of the same forgivable qualities.
The jank was acceptable because it was supposed to be a simple 2D game that ended up outgrowing it's diapers as it grew, and being a Unity project a long time ago, was stuck on abysmal physics systems. It couldn't NOT be jank. Everyone always "wanted" a better physics system or game engine entirely, because KSP1 was often held back by Unity, but that would have definitely killed the project. Then KSP2 is like, still…
One benefit of Unity is moddability.
But yeah, thats not really worth the drawbacks for something like KSP.
Earlier quoted context omitted.
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 da…
The thing I'm not sure about is how you'd implement secure initialization/registration of a new app on first run.
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?
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?
Everyone seems to love shitting on KSP2, when the same people forget what KSP1 was like in Alpha. No science, shitty graphics, excessively wobbly rockets, inconsistent orbits, (other than graphics) seems familiar? 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.
So you're saying the KSP2 devs had the benefit of being able to look at the past mistakes and issues of their predecessor, and still failed to learn from it? Stop defending the billion dollar corporations, please.
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?
Where do you store where the application-specific KV stores are located? Are you just going to hard-code it so the application cannot be moved or installed elsewhere or on external drives? Where does the OS store its own settings? 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 configur…
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).