blowfish

Each version of KJR is really only designed for one KSP version. If you want to use previous KSP versions, you will need a previous KJR. All the old versions are available on Github.

Thanks for finding that! Would you mind reporting on Github so I remember to fix it?

You can put more than one mod in a NEEDS block, separated by & or , (meaning and), or | (or), e.g. :NEEDS[mod1,mod2]

Correct, any combination of more than one :FOR, :BEFORE, :AFTER, :FIRST, :FINAL is not allowed. But again, it wasn't really meaningful even in previous versions of MM, it would always use the first one and ignore any others.

Thanks! I see errors from RealPlume-StockConfigs and SETI. The RealPlume-Stock errors have been fixed in 1.0.1, so be sure to update. I've reported the SETI error in the thread but no response from the author yet (and can't make sense of which Github repositories correspond to what so I can't submit a fix myself). :FOR[GPOSpeedFuelPump]:FINAL, :FOR[GPOSpeedFuelPump]:FINAL, :AFTER[zzz_CryoTanks]:FINAL are all specifying two passes. ModuleManager has only ever applied the patch in one pass, so it was previously meaningless (and now an error) to provide more than one.

@PART[*] works fine, because each PART node will always have a name value (or KSP will not compile the part). However, @PART:HAS[...] will work fine, you only need the ,* on subnodes, since by default it will only apply to the first one. The problem we found here was with EXPERIMENT_DEFINITION, since those don't have a name value.

Do you have DropBox, Google Drive, OneDrive, or similar? Most people use one of those (and then share the file).

The simplest thing to do is just to upload your log. There's a lot in there, but myself and others who have experience doing this can find what we need to pretty quickly. Also worth making sure all your mods are up to date - many have been updated for this in the last few days.

IIRC, their main purpose is to increase the stall angle so that you can perform higher AoA maneuvers without stalling.

The fairing auto-deploy will keep the payload attached though - only the fairing sides will get detached once you reach that altitude. You can keep the payload attached for as long as you want after that, at which point you can stage to decouple the payload.

For the fairing itself, you have an "Auto-Deploy Fairing" toggle, for the decoupler you have the "Decoupler: Disable Staging" action (again, you may have to turn on advanced tweakables, I don't remember). I'm interested to know why the auto-deploy doesn't work for your purposes though. Could you explain that to me?

Yes. The idea is that the fairings will auto-deploy (but not decouple the payload) at the correct altitude, then you will later stage to deploy the payload. But this is configurable - you can disable the auto-deploy if you want, and turn off decouple on stage (this might require advanced tweakables, not sure)

B9 Part Switch doesn't do anything to anything to any tank by default. If there is a B9 Part Switch module on these parts, then some other mod is adding it. Do you perhaps have CryoTanks installed?

Hello! It seems that a couple of SETI mods have some ModuleManager patches that have more than one pass specified, e.g. :AFTER[RemoteTech]:FOR[SETIprobeParts] . This never really did anything useful, it would always apply to the first pass (in that case :AFTER[RemoteTech]). But in the new version of ModuleManager this generates an error. Since I am responsible for the changes in ModuleManager, I meant to identify as many mods as possible with this problem before the release, but evidently I missed several (sorry!) Based on logs that I have seen, the following files seem to have this issue: P.S. it's not immediately clear to me which Github repos correspond to which parts of SETI. If you would prefer this info in the form of Github issues, feel free to point me to the correct repos.

The issue has been fixed in RealPlume-Stockalike. I see additional occurrences of the error in SETI, I'll report them to the author of that mod.

The planetarybaseinc is a different bug actually, but thanks for finding it. It turns out I broke :NEEDS checking on subnodes/values if the root node also has :NEEDS

Hmm, this was not an intentional change, I'll look into it. I mean, it kind of makes sense as the thing in the brackets is supposed to stand in for a name value, but still. If you upload your log I can take a look and see what mods these patches might belong to.

KRJ works fine in 1.3.1. If anyone has any serious problems to talk about, they should probably formally report them with logs and full reproduction steps.

It looks like the licenses might not quite be compatible, so I will have to get in contact with BahamutoD to get permission for them to be re-licensed.

Have been meaning to do this actually - still have to verify that the license is compatible, but it seems reasonable to include the B9 textured versions of those.

B9PartSwitch v2.1.0 for KSP 1.3.1 Add texture switching Each subtype can now have TEXTURE nodes which take the following fields: texture (required) - path to the texture you want to use, e.g. MyMod/Parts/SomePart/texture currentTexture (optional) - name of the current texture (just the filename excluding the extension, not the full path). Anything that does not have this as the current texture will be ignored. isNormalMap (optional, default false) - whether the texture is a normal map or not (necessary due to KSP treating normal maps differently when they are loaded) shaderProperty (optional) - name of the shader property that the texture sits on. Default is _MainTex if isNormalMap = false or _BumpMap if isNormalMap = true. For an emissive texture you would want _Emissive transform (optional, can appear more than once) - names of transforms to apply the texture switch to baseTransform (optional, can appear more than once) - names of transforms where the texture switch should be applied to them and all of their children If no transform or baseTransform is specified, it will look for textures to switch on the entire part

I could’ve sworn the patches did that already...

Hey, thanks for providing the screenshot and log! It looks very much to me like your GameData/Squad folder is corrupt - you're missing all of the stock resources (looks like this is causing some other issues as well)

KSP has no physics concept of the entire vessel, it's really just a a bunch of parts bound together by physics forces. I think what you want to do is apply the force to each part proportionally to its mass. BTW, part.vessel.GetComponent<Rigidbody>() will return the root part's rigidbody (vessel is attached to the same GameObject as the root part)

I took a look at the code, | doesn't work at all in a HAS block unfortunately