[1.11.2] B9PartSwitch v2.18.0 (March 17)

[AccidentalDisassembly]

7 minutes ago, blowfish said:

Sure, specifying a default is easy, the question is how to decide when to use this and when to try to determine the subtype automatically based on resources.  One option would be to always use the default if it is specified, but that would effectively break the feature for anything having a default.  Another option would be to only use it if there are no resources currently on the part.

Yup.  It will detect that the resources are there already and use them rather than creating new ones.  You don't even have to match up the amounts, but if you didn't then you might end up with partially filled tanks and it would display the wrong amounts to the user in the part info window.

OK, that makes sense. In that case, it seems like I can simply write my "universal patch" without ever removing resources from the tank - Since I want the tanks to have their original setup as a default, and since the amounts will remain the same as they were originally, it sounds like the setting-to-default stuff will take care of itself manually. Thanks for the info! Will go try it out.

Regarding the idea of specifying a default type.. It seems to me that breaking the auto-detect feature when a "defaultTank" (or whatever) is specified is exactly what you'd want to happen: if the user specifies a default, overriding the auto-detect feature is what they're trying to accomplish. Unless I am not thinking of some use cases... If the user prefers the auto-detect feature, for whatever reason, they simply don't define a default in a given patch.

Edited March 7, 2017 by AccidentalDisassembly

[blowfish]

9 minutes ago, AccidentalDisassembly said:

OK, that makes sense. In that case, it seems like I can simply write my "universal patch" without ever removing resources from the tank - Since I want the tanks to have their original setup as a default, and since the amounts will remain the same as they were originally, it sounds like the setting-to-default stuff will take care of itself manually. Thanks for the info! Will go try it out.

It occurs to me that there might be some inconsistency in the part's cost, since KSP assumes that the base cost includes resources and B9PartSwitch assumes that it isn't.  It would be hard to say for sure without trying it though.  Let me know what you see!

1 minute ago, AccidentalDisassembly said:

Regarding the idea of specifying a default type.. It seems to me that breaking the auto-detect feature when a "defaultTank" (or whatever) is specified is exactly what you'd want to happen: if the user specifies a default, overriding the auto-detect feature would in fact be exactly what they want to happen. Unless I am not thinking of some use cases... If the user prefers the auto-detect feature, for whatever reason, they simply don't define a default in a given patch.

It would work for users transitioning from a stock to a switching setup, but would break for moving e.g. from firespitter mesh switch to B9PartSwitch.  But maybe that matters less now that all of B9 is actually converted.

[Jso]

I didn't even know there was an auto detect feature, and I currently remove any managed resources from the part. But were I taking advantage of auto detect (and I might now that I know about it), and then added the proposed default = subtype I would expect it to do something. That's a very direct way of telling B9 my intentions vs guessing based on the default resources.

Getting cost to display sensibly in the VAB pallet is a bit counter intuitive but I don't think there's much you can do about that without breaking a lot of configs. 

[AccidentalDisassembly]

On 3/6/2017 at 5:13 PM, blowfish said:

It occurs to me that there might be some inconsistency in the part's cost, since KSP assumes that the base cost includes resources and B9PartSwitch assumes that it isn't.  It would be hard to say for sure without trying it though.  Let me know what you see!

It would work for users transitioning from a stock to a switching setup, but would break for moving e.g. from firespitter mesh switch to B9PartSwitch.  But maybe that matters less now that all of B9 is actually converted.

Yeah, I haven't quite figured out what the cost is being calculated from, except for the resources present - that part is clear. When controlling for resource costs in an FLT-400 tank, though, it still costs 100 credits more than without the patch I've made.

What exactly does tankCost do? Perhaps the default type I'm using (LFO) is adding the tankCost to the "cost = 500" in the Squad config? The LFO type has "tankCost = 0.25"... if that means 0.25 times the number of volume units (measued in units of 1 LF or OX), then that would make sense, because 500 + 0.25x400units = 600. But I thought that variable overwrites the cost entirely rather than adds.

[blowfish]

36 minutes ago, AccidentalDisassembly said:

What exactly does tankCost do? Perhaps the default type I'm using (LFO) is adding the tankCost to the "cost = 500" in the Squad config? The LFO type has "tankCost = 0.25"... if that means 0.25 times the number of volume units (measued in units of 1 LF or OX), then that would make sense, because 500 + 0.25x400units = 600. But I thought that variable overwrites the cost entirely rather than adds.

