SilverState

Chatterer settings most likely

Don't get me wrong, i agree the :FINAL should be avoided at all costs, and ideally should be left to the players to reconfig stuff to their own preferrence. But not everyone respects that, and there's a bunch of :FINAL patches everywhere, once you start mildly modding your game.

He doesn't want, he needs to be late in the patching order, otherwise his patch may not do what it's intended to. There's quite a few mods that mess with EXPERIMENT_DEFINITIONs.

Surveys are broken currently. Contracts in general need a pass, I would assume a bunch are broken/not working as intended.

Note: There's some weirdness going on with transmitting data and not getting full science reward. Someone's working on a fix.

You may also want to specify a pass. Your patch breaks at the first sight of a mod that touches scienceCap. As your patch applies in the beginning, you're assigning baseValue the initial scienceCap. Once the scienceCap is changed by anything, baseValue stays at the old value. Generally, :FINAL passes are frowned upon, but considering how many mods mess with experiment definitions, you may be forced to do a :FINAL. In short, @EXPERIMENT_DEFINITION:HAS[~id[deployed*]]:FINAL { @baseValue = #$scienceCap$ }

I messed with the ordering a bit for some ungodly reason and a bunch of them are broken. Not sure about the ones you found in that post, I believe they SHOULD work. I'll revisit them at a later date and probably include them with a future release. The problem with those patches is that the result is not pretty. It's a hacky workaround that makes SSTU lose quite a bit of functionality, causes some weird side effects and introduces a new dependency. SSTU desperately needs plugin support, but the plugin wizards noped out when they saw how complex are SSTU modules (basically the reason was that SSTU is still technically in beta, and changes could be made at any moment. Supporting SSTU would have to be an ongoing effort, and that effort could probably be put to better use in developing Kerbalism further). I have an idea that i'm trying to pitch to them that should fix not only SSTU, but most mods that have custom panels. My MM Fu has also gotten better since then, so I'll have another go at them once more pressing issues are solved. As stated above, i'll probably include them in a future release once I have another look at them.

As @N70 said, [x]Science and any other science collection automation does not and probably will never work with kerbalism's science without support from the mod authors. There isn;t much we can do on our end, as we use a custom experiment module to be able to do all the fancy stuff, which needs to be accounted for by the mods themselves. [x]Science still provides info on what's not completed though afaik, so you still have at least some utility from it.

We need more info. This doesn;t really explain the problem. Tell us what experiments are you running, what other stuff you have on the vessel running, how many antennas, etc.

I'll also probably state the obvious: While we did try to test and weed out bugs, THERE WILL BE BUGS/INCONSISTENCIES. Kindly report them either on github (create a new issue), or on discord (link in OP). Ping one of the contributors, and if it's serious/gamebreaking, we'll try to fix ASAP. DO NOT ASK FOR MOD SUPPORT. I'll do them at my own pace, and they'll be included in next releases. It's a slow process, as I have to play with the mod for a bit to understand what/why it does certain stuff, then patch, then balance, then test. It's not fun. I will take mod suggestions though, but they'll be at my own discretion.

You can enable/disable features from ...\GameData\KerbalismConfig\Settings.cfg That's what he's referring to.

Maybe, but the choice is between having another mod (and possibly another dependency?) required vs setting a true/false inside a cfg.

As stated above, these are toggles for different features implemented by kerbalism. They can be found in settings.cfg in Kerbalism folder, and most of them have a Featurexxx associated with them. This is done to filter out when specific patches should apply related to a feature introduced by kerbalism, depending on wether they're enabled or disabled in the settings.cfg

Those are MM errors. we need more info, as in which .cfg causes them. Could also be a mod conflict, something that messes with the variable being searched for before that patch is being applied. I get no errors on a stock install + Kerbalism, so it's probably something to do with how that mod's parts are configured.

change animBackwards = True to animBackwards = False

