Kerbolox

Quick question on that: Do these additional attachment nodes affect the aerodynamics of a vehicle (like how non-covered attachment nodes often produce notable drag)?

That's funny that this was the reason... indeed before the last update I got randomly thrown out of centrifuge gravity mode several times while running around in SSPXr's 'Coriolis' centrifuge. Now, after the update, that still happens in a craft that I have built before the update (am I right and the culprit is that fire extinguisher - or is it a different prop?) but I haven't been able to replicate the issue with a 'Coriolis' in a vessel built after the update. Now I thought I'd take the opportunity and report on a few other things I noticed while I was messing around for fun with SSPXr's centrifuges and FreeIva: 1. With the large 'Mercury' centrifuge it is just a little more cumbersome to get out of the gravity mode than it is with smaller centrifuges like the 'Coriolis': In the latter, when you climb up into the center section and jump once you're there, the gravity mode is easily disengaged. Instead, in the 'Mercury' I additionally had to move a bit along the center section away from where the rotating hatches are. Merely jumping while in the center section of the 'Mercury' with engaged gravity mode instead leads to a weird visual effect where the centrifuge appears to rotate very quickly as one reaches the highest point of one's jump. 2. Also in the 'Mercury' centrifuge, while climbing the ladders up to the central section, the Kerbal tends to slowly move away from the ladder. When I don't pay attention I often lose grip and fall back down before I reach the top. To my knowledge this effect is consistent with (and may actually be due to) the Coriolis force. Thus you may argue that you may want to keep it like that (even although it sounds unlikely to me that astronauts would lose their grip on a ladder because of such an effect even when not paying attention). 3. And again in the 'Mercury' centrifuge I noticed an issue with the first hatch one has to open when climbing from the outside to the center: Upon opening it doesn't get replaced with a hole but with a visual (but non-collidable) wall one has to climb through. 4. Transferring a Kerbal into or out of a spinning centrifuge (using 'transfer crew' in the parts' right-click menus) and subsequently trying to unbuckle them will break the unbuckle feature for me: The Kerbal gets stuck into a state where most of the keys will do nothing (including 'C'). Pressing 'Y' again won't do anything, either, except for displaying "Unbluckled" once more. After entering and exiting the map view, the Kerbal is reset to a proper buckled state. However from this point on, trying to unbuckle any Kerbal anywhere on the ship will get them into the same stuck state as before. I was able to fix this, e.g., by going to the tracking station and reloading the vessel. But anyhow I have to say that I am really amazed with how well the gravity in centrifuges already works. I didn't believe something like this was possible! And that is not the only thing: I have had it several times when playing around with your mod that I noticed, you know, an inconvenience or something that felt like a missing feature, but I (who by the way really has no experience at all with real programming) thought: "Yeah, this probably can't be fixed and it's a sacrifice one has to make for this mod's awesome functionality" or "well, maybe at some point in the future they will tackle this but it's probably far too ambitious for now" - only then to find out that this exact issue was already in the list of planned features on your github and was already being worked on. So, that is to say, I love your ambition and your dedication to make this mod into a masterpiece. I hope you'll keep it up! (Besides, I'd be willing to call it a masterpiece already now, just for the idea and how it allows you to really 'feel' your spaceships and space stations. It's so cool.)

