foonix

I'd rewrite the core game systems in Unity ECS. The game would run fine on a modern 4-core system with 100+ vessels and 10k+ parts.

Thanks, glad it helps. Software development is a balancing act that depends on technical, business, and human factors. I've found that being empathetic about that helps deal with irritation from hitting "game breaking bugs" or other problems in my favorite games. Why no one did it before, well, I don't know of a specific tool for this. Programmers are usually more concerned with questions like "will it work?" "how does it work?" "What will happen if I do things differently?" The programming tool used is intended to answer those kinds of questions. The programming tool is half of the process. The text manipulation I used is the other half. The former is a tool only used by programmers, and the latter is something more known in the domain of systems administration. I happen to have both skill sets. So the group of people who could do it this way and who would want to do it may be very small.

For what I posted, I think that's actually kinda true in a way. "Lines of code" is a derided metric of of developer work output exactly because it doesn't consider human factors or things like how important a change was. But two things: Making this kind of judgment is a "preponderance of evidence" type decision, not a "my paycheck depends on hitting specific numeric quotas" situation. We're just trying to judge what is more likely. So the normal objections against LoC don't really apply here if we're limiting our judgement to if the devs did something or not. The goal here is to provide some kind of objective evidence to drive that subjective judgment, one way or the other. I know a lot of stuff about the codebase that I'm not sure I can share here in more detail. I definitely have some anecdotes from development of my KSP2 mod. I've gone back through some of KSP2's performance issues I've addressed and checked the relevant code in KSP1. My "human factor" impressions from that experience are in line with the data above. Even some "re-used" code received significant code refactoring. That's why I thought it relevant to include both the class names and the LoC in the data. If you want to know more, ping me on Discord I guess. Code and data tend to be coupled. Changing scenes, object hierarchy, etc will tend to result in changes to the code. If they didn't change these things, their would be no need to change the code. If they did, they'd probably have to. Unity hasn't fundamentally changed much in terms of basic handling of such things. You still use stuff like Instantiate() and GetComponent<T>() and the like to do the same things. So broadly speaking, I'd expect these things to be reflected in terms of code change. But oddly enough, a lack of such coupling in a specific system is one of the performance issues I've tried to address by modding. But it's clear to me that the system was reworked, and that rework is reflected in the numbers. So, you know, it's complicated. vOv

