garwel

I actually first heard of KSP about a decade ago from one Paradox dev quipping on their forum that he would make KSP better. That said, PDS develops very good grand strategies, but their titles developed by other companies... let's say they are not all created equal. So I'm not sure they'd handle a unique game like KSP well.

It's related to CLS integration, which constantly gives me pain in the ass. I'm wondering what kind of vessel you had at that moment. I added some null checks to prevent it for the next release. For now, you may try disabling CLS integration in Kerbal Health options.

Something is definitely wrong here. With Kerbal Health, radiation almost never outright kills kerbals. Are you sure about that? Do you have a log? Hmh, looks like some kind of radstorm-related error. I'll try to check what could go wrong (althoguh it's hard to do without a log and in a very heavily modded setup). PS: I'm wondering if he is playing an old version of Kerbal Health, which did have such issues with radstorms. This was fixed in v1.6.8 in January, but maybe the author forgot to update.

I haven't played with MKS for years so haven't really been following its development. You may use this spreadsheet to find the recommended values for the parts and even to generate patch code.

KSP1 has been my most played game ever (4000+ hours on Steam), yet that game has never really been polished. It has lots of unfinished stuff that devs started and left half-baked (consider kerbals' useless "courage" and "stupidity" values for example). So I was really happy when KSP2 was announced. I hoped it would be an opporunity to make a great game even better by producing something of a professional quality with resources of a major company. I hoped KSP2 would be deeper and more realistic than the first installment. I realized things were going wrong when I saw almost no news about development for months. The few updates we were given were nothingburgers, they were discussing third-rate stuff like kerbals' emotions instead of serious development areas like the engine, gameplay, moddability etc. Things were obvsiously moving very slow. So when they announced the release date, I wasn't happy at all. It was clear to me that the development was still in an early stage, and it was pushed out half-baked by the impatient distributor in order to get at least some of its investments back before shutting the project down. I didn't buy KSP2 (I decided that I would do it after they had a working science system and, even more importantly, moddability), but I'm still very sad to see the game die. I don't know why the development was so slow: corporate games, Covid, not enough resources, inexperienced management team or something else. But I think this slow pace is the main culprit: no one was ready to wait 10 years to publish a sequel to an already existing game.

Yes, I think I found that bug. I want to fix another issue before I publish a new release though. In the mean time, you can download this DLL and replace with it the one in GameData\KerbalHealth folder. Tell me if you encounter the issue again.

The best way is to start by training them at KSC to the maximum. The training screen in the Editor and the status monitor in the KSC/flight scene show you the more or less accurate prediction when the training should end for each kerbal. The duration depends on how familiar they are already with respective parts and on their intelligence (or rather, stupidity) stats. You may disable the latter in the settings, then they will all take the same time to train. For especially challenging missions, you may indeed have some initial training in the orbit of Kerbin or at its moons. The training speed depends on the science modifier in the relevant situation, so the more challenging it is, the faster they train.

@Syczek Could you share the whole log (not in the post, of course, use some cloud service)? Maybe sharing the save file will also help.

And here is the hot fix: Kerbal Health 1.6.8 Fixed freezes on some radstorms (the problem was due to an error in handling numeric strings) Download here

Today marks 7 years since Kerbal Health's original release, so I decided, why not make a small, long overdue update? Kerbal Health 1.6.7 Added: Support for RemoteTech's connected state, at last (as requested by @Syczek) Download here

I'll see how hard it is.

Kerbal Health 1.6.6 Added: Detailed quirk information (click ? next to the list of kerbal's quirks in Health Monitor) Added: Agoraphobic and Carefree quirks Changed: Kerbals now have a chance to acquire quirks when they first appear in game (i.e. at level 0). When you load your save for the first time after updating, the existing kerbals may acquire quirks (including bad ones), so be careful. Changed: Max number of quirks is now 5 by default instead of 2. Only affects new games. Changed: EVA factor now drains 18 HP/day instead of 8 Updated: BDB patch Improved: Some optimization and refactoring Fixed: Some factors weren't correctly affected by quirks, conditions etc. Fixed: Unstable quirk didn't affect panic attack chance Fixed: Syntax error in the MKS patch Fixed: CLS-related NRE Fixed: Minor memory leaks due to not releasing some event handlers Download here

Can you make that doc publicly accessible?

Thanks for catching this bug. I'll fix it in the next release, which I hope to post soon. The location of your logs depends on your OS and probably whether it's a Steam install. In the case of Windows + Steam, you can find it in the main game folder (something like C:\Program Files\Steam\steamapps\common\Kerbal Space Program) as KSP.log. I think that the problem in issue #169 should be fixed in the next release, although I haven't been able to reproduce it.

It doesn't look like Kerbal Health's errors. Judging by the namespace (LifeSupport), a life support mod that you are using causes the errors. As to the multiple stars radiation, I haven't played with those mods and I don't know how they are configured exactly. The thing is, KH's native radiation calculations depend on the distance from the main star. I think in multi-star mods, it's either the invisible barycenter (in this case, you may see that radiation grows as you get closer to it and not to actual stars) or one of the stars (then the others won't produce any radiation unless they have special configuration). I guess, if you also use Kerbalism and revert to its calculations, it may work better. But you are welcome to test and see what works and what doesn't. In worst-case scenario you can just disable radiation in Kerbal Health.

Depends on what you want to do. Some things, like default settings, conditions, quirks etc. can be changed with simple MM patches. They are provided in the cfg file. But if you mean actually directly altering the mechanics or adding new health factors, it can only be done using reflection and/or Harmony patches. I never quite got around to making a handy API, but at least tried to expose most things as public and extendable classes.

Can you share the entire log as a file? And please place such long fragments of text under spoiler tags or share them elsewhere.

Thanks for letting me know, will take a look.

There were some issues with the integration, and I tinkered with it recently, so I probably broke something there (or maybe CLS got updated). Will check it.

I suspect that merely fixing the existing bugs and improving performance (two highest-priority tasks the devs have mentioned) will take at least 3-4 months. Then each step in the roadmap will probably take about 6 months, so that the game will be more or less feature-complete in 2025 or 2026. I also wouldn't be surprised if some of the features wouldn't be implemented in the end (e.g. multiplayer, which requires massive changes to the game). It sounds pessimistic, but remember how many times the initial release has been postponed. I just hope the development won't be abandoned before the game is solid.

Interesting, thanks for the link,

I probably used the wrong term. I meant that this could be done using the approach of dividing space into spheres of influence and drawing the trajectory in each SOI. Of course, the shapes will be different from the current simple keplerian ellipses. But if we assume that the second most influential body is the main body's parent (which will be the case in 99.9% situations), they shouldn't be too hard to compute or predict.

It's interesting that KSP2 concurrent players have decreased and fallen below KSP1's three days after the release. How normal is that?

Problems with development were obvious from the start. All the Star Theory/Intercept controversy notwithstanding, I could see that things weren't going smoothly from the developers' comms, or lack thereof. When you develop such a complex game as KSP, you should have lots of interesting things to tell users about new and improved features. It should be getting more substantive as you get closer to the release date and more things are already in place. Instead, we got rare and often irrelevant posts or videos, and very few actual gameplay pics or footage. To me, it was a sign that development was going very slow and that there were still major obstacles. Moreover, it became clear that the game would have very few new features compared to KSP1 (namely, multiple stars, colonization and multiplayer), and almost all of them are still a long way down the road. I can only speculate as to why the development was so slow and inefficient (there are some better-informed opinions in this thread), but it looks obvious that the game wasn't really ready for release, even as Early Access. Apparently, Take 2 finally lost their patience and pushed it out. I hate to be a Cassandra and I hope to be wrong, but I feel that, unless a miracle happens and the game will be quickly fixed and improved, the development will be abandoned long before it reaches its later milestones.

Indeed, there is nearly zero chance that N-body physics will be implemented in KSP2. It's a big overhaul of the fundamental systems of the game. I have another idea that might, just might, be more feasible: three-body physics. Basically, instead of having just the vessel and the main body, the physics system might also include influence from the second most influential celestial body. It would be Kerbin when you are near Mun or Minmus, Sun when in a planetary orbit and so on. I think it could still be done using the existing patched conics approach and would be reasonably realistic while not too computationally difficult or unstable. It would allow you to have Lagrange points, for instance. The SOIs would have to be much bigger (e.g. Mun's SOI would end at a point where the Mun's influence gets stronger than the Sun's), but crossing them would have a smoother effect on the trajectory.