Streetwind

Can you share some of the issues you're facing? I'm currently observing some, but not all, of my OX-STAT solar panels outputting >10 EC/s instead of the stock 0.3 EC/s at full exposure. Needless to say that's a bit overpowered for the earliest, smallest panel there is. <_<;; And I'm wondering if Kerbalism is doing this intentionally for some reason, or whether something else is screwing with things. (It's not the Modular Science Config though, that one doesn't even touch solar panels.)

I didn't even know there is supposed to be a geiger counter science part! I've just been using the one built into the probe cores. I would instinctively assume they disappeared when you turned off the radiation feature... though then again, I don't know how the internals of Kerbalism work, perhaps they could be separated. I found the config file you mentioned, thanks! Now I can ponder whether I want to turn it off for myself. It will depend on how annoyed I get with it. I was hoping I could adjust the frequency or length of the events somewhat - I get a storm roughly every 30-40 hours, it feels like, and that feels a bit silly. Unfortunately there's only a binary on/off setting. =/

@SheepDog2142 Yeah, I noticed significant issues too. Didn't get as far as trying volumetric clouds, but even with just a default install of EVE, I got heavily broken atmospheric visuals. Eventually I found out that this would only occur when starting KSP fresh, and would fix itself once the player enters the tracking station and then exits it once. In the tracking station itself there were also issues - for example the launch sites seemed to jitter and move about on the surface of the planet. This also fixed itself in most cases by entering and exiting the tracking station, though in some cases (like when not using the home switch feature but instead moving the stock system to Kcalbeloh) it remained broken permanently. I ran into the Parallax issue aswell. Made a bug report to Linx, he said that he's never tried moving the player's start location elsewhere, so he needs to look into how that works before being able to say for sure why it breaks. But he did notice that apparently whatever body you move the KSC to gets internally renamed as "Kerbin" by the home switch patch, which results in there being two bodies named Kerbin (even if you remove the stock system, the planet definition still exists), which is what might well be the thing that breaks Parallax. Since I had already been on my ninth consecutive day of testing, troubleshooting, and configuring mods at the time, and I just wanted to play already, I ditched Kcalbeloh in favor of stock system + OPM. But perhaps you can try and modify the home switch patch so that it renames the old Kerbin into some dummy value the same way that Suluco gets renamed into Kerbin? Ideally that should remove the error about two Kerbins being present.

Right, so I tested the geiger counter again. The "inner belt", "outer belt", and "magnetosphere" situations are unable to be researched due to the disabled radiation feature. The other situations, however - that is "surface (biomes)", "flying low", "flying high", "space (global)", "solar storm", and "interstellar" are all possible - if I interpretate things correctly. So that's only two out of five situations in orbit (plus interstellar but that only shows up in solar orbit, not for any other body), but the surface being biome-dependant means I'd say that there's enough of a reason for it to exist and be used. The experiment description is a bit confusing since it mentions extra situations that don't exist, but it's probably fine? As for the solar storms - they're a bit annoying right now because they're effectively just random blackouts of your comms network without warning or means to stop it. The game shows no message that a solar storm is coming, no message that one is active, and no message that it has passed. I'm new to Kerbalism, so maybe you know more about how one is supposed to forecast, interact with, and protect oneself from these events...?

Okay, scratch that post before - something odd is going on. When I launched that geiger counter experiment, it reported a "solar storm" as its result. It never reported anything else. And given that (a) I was not observing any effects whatsoever and (b) radiation as a feature is supposed to be turned off by this science-only config, I assumed that that was just the default message it fell back to because none of the radiation belts it is supposed to be scanning actually exist. Well, turns out that solar storms are actually a thing, and they do have effects. I just didn't notice any because up until now, all my missions have been crewed (took a while to unlock a probe core with a reaction wheel and SAS). I only learned about this when I was trying to raise the orbit of my three brand-new commsats after launch (the launches went fine), only to discover that they would lose all commlinks as soon as they got anywhere near sunlight. Unfamiliar with Kerbalism as I was, it took me a good long while before I accidentally moused over the correct status window in the toolbar and noticed the solar storm indicators. Which means that the geiger counter experiment might actually have been working correctly, I just happened to launch it into a solar storm by sheer chance. So I need to launch another mission with it later to verify whether it works or not. In the meantime, though - question: is this config not meant to turn off solar storms along with the other non-science features? Or is this something you have no control over, @theJesuit?

