caipi

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.

What exactly do you mean by "smusing the stock mining with SME"? The way Simplex Kerbalism is right now (version 3.7), SME drills (in the scenario as previously described, with CRP and without Simplex Resources) have no functionality/mining option at all, not even for stock ore. All they have is "reliability" (see screenshot above). With my dirty cfg-edit that I provided above, I'm able to mine stock ore (and EL's metal ore, because I wanted it that way) with SME drills - if that is what you are asking. Just to clarify, this isn't so much a "please fix it for me". I got it working for me and I don't need any immediate help with it. (Though I do of course always appreciate a proper working config.) Please consider my report just as a general bug report about something (probably) not entirely working as intended. Take care of yourself and your health first! Don't stress yourself out over this.

First things first, I've found a bug that was driving me krazy - and the game as well as it created NaN errors en masse. The error is in KerbalismSimplex\System\ScienceRework\ScienceDefs-Stock.cfg in line 96. It prevented Gravity Scans from working properly. Well, for one, I disagree that without Simplex Resources all these harvesters -or the mod in general, which offers so much more- become pretty much useless. For one because Kerbalism Simplex requires Kerbalism, which in turn requires CRP. CRP has more than just Ore that is minable. And even if I'm only looking for Ore to mine, the different shapes and profiles still have value. But that's really debatable and not my point here and I'm not here to advertise any mod. My issue is that Kerbalism Simplex states compatibility with SME - without stating that it required Simplex Resources - when it actually completely removes the drill functions of these drills. See here: As for the necessary patches: Thank you very much! I really appreciate the offer. In the meantime, I've already created a "dirty" edit to satisfy my needs (oops, that sounded dirtier than intended ). I'll provide it here just as a basis if you or anybody else wants to expand on it. It doesn't have any localizations and the NEEDS requirements should also be reworked, probably best with excluded Simple Resources requirements. Also, since I'm using EPL/EL, I wanted them to have the option to drill for Metal Ore. As for the Water harvesting ability of the ocean drills... I don't know! Thought it'd be cool and make sense. I don't know if I'll have any utility for it, though. This one is essentially if you're using Kerbalism + Kerbalism Simplex (+CRP) + EPL (metal ore instead of CRP's metallic ore). Also, I don't really consider it "balanced" as I have no patience to properly balance it, nor do I feel objective enough to do balancing. I feel like always ending up overpowering stuff. Or the opposite because of the fear of making something OP. You mean Kerbalism Simplex removes the necessity for the complexity that CRP provides, right? With KS you have no need for all the resources of CRP. Yeah, I agree with you there. Still, you might still use other mods with KS which require CRP. And SR is not a requirement for KS, is it? I mainly use KS to simplify Kerbalism and its life support a bit. I actually don't use (most of) the resources defined and used in CRP, but I'm also not looking to introduce any new ones (such as natural ore, rare ore, etc.), either. I think this is my first playthrough without USI and its vast resource system. I like it, I like it a lot. But I found myself being more busy with building bases and what not and less with exploring any of the great planet mods and the planets themselves. So this playthrough, I wanted to focus on exploring JNSQ even though it's not my first JNSQ playthrough. But I still want the added challenge of Kerbalism. KS is actually exactly what I'm looking for in the life support and environment department. I still want to be able to build off planet, though. So I went with an all-time favorite of mine, extraplanetary launchpad/EPL/EL. It's fairly lightweight. So now, all I need to do is mine ore for fuel (cryo and regular) and for life support resources (-> organic slurry and air), and metal ore for rocket parts -> building off planet. As much as I appreciate all the resource packs out there, and I know there's a logic and reason behind all of them and they are all valid and great, I actually dislike the fact that there are so many out there as it makes it tedious for mod compatibility. I can't just go and say "oh, I want that mod, and that mod, and that mod, but not that one". I always have to pay attention if their resources and resource mods are compatible. I think I even tried SR before I started my current playthrough, but it created some issues which I would have had to investigate first - and frankly, I just didn't want to because I didn't see the added value. I actually hope that for KSP 2 we only get one Resource Pack Mod where all potential resources get defined and added (I know, this was CRP's original goal) and which gets an ingame option to activate and deactivate resources at will (or at the very least an easy config option to disable unneeded resources). That would be so great as it would declutter the game from unnecessary resources while still increasing mod compatibility. Especially if mods then only need to check if that resources is activated (e.g. in drills or ISRUs). But I'm afraid that even in KSP 2 and even if we had such a mod, someone would eventually find a valid reason to make another resource pack and we would end up where we are right now. Just to clarify, I don't want to chide, shame, or discredit any of the mod authors or their mods. I also don't want to discourage any (potential) modder. This game is only so much fun because of all of you and all of the variety you offer. They are all great in what they are aiming for and all have their more than valid reason to exist (not that they need my approval!). I just find it cumbersome to manage mod compatibility. Having all of them exist simultaneously just creates problems and extra work, as some mods or authors prefer this CRP, others Rational Resources or Simplex Resources, others introduce their own resources again. *sigh* Sorry for going a bit off-topic here and thank you for indulging me

@theJesuit I'm currently playing 1.12.3 with, amongst other mods, Kerbalism and Kerbalism Simplex (or Simplex Kerbalism, whichever way you prefer ) as well as Stockalike Mining Extension/Expansion (the name seems to vary ;-) ), which is listed as supported mods in your initial post. My current issue is that the SME drills/harvester have no functionality, only reliability. So I just looked at the corresponding GameData\KerbalismSimplex\Support\SimplexMiningExpansion.cfg and noticed that the drills have only patches for when you also have SimplexResources installed, which I have not. (See ex.1). If I compare it to the KPBS/Planetary Base cfg file, I notice that this file has patches for two scenarios, one for a case with SimplexResources (see ex.2) and one without SimplexResources.(see ex.3). I think the SME-support file is missing support for users who are not using SimplexResources (I know, their/our loss and "what's the point?" :D). Would it be possible to get support for this mod as well in the scenario as described above (with Kerbalism, Kerbalism Simplex, but without SimplexResources)? Or am I just missing something? (Please don't say Simplex Resources )

My thought -after reading @SkyFall2489's workaround- was that it is related to the position of the chute and that the nosecap is "shielding" it from the drag, similar to a cargo bay. I thought that if it were placed outside (maybe invisibly), it shouldn't happen.

I don't know if this is what you are looking for, but doesn't Kerbal Engineer Redux essentially provide what you are looking/asking for? I'm not quite sure if you can use it in the Tracking Center, but when you are in in a vessel, you don't need focus the body. Unfortunately, it only shows the values for the body in whose SOI you currently are. Still, you can see it in the map view (and not just there) for the current planet and it also offers many of the values PIP is providing.

I recently had the issue with Lindor's rings as well (without using Ad Astra). I tried to track it down to some mod incompatability or false settings. In the end what solved it for me was completely removing the following folders (if you have them): and then reinstalling the following mods: Kopernicus, scatterer (0.0772), JNSQ, EveRedux 11.6.1 (with Eve you should have clouds). I did not have to delete my settings.cfg in the KSP main folder after doing that. I still don't know what caused the issue. My best guess is something corrupted some settings in any of the mods mentioned above - I just didn't want to spend more time tracking it down. After all, I 'solved' my issue. After encountering the issue, I tried a new, clean KSP install of only these mods, then adding more and more mods (in a bundle because I had too many). After triggering it, I removed them one after another, trying to see if it would work again. It didn't. I was left with the initial folders/mods, but the issue still persisted. Did a fress install of the mods again. Worked again. So I deleted the above mentioned folders in my heavily modded main KSP game and replaced them with a fresh install. It worked. So I don't think it's really a mod. It's rather a setting. It may or may not be triggered by opening some settings window (such as scatterer or eve), but that's just a wild guess and I don't have any expertise on that subject. Bottom line, it works for me again and I didn't want to spend more hours on tracking it down. There's still a scatterer error in my log when looking at Lindor. Something like "System.Exception: Scatterer doesn't support tiled/thick Kopernicus rings (not implemented)". But it's not a visual issue, so I just ignore. Problems go away when you ignore them, right? Sorry for the late response. I hope it still helps you - or others.

Awesome and quick work! Two thumbs and two toes up (I would give more if I had more ). I can confirm that it works properly now. @Snark Apologies for the redundant request. I missed it, my mistake. I didn't mean to be pushy about it! Your explanation makes perfect sense.

Mhm, is it just me or does this not work properly (at all) with Kopernicus+JNSQ? I Just tried it on a clean install with KSP 1.12.3 + ModuleManager 4.2.1 + Kopernicus (latest stable release) + JNSQ (latest) + PIP (Planet Info Plus :D) 1.1 + DunaDirect (testing something else simultaneously, but it shouldn't be the cuplrit). It doesn't show (I can provide screens if requested, but you can probably guess what you'll see, the stock info). If I delete Kopernicus+JNSQ, it shows correctly. Anybody else or is anybody using Kopernicus+JNSQ+PIP and seeing the intended information? If so, I'll have to do some more troubleshooting -.-' @Snark, I actually have a suggestion as well. An information I frequently seek is the border between near space/orbit and high space/orbit. It would be awesome if it could be added here. I think it's a good addition to the atmosphere height.

I'm probably reading this wrong, but it looks as if ToolbarControl(ler) isn't loading. Have you installed it?

I think we might. I don't know, maybe it's just me. The Rudaux Nosecone ( MarsDirect/Dockingport/MD-Dockingport ) seems to be bugged. The parachute is not fully deploying, just semi deploying. At first I thought it might be caused by some of my mods. So I set up a test environment, KSP 1.12.3 + ModuleManager4.2.1 + latest DunaDirect. The issue persists. The semi deployed state also does not appear to be slowing me -I mean "my rocket", I'm definitely not holding it in my hand!- down. Weirdly, the Samara Nosecone (the non-docking-port version) is working just fine and the semi deployed state also slows me down significantly. Can anybody else confirm this issue? Or is it only supposed to work on Duna? o.0

Yes, I am using Contract Configurator. Thanks for the explanation. I was surprised since I didn't see this in my last playthrough (1.10, I believe, where you were already using the watchdog file - I could be mistaken though). It doesn't really bother me, I just wait for the next contract. Or maybe I'll accept it and use the cheat console to fulfill the contract. I think that might do the trick, too. Running from me wth the speed of light, eh? Mhm, ok, I have a plan. First, I place a mirror behind it. Then I approach it and force it into the mirror. So that it'll bounce back to me. I just have to figure out all vectors, first. I'm sure it'll work. Or do I need a trampoline instead of a mirror?

I'm currently using the latest Watchdog and Kopernicus Release 82 in KSP 1.12.3. Has anybody ever had this, uhm, "feature" to explore the body/planet "Watchdog"?

@hmmmm I think this is what you are looking for.