caipi

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?).

Hi @zer0Kerbal, first of all: thanks for adopting and maintaining this mod. in short/TLDR: I recently noticed that I cannot SuperKlue-Kaboom the inline drills from KPBS (Planetary Base Systems). Is that a known issue? Is there any way to get around it or fix it? Long explanation: As I was building my Minmusbase, at some point I ran into an issue where I tried to get rid of the old, obsolete drills I no longer need. I wanted to Superklue-Kaboom them. It just created a NullRef Exception. At first I thought it could have something to do with struts or the mass and center of the base (previously added a huge fuel tank and filled it up and connected it via a KIS/KAS corridor). But it turned out that only the (K&K) Inline Drills (both, ore and metal ore) were affected. So I created a new clean install with some basic mods, KPBS and Kaboom. It doesn't appear to be a conflict with other mods. Other KPBS parts superklue-kaboom just fine. My best guess would be that it is related to the fact that the inline drills are dynamic (shapeshifting ) in their form and change when you attach objects to both sides. But I wouldn't be surprised if it had something to do with the attachment nodes and how they are set up. Or it might be something else entirely since I don't really no s*tuff about it. ;-) Here is a short log excerpt with the coressponding Nullrefs (two attempts for two parts, the inline drill attached slightly different ways): If you want to, I could provide more logs or screens. But it's quite easy to replicate and I don't want to spam you (yet) in case this is known and/or easy to fix.

@schlosrat You can also use Windows' own DPI scaling to increase the game UI entirely. Just google it. I have a 32" 4k monitor and have my DPI scaling set to 150%. For each application or game, I can choose (in the app settings via Windows) if I want to use the Windows DPI scaling or no scaling (i.e. 100%). It's far from ideal, but it's better than nothing.

Is there an option or potentially a mod that allows to change all the auto-struts at the same time in flight, just like this mod allows in the VAB/SPH? Or maybe a way to delete all auto-struts in flight (and I don't mean manually by clicking each part and changing it to none).

Going from Remobilized: Mobile Science Services - "Can you test me now?" As a reference to some mobile communication services, "Can you hear me now?" Not really a good name for a mod, I know. But it's just so silly I had to share it.

Alternatively in map view, [numpad] 1 shows the inner belt, 2 the middle, 3 the outer belt. 0 hides the radiation belts again. Just in case you don't want to go through the B-button menu.

I agree with @DeadJohn. If it reenters the atmosphere while you are too far away (might be 25 km as DeadJohn says, but I'm not sure about the exact distance), SR does nothing. I had a couple of stages in an atmospheric orbit (PE in atmosphere, AP above atmosphere). I could watch them on the map enter and exit the atmosphere. Nothing happened even when they had fuel and a command node/probe core. So my bet is #3 as well.

That's the same bug I was talking about and which I know all to well from previous playthroughs, but not from my current one (which is my first playthrough in 1.12 - my last one was in 1.10.x). Though it might just be a coincidence that I haven't encountered it (yet!). If you had said it was already fixed (before R84), I would have believed you. Yes, you understood correctly. It's still "bugged" (if you can call it that) for me. The camara elevation is consistently higher, right from the start. Starting the game (new game or resuming a game makes no difference) is enough. Maybe it can just be fixed with a new or altered setting in JNSQ? Again, this isn't really bothering me. I just noticed the altered standard behavior and wanted to confirm @Kwebib's finding/report. Honestly, I find it almost trivial. And if it fixes another bug that is slightly more annoying, keep it, I'd say. I took a few screens from a fresh install, comparing JNSQ with R83 to JNSQ with R85. The first one is the default angle and elevation when you start or switch from any planet, editor, or tracking station back to the Kerbal Space Center (no turning, no moving the camera, no zooming, etc.pp.). The second screenshot is the same angle and elevation unchanged, just zoomed in to the maximum to show the camera reference point a bit more clearly (I hope).

I already changed my angle at the screenshots to clearly show the elevation difference. Thanks, testing it right now. Taking a similar screenshot and comparing it to my previous shows no change in elevation. If you want to, I can also try a fresh/clean install with KSP, kopernicus, JNSQ (+all their dependencies) later. As for your previous question, what's worse, sinking bug or elevation/angle bug. I consider the sinking bug worse (or annoying) and the elevation/angle as merely cosmetic. The latter is nothing that would bother me. Although I haven't really encountered the occasional sinking bug in a loooong time. Now that I think about it, I don't think I've ever encountered it in my current KSP 1.12(.3)+JNSQ throughplay, starting with Kopernicus R70 or so. Though I haven't gotten very far out yet (Duna/Eve) - maybe that's related. Dunno.

I'm also using JNSQ and I can confirm the change in camera position with R84.

I believe you can find the consumption rate in \GameData\KerbalismConfig\Profiles\Default.cfg. You'll probably have to edit the rules for eating, drinking, breathing and reduce the rates to 0. But you might also try SIMPLEX Kerbalism, which is basically a slight simplification of Kerbalism but still keeps radiation, electricity, part failure, stress, etc. It does also have a simplified life support.

To be honest, that was mostly some silly goof so I could throw in the "ultron" remark. But I think it might help with off-world production, seeing as a larger ISRU (usually) has more output (with more input, of course). I thought it'd be helpful to achieve a larger off-world/off-kerbin production with less parts. So no special or new reason behind it. Just the old "bigger is always better" thought.

Yippie, wrapper parts! I think we really don't have enough of them! And they look so beautiful, too. As usual. Question: Will you only make 12-25 wrapper parts, meaning they fit on a 1.25meter part and have a size of 2.5 meters, or do you also consider making 25-37 and larger wrappers, or maybe even 12-37 (fit on 1.25 meter parts and have a diameter of 3.75m themselves) wrappers? Maybe even via an alternative part option instead of a new part? I don't use tweak scale, so I cannot just enlarge wrappers. :-/ Regarding the ISRU/device name: I cannot wait for a 5m ISRU. Will you name it Ultra-Tron, or Ultron for short? Though I'm not sure you could slap a ™ on it.