[1.11.2] B9PartSwitch v2.18.0 (March 17)

[Nertea]

10 hours ago, blowfish said:

I did manage to reproduce, but the solution is still stumping me.  I so far have determined that it has something to do with re-rendering drag cubes, so I suppose you can disable that while I continue to investigate this.

E: Figured out what's going on.  Reported to Squad so that hopefully the underlying issue will be fixed in KSP 1.3.1.  Will look into whether an interim hack is possible to fix it before then, no promises though.

No problem, thanks for investigating so fast! There's an acceptable fix at the moment, which is just re-rooting so that the command pod is not the root part, so I'm not too worried.

[blowfish]

B9PartSwitch v1.8.1 for KSP 1.3 is now available

• Fix drag cubes being overwritten with defaults on root part in flight scene
• Fix vessel disappearing from map view if root part has a switcher that affects drag cubes**

** I had to implement a bit of a hack to get around the issue @Nertea reported above.  I have reported the underlying issue to the KSP team, and hopefully it will be fixed in KSP 1.3.1 so that I can remove this workaround

[Nertea]

That was fast! Thanks for the quick fix!

[Pappystein]

Ok so I am just starting to play with B9PartSwitch.   A couple questions

1) Is there a way that B9 Part switch can switch between different Configs on the same model?   I am looking for a way to eliminate duplicate parts...   I am thinking for the LR-87-5/7/9/11/11A family.   I could see going the route of SSTU but that adds a lot of complexity because whole models are swapped in and out.  In the case of the LR87 family... not much changes visually at the KSP level thus no need for additional models/parts..... If swapping is possible.    Obviously the Part Upgrade path is an alternative but it brings about it's own problems (I may WANT the older version down the line.)

2)what order does B9PartSwitch process CFG files that affect it?  Is there a way to "patch" the B9PS Cfg files with other files similar/with MM?   I am trying to add four Hypergolic fuels in three combinations to multiple mods that each have their own B9PartSwitch Fuel.  Both mods (Bluedog_DB and FueltankPlus) use MM files to add the B9PartSwitch to their Tanks...  The B9 process is NOT built into the core Cfg files of any of the tanks in question.

 

Thanks for help with NOOB questions!

 

 

[blowfish]

12 minutes ago, Pappystein said:

Ok so I am just starting to play with B9PartSwitch.   A couple questions

1) Is there a way that B9 Part switch can switch between different Configs on the same model?   I am looking for a way to eliminate duplicate parts...   I am thinking for the LR-87-5/7/9/11/11A family.   I could see going the route of SSTU but that adds a lot of complexity because whole models are swapped in and out.  In the case of the LR87 family... not much changes visually at the KSP level thus no need for additional models/parts..... If swapping is possible.    Obviously the Part Upgrade path is an alternative but it brings about it's own problems (I may WANT the older version down the line.)

2)what order does B9PartSwitch process CFG files that affect it?  Is there a way to "patch" the B9PS Cfg files with other files similar/with MM?   I am trying to add four Hypergolic fuels in three combinations to multiple mods that each have their own B9PartSwitch Fuel.  Both mods (Bluedog_DB and FueltankPlus) use MM files to add the B9PartSwitch to their Tanks...  The B9 process is NOT built into the core Cfg files of any of the tanks in question.

Thanks for help with NOOB questions!

1. B9PartSwitch can change the model but not actually anything about the engine itself (thrust, Isp, ...)
2. MM runs, then all the tank types are loaded (but not any parts that use them), then the parts are compiled including any part switch modules.  Anything you do in MM will necessarily run before B9 Part Switch is even aware of anything.

Hope that helps!

[Pappystein]

So if B9PartSwitch does not allow select-able CFG / Select-able Upgrades  IS there a method to do so?   I have looked into SSTU and while it is an awesome mod, it is a bit daunting and requires a full download of the SSTU mod.

To be Honest, I was hoping B9PartSwitch handled this because it seems to be the easiest and quickest/simplest of any mods I have looked at for any sort of Functionality changes...  Also given how quickly you have updated it to solve issues... one of the most efficiently supported nope not any sort of gratuitous brown-nosing here just the truth!

