Live data from Hacker News

KSP2 is spamming the Windows Registry until the game stops working

forum.kerbalspaceprogram.com

31–40 of 306 posts

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

#31
post #15
post #9

KSP2 had all the warning signs of being a disaster ever since the initial delays and controversies with the original studio. Unfortunately, as usual, the community put on hype blinders until it became impossible to ignore.

I knew it was going to be a disaster as soon it became obvious that it was a continuation of the old code base, which has a lot of fundamental issues.

This is the first time I'm hearing it uses the old code base - do you have a source? I thought in the initial marketing they were big on saying it's a full rewrite.

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

#32
post #28

Earlier quoted context omitted.

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…

[flagged]

Yes.

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

#33

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.

KSP2 can't be developed forever.

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.

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

#34
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…

They are global variables. Worth working very hard to block in any project. Separate microservices are the most effective way I saw so far to stop people in a large org from making shortcuts via global contexts. I feel bad for our frontend devs dealing with a tide of global constructs in our React codebase.

I still haven't seen a non-handwavy method for orchestrating a transaction across microservices. That means I still can't use them. Although I don't think I ever wanted to particularly.

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

#35
Adding 322 mb of data to the registry isn't going to be healthy for windows either.

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.

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

#36

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.

I forgot KSP2 was made by an indie studio /s

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

#37

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.

Except KSP was cheap (I got it for $9 IIRC, which was good value) when still in beta. KSP2 is $50 for the same level of beta, after years of development and drama. Don't chill, don't buy this crap until it gets better.

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

#38
post #2

Sorry for the language but Wow this is incredibly stupid How did this get allowed ?

Look at the reviews for KSP2. This is not even one of the larger problems with the game. They released into EA with terrible, nearly unplayable performance... on an RTX 4090! a $1600-2000 GPU that at the time was difficult to obtain even if you had the cash.

That kind of performance is fine for a pre alpha.

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.

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

#39
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…

A central key-value store that can be programmatically accessed to persist state across users, processes, and boots, that is also strictly typed and hierarchical is quite useful.

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.

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

#40

Earlier quoted context omitted.

They are global variables. Worth working very hard to block in any project. Separate microservices are the most effective way I saw so far to stop people in a large org from making shortcuts via global contexts. I feel bad for our frontend devs dealing with a tide of global constructs in our React codebase.

I still haven't seen a non-handwavy method for orchestrating a transaction across microservices. That means I still can't use them. Although I don't think I ever wanted to particularly.

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