caipi

@ble210If you're having an issue with the "display" being only half of what it should be, make sure to install Kronometer as well. This will actually fix it! Otherwise you used double the reliability, but still have the "bugged" ingame display. Kronometer really should be installed if you are using JNSQ and Kerbalism. More about it can be found here: I suggest you read this discussion.

In 7 days, we* will all die! There is a moon about to crash into a planet. Isn't it obvious from the screenshot? *we who have seen the video and received the phone call image and read this thread. This was our 7 days notice.

Well, I fiddled around with the planetlist.cfg a bit more. I checked yours (both are actually identical according to PSPad's text comparison) and the original JNSQ-one. It has some properties which yours are lacking, such as "sunColor" (I don't know what they do, though). Since I didn't want multiple config files competing each other and only one place to edit them, I ended up incorporating most of your old settings or suggestions (here and elsewhere) into the JNSQ planetlist cfg file and deleted yours (this is just for me, but I do think it would be wiser if your install would replace the JNSQ file). This is the one I'm currently using and I think it might be a good basis for you to continue from - if you choose to use it. Just a friendly and humble offer. No guarantees though. I only learn by doing and haven't really done anything in this regard. It still has the washed out Eve and the Tam issue. Lindor looks fine to me, but I don't know what you were expecting there. As for Tam, I'll have to see how it plays out in my normal modded game, which also includes TU and TUFX. The profile I'm using there might actually hide that layer or sphere or whatever it is.

@G'th Is there a reason that there are two identical(!) planetsList.cfg in AdAstra, one in \Ad_Astra\scatterer\ and the other one in \Ad_Astra\scatterer\Planets\ ? I'm currently testing Ad Astra 1.7 in a controlled environment with just Kopernicus, JNSQ, Scatterer, and EVE and I ran into a few issues. It might be caused by an installation error on my part, though I did try to follow your installation instructions. Still, I'm doing it while I'm at work (don't tell my boss! xD ), so I might be slightly distracted and some errors might have happened after all... (just as a disclaimer/explanation). I've just checked the planets from the tracking center though. No surface contacts yet. Let's go from inner to outer planets and moons: Moho: Is it supposed to have that "dust cover" and is it supposed to be only visible if you look at it from the sun? (see screenshots). I assume this is supposed to be some intentional dust effect to be connected to Moho's low Sun orbit and solar winds. It looks nice, really nice! I'm just asking if it is supposed to look like that. Eve: It looks a bit pale and textureless (when CloudIntegration is enabled. Disabled it's black). Is that what you meant by planets being turned nearly white? I wouldn't really call it white or nearly white, but it still looks a bit overly smooth as if a texture was missing. If it's supposed to look like that, that's fine. Just asking to double check. Tylo has some weird atmosphere effects with usesCloudIntegration = True (first two images with the planet rotated a bit, to show that it's atmosphere-/lighting-related and not ground texture only). I deactivated CloudIntegration and they were gone (picture 3). Lindor: It looks a bit dark. Just doesn't feel right to me. Also, there's a weird visual glitch with the rings (last image). So I manually set CloudIntegration to enabled for Lindor and it was fixed (third image). Tam, one of Eloo's moons, has a weird almost invisible sphere. I don't think it's supposed to look like that.