The Upgrade process as laid out by Squad would sort-of work.  But I have several rockets that really can't take advantage of the improved versions of the engines and further If I want to go back to older variants I can't

I know I am wandering off Topic but since the discussion was started here I thought I would/should ask.

 

 

[blowfish]

Unfortunately B9 Part Switch wasn't really designed to handle changing arbitrary info on any other PartModule.  As it is, every thing that it touches I have had to add with code, and it does not interact with any other modules currently.  I've been thinking about ways to add this in a consistent and reliable way, but it's not a trivial problem to solve.

[Pappystein]

19 hours ago, blowfish said:

Unfortunately B9 Part Switch wasn't really designed to handle changing arbitrary info on any other PartModule.  As it is, every thing that it touches I have had to add with code, and it does not interact with any other modules currently.  I've been thinking about ways to add this in a consistent and reliable way, but it's not a trivial problem to solve.

Thanks for the explanation...   I hope you have a series of Blinding Eureka moments and it becomes the easiest code you have ever written

 

 

[Nertea]

@blowfish, what's the feasibility for getting some kind of stack symmetry modifer for subtypes? Example - I have a part with a varying amount of engine cluster mounts that I'd like symmetry to behave well with.

[blowfish]

17 minutes ago, Nertea said:

@blowfish, what's the feasibility for getting some kind of stack symmetry modifer for subtypes? Example - I have a part with a varying amount of engine cluster mounts that I'd like symmetry to behave well with.

I can look into it.  Not sure exactly how that field functions, but any fields on the part itself can be added relatively easily.  Could you open an issue at Github so that I don't forget?

[Nertea]

Done!

[blowfish]

B9PartSwitch v1.9.0 for KSP 1.3 is now available

• Add stackSymmetry part field to subtypes

This ended up being a very easy change.  All the other requests are still on my radar but there was no point in waiting on this.

[trias702]

Hello,

I am trying to compile B9 Part Switcher from source on Visual Studio 2012 and have run into an issue which I was hoping I could ask about here. It looks like the code makes heavy use of C# 6.0, so the native VS2012 compiler won't work. I see that you link in the Roslyn compiler, version 2.0.1, via NuGet which would indeed compile C# 6.0. However, according to all of the documentation I can find, the Roslyn compiler will only work with Framework 4.5, which, if I'm not mistaken is not supported by KSP 1.2.2 (all .dlls compiled for KSP 1.2.2 must be no higher than Framework 3.5)? I note that the packages.config file distributed in the source code has the following entry:

<package id="Microsoft.Net.Compilers" version="2.0.1" targetFramework="net35" developmentDependency="true" />

The target framework in the project files also points to 3.5; however, because of this mismatch between Roslyn's requirement of 4.5 and the project using 3.5, I get the following error when opening the project:

The "Csc" task could not be instantiated from the assembly "..\B9PartSwitch-1.9.0\B9PartSwitch-1.9.0\packages\Microsoft.Net.Compilers.2.0.1\build\..\tools\Microsoft.Build.Tasks.CodeAnalysis.dll". Please verify the task assembly has been built using the same version of the Microsoft.Build.Framework assembly as the one installed on your computer and that your host application is not missing a binding redirect for Microsoft.Build.Framework. Unable to cast object of type 'Microsoft.CodeAnalysis.BuildTasks.Csc' to type 'Microsoft.Build.Framework.ITask'.

At least, I think it's because of the mismatch between them. I don't know enough about binding redirects to understand how to fix them. Even though I'm using VS2012, I have MSBuild 14.0 installed, but perhaps it's pointing to the old Microsoft.Build.Framework instead of the v14.0 one? Is there something else going wrong here of which I'm not aware? I would greatly appreciate any help you might provide.

EDIT: Nevermind, I solved the issue. Building the solution with MSBuild fixed everything.

Edited July 14, 2017 by trias702

[Aelfhe1m]

2 hours ago, trias702 said:

Hello,