Hi everyone , I've got a little story to tell you that will end with a couple of questions on how the configuration of engines with multiple nozzles works. But before I start, here is a... TLDR: How can I configure an engine with multiple nozzles in KSP? And is it possible to tamper with the multi-nozzle configurations of stock engines by modifying their config file? If yes, how does it work? Okay, so I have been a little dissatisfied with the stock Launch Escape System for quite some time. It does its job when aborting mid-flight, even although in many such occasions it would also be sufficient to simply shut down all engines and decouple the command pod; but the LES's miniscule amount of propellant gives it far too little burn time to be useful for an abort on the launch pad. Instead, if it had more fuel, it could really be used in those situations where one builds a far too big and too unstable rocket that spontaneously disassembles itself right on the pad, to pull the capsule to a height large enough to deploy the parachutes and land safely back on the ground. Thus, in my KSP 1.8.1 install, I decided to give a look at the LES's config file and see what I could do to "improve" it. I have little to no experience with KSP modding, but still, increasing the amount of fuel in the LES was simple enough for me to manage that. However it then turned out that there is a problem created by the fact that the net thrust generated by the LES is angled with respect to its vertical axis. Once the burn time of the LES is more than fractions of a second, this will lead to the capsule spinning out of control quickly and stop it from gaining height after a pad abort. Therefore, I gave the config another look to figure out what I could do to reduce the amount of torque the LES induces. Unfortunately, I haven't been able to find anything that I can do to modify the center of thrust or the angle of the thrust the LES generates. My feeling is that the direction of the thrust the LES generates is computed internally by adding up the thrust of all its five nozzles, and therefore there is no single variable that determines the direction of the net thrust. Then, I'd only have to modify the configuration of the LES's off-center nozzle at the top to make it less off-center. Unfortunately, I haven't been able to find anything in the config file that seems to configure the multiple nozzles, their position, rotation, etc. and moreover, I also haven't been able to find any information on that anywhere else. So, in case someone reads this who knows how to configure multi-nozzle engines, I'd be very happy if you could explain it to me. Maybe it is configured somewhere else than in the LES's config file? Maybe it is not even possible to tamper with the multi-nozzle configurations of stock engines? Or maybe I'm just blind ? I just don't know and I'd appreciate any hints that you can give me. At least I am pretty sure that multiple nozzles have to be configured somewhere. I have RealPlume with stock configs in my install and for the LES it only configures a single plume which is automatically attached to each of the five nozzles. And here is a second issue that I am having: I find the plumes way to underwhelming for the thrust the LES generates, and I would like to make them much larger and longer. However, increasing the size of the plume also increases the size of the plume emerging from the little nozzle at the top, which I don't want. So I am guessing that what I could do, is to remove the top nozzle from the config and then manually add a small plume to it in a similar way it is done, for instance, with the turbopump exhaust plumes of various engines (like the ones in the ReStock mod for example). But before I can do that, again, I have to know where the multiple nozzles are configured. So, if you have any answers to my questions or any other suggestions you can give me on those problems, I'd love to hear them!

