blowfish

AFAIK, if you compile against an assembly, then the AssemblyVersion of it is baked into that reference and it will refuse to use any other version. Makes it kind of difficult to add dependencies.

It looks like the plugin is built against BDArmory, so it's expecting to find that plugin too but it's not there (or it did not load properly)

If Github is blocked, you are going to have trouble downloading a very large number of mods. I'd recommend looking into why this is and fixing it.

Got a development build with working texture switch if anyone wants to play around with it: https://s3.amazonaws.com/blowfish-ksp-b9partswitch-dev-builds/TextureSwitch/B9PartSwitch_TextureSwitch_325_v2.0.0-4-ge3bf962.zip How to use it: 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 values are specified, the texture switch will apply to the entire part. All the textures will be reverted to their originals once another subtype is selected (or that subtype's textures will be switched, if it has any). For reference, here is an example minimal setup: SUBTYPE { name = originalTexture title = Original Texture { SUBTYPE { name = newTexture title = New Texture TEXTURE { texture = MyMod/SomeFolder/SomeTexture } } In this example, the "Original Texture" subtype would have the original textures, and the "New Texture" subtype would have the texture SomeTexture applied to the entire part. Definitely looking for feedback about this, including the process of setting it up (in addition to any bugs that might show up of course). Don't hesitate to ask if you have questions or concerns!

Getting PBR working properly requires more than just making configs (need addtional maps). I think it would be cool, but probably not something I have the time to do right now. If someone else wants to work on it though, I'd be more than happy to include that in B9

Doesn't sound like it's caused by B9. Might want to take a look at the "how to get support" link in my signature to you can give us the info we need (logs) to figure out what's really causing your issue.

FYI, you can now remove the craft-breaking workaround of renaming one of the nodes. As of 2.0.0, B9PartSwitch will match on exact names, so top and top2 will be independent

B9 Part Switch v2.0.0 for KSP 1.3.1 Major version change as this contains a potentially breaking change (probably not though) Only match on exact attach node id (this is the potentially breaking change, see below) When switching in flight, resources should always start empty Allow individual subtypes to not allow switching in flight via allowSwitchInFlight field Allow ModuleB9PartSwitch to have its GUI hidden if it has advancedTweakablesOnly = true and advanced tweakables are disabled Better error handling if resource of tank type does not exist (show error dialog in game and force the user to quit) Fix .version file not being able to be parsed by KSP-AVC Move remote .avc file from bintray to s3 Add back assembly guid (accidentally removed a while ago) More info on only matching exact node IDs: Previously if you had node = top, that would match node_stack_top, node_stack_top01, etc. Now it will only match node_stack_top.

Problem is that there isn't really a standard notion of what a mod is. Most mods are self-contained within a directory in GameData, but some mod authors choose to put all their mods in the same GameData directory and then have the individual mods' directories under that. And then there's ModuleManager which is installed directly into GameData without a directory. KSP pretty much just loads everything in GameData without considering how it's organized.

The idea is that information will be stored in instance variables between the two (loaded into instance variables from the node in OnLoad, and then saved back into the node in OnSave). For KSPField fields, it will only save those with isPersistent = true (i.e. those that might be modified by user actions)

Shadow Space Technologies Unlimited or Single Stage to Uranus, depending on who you ask

For what's worth, it's probably best to avoid modifying GameData/Squad/ if possible. ModuleManager patches don't care where they are, so you can put them in another GameData subdirectory.

You appear to have some stuff in GameData/Squad/Stock_RealChute_MM/ ... I know that doesn't come with KSP (found that in the log)

Yeah, the .version file had the version numbers as strings instead of numbers. CKAN seems to digest this fine, but apparently AVC doesn't like it. It's already been fixed, just haven't released a new version since then.

PSA - I plan to release version 2.0 soon, which will contain a potentially breaking change. Currently, if you specify node = xxx on a subtype, B9 Part Switch will find all nodes that contain xxx. This has caused some issues, and I plan to change it so that it will only find nodes that exactly match xxx. So for example node = top will currently match node_stack_top, node_stack_top01, node_stack_top02, etc, but with this change it would only match node_stack_top (the node_stack_ part is stripped out by KSP in either case). Please let me know if there are any concerns about this.

Interesting, the transforms seem to be facing the wrong way. I'll look into correcting it, but I don't have access to the original source files which makes it somewhat difficult.

Might be a better question for the RO thread. I don't know off the top of my head.

B9 Aerospace v6.4.0 for KSP 1.3.1 Release for KSP 1.3.1 Bring back engine pylons for use on things other than engines (note, they only show up if you have the legacy pack installed) Unify all tank masses with the same formula Reduce mass of structural tank variants a bit Remove unbalanced battery option on Y1 end cap CryoTanks: Bring LH2 and LH2O tank stats more in line with CryoTanks CryoTanks: Add cooling to all tanks as in CryoTanks CryoTanks: Fix definition of boiloff module Fix a couple of legacy wings having nonexistent tech nodes Fix FAR patches on S2 fuselages not properly removing ModuleLiftingSurface

In general I wouldn't expect RO to work well with the stock tech tree. It's really designed for either sandbox or RP-0. E: just to clarify, I don't think RO does anything with the tech tree. So RO parts will end up in whatever node the stock/mod part they are based on was originally in

Anything can have :NEEDS on it and MM will look at that

You'll see the most benefit for long-burning upper stages. The tankage looks like a lot more but it actually masses less.

Really depends on if you're talking about RF Stockalike or RO. RF doesn't do anything to engines by itself so it's up to whichever mod is providing the engine configs to add RF and possibly move them around in the tech tree.

I don't think it's related. But here's the explanation of the order of all patches: All patches marked :FIRST are run All patches with no pass specified are run (this is called the legacy pass) For each installed mod*, in alphabetical order: All patches marked :BEFORE[mod] are run All patches marked :FOR[mod] are run All patches marked :AFTER[mod] are run All patches marked :FINAL are run * ModuleManager considers a mod to be installed if one of the following 3 conditions is met: A DLL named mod.dll exists somewhere in GameData A patch marked :FOR[mod] exists A directory exists in GameData named mod/

Welcome toe the forums! Is the problem that it isn't showing up on CKAN or that there is some error when you try to install? If it's just not showing up, the problem is probably just that you're on KSP 1.3.1 and it's not marked as compatible. I've been meaning to make a new release for KSP 1.3.1 but just haven't gotten around to it yet. Should hopefully have time this weekend.

A patch can only be run once. This should have been the case before as well. I'm confused about what you're talking about here...