I am trying to compile B9 Part Switcher from source on Visual Studio 2012 and have run into an issue which I was hoping I could ask about here. It looks like the code makes heavy use of C# 6.0, so the native VS2012 compiler won't work. I see that you link in the Roslyn compiler, version 2.0.1, via NuGet which would indeed compile C# 6.0. However, according to all of the documentation I can find, the Roslyn compiler will only work with Framework 4.5, which, if I'm not mistaken is not supported by KSP 1.2.2 (all .dlls compiled for KSP 1.2.2 must be no higher than Framework 3.5)? I note that the packages.config file distributed in the source code has the following entry:

<package id="Microsoft.Net.Compilers" version="2.0.1" targetFramework="net35" developmentDependency="true" />

The target framework in the project files also points to 3.5; however, because of this mismatch between Roslyn's requirement of 4.5 and the project using 3.5, I get the following error when opening the project:

The "Csc" task could not be instantiated from the assembly "..\B9PartSwitch-1.9.0\B9PartSwitch-1.9.0\packages\Microsoft.Net.Compilers.2.0.1\build\..\tools\Microsoft.Build.Tasks.CodeAnalysis.dll". Please verify the task assembly has been built using the same version of the Microsoft.Build.Framework assembly as the one installed on your computer and that your host application is not missing a binding redirect for Microsoft.Build.Framework. Unable to cast object of type 'Microsoft.CodeAnalysis.BuildTasks.Csc' to type 'Microsoft.Build.Framework.ITask'.

At least, I think it's because of the mismatch between them. I don't know enough about binding redirects to understand how to fix them. Even though I'm using VS2012, I have MSBuild 14.0 installed, but perhaps it's pointing to the old Microsoft.Build.Framework instead of the v14.0 one? Is there something else going wrong here of which I'm not aware? I would greatly appreciate any help you might provide.

Roslyn is built in .NET 4.5 which is why it requires it. But the C#6 compiler is capable of generating framework 3.5 code - all "recent" versions of the C# compiler have been able to target older versions of .NET.

The Csc error you quote means that your machine does not have an up to date version of .NET installed (a potential security hole by the way) needed for the compiler itself to run rather than it being unable to compile to an older target framework.

Is there a reason you're using VS2012 rather than the (free) VS Community 2017?

[trias702]

32 minutes ago, Aelfhe1m said:

Roslyn is built in .NET 4.5 which is why it requires it. But the C#6 compiler is capable of generating framework 3.5 code - all "recent" versions of the C# compiler have been able to target older versions of .NET.

The Csc error you quote means that your machine does not have an up to date version of .NET installed (a potential security hole by the way) needed for the compiler itself to run rather than it being unable to compile to an older target framework.

Is there a reason you're using VS2012 rather than the (free) VS Community 2017?

Thank you kindly for the help! I sorted it all out in the end though, it built fine as is when I switched to MSBuild 14.0. I'm not sure the issue was with having an out-of-date version of .NET, as I have up to 4.6.2 with all security patches. I think it has more to do with VS2012 not seeing MSBuild 14.0 correctly, and having no understanding of the C# 6 syntax in the project, or its external link to the Roslyn compiler. Everything worked perfectly with MSBuild from command line, using the Roslyn compiler and targeting Framework 3.5. So everything needed to compile was there on my computer all along, it was just a matter of getting VS2012 to see it also, something which I was not able to do. I'm not sure it's possible to have Roslyn integrate with VS2012 such that VS doesn't red highlight all of the C# 6 specific syntax.

[blowfish]

I originally included Microsoft.Net.Compilers to force by build pipeline (compiling against Mono on Linux) to use Roslyn rather than the Mono compiler.  I suppose I could remove it now that Mono got rid of its compiler and comes with Roslyn, but I don't think it's really harming anything.

Regarding VS and C# versions, I think that specific VS versions only support specific C# syntax versions.  Fair warning, I will likely begin to add C# 7 syntax as I see fit, so you should probably be using VS Community 2017 if you don't want it to show that as an error.

[GonDragon]

Hi! I'm doing some experiments with this mod, and I think I nailed the fuel type switch but... about the mesh switch, I think I didn't get it...

Reading the Wiki, and looking for some examples in Near Future Mods Github, I ended with something like this:

 