I have recently done some testing with KCT and KK with Kerbin Side Remastered (KSR) in KSP 1.8.1 and I have also experienced some strange behavior with the launch pads KCT offers. Since I have seen this post, I'd like to share my experiences as well. I have first tested Sandbox mode, and everything was looking geat: KCT did allow me to launch from KSC, Woomerang, and Dessert, but not from any of the pads added by KSR. After opening some of the KSR pads through the KK UI, they got available in KCT as well (not immediately in some cases, but after entering and exiting the VAB once, they always ended up showing up in KCT's "select launch site" list). After closing some of the KSR pads again, they also disappeared in KCT (again possibly after entering and exiting the VAB). However, in Career mode, things were looking different and quite weird. KCT did not offer Woomerang and Dessert any more (which is fine and to be expected), however on some occasions, it offered all KSR pads, even although I had not opened any of them (and some of them were even hidden, i.e., they don't show up in the Tracking Station or any of the KK menus until they have been discovered). Then, after getting into KSP a few days later, I was suddenly only offered a selection of those pads (namely the non-hidden ones, however independently of whether I had opened or closed them in the KK menus), and I can't think of any reason why (no mod installs, resets, or career progress made in the meantime)... I have made an observation which might have to do something with this behavior: With KK installed and in Sandbox mode, when you are in the VAB, all the launch pads opened in KK will be added to the drop-down list of available pads below the launch button. However, in a new Career game, this drop-down list is not available. So what I imagine could be the case, is that, more or less, when that drop-down list is generated, KK saves all its opened pads to the pads that show up in this list, and KCT gets the pads it offers from the same location (this might also explain why I had to enter and exit the VAB for the list of pads in KCT getting updated in Sandbox mode). And since in a new Career game, that drop-down list doesn't show up, things are somehow messed up... if all of that is true, then I imagine, this is rather an issue with KK, and it would have to improve the way it communicates to the game which pads are available, in order to be better compatible with KCT. However, that is only a theory. I might very well be completely wrong with all of this. And finally I have noticed something else that I'd like to ask about: When you want to launch a vessel from a KK pad in Career mode, the size restrictions that apply are the ones of the KSC launch pad that is currently selected in the KCT menu. Instead, KK launch pads usually come configured with their own specific size restrictions. Is there anything one can do to make KCT use these size restrictions instead, or is this issue simply something one has to accept when combining KCT with KK?

Hey @garwel, thanks for the reply. Cool, it is really awesome to hear that! Thank you for giving it a look! Thank you for the explanation! Yes, I agree that I haven't really thought that through. In fact, the surface of a vessel is not the main factor to determine by how much radiation it is getting hit. Instead, you'd much more care about its cross-section area with respect to a certain direction... what I mean is, take a plane in space (for example the one perpendicular to the incoming radiation from the sun), project the vessel onto this plane (so that it becomes flat) and measure the area of that projection. Then, to avoid having to account for the current orientation of the vessel, you could average over all the possible orientations the craft can have (or, alternatively, assume that it is getting hit by radiation uniformly from all directions). Now that I think about it, it looks like a really interesting mathematical problem to understand how the geometry of the vessel affects this average and the way it scales with the vessel's volume . For a large vessel that extends into all directions of space, a volume^(2/3) - law sure looks like the right thing to me. And then there is of course another effect, which is of physical nature, namely that not all the radiation is getting blocked by the occluding part, but a small fraction of it could still hit parts behind it. I agree with you that coding all of these effects would be much too complicated, especially for your Kerbal Health mod, since I consider it to be one of its strengths that it offers a very nice balance between simplicity of the underlying mechanics/maths and the depth of gameplay and realism it adds to the game. I really like it when you calculate radiation by a simple rule of thumb that yields reasonnable results. And now that I take parts occluding each other into account, I understand that your volume^(2/3) - law is a good choice. Ah okay, I understand your idea. Thanks for explaining! When I was doing some testing before, I usually ended up adding uncrewed Mk3 Crew Cabins to the vessel because they offer the highest base living space. Then I got annoyed a little because these Cabins don't really fit most space craft designs . Now I think that, before I give a closer look at these configs, I'll play around a little more with command pods to see whether I can design some vessels that look fitting to me and end up having living space / comfort values that I like. From a realism perspective, though, I think I am still a little more into the idea of crew compartments (especially the modded ones I have mentioned) providing both living space and comforts, because that would make sense for me from how their models and interiors look like. However, I can't say how much that would hurt gameplay... In any case, I am looking forward to seeing what ideas you will come up with when you eventually start working on the task of rebalancing the parts .

I am also using Click Through Blocker in "focus follows mouse" mode and it also happens to me from time to time that inputs get locked and I cannot interact with the KSC scene any more, even although I have closed all dialogs. I find it a little annoying, too, however for me it always works clicking on the "Clear all input locks" button in the toolbar (some mod must have placed it there exactly for these situations you and me are experiencing from time to time, not sure which one though, might actually be Click Through Blocker itself?). It's the button inside of the red circle in the second image you have linked and I find it much more convenient to use than going into the debug console every time . Actually I was thinking that this is a rather common issue with Click Through Blocker at the moment and that many mods that contain dialogs can cause this (and not only KCT). But to be honest, I have never really paid any attention to when exactly I am experiencing these input locks and I'll have to do some testing to be sure. Hey everyone, while I'm here, I'd also like to ask a short feature-related question: When I open the KCT settings with a right-click on the KCT button in the KSC scene, I can find the settings "inventory effect" and "build effect". Does changing these settings have any effect on the game play when the Scrapyard mod is not installed?

Hi @garwel, first of all I'd like to say that I absolutely love this mod - already from only reading about its features and doing some testing with it . In my opinion, the way it offers an alternative to both Kerbalism and Crew R&R is just great. What's more, I am deeply impressed by your dedication for this mod, providing updates and adding new features regularly and also, providing compatibility patches for a large amount of mods. I find the latter especially noteworthy, since I have the impression, that the way things usually go, is that mods that add parts provide patches to ensure compatibility with other mods like life-support mods, and not the other way around. So, it's a great mod and looking at the download numbers in CKAN, I believe it would definitely deserve to be much more well-known. I have actually started to do a little bit of testing with this mod like a year ago or so and back then I have noticed a few things that I wanted to tell you or ask you about, but I somehow didn't get around to it. Now I have given it a look again and have noticed that some of the things I encountered back then, have already been fixed in the meantime . Still, there are a few things, I'd like to ask about: 1) It looks to me like if you launch a vessel with a Kerbal assigned to an external command seat, KH will not classify the Kerbal as on EVA. On one hand, this means they will not lose HP for being on EVA, but on the other hand, if the vessel does not have any other crew compartments, the Kerbal will lose a huge amount of HP because of the lack of living space. Instead, if you launch a Kerbal in a vessel, let them EVA and sit in an external command seat, they are still classified as on EVA, so I believe that is what should happen when you launch them in an external command seat as well. 2) I was a little surprised when I noticed that bolting to a command pod another command pod with the same amount of shielding reduces the radiation exposure Kerbals get. According to the wiki, the amount of shielding you need for a certain exposure to radiation increases with the power 2/3 of the vessel's crew capacity. This absolutely makes sense when you assume that the vessel has the form of a sphere (or any other geometric object for that matter), so that its surface area is of the order (volume)^(2/3). However, I believe that in practice you much more often have the case that X times more crew capacity on your vessel means that you have X times more parts that can house crew, which all have roughly the same amount of surface area, so in total you end up with X times (and not X^(2/3) times) more surface area. For this reason I think I would rather choose a linear scaling (or maybe a scaling with an exponent closer to 1 than 2/3). So, I'd like to suggest to maybe consider changing the exponent. However I don't want this to look like I ask/expect you to do so. I totally understand it if you want to keep it at 2/3 and I love your mod no matter how you decide . 3) I have a question about the amount of living space some of the habitats (especially in SSPXR and KPBS mods, but applies for instance also to the stock Hitchhiker container) have: Usually they have considerably less living space per crew capacity than command modules, even although in many cases their models and interiors look more spacious. Instead, they often have a special module that reduces the HP loss due to living space for a certain number of Kerbals by a certain percentage. I however have the impression that, in order for these modules to pay off and allow for long-duration space flights, one also has to add an (ideally uncrewed) crew compartment with a high base living space to the vessel. For this reason I might want to write my own configs with living space values that seem fitting to me, but before I do that, I wanted to ask whether, when designing the current configs, you have had some specific design/balacing considerations in mind, which I may not have understood. Thanks in advance for giving these things a look, and thanks a lot for this awesome mod! I might do some more testing on it in the near future and if still I notice something else, I'll let you know.

