Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

KSP2 is spamming the Windows Registry until the game stops working

forum.kerbalspaceprogram.com

Post reply on HN
Print view View original

241–250 of 306 posts

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

#241

Post by joombaga »

MaxikCZ wrote: post #163
philistine wrote: post #152

Earlier quoted context omitted.

macOS has a folder called Library where this stuff is supposed to go. It's not enforced by decree, with many apps doing their own horrible thing. Ultimately, its macOS' culture that mostly makes apps puts their settings and other resident details in Library. 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?

I pressume "Program Files" or "AppData" folders are Windows analogy to Library

"AppData" is like $HOME/Library.

"ProgramData" is like /Library.

"Program Files" is like /Applications.

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

#242

Post by dataflow »

vardump wrote: post #230
dataflow wrote: post #228

Earlier quoted context omitted.

What are you comparing against here that's leading you to a different opinion? Are you claiming file I/O would be faster or that you could write the equivalent functionality faster? Also note that performance isn't just speed either.

For example SQLite is superior. That said, on Windows you kinda have to use registry, especially on the kernel driver level.

> For example SQLite is superior.

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.

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

#243

Post by thefifthsetpin »

pluc wrote: post #233

Is it common to use the registry essentially as a database? 300mb is way more than I expected that thing to support in a single key, but I admittedly know nothing about Windows. I've only ever seen it used to store booleans or simple string values.

I just exported the registry on my personal windows machine to see. It was 400 MB as a .reg file and zipped down to less than a tenth of that.

I'm not sure what's common, but clearly not many programs are dumping large data into my registry.

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

#244

Post by yazzku »

zeusk wrote: post #190
jncfhnb wrote: post #105

Earlier quoted context omitted.

Somewhere a unity exec has just figured out the new metric that determines their royalty pay rate.

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

They will bill you by the pixel. Usage metrics are streamed in real-time. You're gonna wish 480x320 came back.

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

#245

Post by pests »

nullindividual wrote: post #183
hotnfresh wrote: post #153

Earlier quoted context omitted.

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)

You can search for keys and values across all loaded hives. This makes finding things in the registry much easier. 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've got essentially a single GUI application and CLI or programmatic access

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.

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

#246

Post by protocolture »

ianhawes wrote: post #60
sBqQu3U0wH wrote: post #53

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.

You may be referring to Unreal in this instance. Unreal is open source* but you pay to license the engine, so you can make core changes I.e. memory management or tweak underlying net code. Unity is closed source and so you can only really extend very core parts of the engine. FWIW my experience in gaming has been that Unity is exceptionally powerful and allows game developers to create games that would otherwise requ…

My limited experience with Unity was that, if you are planning to do something the Unity way, its very easy to bootstrap and start just coding cool features. Which is why theres a proliferation of Unity store assets + cheap gameplay on steam.

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.

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

#247

Post by fbdab103 »

fayalalebrun wrote: post #173
philistine wrote: post #152

Earlier quoted context omitted.

macOS has a folder called Library where this stuff is supposed to go. It's not enforced by decree, with many apps doing their own horrible thing. Ultimately, its macOS' culture that mostly makes apps puts their settings and other resident details in Library. 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?

Linux has ~/.local, ~/.config, and ~/.cache for user-specific program files. Sadly many programs don't respect these and pollute your home directory instead.

Even better are the programs which will stick cache files inside something like ~/.config/appx/mycache . Like a little middle finger from the developer to waste space in my backups.

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

#249

Post by dathinab »

pratikss wrote: post #18
SketchySeaBeast wrote: post #3

KSP2 is really becoming the premier example of "Nearly perfect labour of love's legacy ruined after being bought by a larger company." More on topic: I have no idea why one would want to use the registry to store this information.

It's far worse than that. Take-Two bought Squad and KSP along with it. Soon after they took Squad's original IP from them and gave it to Private Division to develop KSP 2. Then they poached staff from Squad. It's not like KSP 2 is developed in some innovative way, I was expecting that game like KSP 2 should have been developed in it's own engine since it's so unique among other games. But nooo. KSP 2 still uses Unity…

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

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

#250

Post by toast0 »

recursive wrote: post #41
duped wrote: post #40

Earlier quoted context omitted.

You wouldn't ever design a microservice architecture that required transactions across them. Every microservice owns its own data.

Maybe it's just the domain, but I guess it means the scope of my microservice is just the whole damn thing anyway. I guess I was doing microservices the whole time.

That seems domain specific. I can imagine some services where transactions across everything are unavoidable, but I've also worked on lots of things where there's different databases and transactions aren't needed between them.

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.

Post reply on HN