MODULE
	{
		name = ModuleB9PartSwitch
		moduleID = meshSwitch
		switcherDescription = Boattail
		
		SUBTYPE
		{
			name = No
			transform = ¿?
		}
		SUBTYPE
		{
			name = Yes
			transform = ¿?
		}
	}

 

I don't know exactly what put into transform. I guess I should put there a name that point to some structure where the mesh is defined, but I don't know what that structure is. In the mod that I checked, the name was something ambiguous, like "ColideA".

To put everything in context: I have the meshes and textures of two diferent engines, I want to use B9PS to being able to change between one engine and the other... Only the meshes (and probably, the colition box), no other effects or stats.

Can someone help me? Thanks in advance.

[blowfish]

53 minutes ago, GonDragon said:

I don't know exactly what put into transform. I guess I should put there a name that point to some structure where the mesh is defined, but I don't know what that structure is. In the mod that I checked, the name was something ambiguous, like "ColideA".

Yeah, it's difficult to know the transform names unless you made the model.  There are a couple of ways to work around that though:

1) Install this mod and use it to inspect the hierarchy in game:

2) Use this to import the model into Blender and inspect it there

--------

Although, if you are switching between two models defined in separate .mu files and MODEL nodes, the root transforms of each model have a special name which I can show you

[evileye.x]

Hello @blowfish.

Stupid question - can this plugin be used to change procedural fairing sides shapes and textures? Instead of having bunch of configs like this mod has?

 

[blowfish]

1 minute ago, evileye.x said:

Hello @blowfish.

Stupid question - can this plugin be used to change procedural fairing sides shapes and textures? Instead of having bunch of configs like this mod has?

I'm pretty sure the answer is no.  The shapes are all procedurally generated, and there's currently no pure texture switching.

[evileye.x]

7 minutes ago, blowfish said:

I'm pretty sure the answer is no.  The shapes are all procedurally generated, and there's currently no pure texture switching.

The shapes are not all procedural generated, the size is. The shape is ruled by config:

@MODULE[ProceduralFairingSide]
    {
        %density=0.1
        %specificBreakingForce =2000
        %specificBreakingTorque=2000

        %noseHeightRatio=2.2
        %baseConeShape=0.3, 0.3, 0.9, 1
        %noseConeShape=0.54, 0, 0.52, 0.035
        %baseConeSegments=2
        %noseConeSegments=10

        %mappingScale=1024, 1024
        %stripMapping=992, 1024
        %horMapping=10, 490, 500, 980
        %vertMapping=10, 170, 694, 1014
    }

This one for soyuz shape.

 @MODULE[ProceduralFairingSide]
    {
        %density=0.1
        %specificBreakingForce =2000
        %specificBreakingTorque=2000

        %noseHeightRatio=3.5
        %baseConeShape=0.1, 1.0, 0, 0.7
        %noseConeShape=0.1, 0, 0.7, 0.667
        %baseConeSegments=3
        %noseConeSegments=11

        %mappingScale=1024, 1024
        %stripMapping=992, 1024
        %horMapping=10, 490, 500, 980
        %vertMapping=10, 170, 694, 1014
    }

This one for Atlas.

But I guess the answer is still no?

[Aelfhe1m]

41 minutes ago, evileye.x said:

The shapes are not all procedural generated, the size is. The shape is ruled by config

The shapes are procedural - as opposed to being defined by a mesh file. The parameters in the config define the rules for the procedural algorithm to generate a specific profile.

Edit: In order to have shape switching I think procedural fairings would need some sort of collection of shape nodes in the config that could then be switched between on demand sort of link procedural parts' tank shapes. This would involve code changes in the PF mod however not really something part switchers like B9 are designed for.

Edited July 18, 2017 by Aelfhe1m

[blowfish]

Basically what Aelfhe1m said - B9PartSwitch has no general way to interact with data in other mods.

[evileye.x]

I suspected that, thank you for clarification. Still, the plugin is great.

Edited July 19, 2017 by evileye.x

[EdwardB3020]

I need help! Which folder do I need to move into the Gamedata folder?