First thought of feedback - the geiger counter experiment integrated into probe cores (and possibly other things?) is a bit awkward because the radiation feature is disabled. It works normally in-atmosphere, but in space - where it should have more than half a dozen different situations - it just defaults to one report. For all of space. Might consider disabling that experiment.

I added those lines to the file, but it doesn't seem to be working. I didn't expect it to, given that it did not have those lines in the first place, which indicates those contracts are using an entirely different method of controlling their frequency. It'll need a DLL mod to make changes to this, hence my suggestion for Contract Configurator.

Alright. After one and a half weeks of choosing and testing mods, and writing over 1500 lines of ModuleManager patches to fix issues and customize the experience to my liking, I have actually started playing today! So far the Kerbalism-Science-Only approach appears to be working, though I've not yet left Kerbin. I did notice that a small select few custom science experiments shipped on a few modded parts didn't get caught and removed, though I don't know if that's on Kerbalism itself or this mod. I removed them myself.

@Professor K Is that maybe an older part that was discontinued from the mod? Because when I look into ...\NearFutureElectrical\Parts\RTG, there are four part config files there, and none of them use the keys #LOC_NFElectrical_rtg-0625_(etc). No part is named nfe-rtg-0625-1 either. The English localization file probably got updated when it was removed, since it's the "main" file and done by Nertea himself, whereas the other languages may have been contributed by others and thus didn't get changed (yet). ...of course, that's all just my speculation based on what I see in my GameData folder

This is the best mod I never knew existed. Until now. Outstanding work as always, Nertea!

I figured it might be something like that... it's probably quite hard to account for everything that a massive toolkit like Kopernicus offers. It's also possible that something is wrong with the way Kcalbeloh implements its patches too - even before adding Parallax, I occasionally had some weirdness going on during testing (like atmospheric visuals being broken after a fresh game start until the first time going into the tracking station and back out; or the markers for the launch sites drifting around on the planet's surface in map view sometimes...)

Quick question, has anyone managed to use Parallax Continued successfully with Kcalbeloh, while using the Home Switch feature to put the KSC on one of the Kcalbeloh planets instead of Kerbin? I keep getting an exception that prevents the game from starting whenever that setting is on. I already went and made a bug report on GitHub, but maybe someone here knows of a potential fix...?

It was definitely coming from the game. And after extensive sleuthing, which included checking logs and console output, I've determined the culprit: It was OhScrap!. Apparently it is meant to play various alerts whenever certain failures occur. Why it decides to instead play an alert when the player holds Alt and/or changes symmetry modes while hovering over certain other parts in the editor is anyone's guess. (As is why a vibrating phone noise is even part of a set of alarms meant to alert the player to part failures...) Welp, I was already on the fence about whether to include that mod at all. If it's outright broken, that's an easy decision to make. Bye-bye! Hopefully this will, at some point, help someone else... though given how weird this was, probably not

I have a question about the "Exploration contracts" / progression contracts. As in, the one where it tells you to do a bunch of stuff around the Mun, then there's a series for Minmus, and so on. And you can only ever have one of them at any given time. I understand that these are not defined in config files like the procedural contracts, but rather in the game's codebase. Would it be possible for Contract Configurator to coax the game into offering more than one such contract at the same time? Specifically, it would be great if two separate celestial bodies could have their Exploration contract series running in parallel. For example, after reaching orbit, instead of generating the one Exploration contract for a flyby of the Mun, it generates both that and also one for a flyby of Minmus. There would always be one Exploration contract active for the Mun, and one for Minmus, following their normal progressions. You could work on both moons in parallel, or choose in which order you want to do them. After all, many players consider Minmus no harder than, or even easier than, the Mun. Once one of the moons has been completed, it would start offering you destinations in solar orbit while the other moon still has contracts up, again letting you work on things in parallel. And if you really don't want to do a specific destination or task, and refuse to complete that contract, you wouldn't stall out the entire Exploration contract chain for the rest of your playthrough - there would still be a second series running for a different celestial body.

Neat, I didn't know the game could generate Exploration contracts like that. I thought they might have been predefined. Maybe it's based on science value? That's also something I was going to ask about, since the system is offering you multiple start locations, in addition to the default start of Kerbin. Science values should be low in places easy to reach from your starting location, and high in places difficult and/or time-consuming to reach. Does each of the starting locations actually change up all of the science values? That would be an impressive amount of effort. Or is there some compromise in this regard? EDIT: Would the Exploration contract progression work better when starting on Efil?

Given that I'm not sure NFLV even ships any sounds at all, it could be coming directly from my computer, yeah. But it is more likely the fault of some kind of weird effect in my specific pile-up of mods, and not NFLV on its own. I am just asking here because a few parts from NFLV happen to trigger it, which means that there might be a very small chance that someone else in this thread has run into the same thing. Which is what I am hoping for. (Of course, chances are not looking good, since a search for certain keywords in this thread yielded nothing.)

Well then, to get back on topic... I'm strongly considering using Kcalbeloh as a star system replacement (starting on Suluco, Kerbol completely disabled). Since I haven't played KSP1 in... four or five years(?) I'm pretty clueless when it comes to these newfangled visual mods that the kids are using these days So I have questions. How is the status of the volumetric clouds config? The release page names five bodies as finished, but does that mean that they are the only ones that have clouds at all? Or do all the atmospheric bodies have at least basic support, and just aren't all considered "finished"? On one hand I really want to try out volumetric clouds, but on the other hand it would bother me if there was a big disconnect between the visual appearances of different celestial bodies. If there is such a thing, I might consider dropping volumetric clouds in favor of a more unified visual style. If I do end up using volumetric clouds, can I install that together with the likes of Spectra or AVP? Or are they incompatible? I have since learned: they are incompatible. If I do end up using either Spectra or AVP (either because they are compatible or because I dropped volumetric clouds), which one would you recommend? Since I am disabling the Kerbol system, it doesn't matter which of the two does that system better; I only care about how the Kcalbeloh system itself looks. (And yes, I realize that beauty is largely subjective, but there can also be objective measures like when one of the two packs simply works better/implements effects in places the other doesn't/etc). Do the rescale configs shipped with this pack also take care of rescaling the Parallax configs? Or would this be something I'd have to do myself if I wanted to go for a rescaled setup? I have since learned: Parallax Continued itself offers appropriate patches. EDITed to add two other questions: Do asteroids generate in the Kcalbeloh system? I actually wouldn't mind if the answer was "no", since I don't like the feature very much. In the past I often ended up delaying the upgrade to the level 3 tracking station as long as possible to keep these things from clogging up my save. So... just saying... if there was a way to ensure that no asteroids generate... I would be all ears And, given that I'll not be starting on Kerbin, what happens to the contracts in career mode? I assume it still gives me the first contract in the "Explore the Mun" series, and then remains stuck there because it will never get completed, and meanwhile I'll be getting the usual assortment of procedurally generated, non-Exploration contracts? Who knows, maybe I can disable the stock Exploration contracts using Contract Configurator or something...