It adds to the base cost, same as mass.

[Cratzz]

Hi, im having a conflict with RealFuels it seems, with B9PartSwitch installed i can't navigate the part-list in SPH or VAB. Here's my log

[blowfish]

1 hour ago, Cratzz said:

Hi, im having a conflict with RealFuels it seems, with B9PartSwitch installed i can't navigate the part-list in SPH or VAB. Here's my log

I see the problem.  You have B9_Aerospace_Legacy installed but not the main pack.  The legacy pack depends on the main pack.  This failure should probably be more graceful on B9PartSwitch's side though.

[Blackline]

Is it possible to change the tank layout during flight? Lets say from LFO to LiquidFuel? I think @FreeThinker's IFS can do that, but it seems to disable itself if b9PartSwitch is present.

Cheers!

[blowfish]

9 minutes ago, Blackline said:

Is it possible to change the tank layout during flight? Lets say from LFO to LiquidFuel? I think @FreeThinker's IFS can do that, but it seems to disable itself if b9PartSwitch is present.

Cheers!

It is currently disabled.  Definitely possible to implement, but I'd like to know a bit more about it first.  So what's your use case, or more broadly, what are you trying to accomplish by switching tanks in flight?

[Blackline]

I brought a tiny drill + ISRU station with only one LFO tank, and would like to produce LH2+Ox (for another craft in range for simpleLogistics):

[FreeThinker]

On 9-5-2017 at 5:59 PM, Blackline said:

Is it possible to change the tank layout during flight? Lets say from LFO to LiquidFuel? I think @FreeThinker's IFS can do that, but it seems to disable itself if b9PartSwitch is present.

Cheers!

 

Yes off cource it is, but if you assigning IFS on a part, it will not disable itself

Edited May 14, 2017 by FreeThinker

[Blackline]

Ok, so I'd need to customize @blowfish's b9 cfg files and remove b9 tank switching and get @FreeThinker's IFS to do the job. Did anyone already do that?

Although I like b9's interface more, if it just had in flight switching...

[blowfish]

@Blackline one other thing to note is that the tanks typically have different dry masses, so you'd probably want a unique set of tank definitions just for this.  Then there's the question of what to do if the user tries to switch off of a tank with fuel in it (probably allow them to dump the fuel after confirming, but that's another thing that would have to be implemented).

[Blackline]

I think a dump button exists for ore tanks already, and also a small cfg to enable it for every tank/propellant. So only be able to switch empty tanks should be ok.

For the dry masses: just switch them together with the fuels (maybe ooc for some people) or set dry masses to an average/max value for those switchable tanks. Not every tank has to be switchable, it could be a selected subset IMHO.

[blowfish]

B9PartSwitch v1.8.0 for KSP 1.3

• Recompile for KSP 1.3
• Drag cube re-rendering now supports IMultipleDragCubes

More about drag cubes:

Previously, B9PartSwitch could re-render drag cubes, but it could only render one.  This means that stock modules that rely on multiple drag cubes (some animations, engine fairings) wouldn't work (if you switched meshes, you would either have to disable drag cube re-rendering or accept a single drag cube for both states).

In KSP 1.3, a new way to re-render drag cubes has been made available, so e.g. if the part has an animation, then both animation states can be re-rendered.  B9PartSwitch has been modified

Note, this is still unsuitable for cargo bays.  I am thinking of possible ways to deal with this.

[Jso]

On 5/14/2017 at 4:27 PM, blowfish said:

@Blackline one other thing to note is that the tanks typically have different dry masses, so you'd probably want a unique set of tank definitions just for this.  Then there's the question of what to do if the user tries to switch off of a tank with fuel in it (probably allow them to dump the fuel after confirming, but that's another thing that would have to be implemented).

I would love this for supply containers. Unload Food/Water/Oxygen, then switch it to Waste. Have you put any thought in to what the UI might look like? I can't see the current control widget fitting into a multi step "Are you sure?" process.

Perhaps some event hooks could be added? I could see wanting to do something additional on a tank change, like enable/disable other modules.

[Blackline]

On 14.5.2017 at 10:54 PM, Blackline said:

I think a dump button exists for ore tanks already, and also a small cfg to enable it for every tank/propellant. So only be able to switch empty tanks should be ok.

For the dry masses: just switch them together with the fuels (maybe ooc for some people) or set dry masses to an average/max value for those switchable tanks. Not every tank has to be switchable, it could be a selected subset IMHO.

anything regarding live fuel switching?

[Stevie_D]

Just a quick question about using b9 partswitch in our mods - I read the documentation, but didn't seem to find the answer to my question.

I'd like to add a resource as an option to my part, but do i -have- to create a definition in the tank definitions, or is there a way to just put a "addresource = ####" in the actual cfg module? (I'm trying to add an optional heatshield and adding the ablator resource)

Edited June 15, 2017 by Stevie_D

[Errol]

Can this be used to modify minThrust? Can it switch while in flight scene?

[blowfish]

On 6/13/2017 at 10:35 AM, Blackline said:

anything regarding live fuel switching?

Still thinking about how to do this.  It turns out that the way the UI currently works makes this somewhat difficult.

1 hour ago, Stevie_D said:

Just a quick question about using b9 partswitch in our mods - I read the documentation, but didn't seem to find the answer to my question.

I'd like to add a resource as an option to my part, but do i -have- to create a definition in the tank definitions, or is there a way to just put a "addresource = ####" in the actual cfg module? (I'm trying to add an optional heatshield and adding the ablator resource)