Incorrect. Kerbalism calculates volume/surface based on part model. For more intricate parts, the calculations are way off, that's when it needs custom volume/surface cdefinitions, thus the custom values. If there are no custom values, it applies whatever it thinks the part should have.. But it most definitely calculates habitat volume and surface based on part model. If there's a Habitat module on the part, Kerbalism automatically calculates volume/surface. as stated above, if the part has an intricate model, most of the time the values will be calculated wrong. This is where you'd have to do your own calculations (plain old math) and set those values. If you set a value for surface/volume, Kerbalism will use these instead of what it calculates. The other stuff is related to animations/default state of the habitat, if relevant. all of these are inside the same module, make sure there aren;t multiple Habitat modules on a single part, otherwise it gets weird.

I have no idea, I haven't looked at KEES yet. I have other more important stuff to patch on my plate. When I get some breathing room i'll look into patching it. As a general rule, experiments should work, depending on if we can replicate the functionality. If not, 2 things will happen: 1: If too much stuff breaks that relies on them working as they are provided (such as contracts, all sorts of UIs, etc), they'll be left untouched. That means you'll still get science at a click of a button. The trade-off would be breaking that functionality, which may or may not be a good idea. We hope that if this picks up, modders will provide their own support for this system, or at least give me the green light to adapt the experiments to what we can replicate. 2: If only minor functionality is lost, and we can compensate with something else (e.g. making them more fun/challenging in a different way), they'll get changed accordingly at my discretion. Unpatched mods/experiments will retain their default behavior, till I get around to patching them. Exceptions are antennas and pods/probe cores. Antennas are hit by a global nerf (I have to do it, stock data rates are way too overpowered in this new environment), and unpatched pods/probe cores will get the smallest hard drive available until patched, for the same reason as with antennas - unlimited drives break all sorts of balance (or attempt at it)

Thanks a lot for this bit. You just made my life a whole lot easier.

Interesting. Was there a MM syntax change at some point? the @EXPERIMENT_DEFINITION[*] { whatever } should never work from what i can understand about MM. if you wanted to patch all the experiment definitions, you'd use @EXPERIMENT_DEFINITION,* { whatever } As i learned a few days ago, the moment you use a :HAS, MM is basically forced to do a search through all experiment definitions, regardless of what you do. It'll obviously only match the ones that respect the :HAS conditions, but nevertheless, it searches through all of them.

That actually makes sense. The [*] is a short way of typing :HAS[#name[*]]. That's what functionally it does. So my initial guess was off because I didn't pay enough attention to your syntax. As you probably noticed, they don't have names, just ids. So MM was looking for a name inside an experiment definition, which it obviously did not find, therefore nothing got patched.

Using stock messages as in still using stock planet names? If yes, that means that internally, Beyond Home may be using stock planet names (probably), they're just displayed under a different name. You'd have to change the stock messages themselves, and not add new ones. @EXPERIMENT_DEFINITION:HAS[#id[geigerCounter]]:NEEDS[BeyondHome,FeatureScience]:AFTER[Kerbalism] This is a slightly safer option, as it won't throw errors if kerbalism is not installed. But again, as Sir Mortimer said, you should not bother with this as they'll become redundant fairly soon.

USII is not patched yet afaik, so that's why. When it'll be patched, it'll work as intended. This will probably get fixed in 3.0

please do not download 2.2. Stick to 2.1.2 for now

The first one won't work because MM will search for CrewCapacity inside the Resource, which it will never find. The 2nd one does the exact opposite, it will search for all parts that have ModuleCommand and at least CrewCapacity = 1. Both of these should work: @PART[*]:HAS[@MODULE[ModuleCommand],#CrewCapacity[0]] @PART[*]:HAS[@MODULE[ModuleCommand]:HAS[#minimumCrew[0]]] The first one will work for all probe cores that have CrewCapacity defined. I believe some modded ones skip that, so MM will also skip patching them. The 2nd one is a lot more reliable, as all probes have that in common, modded or not. @Jso His syntax will also work.

I'm not sure, i'm not handling the patching for other stuff. I'm touching science and anything related to it.