Okay, so... I have a really weird issue. Possibly the weirdest issue I have ever had in KSP. When I have one of the cluster mounts that NF Launch Vehicles supplies placed in the VAB, and I mouse over it while having an engine selected, then everything is fine as long as I am in single-item symmetry. As soon as I change the symmetry mode to anything other than single, then an intense alarm noise will play whenever I mouse over that engine mount while dragging an engine. It is very loud. It is not a sound that is part of KSP, I have never heard it before. It sounds like a mobile phone going off, having both a bright tone, and multiple vibration "hums". It plays every single time. I can get it to overlap if I rapidly move the mouse off and on the cluster mount. I spent like half an hour confused, looking around my room for where that sound was coming from, until I clued in that it was the game. I cannot imagine this is intended. Has anyone here ever experienced anything like it?

@JadeOfMaar I'll have a look. And just like that, the quest to finish customizing a playable modded instance to my liking gets extended once more... Currently on day 8 and counting. It means these radiators need to either be in an atmosphere to function, or will consume water instead when in a vacuum. In other words, they're not radiators at all, but rather convection devices that use pumps/fans to move ambient air (or supplied water vapour) through a heat exchanger. They can't work without a convection medium.

Neat! They did it the same way as I did, which gives me confidence that I did something right A difference being, their patches straight up copy the heat output of the MKS core heat configs, ending up with 200 kW heat load on the large Atlas harvesters, whereas my patch attempts to scale heat output according to EC input and ends up making them generate more than twelve times that much. (The small drills are very similar though.)

