SilverState

That makes sense, and is fairly common. The patching system of Kerbalism is pretty complex and convoluted, due to the sweeping changes Kerbalism does to a lot of game systems. Due to that complexity, it's also vulnerable to other mods patching/removing triggers that kerbalism relies on to apply the correct configurations to parts.

As far as I'm aware, no, Kerbalism itself doesn't do this due to transmission rates not being constant - they mainly vary due to distance. There was a KCC - Kerbalism Companion Calculator which did this, unsure if it still works in the latest game version. Feel free to give it a try. https://spacedock.info/mod/2580/Kerbalism Companion Calculator This is subject to what other mods you have installed. Something is messing with the patching order of Kerbalism, and it breaks somewhere. I cannot replicate this issue, as the Configurable Unmanned Experiments button is present and working fine in my install.

MM ignores everything besides the first pass specifier when there are multiple. The :FINAL pass specifier does nothing except kick up warnings. [WRN 17:54:58.189] more than one pass specifier detected, ignoring all but the first: SWE/Configs/Bluedog_Design_Bureau/GEM40-Inline/gem40_inline/@PART[bluedog_Delta_GEM40_Inline]:FOR[SWE]:NEEDS[RealPlume,SmokeScreen,Bluedog_DB]:FINAL It even states that in the log file.

Most likely (99%) is that the vessel uses custom generators (panels, fuel cells, reactors, whatever else) that are unsupported by Kerbalism. Unsupported means that Kerbalism cannot simulate them in the background, because they're either incompatible, or unpatched. When you switch focus back to the vessel, the parts work as intended, but the background simulation does not. It can be fixed with a patch, by replacing the module responsible for EC generation in the part with one supported by Kerbalism, if you want to dig into that.

Hm. that was an oversight on my part. I patched the Station Science to work with Kerbalism, but apparently I missed the part where the background sim needs to account for the specific processes which generate the resourrces. Your apprroach is correct in a way, I'll fix it soon.

I'll do it, that's why I asked for your permission to use your config as a starting point and fix whatever needs fixing.

That's why I said it needs to be patched per part. Bunch of manual labour, but not the end of the world.

Regarding animations, those have to be patched individually per part. You can probably figure out a filter to see if the experiment has an animation, copy it to the Kerbalism Experiment, then delete the module, but i bet they're inconsistent (as usual) and stuff will break. The config you made is solid, but needs tweaks for animations and probably a slight rebalance. Regarding those 3 experiments, they're patched properly, and i did check ingame. The only one unpatched from your config is "CAE-SC-VIS Vorona Imaging System". The orbital scope there is stock experiment, which should be patched, but isn't. I'll see why. Question: Assuming i modify the cfg to fix random stuff (such as animations, balance, whatever else slipped through the cracks), would you mind if i added it to Kerbalism's repo? (and ultimately download, so everyone can have it)