Hey there, I have recently done some testing of this mod (v1.0.1) together with Kerbal Konstructs v1.8.1.15 and Kerbal Construction Time (v1.4.8) (all installed via CKAN) in KSP 1.8.1 and I have noticed a few things I find weird and I would like to ask about them. I am quite new to all of the three aforementioned mods and I'd like to apologize in case I am missing some obvious things. Also I imagine that some of the things I am asking about actually might not have anything to do with KSR but with KK or KCT instead, in which case I am sorry for posting them here. Anyway, I am very glad about any kind of help or hints that you can give me. 1) I have experienced the same issue as @Manul, even although I am still on KSP 1.8.1: To my current knowledge KK hasn't been updated to 1.9.x yet, this is probably a PQS issue. If @Ger_space is available to chime in. 2) Also, I have noticed that, in the UIs provided by KK, the South Lake launch side belongs to the category "Other". I assume, it should be declared as a runway instead? 3) I am seeing a texture on the Kojave Sands base that looks a little strange to me: I have first thought that it is intended to be like that, but then I have seen the image linked in the first post of this thread, where the texture looks different. So I'd like to ask: Is the texture that I am seeing the one I am supposed to be seeing, and if not, do you know how I can fix it? 4) In the vicinity of several bases I am seeing some ugly terrain spikes: I am assuming this happens where the terrain, that has been modified using KK tools, transitions to the original terrain. However, I haven't found anyone who pointed out this issue, neither here nor in the KK thread. Therefore, I wanted to ask about it to be sure that I am not the only one having these spikes and that it is just something one has to accept. Or did perhaps something go wrong with my installation? 5) Finally, I have encountered something that completely confuses me, because I am unable to see any logic in it: As far as I understand, some of the KSR bases, e.g. Kerman Atoll and Baikerbanour, are hidden at the start of a new game and have to be discovered first. In a newly started Career game, I cannot see (and access) these bases from the tracking station and they also don't appear in the list of launch pads that pops up when pressing the KK button in the VAB. In contrast, some other bases, e.g. Cape Kerman and Kojave Sands, are accessible from the beginning on via both facilities. Instead, in Sandbox mode, things are a little unclear, because the hidden pads do not appear in the VAB but DO show up in the Tracking Station and can be opened from there without sending a vessel to them first. After doing so, they also show up in the VAB. When I did some testing in Career mode a few days ago, KCT however allowed me to launch vessels from all KSR launch pads, whether visible/discovered or not (and actually also whether opened or not via the KK base manager). (I assume, this is either a KK issue or a KCT issue, but it confuses me a lot, because in Sandbox mode everything works exactly as expected: KCT allows a launch pad to be used only when it is discovered and opened.) After launching a vessel from one of the hidden pads, they became visible both in the VAB and the Tracking Station, which is exactly what I expected: I suppose, by having a vessel nearby, I have discovered them. However, when I loaded up my savegame today, they were now hidden again! (Moreover, KCT did no longer allow me to launch from them. However, I could still launch from the non-hidden bases Cape Kerman and Kojave Sands, even although I haven't opened them...) So, since I seem to lack the understanding of how hidden bases and discovering (and opening) of bases really works, I would be super glad if someone could explain these things to me. And are the things I have experienced intended to work this way or are there some bugs I have encountered here? Okay, I believe this post is more than long enough for now ... I'd be very happy about any hint you can give me on any of my issues and thank you in advance for any help.