Well, this is what I came up with in the end: https://pastebin.com/0NLY0CgP Outlet temperature had to be 500K, as that is the efficiency sweetspot of the USI harvester module. It also makes these drills slightly easier to cool than the stock ones, which I think is a good thing. Because the Atlas harvesters are gigantic and consume mountains of power. I originally aligned with the heat output of the stock drills, which ended up with the largest Atlas harvesters at 4MW of cooling required; but in testing this with actual radiators, it became ridiculous. You needed seven 'Delta' high-temperature radiators from Heat Control, or sixteen of the stock Thermal Control System (Large), to cool a single large Atlas harvester. And you're meant to deploy more than one. The endgame Atlas domes have five harvester slots each. So I scaled everything down a little, to peak at no more than 2.5 MW. That's still a hefty enough challenge at this low a temperature. As an aside - Nertea, would it be possible for SystemHeat to not round MW values to the nearest whole number in its various displays, and the part module info in the VAB parts list? A single decimal digit would go highly appreciated, at least for otherwise single-digit MW numbers Now, for anyone who actually wants to use this patch: I'm afraid it's not necessarily going to be a "drop in and forget" deal. Because if you have any other mods installed that affect the USI harvesters in any way - or heck, if I had other mods installed that affect them while making this patch and you don't - then there's a chance the patch will not work. Because the module index of the USI harvester module might change. It's a fairly small chance, admittedly, because new modules will usually be appended at the bottom, and thus not modify the existing order of modules further up. But have have to be aware of this - and when it happens to you, you'll need to go and fix it yourself. Because the indices you need to set will be specific to your own set of mods, so no one else can fix it for you. The easiest way to do so will be to load up the game, hit Alt+F11 to bring up the ModuleManager menu, and dump the DB to disk. That will create a new folder in your KSP directory, which will contain every single part.cfg file in its final state, after all MM patches have been applied. Find the files for the various USI harvesters, open them, and count every instance of MODULE you see in each one. Do not count any other subnodes, only those named MODULE. Count top to bottom, starting at zero. The number you reach when you find the USI_Harvester module will be the number you need to input into the patch. Be aware that not all the harvesters may use the same index, due to differences in their file structure. In my case, I found some to use index 4 and some to use index 5.

Well, this was easier than I feared it might be. Guessed the index correctly on the first try Of course, this is just a quick simulation in the VAB, I haven't tested this in the field. But it behaves the same in the simulation as the stock drill, so there's that, at least... ...Now to actually choose some sane values for the anything-but-sane default values of MKS.

*squints at code* ...so if I understood this correctly, I would add a ModuleSystemHeat to the part, and a ModuleSystemHeatBaseConverterAdapter. I would give the adapter the name of the ModuleSystemHeat, and the... index of the USI resource harvester module? (How do I find this index? Is it just counting modules from top to bottom in the part definition, starting at 0?) Then I tell the adapter how much heat it should be generating in the harvester's stead, and other relevant values, while turning the harvester's core heat output off and (possibly) getting rid of the ModuleCoreHeat? I can certainly try and see if this works.

Hey @Nertea, is there a SystemHeat module that can output "dummy heat" based on another module's status? I was looking at MKS resource drills. They use their own bespoke resource harvester module, which the SystemHeatHarvesters patch cannot replace. I'm assuming that supporting this custom module in Systemheat directly would be a bunch of work. So I was instead thinking, is there perhaps some way to trick one of the existing SystemHeat modules into outputting heat if that USI module is running? (The USI module can already be set to not generate heat itself, so there would be no issue with stock CoreHeat accumulating.) If not, I suppose I'll just turn off heat generation on the drills and have them run that way, since there are no CoreHeat radiators to service them...

Since I'm building a new modded instance with MKS right now, I took a look at the issue with EVAConstructionTweaks.cfg. The fix is actually fairly simple. Open the file, and replace the second line: @PART[*]:HAS[!MODULE[ModuleCargoPart],#mass]:Final with: @PART[*]:HAS[!MODULE[ModuleCargoPart],!MODULE[ModuleGroundExpControl],!MODULE[ModuleGroundExperiment],!MODULE[ModuleGroundSciencePart],!MODULE[ModuleGroundCommsPart],!MODULE[ModuleGroundPart],#mass]:Final All this does is add five additional checks that prevent the patch from firing on any parts that have one of Squad's various stock modules which already define packed volume on their own. With this, all of the Breaking Ground surface experiment parts, as well as the ground anchor and worklights, do not get patched and use their preconfigured volumes. It will also cover any modded parts that use these modules. I didn't see any other parts that were affected, but there are a lot of parts in this modded instance, so I've lost any semblance of overview Tagging @dlrk and @Iuno because it seemed relevant to you.