Something is misconfigured then. The patching process, while it looks confusing and scary, is fairly straightforward. Check MMConfigCache, for the part you're trying to patch, and check what's happening. @PART[*]:HAS[@MODULE:HAS[#experimentID[yourExperimentID]]]:NEEDS[YourMod,FeatureScience] { !MODULE:HAS[#experimentID[yourExperimentID]] {} MODULE { name = Experiment experiment_id = yourExperimentID whatever else } } This bit basically removes the existing experiment, and adds the new version to the part. If you're still seeing the old experiment, means this bit is not applied properly. Check your .cfg, maybe even your patch ordering. can;t really tell you more without looking into the config cache. There's also the possibility of a mod conflict, where the patches fight each other and mess everything up.

Kerbalism already does this to an extent (think habitats and all the resources that go with it) Please explain in more detail what exactly you're trying to do, and I may give you some tips if I can.

we already have a patch for sounding rockets. For the experiments at least. No hard drives patch yet.

You're probably right, but hey. I'm not a rocket scientist, i just patch stuff. You know the saying: Monkey see, monkey patch.

^ It's lead. that's why it adds so much mass to parts.

Correct. Shielding = surface area of the part. Inflatable habitats don't get shielding, because logic. Exception are rigid inflatable ones (think SSPX centrifuges)

Correct. Science Rewards slider affects the total science gains, and it's global. The tweakables have per-experiment settings, and pretty much anything can be changed there, including duration, costs, science value, all sorts of requirements, crew requirements, situations, etc. All you have to do is modify the values in that file to your liking, and the core patches take care of the rest (applying and changing everything relevant). Keep in mind, tweaking one experiment will adjust values for all parts that have that experimentID. If you decide to fiddle with the tweakables, make sure the values you are adjusting are in the same format as they currently are, otherwise weird stuff starts happening (e.g. if it's a number, stick to a number, if it's false, set it to true if you wish, and so on) For modded experiments, the "tweakable" part is at the top of the mod's config in ModSupport folder.

There was a "rebalance". We made stuff harder. All patched experiments were given new values, we messed with biomes/situations and a whole bunch of other stuff. It will be similar with all future patched mods. There's an idea in the works that will dynamically rebalance experiments based on what mods you have installed, but no promises. It's proving quite the headache. We also remove duplicates - functionally identical experiments get nuked, and only one remains. In general, there's a lot less science to go around, we're trying to force you to explore. If you don't like the changes, there's the slider ingame, or go into tweakables folder and tweak there to your liking.

See the post above yours, specifically: For non RO Kerbalism, those are my configs, and there's no guide. The configs were provided in a "this should work" state, but they definitely need polish, especially documentation. If you're not familiar with them and try to patch something related to Kerbalism science (hard drives included), you'll probably have quite a few head scratches trying to figure out why the values you're setting are not the ones ingame. I would assume you get parts with 512kb of storage (that's the default for non-patched mods), therefore, if you want to change those values, you'd have to target each part individually. I had some ideas regarding global patching based on cost and unlock tech, but it makes everything bland and causes a lot more trouble in the long run than it's worth. If you decide to patch these yourself, make a new .cfg file, and stick it anywhere inside GameData folder. Your patches should look something like this: And so on for each individual part. (EDIT: they don't need to be in a separate .cfg, you can do all of them in a single file) Don't go overboard with base values for dataCapacity and sampleCapacity, as they get hit by a series of upgrades based on their initial values. Namely, for data capacity: >2 -> x2 >16 -> x8 >64 -> x128 >512 -> x1024 and for sample capacity: >2 -> x3 >5 -> x6 >8 -> x12 these are multipliers, non additive. Edit: This is a very basic way to patch the drives. It works, but it's not consistent with how i did it in the provided configs with Kerbalism.

I doubt there's any docs on the configs. I built that mess, and Standecco adapted it for RO. I don't know his forum name, but you can either ping him on RO discord, or on Kerbalism's (@Standecco)

Soon. In all seriousness, I have the issue on github, I'll get to it eventually.

^ What he said. Another 2 cents: Having orbital decay, while realistic, becomes extremely tedious and unfun really quick. Ultimately, we're playing a game, not running accurate simulations. Having orbital decay would go two ways from what I can see: 1: Having to manually re-boost vessels. Imagine having a few dozen sats/ships all over the solar system, and having to periodically switch to them, plan maneouvers, and execute those maneouvers. While yes, accurate, it would get extremely tedious really quick, and will suck out all the fun from the playthrough for the vast majority of people. I get it, there's an audience for this type of stuff, as with everything, but the vast majority will find it questionable. Kerbalism is already too much for quite a lot of people, judging by the fact that other LS mods are more popular. Adding this in will further trim down the player base using Kerbalism. 2: Automating the re-boosts: If it's automated, why even bother implementing it if it doesn;t change gameplay for the player? Forcing them to carry a bit more extra fuel? I don't see the value of putting in work to implement it just to bypass it completely afterwards.

Have a look at these 2 commits: https://github.com/Kerbalism/Kerbalism/commit/70cbaa00e23cb0c277cc459aa55d2e033ca768a0 https://github.com/Kerbalism/Kerbalism/commit/72eca8cc757adba4cdb82d1f31e43a16994bf9ba I'm the config guy, so I have no clue what he did there (I don't know C#), but you can probably have a look. Alternatively, drop into our discord and pester Sir Mortimer there, he's reasonably active. @Jognt Regarding the science changes, they're not KSP version specific, they're Kerbalism version specific, i.e. the new science mechanic is present on Kerbalism 3.0+, but you can install it on KSP 1.4 +. So you can still get the new science on an older KSP, DLC is not required. Squad changed something in their code with 1.7.1 (probably to make the new deployable experiments work), and that screws with transmission (you still get full science value if you recover the vessel). This breaks this patch (we literally use the same MM patch, hidden away in a bigger config). Misread your question. The change is introduced in 1.7.1, probably for DLC support. I haven't specifically tested 1.7.1 without the DLC, thus the following is an educated guess: The changes are there even without the DLC, and assumed present on 1.7.1 regardless wether Breaking Ground is installed or not. The bad news is, he only patched our own implementation. I have no clue if this is even fixable for stock modules.

Not a bad suggestion. I'll open an issue on github. As far as i know, it doesn't REQUIRE. but it's strongly recommended. All in-flight science vessels will become useless, as there was a module change (ModuleScienceExperiment -> Experiment), thus you won't be able to do the old experiments anymore. You'll also get plenty of warnings in game for active vessels stating that they're missing modules. Another reason to re-start is balance. We tried to change the progression a bit, and "balanced" (i know I'll get flak for it) stuff to make it a lot more challenging, especially in the early game.

In this case, I fully believe that the :FINAL is warranted. This MM patch does a single and a very specific thing. When players install this, they're fully aware of what they're installing and what it exactly does. I don't see a case where they'd want to re-patch this (if some other mod messes with balance, this patch would also re-adjust the values accordingly). Look, I've spent a few weeks writing the configs for Kerbalism's 3.0 science mechanic. 95% of the science configs are my work, and I had to deal with this very exact issue. We did contact a couple of mod creators, requesting changes in their configs, because I was and still am hell bent on avoiding :FINAL. But this is an uphill battle (some never reply, some are inactive, some can't be bothered due to Kerbalism not being everyone's cup of tea), thus not always possible. Currently, I'm running EXPERIMENT_DEFINITION patches very late (:FOR[zzzKerbalism]), and we also incorporate the single run experiments mechanic as well, which has to run :AFTER[zzzKerbalism]. All it takes is one bad config to mess this one up, and I would be forced to do the same (:FINAL). There's just no winning in this. It's a plugin issue introduced with 1.7.1 (works fine on 1.7.0 and lower). We had to fix this as well. I'll copy paste the explanation from our discord: Therefore, this patch is now useless without plugin support. You should update compatibility stating it's UP TO and including 1.7.0.

They don't NEED configs, they should be left untouched if they're not patched. I specifically avoided global nukes for this very reason. Bad news is, unpatched mods SHOULD retain stock behaviour, thus no fancy features, and you'll have to deal with 2 science systems instead of a unified one. Mod compatibility is an ongoing process, so most mainstream mods will be supported at some point or another. Regarding HDDs. If something has a 512kB drive, means it's not patched. This is a standard global drive size value, as 2.1.2 drives had infinite capacitties, which would break all sorts of "balance" that we're trying to achieve. Infinite drives basically nullify a whole bunch of work that we put in, thus 512kB.

Mk1 Pod configuration is intentional. Both it being unpressurized and not getting HDD upgrades. We're trying to give you an incentive to use higher tech pods, in addition to more crew capacity/more ec, etc. I still have to wrap my head around configuring contracts. It will be done at some point, but i wouldn;t hold my breath. may take a while. It's very tedious and time consuming.