You can now add RESOURCE nodes directly to a SUBTYPE.  Note though that it's the same RESOURCE node that you would put in a TANK_TYPE, so there is no amount or maxAmount field (you want to use unitsPerVolume etc).  I wouldn't recommend creating a lot of these (this is exactly the problem tank types are designed for) but for one offs it probably makes sense

2 hours ago, Errol said:

Can this be used to modify minThrust? Can it switch while in flight scene?

Nope, sorry.  It does not interact with engine modules at all (or really any other module except other part switch modules)

[Stevie_D]

Thanks for the quick reply, Blowfish. It's appreciated! *scurries off to try it*

[Nertea]

Hey @blowfish, I'm having an issue where a part (command pod) loses its Vessel icon in the map view when the part is equipped with a switching module. This doesn't occur if the part is the second part on the vessel - only if it is the first part. The relevant code:

MODULE
	{
		name = ModuleB9PartSwitch
		moduleID = meshSwitch
		switcherDescription = #LOC_NFSpacecraft_command-mk4-1_switcher_title

		SUBTYPE
		{
			name = Basic
			title = #LOC_NFSpacecraft_command-mk4-1_switcher_variant1
		}
		SUBTYPE
		{
			name = 375m
			title =#LOC_NFSpacecraft_command-mk4-1_switcher_variant2
			transform = ShroudA
			//node = bottom02
			maxTemp = 1300
		}
		SUBTYPE
		{
			name = 5m
			title = #LOC_NFSpacecraft_command-mk4-1_switcher_variant3
			transform = ShroudB
			//node = bottom03
			maxTemp = 1300
		}
	}

[blowfish]

1 hour ago, Nertea said:

Hey @blowfish, I'm having an issue where a part (command pod) loses its Vessel icon in the map view when the part is equipped with a switching module. This doesn't occur if the part is the second part on the vessel - only if it is the first part. The relevant code:

Hmm.  I'm not aware of anything that could possibly cause this.  Is there any way I can try this out for myself?

[Nertea]

15 minutes ago, blowfish said:

Hmm.  I'm not aware of anything that could possibly cause this.  Is there any way I can try this out for myself?

Grab the most recent release of NF Spacecraft (https://spacedock.info/mod/708/Near Future Spacecraft). Replace the /GameData/NearFutureSpacecraft/Parts/Command/command-pods/command-mk4-1.cfg filewith the one from my dev branch (https://github.com/ChrisAdderley/NearFutureSpacecraft/blob/dev/GameData/NearFutureSpacecraft/Parts/Command/command-pods/command-mk4-1.cfg) as I've fixed some bugs.

To reproduce, just create a ship consisting of a single Mk4-1 Command Pod and launch it, and then check the map view.

[blowfish]

8 hours ago, Nertea said:

Grab the most recent release of NF Spacecraft (https://spacedock.info/mod/708/Near Future Spacecraft). Replace the /GameData/NearFutureSpacecraft/Parts/Command/command-pods/command-mk4-1.cfg filewith the one from my dev branch (https://github.com/ChrisAdderley/NearFutureSpacecraft/blob/dev/GameData/NearFutureSpacecraft/Parts/Command/command-pods/command-mk4-1.cfg) as I've fixed some bugs.

To reproduce, just create a ship consisting of a single Mk4-1 Command Pod and launch it, and then check the map view.

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.

Edited June 19, 2017 by blowfish