caipi

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.

I just now noticed @JadeOfMaar's awesome Skybox. I kinda want to use them all. And not just his. There are way too many beautiful skyboxes out there. I guess what I'm asking is: Is there a chance we could get an automatic skybox rotation (if it isn't already in there)? Like with Windows background wallpapers, changing the background every x minutes. That'd be sooooo awesome.

Maybe Microsoft is secretly trying to push down or slowly silence all space-travel-related projects, so that people don't start fleeing earth, escaping their grasp - or at the very least delay it a couple of years. The more humans they can keep earth bound and the longer they can do it, the more profit they make. Okay, enough crazy tinfoil-hat theories. Somebody might actually start believing it. xD I actually found it pretty quick by going to LGG's github repositories page: https://github.com/linuxgurugamer?tab=repositories

https://github.com/linuxgurugamer/SpaceDockReBoxed/releases/latest

If you go into the settings (while in a game) and then into the difficulty options -> Kerbalism (1), you can deactivate lifetime radiation. Meaning they are completely healed after you recovered them on Kerbin. I don't think there is an option or mod to reduce it slowly. It's either all or nothing, keep it (lifetime radiation) or don't. Though such a treatment facility would be a great mod idea. As for the radiation itself: It might be safe to go to the Mun without shielding in theory, but Kerbin has a radiation belt as well. Press [numpad] 1-3 to see the different belts., 0 to deactivate it again If you keep your Kerbals for too long in such a radiation belt -for example if you launched it straight into such an orbit and then let them make a few rounds- they might accumulate more than on a regular, direct trip. So don't launch them too high, especially on JNSQ. The belt is somewhat tight. I think I usually start with a 110-120km orbit, which is rather safe. /edit: So I guess your Jeb is making for a fine lightbulb now. Is he glowing already? Are his fellow astronauts describing him as "radiant" already?

Have you tried the following?

Thank you very much, that's the answer I've been looking for. I wasn't aware of Kronometer at all. I read something about it in the initial post (now compatible with Alarm Clock -which I'm not using yet- and the sunrise at KSC requiring it, as well as it being removed from the JNSQ pack), but I wasn't aware it is integral for the correct time keeping with JNSQ. Might I suggest to add Kronometer to the Recommended Mods list?

I had a similar issue in KSP 1.12.3. But it only happens with "Blizzy's" Toolbar. If I use the stock toolbar to launch SOC, I can open and close it without any issues, so I only use the stock applauncher. I was too lazy to follow the issue any further since this easy workaround works perfectly.

I've run into a similar issue as Graploos, but with Kerbalism and Simplex Kerbalism. Simplex Kerbalism clearly states that it uses the 12 hour day: We know that JNSQ changes a Kerbin day from 6 hours to 12 hours: The game continues to use and display the old Kerbin-time, 6 hours a day. Kerbalism however starts using the 12 hour rotation as one day. So a resource of 5.0 units with a consumption of 0.167/hour (~29.94 hours) is shown as 2 days 5 hours (the 0.94 are probably rounded down) instead of 5 days 5(.94) hours which it actually lasts. It's using the "real" JNSQ Kerbin day. I assume Graploos Alarm Clock issue relates to the same issue. Alternatively, I can switch to 24 hour days display in KSP settings, but that doesn't change the Kerbalism readout. Is there a way to switch the ingame day to a 12 hour day instead of 6 or 24 hours? I searched the JNSQ readme but found no answer. Or is the game supposed to use a 12 hour day already and there is just something wrong with Graploos' and my install?

I just watched the KSP 2 trailer and was majorly disappointed. I mean what da f##k, guys? You dare call that a KSP trailer/teaser? There was not a single explosion or implosion! Come on guys, we're used to better stuff. Just kidding, or rather teasing. Good job, guys. It's a bit sad to see the development coming to an end. But as you said, it's not really an end. It's just time to move forward. So here's my most important message: Thank you for such a great game and such a long lasting experience. Primarily of course to the developers and the initial creators, but also to the many, many, many big but also small modders who made this game as great as it still is! There are very few games which gave me so much pleasure over such a long time without becoming dull or repetitive.

Textures Unlimited

I've been wondering: Would it be possible to change the OPT_Reconfig\CRP\OPT_CryoEngine.cfg so that instead of replacing the LF-modes with LH2 Fuel modes, it adds the LH2 Fuel Modes with a B9Part Switch? I really like the OPT engines in both variants. And I love the whole cryo engines concept. But when I build spaceplanes, I definitely prefer LiquidFuel over LH2 because the lower density means that I have to use A LOT of tanks, which just makes my planes much bigger than I want it or need it to be. So for Spaceplanes, I use mainly LF engines. But for rockets and, well, non-spaceplane-constructions -I wouldn't exactly call them rockets- LH2 is my favorite choice. I've looked into it and tested around a bit, but I'm no modder and module manager most certainly just isn't my friend (I never really bothered trying to understand it entirely, though). Right now I'm running into issues with the atmospherecurve. Hardcoding (as in providing a value in the switch instead of a multiplier - similar to the ISP switches for SAGE and others) is certainly an option, but that means that each engine would require it separate lines/patches instead of bundling them (unless they have the same ISP, of course). I mean I could probably create something like it with lots of effort, which might work, but it would be a rather dirty patch. It's just an idea. I fully understand if it's unwelcome, especially given the effort that probably has to be put in. Right now, unfortunately, I'm playing with that patch deactivated since LF is just much more sensible for spaceplanes in my opinion.

I just found an oddity and I was wondering if this is done on purpose. I kinda doubt it though. The "Bubble" Tilt Engine (name = opt_vtol_bubble1) has two fuel options with two modes each. Using CryoEngines seems to have messed it up a bit. Fuel Option 1 LH2+Air: Airbreathing mode uses LH2 + Air (as intended), Closed Cycle suddenly needs Liquid Fuel + Oxidizer instead of LH2/O Fuel Option 2 LH2O+Atm: Airbreathing mode uses LH2 + O + Atm (as intended), Closed Cycle needs LFO instead of LH2/O I find it strange that the closed cycle modes aren't using LH2.