When I was troubleshooting for Scatterer 0.08xx turning Jool black, I found that it only did that when I was using KSP 1.12.3 + latest Kopernicus stable + JNSQ + Scatterer 0.08xx (of course) + EVE Redux (all stock install, no fiddling around in any settings). Without EVE Redux and with Scatterer 0.08xx, Jool became green/blue again in a unique way. I didn't really pay much attention to what else Scatterer was achieving or failing at this point (compared to the JNSQ-stable Scatterer 0.0772, that is). I'm sorry I can't contribute anything else. That was my main nuisance at the time, so that's what I was focussing on. Looking forward to Ad Astra again. I loved it in the past in my previous JNSQ playthroughs. Your work is highly appreciated! (A sentence that most modders should probably hear much more often. This game has the best and most dedicated modders I've ever seen in any game.)

Or to put it in other terms, just like Bruce Willis*, Nertea is now retired (well, in Nertea's case: "from KSP1 modding and will only be providing bugfixes"). *I was going to use the name "Sir Thomas Sean Connery since he -in my opinion- showed a similar class of quality in his respective work and a I have a similar respect for his respective work. But I felt that comparing him to a late actor might be somewhat inappropriate. So I hope you don't take the comparison to Bruce Willis in a negative way, Nertea.

I'm using it in 1.12.3 without any issues.

With ScanSat, I scanned Kerbin for Anomalies and visited each Anomaly/Question Mark on the map. I believe this is the non-cheaty way to find the stations. I have only tried that in career, but I don't see why it shouldn't work in Science only either.

You are not using EVE Redux, are you? I just checked, deleting EVE and using the latest scatterer with JNSQ made Jool, well, it ain't blue or green exactly, but also not turquoise. Let's just say it made it colorful again. So I guess if you want to use eve, use scatterer 0.0772. And if you don't use Eve, use the latest scatterer? I dunno. It might just be a question of tweaking the settings properly. I just did a quick check with the "out of the box settings". I have it working in my regular game. This was just a quick test environment. As for the other part: I just overlooked your edit. I've edited my previous post to reflect your edit.

Okay, so just out of curiosity, I set up a test environment again (KSP 1.12.3 + MM + CTB + Toolbar and its controller + EVE Redux + Kopernicus + JNSQ + dependencies). I started the game a few times and checked out Jool. It was beautiful(!) and green and had a cloud layer, as expected. Then I installed Scatterer 0.0772 and started it a few times (in total more than 5, with 3 consecutive starts). Jool was still green and had its cloud layer. So it was working fine with 0.0772. The atmo.cfgs in ..\GameData\JNSQ\JNSQ_Configs\Scatterer\Planets\Kerbin and in \Jool were unchanged and still had their JNSQTag = true. I then installed the latest Scatterer (0.0834) and started the game twice. Jool was black without its green cloud layer, though it still had some lightning effects. The atmo.cfgs (Jool & Kerbin) however were unchanged and still had the JNSQTag = true. I deleted Scatterer 0.0834 and ScattererAtmosphereCache, reinstalled Scatterer 0.0772 and Jool was green again (I started and checked it twice, just to make sure). So what I can say after this test: I can confirm that the latest scatterer (anything above 0.08 presumably) turns Jool black. I cannot confirm @JebIsDeadBaby's finding that scatterer would change the atmo.cfg - at least not scatterer 0.0834 or 0.0772. Also, I cannot confirm that the JNSQTag = true line has to be missing from any atmo cfg for Black-Jool™ to appear. Also, this time, I did not have to reinstall JNSQ to make Jool green again. Which makes me think that none of the JNSQ files had been (or had to be) altered. @JebIsDeadBaby Could your atmo.cfg being altered maybe be a side effect of another mod interacting with scatterer/JNSQ/Kopernicus? /edit: Thanks @HebaruSan! I missed the edit from Jeb. I read the original post back when it didn't have the edit. My bad for overlooking that part. /edit2: I crossed out stuff that was already solved and unimportant.

@JebIsDeadBaby Just out of curiosity, which scatterer version are you using? I think at the time when I had the bug, I might have been testing/playing around with different (newer/latest/very recently updated and not recommended versions of) scatterer versions before reverting to the recommended 0.0772. Right now I'm playing without scatterer (decided it wasn't worth the trouble, for some reason - don't ask me why exactly, might have been performance or some other reason like an incompatability).

In my case, reinstalling JNSQ fixed it permanently. Applying EVE-clouds ingame (as described in my previous post) only fixed it temporarily until the next game start. But if it should happen again to me (which I doubt since the issue hasn't reappeared since), I'll keep an eye out for the JNSQTag in the mentioned scatterer-atmo-cfg file.

I've finally gotten around to finishing my Minmus Base in a JNSQ playthrough from which I should be able to build and launch any vessel in the future. How about ridonkulous? Btw, those images/this rocket looked pretty much like my first attempt to build a viable Eve-Lander-capable-of-safely-returning-to-Kerbin back in 0.23 or 0.24.

The Mod isn't dead. @RoverDude just moved his github page and forgot to update the initial post and the links. The correct link you are looking for is this: https://github.com/UmbraSpaceIndustries/MKS/releases (instead of https://github.com/BobPalmer/MKS/releases ) Direct Github link to the latest release: click me

I had that too, once. Unfortunately, I don't fully remember how I solved it. IF (big if!) I remember correctly, it was working for me at first and then stopped at some point and Jool became black*. It may or may not have been an update/install of another mod (probably the most likely cause). I tried to trace it like OhioBob suggested here as well and reduced the number of mods. In the end, I ended up with only JNSQ (and its dependencies) in a test environment and Jool still remained black. So I decided to reinstall JNSQ (first in my test environment, later in my normal, heavily modded game) and it was solved. My suspicion is that some setting got messed up along the way - or that I did an error during another mod installation. I honestly don't know. *As for the asterix on Jool being black: Again, IF I remember correctly, I could temporarily solve this ingame by opening the EVE Redux settings and just (re-?)apply the clouds (I believe it was the clouds) -without changing any settings, just hit apply- and Jool got its colors back. But restarting the game reverted Jool back to being black (not that there is anything wrong with being black, or green, or anything else). So it wasn't a permanent fix. Sorry that all my statements are so vague. It's been some time since I had that issue and I didn't write down what I did when troubleshooting the issue. All I remember is that a fresh JNSQ installation over my already heavily modded game solved the issue. :-/ I hope it helps you anyway.

You know, now that you mentioned it, yeah, I keep seeing it too in my game. Wasn't sure when it first popped up and just ignored it in my mind so strongly that I didn't even notice it anymore. xD

I think the planets fired the maid. (mhm, that pun works phonetically, but not if it's written down. oh well...)

Bug reported: https://github.com/zer0Kerbal/AdjustableModPanel/issues/30 Sorry it took so long. I didn't really find any time* before today. It seems like TUFX is the culprit/incompatable mod that breaks KAMP functionality. Let me know if you need anything else from me. I hope I didn't forget anything essential. *turns out time was hiding in my watch all along. I just had to look for it there. Silly me.

And to add to what @UnanimousCoward said: On the big map of ScanSat, you can also right click a location to bring up the small zoom map and place a marker there. I use it quite often, especially when I want to land in a small biome like a mountain top or a specific rare or exotic crater, or simply near an anomaly. And if you open Trajectories (right click on the button of the app) and switch to Target -I believe that's what it's called- you can see how far away in the X and Y axis your current crashing landing point is.

@zer0Kerbal In the 1.5.5 version (and KSP 1.12.3), some mods don't seem to like to be "removed" via AMP/KAMP. If I do that and change the scene to where they aren't supposed to be shown, they show up anyway -while others are properly hidden- and create a single NRE. Is that something you are aware of? Do you want me to create a proper bug report for it on GitHub? Or should I even wait for the new version to be compiled? Just asking before I compile a proper bug report since I'm not gonna do it on my current heavily modded game... I probably won't have time to do it before the weekend, though.

Hey everybody, just to make sure I haven't missed or overlooked something: The only way to get Bad Air right now is either by Kerbals breathing (and thereby producing bad air, maybe through farting and sweating too...) or by Atmospheric filters, right? There is no ISRU process for e.g. ore -> bad air (even as by-product), is there? Means on a planet without atmosphere, I cannot have an in situ bad air production and am limited to my current supply/closed loop. Thank you in advance. P.S.: Not a criticism or suggestion. It makes sense. Just checking if I missed anything.

Yes, Susan (Ivanova), you were right... (I think I need to binge watch B5. haven't seen it in 2 decades) But I mean, KSP is a space game, it's right there in the name, Kerbal Space Program. I think you're supposed to space every now and then. You're not just supposed to blow up huge rockets on the landing pad all the time, killing Kerbals after Kerbals in the process. As much fun as that might be. The explosions, not the Kerbal killing, obviously! I did some preliminary tests. It seems to work properly.

I think these are the wrong (old) curseforge links - both, in the initial post (quote above this text) and the last announcement (first quote). The lead to the old mod/version 1.1.0 on the page https://www.curseforge.com/kerbal/ksp-mods/kaboom Version 1.4.10 is found on https://www.curseforge.com/kerbal/ksp-mods/kabooom (with three o's). Anywho, I'll test it later today. Thanks for fixing it.

Sounds like you guys already found the cause of the problem: The drill has no node_stack_top defined in its user part and your code requires that top node. I guess that means all parts that don't have a top stack node should be affected. Do you still need me to provide more detailed logs and stuff (given that you alread found the issue)? By the way: Drills undeployed, not drilling - but that didn't make a change. I could deploy them and start drilling, wouldn't change a thing Mods are all installed manually and in their latest version, along with KSP 1.12.3 Also, just to check and confirm if that is really the issue, I changed the drill config from to Since it didn't really change the nodes (orientation and position), but only the names, I thought I'd give it a try. It worked! Renaming the nodes is a quick, dirty workaround (just in case anybody else stumbles into it before it gets/got fixed). After renaming the nodes, I could superklue-kaboom (weld together) the drills. I don't know if that creates some other issues along the way, though. So it would probably be better to fix the code - if possible. So very, very likely a silly question from somebody who never bothered to learn how to code: Wouldn't it be enough to put an if clause around the line that @flart mentioned, something like "if top stack node exist (code) else use front stack node for whatever it is you need it for (and potentially back node instead of bottom node, if it is also still mentioned somewhere)"? I'm probably oversimplifying the issue and solution here... Again, I have no coding skills!

Just a quick response before I go to bed - I'm gonna share more information and logs tomorrow. First: What an awesome video clip!!! (I couldn't put enough exclamation marks on it to signify how much I like it - but I don't want to spam you ) And I hate to correct you, but it does actually go boom. It just doesn't go super boom. I mean superklue boom. I can make it explode, but I cannot make it explode and simultaneously attach the two parts, that were previously attached to the drill, to each other. It's just the superklue function that does not work as intended with the K&K inline drills. If I try, I get the NullRef error message and no boom (No boom today. Boom tomorrow. There's always a boom tomorrow.). The superklue boom function works properly with other K&K parts, even the appearance-changing K&K Cross-Way works fine. Just not the drills. The normal boom function works with the K&K inline drills. If I have superklue disabled, it makes boom as it should. Sorry if I didn't make that clear enough in my initial post. More tomorrow (or when I find time silly alternate real life... we all know Kerbal is actually the real life, isn't it?).