Aaaaahh, I see, many thanks for the hint! Cool! Waterfall looks really promising to me and I'd love to see it on those Merlins!

Hey there, I seem to have come across a weird little bug, which makes a fully built vessel disappear from the KCT build list. I have first experienced this issue in a KSP 1.8.1 install but have been able to reproduce it in KSP 1.10.1. Here is my modlist for the latter install: Animated Decouplers Click Through Blocker Kerbal Alarm Clock Kerbal Construction Time 1.4.8 MagiCore 1.3.2.3 Module Manager 4.1.4 Retractable Lifting Surface Module Scatterer Scatterer Default Config Scatterer Sunflare SpaceTux Library 0.0.3.9 SpaceX Launch Vehicles-Stock Size Textures Unlimited Toolbar Controller 0.1.9.4 Zero MiniAVC 1.1.0.1 (The mods with version numbers on them are the ones that I also have on my aforementioned KSP 1.8.1 install where the bug also occured.) I have installed all the mods via CKAN. After starting a new game, the steps to reproduce the bug are the following: 1. In the KSC scene build a new launchpad from the KCT UI (didn't take time for me to finish - I suppose due to sandbox mode). 2. Enter the VAB and build a vessel (I just used a Kerbodyne S4-512 Fuel Tank with a HECS2 Core on top). 3. Add the vessel to the build list twice. 4. Exit the VAB and warp to completion of both vessels. 5. Roll out the first vessel to the original launch pad and the second vessel to the "KCT-clone" created in step 1. 6. Warp until completion of both roll-outs. 7. Press launch on the first vessel. 8. Return to the KSC scene using the stock button above the height indicator. 9. Press launch on the second vessel. A message "Launch Pad not clear!" pops up. Press cancel. 10. In the KSC scene click on the icon associated to the first vessel (the one already launched) and click on the Fly-icon to return to the flight scene. 11. The second vessel (which has not been launched yet) has now disappeared from the KCT build list (both in flight scene and in KSC scene). Before posting this, I have tried to make sure that this is not an intended behaviour of this mod (however I am really new to KCT and I'm not yet very experienced with its features) and that this issue has not already been reported. Many apologies in case I have missed something. Also, thank you in advance for giving this a look .

