It can be very stupid. Depends on the software though as the registry is meant for saving user and system settings to a degree. Like Windows File Explorer makes perfect sense. As does settings for audio.
It’s generally advised to not bloat the registry wherever possible. WinSCP is a great piece of software. Unfortunately it defaults to saving to the user registry. You can change it to save to an ini file instead. By using the registry to save settings it can be jarring for the user when they’re trying to troubleshoot something. Only to find out after uninstalling and reinstalling it doesn’t start over fresh. Or if they’re trying to backup settings and data to restore with later. The registry isn’t typically included for good reason.
It might be bad practice to dump 1.3GB of variable user data into the registry, though. Especially when there’s SQL servers and Nuget packages that can deal with that kind of data in a platform-agnostic way.
I remember Scott Manley asked someone important on the dev team of ksp2 how they approached the 2 body problem. They guy gave a vague answer that they had solved it. If that were true they would have a Nobel Prize but they don't. So then and there I decided that KSP2 will not get my money. Which sucks because I have put a little over 2000 hours into KSP1.
I don't think that was the way he portrayed it. He made it seem like they really solved the 2 body problem. Scott Manley even made a comment about how grand that was. I really wish I could find the video to better show what I mean.
Funnily enough, there is an n-body mod for ksp1, which makes interplanet interactions more realistic (in fact, the mod has to slightly change the default system to stop the moons of Jool from slingshotting each other out) and allows advanced maneuvers like ballistic capture and lagrange points
And as someone who couldn’t even land on the Mun without crashing, I downloaded that mod and unsurprisingly found things even harder since it disables the standard maneuvers.
Basically a network/local/user specific configuration database. Playing with it can break apps that expect their config to be in it, or to be of the type expected, even though they shouldn’t.
This about:config on Firefox but system wide. It’s your ~/.config and /etc/ folders in one database format, also manageable with AD and proper permissions.
Is It a frontend for dconf? I have to admit I never tinkered with any dconf stuff before as I live mostly in terminal and web browsers. Does dconf share similarities with windows registry?
As a Unity dev of 6 years, playerPreffs (the unity system that stores data in the registry) are a good place to store small amounts of data in a dictionary style structure quickly without creating your own data system. But they are extremely limited in the types of data they can hold and the control a dev has over them. Whenever I see playerPreffs used I think the dev must-have needed something quick and easy. They may have also created their own registry save system in that case should be an easy fix. (De)Serializing json or even custom binary files in compartmented files in a defined folder like StreamingAssets gives much more flexibility in data types and control. You can see playerPreffs limitations in the documentation below: (docs.unity3d.com/…/PlayerPrefs.html)
Seems like horrible dev practice to place save data of any kind in the Windows registry lmao. I get that it’s designed for storing user data in some respects but the registry is an old and fickle solution to setting global variables important for communication between processes and applications.
If you’re storing data that’s only ever needed by your own application, especially if it isn’t OS-related, you shouldn’t mess with the registry. Not only does it not have the performance you’d expect for most circumstances, but the registry has a real performance and stability impact even when outside of your app.
What’s worse, imo, is that this data is difficult to access for making backups, utilising cloud synchronization, and cross compatibility of your app.
Unity is a lot more borked than I thought, but KSP devs should probably be careful with what data serialisation APIs they mess with.
Dodaj komentarz