Background There has been a lot of debate on the internet if KSP 2 is just "ksp1 but new graphics", or if there is some common code heritage, or to what extent the developers might have been ordered to "not change KSP 1 code when developing KSP 2." Personally, I find this debate moot. The idea of "reusable code" is a goal and cornerstone of many software design philosophies. And yet, with time, change of circumstance, change of technology, and change of goals, code will need to be modified to adapt. Even a from-scratch rewrite can result in substantial similarities, or even some identical code, because the rewrite is tying to solve the same set of problems. Re-use of code (or lack thereof) thus speaks to neither the code quality, developer "laziness," or "legacy baggage." It is possible, for example, a developer to not waste time modifying some old code because it happens to be working just fine. But some cursory analysis and a little set theory can shed light on to what extent code might have been used "as-is", at least. This study compares the class/struct names and distinct behaviors of code to look for overlap. The assumption is that as KSP2's development progressed, changed or added code from KSP1 would generally tend to reduce the number of identical behaviors. Holding over more code from KSP1 would tend to increase the number of identical lines. Methodology This study compares the KSP1 and KSP2 codebases by analyzing differences between Assembly-CSharp.dll in the two projects. The releases compared are the portable windows versions of KSP 1.12.5 (sans expansions), and KSP2 0.2.2. In a Unity game, Assembly-CSharp.dll is where most of the game code lives. The developers can use additional 3rd party DLLs, and can put some of their game code in other DLLs. But both projects put the lion's share of the game-specific code in this dll, so focusing on this gives a good indicator of similarities or differences between the two games, while reducing the amount of 3rd party code that is considered. (3rd party code CAN go in Assembly-CSharp.dll, but it's not the norm for large 3rd party libraries.) The code was analyzed with a tool that is commonly known among C# developers. The output of that tool is certain important textual analysis information about the DLL. The text output will tend to change depending on what the DLL does. I can't name it here, but if you ask a skilled C# developer to name two or three tools off the top of their head they might use to compare managed DLLs, the tool used here would probably be one of them. A few files (csproj and some automatically generated Unity files) were manually deleted from both output, as they are not relevant to what we are trying to analyze. Classes names were determined by the filenames output by the tool. Namespaces were ignored. The text was then converted to Unix LF and run through a series of unix-style text processing and munging steps. Empty lines were removed. Leading white space was stripped. Outputs were de-duplicated (the same behavior shared between multiple classes/methods is only counted once) The separate set of text lines from each output were combined, then run through more process to determine the set intersect and set union. ("cat ksp1-uniq.txt ksp2-uniq.txt | sort | uniq > lines_set_union.txt" and again with "uniq -d" for the intersect) The text in the resulting files were counted with "wc -l" to get the data for the below tables. The resulting line and class counts are intended to represent a VERY rough (See "Limitations") gauge of similarity. Study Limitations I don't have a good way to address the "Ship of Theseus" problem with this kind of analysis. It can't address, for example, if a class was sufficiently reworked to not be considered the "same code but with minor changes." I can only look for stuff that is exactly the same. Similarly, I can't tell if brand new code just happens to look the same as the old code. I wasn't standing behind the developers when they wrote it to check that they weren't just cribbing old code and that getting the same results is just a coincidence. There are some cases where more than one class share the same name but exist in two different namespaces. For example, "Wheel" and "VehiclePhysics.Wheel". Due to the fact that I'm blindly text munging, the total classes in a game (which includes classes with the same name in different namespaces) won't add up exactly in the overlap totals (which don't). I'm just trying to get an approximate estimate here. Although I'm using the same tools to analyze both projects, It's possible that the same source code can appear different due to difference in compiler versions. KSP 1 uses an older version of Unity, which could output different Intermediate Language for the same source code, which is what I'm actually analyzing. (This isn't straightforward to fix without access to the actual source code.) There is definitely code in KSP2 that comes from KSP1, but is totally unused. No attempt is made to eliminate this code from the results. See for example, KerbalFSM, KFSMState, KFSMEvent, probably a bunch of of other stuff. This does not compare things like shader/compute code, which is not part of the dll. Results Class set intersect (possibly shared between projects) 587 classes Class set union (all unique class/struct names across both projects) 8,869 classes Line set intersect (possibly shared between projects) 26,683 lines Line set union 434,801 lines KSP 1 KSP 2 Total classes/structs in project 3,298 6,193 Classes/structs not in the other project 2,711 5,606 Unique class percentage 82% 90.5% Total (deduplicated) lines of code in project 214,272 247,212 Lines of code not in the other project 187,589 220,529 Possibly unique percentage 87.5% 89.2% My own rambling analysis after working extensively on KSP2 and briefly thumbing through KSP1 Regardless of how it happened, KSP2's codebase is wildly different from KSP1. Major systems have been significantly altered or radically replaced. Some systems have been converted to burst jobs or even rewritten as compute kernels. The basic "spine" of the game is radically different. They are just wildly different animals that happen to live in the same cage (Unity) and eat the same food (parts/vessel/physics/orbit/terrain simulation). The amount of engineering that went into KSP2 (regardless of what one might think of the results) was significant. A few bits here and there seemed to hold over. A few bits are still in the files but are vestigial. But I don't think suggestions that they are significantly the same really hold up.

What's the trick? Open the the game installation folder go to the KSP2_x64_Data folder Open boot.config with Notepad (or other plain text editor) Add the following settings to the existing ones: gfx-enable-gfx-jobs=1 gfx-enable-native-gfx-jobs=1 Save and restart ksp2 What difference does it make? Here's the difference it makes to the camera rending with a "minimal" test with 36 parts in Kerbin orbit on my computer. The difference increases as part count increases. (300 frames, blue/left is without the settings, orange/right is with the settings) There is a slight additional bump in performance, because Unity can start the next frame loop while the graphics thread is still working on the previous frame. On my machine, this is about another 0.7ms. Total FPS went from about 38.19 (median over 300 frames) to 40.98. Not huge, but something. The difference scales up with part count and in more complicated situations like on the launch pad. So the above test can be thought of a minimal increase. Here is 200 parts on the launch pad: (300 frames, blue/left is without the settings, orange/right is with the settings) So saves about 3.7ms off for a larger vessels. A minimum of -2.84ms in this test. Not bad.

If you are using portable zips, I recommend to BACK UP YOUR FILES NOW.

Leaking the project source files wouldn't really be all that helpful, because it's not like modders could turn around and distribute modified versions without permission. Now, if they'd shipped unused assets in the game files with the game, it might be possible to write mods that integrate those into the game. But alas there is no one to do that and it's still pretty unlikely.

KSP2 WorldVis A visual asset and mod development tool for KSP2. This project also serves as an example of how game resources can be integrated in the editor, and a demo of BundleKit (WIP alpha code) See the github README for setup instructions. Features: Run PQS planets in the Unity editor. Get instant feedback when developing planet assets. Planet debug visualizations. LookDev part assets against actual KSP2 shaders, etc. ThunderKit Addressable browser provides easy viewing of stock parts to use as examples and view material/behavior layouts. Zip around Kerbin at mach 50 while making wooshing noises PQS FreeCam demo video: https://vimeo.com/970942659/f9acd8a73b License: MIT (TunderKit/KSP2UT editor package dependencies under their respective licenses) Source code: https://github.com/foonix/Ksp2WorldVis/ Known issues: Some features such as science and biome overlays do not work due to lack of appropriate overlay shaders. Some objects on Kerbin throw errors due to lack of GameManager. Burst compilation does not work, leading to increased CPU usage for PQS jobs. This is a limitation of Burst in precompiled assemblies, see here. Possible future work: I'd like to integrate this with some kind of part/planet loading framework so that part-only or planet-only mods can be exported directly. There is code in the game to bake scaled space planet textures from the PQS mesh. Adding a feature to run it could greatly simplify development of custom planets. Screenshots: KSC Debugging Feature Screenshots:

Can someone go poke whoever is keeping the PD website alive to add the download link for new version? I might be the only person who didn't buy it on Steam, but gosh darnint

The game assets contain a set of prefabs for a lot of IVA components. Foot pedals, seats, displays, etc. What seems to be missing for some capsules is the specific interior geometry. (I haven't checked if things like the IVA displays actually work.) Some capsules do have pretty good interior geometry, from what I've seen. But to mod IVA in, someone needs to figure out how to enable IVA in general, and then someone probably needs to get the displays working, and then finally people can finish modding in geometry for more craft.

MSAA doesn't work with deferred rendering in Unity. KSP2 mainly uses deferred rendering. TAA works with URP and HDRP, in both deferred and forward rendering. The devs stated they plan to move to HDRP, so TAA might become available as an option if/when that happens. (There are some complications to make TAA work right with certain kinds of materials, so maybe not right away.) HDRP's "Forward+" rendering mode does much better with multiple lights than normal forward rendering. So it is possible that if they allow using forward mode in HDRP, then MSAA might also be possible. But that's kind of a stretch in this situation. For example, they can't control how many lights a user stacks in the same place. So, if the user stacks too many lights it'll create garbled lighting, because there is a hard cutoff to the number of lights that can stack in the same screen tile.

I hadn't had a chance to really watch it but just remembered this was here Can they do it independently? I think so. Nothing in CBT is married to HDRP. Would they want to? It's hard to say. If I were in there re-engineering the system knowing I'd eventually have to do it in HDRP anyway, I might want to target HDRP in the first place. Nothing jumped out at me as being impossible to do as part of the background render or in a custom render pass. It's just that engineering the color sampling to work with both their current PBR and HDRP's PBR seems like a lot of unnecessary pain. I learned a few other things watching though. Apparently the artists wanted to control the ambient light map in a way that has different emphasis for things like specular bounce, and such. They mentioned it is done from the cubemap sampling side, but for HDRP I believe the cubemap sampling is down in the guts of the HDRP/Lit shader, which has strict limits on what can be change about how light interaction works. So this will probably have to be moved to the cubemap generation process, which can be controlled from code. This throws some more complexity into the conversion process I hadn't realized. They may have to use different materials to render the planet when doing it in the cubemap to get this kind of effect.. which is doable but needs retooling and then an art pass to re-evaluate what they're trying to do works. But imagine something like this, potentially: you pan the camera at the Mun surface and the stars fade out as the camera focuses on the surface detail, then look back up at the sky and the surface washes out a bit while a sky full of stars and Kerbin comes back into focus. They mentioned that they control the directional light intensity based somewhat on the SOI.. that adds a lot of work I hadn't thought about.. at minimum will need an artist to take a pass at tweaking the levels for hdrp to get the desired look. From their diagram, they're probably not really following the inverse square law, which is fine, but this tells me perfectly realistic lighting isn't the goal. But HDRP could also open some opportunity to do things in ways that would have been hard with the current system.. they mentioned trying to adjust the light brightness to get a "moon landing" type feel to the images. HDRP has a notion of camera exposure control, so this kind of thing can be done not only based on SOI but also auto exposure change based on what the light levels are in the camera. Moon landing pictures where the stars aren't visible and the shadows are very hard, that is actually a byproduct of the interaction between the light levels and the exposure settings that had to be used in order to get any picture at all. HDRP should be able to do that kind of thing maybe a little bit too accurately. It can reproduce various physical camera artifacts at a very low cost as well.. I think the total difficulty is going to swing heavily depending on how hard they want to preserve prior artistic choices, and the willingness to lean into the new system to make different (potentially as good?) choices. My heart goes out to the graphics engineers and artists who are working on this... time to start sacrificing some Kerbals to the Kraken

After a lot of poking my nose under the hood, I have to say I'm pretty excited about HDRP. Below are just my random assessments and observations. KSP2 uses unity's legacy built-in render pipeline, but "retrofitted" with a lot of HDRP-like features. For instance, they're already using PBR-style shaders that use a cubemap for environmental lighting. HDRP uses PBR by default, and its "Environmental Lighting" system also uses a cubemap. KSP2 uses third-party deferred light/shadow shaders that support soft shadowing, where HDRP supports PCSS and screen space shadows out of the box. Most opaque materials in KSP2 use deferred rendering, but transparent materials use forward. HDRP supports mixed deferred and "Forward+" rendering, which may perform better in certain lighting situations. KSP2 uses some of the post-processing effects HDRP supports. However, HDRP combines a bunch of them into a single "uber shader", where as the old render pipeline has to apply them one-at-a-time while moving the result between buffers. There are various other postprocessing quality improvements available such as SSAO. KSP2 uses camera stacking for certain things like UI layering. Camera stacking is generally a bad idea in HDRP, but HDRP has features that would eliminate the need for most of the cameras. I've done a single camera that can render out to 100km, and the PQS/CBT might want to be engineered not as a separate camera (see HDRP "custom pass"). The UI camera can probably be eliminated just by moving the UI shaders to the right draw phase. So basically, it might be possible to shove the whole camera stack into one camera. Although HDRP cameras are a lot slower than old cameras, eliminating extra cameras has the benefit potentially reducing the number of culling operations, which might partially make up for it. KSP2 uses a setup that pumps planet cloud data into the volumetric cloud system. I've not used HDRP clouds so I can't comment on how "easy" this would be to use, But, HDRP's various volumetric effects are integrated with each other. For example "god ray" effects would be out of the question if volumetric processing is already turned on. IMHO a big potential win, from a performance standpoint, is might be SRP batching. In certain situations (eg, landed at KSC), draw call batching takes a significant portion of the frame loop. KSP2 uses instancing for a lot of the terrain clutter, which is quite fast in theory, but in practice gets split up into tiny batches due to a combination of material differences and distance sorting. There is potentially some chance to leverage the SRP batcher for this stuff, depending on how the materials are set up. Finally, a big difference is that all of the above (except PQS/CBT) in KSP2 are kind of mix and matched to work in spite of the old render pipeline, more so than with it. Doing them with HDRP means working with a product that was designed from the ground up to do these things, and shares various computational steps between them. The challenges I see: Every material needs to be retouched. At minimum, converted to HDRP/lit, HDRP/unlit, or some shadergraph shader. This process for some assets could be as simple as a tedious repack of the textures/ material. For some assets it may need to be re-baked for HDRP's specific type of PBR and AO mapping. Lighting in general works differently and needs to be retouched. Camera stacking has to be reduced. The way PQS and/or CBT interface with HDRP is different and will require reworking. However this might actually be _simpler_ as an HDRP custom pass. Environmental lighting works differently and may require some custom lighting, depending on how married to the current aesthetic they are.

I've already started working on an SRP prototype that is a drop-in replacement for the built-in pipeline in an attempt to cut out buffers and leverage SRP batching. I'll be glad to throw this out though! But HDRP is probably what I'd do if I were doing it from the source code end. There is just so much better about HDRP than builtin. But quite a lot of assets are going to have to be reworked. I can't understate how much of a challenge this is going to be.

With the dampeners turned down, it's pretty obvious that something in the system is adding energy to the system.. perfectly stationary craft will bounce higher and higher until the gear explode. Even with max dampener settings, it's not enough to stop the bouncing. No matter how heavy a craft is or how poorly aligned the gear are, a stationary craft shouldn't bounce higher on subsequent bounces.. Slashy's tweak helps a lot. The increasing bounce amplitude is still apparent with the dampener turned down.

Check that you downloaded the actual file. I tried to "Right click -> Save As" on the link above, and that was actually the page serving the file. I had to go to the page and click another download link.

Enabling surface attach also worked for me. attachRules = 0,1,0,0,0

I had this exact problem in Arch linux. mozroots didn't work, with or without sudo. ckan (libcurl) was looking for certs in /etc/ssl/certs/ca-certificates.crt. https://blizzy.de is using Let's Encrypt certificates, which were not in the open ssl trust store for the system. The following will fail if this is the problem: curl -I https://blizzy.de Once I fixed the above, ckan started working. The fix in arch, based on this document Download (do not install into the browser) the Let's Encrypt root and X1 intermediate certs from here: https://letsencrypt.org/certificates/ Copy both files to /etc/ca-certificates/trust-source/anchors/ and rename them .crt run: sudo trust extract-compat

With the changes to CompoundPart mentioned in the dev notes, would it be possible to have a piston that attaches like a strut? It could make controlling the same structure with multiple pistons easier, especially if it could function as if having a ball joint on both ends.

For working around the FAR problem, using the KerbalStuff URL seems to work

It would definitely solve the pain point of working with multiple sets of mods and fill the mod pack niche. It would also save a lot of disk space. It might be a bit tricky working with the saves. If a part does not exist when a save is loaded as I understand any craft using it will disappear. I would be worried about shooting myself in the foot switching between radically different profiles. There are some situations where it might be useful to run multiple versions of KSP its self though, such as after a new release when most mods are not compatible. I guess running multiple instances of the manager could solve this problem as well though. Another corner case may be if a mod pack maintainer needs to stipulate an older version of KSP.

Thanks for this. I've wanted a cross platform mod manager for a long time. It would be nice if it could roll a full installation from scratch. Combined with the mod list import/export, this could produce something similar to the way Feed the Beast launcher for minecraft works. It would be a killer feature to be able to click a few buttons to materialize a new KSP instance with all the mods as your favorite youtuber, for example. If a mod manager had such a feature for Interstellar Quest it would be the gold standard by now. The FTB launcher does packs really well, but it is not friendly for building your own custom installations. It might be enough to be able to "subscribe" an instance to mod pack. Maybe pack authors can just publish a meta-data URL, and the manager can poll it for updates. The meta-data would contain a list of each version of the pack, each version of each mod used therein. When the pack updates, the user is notified and can update all of the mods to the version listed in the pack.