Hey @Kartoffelkuchen, thank you for this cool mod and especially for all the awesome models and textures! I have actually come to know this mod because of a KSP recording in a video by Scott Manley, featuring a Falcon Heavy model with the same amazingly realistic plumes as the ones shown in your video "SpaceX Dragon2 Mission in KSP with cinematic simulation" linked in your first post (which is why I assume it is this mod Scott was using, even although I am not entirely sure). Now, for me, in an install with only this mod, all the engines have stock plumes. Also, looking at the readme file and the recommended mods, and also scanning over the mods you have listed at the end of the video, I haven't been able to figure out how to get those other amazing plumes. I'm sorry in case I have just overlooked something obvious and in consequence the following is a stupid question - but I wanted to ask, whether it is possible to add these realistic plumes into my game and if yes, how does it work?

So, I recently worked on setting up an install with New Horizons and I spent some time fixing the issues I encountered with this mod. I have actually done this in KSP 1.3.1 so I haven't had any need to worry about the problem with the compatibility with newer versions of KSP. However, there still have been enough things to worry about and I would much like to post them here on the one hand to provide a reference to anyone else who may want to apply similar fixes and on the other hand to thank everyone who already posted solutions to some issues that have helped me to fix my install. On top of that I have a question in the end about one particular issue that I would like to know your opinion about . To be able to load the mod at all in Kopernicus 1.3.1.7, I have applied this Tidus fix, so a huge thanks to @Lyneira for posting it. Then I have been able to restore the colors of the rings of Sonnah and Titanus to something more reasonnable. I decided to change them as proposed here by @Micro753 and @talkItalk because I like how they look now, but I have realized that these ring colors have also been changed to different values by @linuxgurugamer in his modified version of the mod. I still laugh at myself when I think about how long it has taken me to realize that I had to change "colour" into "color" in the "Rings"\"Ring" node in the Sonnah.cfg file to prevent Sonnah's rings to be completely black... About Arin's rings I noticed that they have the same inclination as Astid's orbit, but the planes are not aligned. I am actually wondering whether this is intended or whether Astid is actually supposed to orbit along the outside of Arin's rings. Since Astid's description seems to indicate that Astid may originate from a different impact than Arin's rings, it might actually be intended the way it is, but to me it seems more reasonnable to see Astid as a piece of rock which is part of Arin's rings, in which case the planes should be aligned. I haven't tried it myself yet, but I think adding the line "longitudeOfAscendingNode = 50" inside of the "Rings"\"Ring" node in the Arin.cfg file should align Arin's rings with the orbital plane of Astid...? I have also added back in Eve's rings which were included in previous versions of New Horizons and they make me quite happy, because otherwise Eve feels so "unspecial" since it has no moons and is already included in the stock game... Next, I have to say a huge thanks to @linuxgurugamer for his version of the mod, which includes Derso's textures. I actually hadn't realized myself that they were missing up to the point where I found your post about this issue in this thread Finally, I noticed two issues with the atmospheres of some of the atmospheric bodies in New Horizons. I found these problems when I tried to send a jet-powered plane to Sonnah, have it fly around inside of Sonnah's atmosphere for a while and finally crash into Sonnah. The first issue is that in my install, Sonnah's atmosphere has been light green. It has taken me a while to figure out that it is actually the color of Jool's atmosphere that I have been seeing. This might be an issue that has been fixed in more recent versions of Kopernicus, but it seems that the "AtmosphereFromGround" node inside of the "Atmosphere" node of a body's config file makes Kopernicus ignore the "lightColor" value provided in the "Atmosphere" node and replace the color of the body's atmosphere by that of its template body given in its config file. In case of Sonnah, the template body is obviously Jool, so I removed the "AtmosphereFromGround" node and Sonnah's atmosphere became blue . To be honest, I don't know what "AtmosphereFromGround" actually does, but so far I haven't encountered any issues... also the fact that many of the planets don't include an "AtmosphereFromGround" node in their config file seems to indicate that it is not necessary to have it. Apart from Sonnah, also Titanus and Arin have an "AtmosphereFromGround" node which I have erased. In case of Titanus the difference in the atmosphere's color is not so visible but in case of Arin it looks really odd otherwise since Laythe's dark blue atmosphere doesn't fit at all. The second issue is that the Panther engine I used on my plane has only been able to deliver a thrust of up to 20kN, even in afterburning mode and deep inside of Sonnah's atmosphere. Inspecting Sonnah's config file I realized that the "atmosphereMolarMass" value inside the "Atmosphere" node has been set to something like 0.000179999990016222 (kg/mol). This value is the same as for the other gas giants Moh and Vanor. I don't know whether this is intended but this value seems unrealistically low, especially for a planet that is supposed to have oxygen inside its atmosphere, given that the lightest gas that exists (Hydrogen) already has a molar mass of 0.00202 kg/mol. Even although the molar mass in Sonnah's atmosphere is so low, one does not experience a large difference in drag when entering it, because on the other hand, the atmospheric pressure rises much faster than for the other bodies (the same again being true for Moh and Vanor). There however seems to be much less heating due to atmospheric entry with these settings... In the end, I have reworked the atmospheres of all of the celestial bodies in New Horizons, but at least those of the gas giants should be changed in my opinion. After having changed Sonnah's atmosphere accordingly, the Panther engine also performs much more reasonnably. Finally I found the issue that none of the atmospheric planets include a "staticPressureASL" value inside of their "Atmosphere" node which makes the planet info panel in the tracking station display the wrong atmospheric pressure for those bodies. Instead of their real pressure, the pressure of the template body seems to be displayed, which in most cases is Laythe, leading to a displayed value of 0.6 atm. This fix also seems to be already included in @linuxgurugamer 's version of the mod. So, about this idea I would like to say that, although I would probably not use such a release after fixing all these issues by myself, I would very much like to see something like this happen, because I think New Horizons is a great mod and it deserves to be taken care of for everyone to enjoy it with as few bugs as possible. To conclude, I want to ask a question about the compatibility with Community Resource Pack. Since I want my install to include TACLS and KPBS, I would very much like to have a reasonnable distribution of a few resources like water and atmospheric oxygen and carbon dioxide on New Horizon's planets. In the OP I have read that New Horizons includes resource config files for CRP, but I haven't been able to find them in the download. In an earlier version (New Horizons 1.5.4 or 1.6, I'm not exactly sure) I have found such config files, and I am thinking about just deleting the resource definitions for the planet Lave (which has been removed in a later version of NH) and using them in my install. Do you think this will work? In some of @KillAshley 's posts I have read that resource config files would be available in a separate download linked in the OP. Does anyone know whether this download still exists?