[1.12.5] Bluedog Design Bureau - Stockalike Saturn, Apollo, and more! (v1.14.0 "металл" 30/Sep/2024)

[CobaltWolf]

2 hours ago, PickledTripod said:

Been a while since I posted anything here... Anyway little gift for @CobaltWolf and everyone:

Standalone Delta fairing ring! You can hang any 0.9375m tankage under it and even 1.25m parts will fit in the interstage. As pictured above the Ablestar tankage and a LM Descent Engine makes for a good approximation of the Delta-P stage used on Delta 1000, 2000 and 3000 series, with 75% the fuel load of Delta-K. Should be available on the dev github.

Awesome!!! Gives a lot more utility to the Delta stuff!

[Zorg]

hi @CobaltWolf, I've just submitted the PR for USI Life Support.

The patch does the following

Increases hab coverage benefits in Apollo Block 3 mission module to 3 crew although physical crew capacity of the module is 2 kerbals. I think Apollo missions should support at least 3 kerbals. A Kane MM when docked with a Kane capsule would have a lot of living space in total so I think its justified to increase the Hab coverage to 3. I am assuming they hot bunk

Adds Hab module to Apollo Block IV mission module. See above.

Adds supplies to Leo MSM service module as per existing item description. 

Adds EC to Skylab airlock. Not super essential in USI as there is always a grace period after you run out of EC but its still convenient so that you can still maintain command on the dark side of a low kerbin orbit without the recycler and lab eating up all your EC.

Patches Skylab RAM adapter identical to Airlock with extra EC and supplies.

Adds habitation and recycling to Skylab Orbital Workstation. Intended for 90 day mission duration for 6 crew.

Adds supplies and recycling to Saturn Venus Flyby module
Adds fertilizer and agroponics to flyby module for extended deep space exploration as per the USI paradigm for deep space exploration, saves a lot of weight over pure supplies. Assuming plenty of space for Hydroponic racks in the wet workshop

 

I hope USI users will find the patch reasonably balanced! I don't actually use the Hab functionality in my game but I think the values are in line with existing parts.

[notJebKerman]

8 minutes ago, Zorg said:

hi @CobaltWolf, I've just submitted the PR for USI Life Support.

The patch does the following

Increases hab coverage benefits in Apollo Block 3 mission module to 3 crew although physical crew capacity of the module is 2 kerbals. I think Apollo missions should support at least 3 kerbals. A Kane MM when docked with a Kane capsule would have a lot of living space in total so I think its justified to increase the Hab coverage to 3. I am assuming they hot bunk

Adds Hab module to Apollo Block IV mission module. See above.

Adds supplies to Leo MSM service module as per existing item description. 

Adds EC to Skylab airlock. Not super essential in USI as there is always a grace period after you run out of EC but its still convenient so that you can still maintain command on the dark side of a low kerbin orbit without the recycler and lab eating up all your EC.

Patches Skylab RAM adapter identical to Airlock with extra EC and supplies.

Adds habitation and recycling to Skylab Orbital Workstation. Intended for 90 day mission duration for 6 crew.

Adds supplies and recycling to Saturn Venus Flyby module
Adds fertilizer and agroponics to flyby module for extended deep space exploration as per the USI paradigm for deep space exploration, saves a lot of weight over pure supplies. Assuming plenty of space for Hydroponic racks in the wet workshop

 

I hope USI users will find the patch reasonably balanced! I don't actually use the Hab functionality in my game but I think the values are in line with existing parts.

The only change I'd make (and have made for myself) would be an addition of supplies to LEM ascent stage and mission modules. They are, after all, supposed to provide storage CM lost with the addition of two more seats

[Zorg]

1 hour ago, notJebKerman said:

The only change I'd make (and have made for myself) would be an addition of supplies to LEM ascent stage and mission modules. They are, after all, supposed to provide storage CM lost with the addition of two more seats

Fair point, we shouldn't let the poor Kerbals starve each time they need to make a surface expedition. I wasn't too familiar with the proposals that inspired the mission modules, I was working under the assumption the service module carries enough supplies (I also have universal storage to add extra packs into the storage bays of the service module). But taking into account the purpose of extended mission time, I will add some extra supplies into the two MMs in an update to the PR.

Edit: I think it might make more sense to add lander supplies to the descent stage as it has already been established to have storage capabilities (for instance KIS storage). Would keep the ascent stage as light as possible by leaving excess supplies behind. It would be expected the ascent stage would rendezvous with the command module asap after lift off.

Edited May 12, 2018 by Zorg

[notJebKerman]

2 hours ago, Zorg said:

Fair point, we shouldn't let the poor Kerbals starve each time they need to make a surface expedition. I wasn't too familiar with the proposals that inspired the mission modules, I was working under the assumption the service module carries enough supplies (I also have universal storage to add extra packs into the storage bays of the service module). But taking into account the purpose of extended mission time, I will add some extra supplies into the two MMs in an update to the PR.

Edit: I think it might make more sense to add lander supplies to the descent stage as it has already been established to have storage capabilities (for instance KIS storage). Would keep the ascent stage as light as possible by leaving excess supplies behind. It would be expected the ascent stage would rendezvous with the command module asap after lift off.

Mission modules are meant to be used on Block III+ & IV (and V for flights to Freedom). Those spacecraft use the smaller SM which doesn't hold supplies at all and is only used for LEO missions. As I've said the purpose of the mission module is to take over the components in CM in order to make space for two more seats.

While adding supplies to the descent stage would make sense, it would be really unrealistic. It's not pressurized, connected only at a few points and doesn't really hold anything but propellant and an engine. But the DS should probably have a waste tank that was used on later Apollo missions.

Edited May 12, 2018 by notJebKerman

[Zorg]

44 minutes ago, notJebKerman said:

Mission modules are meant to be used on Block III+ & IV (and V for flights to Freedom). Those spacecraft use the smaller SM which doesn't hold supplies at all and is only used for LEO missions. As I've said the purpose of the mission module is to take over the components in CM in order to make space for two more seats.

While adding supplies to the descent stage would make sense, it would be really unrealistic. It's not pressurized, connected only at a few points and doesn't really hold anything but propellant and an engine. But the DS should probably have a waste tank that was used on later Apollo missions.

Consider it done! 

[MaxZhao]

Was just wondering if there's any patches out there that converts the BDB fairing bases to use procedural fairings?

Sorry if this has already been asked!

[Gordon Dry]

@MaxZhao https://github.com/jsolson/BDB-ProceduralFairings/releases

But there is something that has to be fixed, found "somewhere"™ deep back in the posts.

GameData\Jso\Bdb\PF\bdb_pf.cfg :

@PART[bluedog*,Bluedog*]:HAS[@MODULE[ModuleProceduralFairing]]:First:NEEDS[ProceduralFairings]
{
	%extraNodeShift = 0.0
}

@PART[bluedog_ableFairing]:BEFORE[Jso_Bdb_PF]:NEEDS[ProceduralFairings]
{
	@extraNodeShift = -0.0171605
}
@PART[bluedog_ablestarFairing]:BEFORE[Jso_Bdb_PF]:NEEDS[ProceduralFairings]
{
	@extraNodeShift = -0.050
}
@PART[bluedog_DeltaK_FairingTank]:BEFORE[Jso_Bdb_PF]:NEEDS[ProceduralFairings]
{
	@extraNodeShift = -0.380
}
@PART[bluedog_centaurFairing]:BEFORE[Jso_Bdb_PF]:NEEDS[ProceduralFairings]
{
	@extraNodeShift = -0.129
}
@PART[bluedog_Saturn*FairingBase]:BEFORE[Jso_Bdb_PF]:NEEDS[ProceduralFairings]
{
	@extraNodeShift = -0.05
}

@PART[bluedog_Skylab_Airlock]:BEFORE[Jso_Bdb_PF]:NEEDS[ProceduralFairings]
{
	@extraNodeShift = -1.0 // insert correct vertical shift here.
}

+PART[bluedog*,Bluedog*]:HAS[@MODULE[ModuleProceduralFairing]]:FOR[Jso_Bdb_PF]:NEEDS[ProceduralFairings]
{
	@name ^= :$:_PF:
	@title ^= :$: (PF):
	
	// Modifier for the base size to account for PF shrinking
	// the part by the fairing wall width.
	// Fairing wall width: 0.04 * scale size
	%extraBaseRadius = #$MODULE[ModuleProceduralFairing]/baseRadius$
	@extraBaseRadius *= 2
	@extraBaseRadius *= 0.04
	
	// Hold the original fairing diameter in tempBaseSize, and set scale
	// to the scale needed to get to 1 meter. PF expects a 1 meter part.
	// Scale is adjusted to account for fairing wall.
	%tempBaseSize = #$MODULE[ModuleProceduralFairing]/baseRadius$
	%tempScaleSize = #$tempBaseSize$
	@tempScaleSize += #$extraBaseRadius$
	@tempScaleSize *= 2 
	@tempBaseSize *= 2
	@tempScaleSize /= #$tempBaseSize$
	%scale = #$tempScaleSize$
	@scale /= #$tempBaseSize$
	%rescaleFactor = 1
	
	// Scale the node positions
	@node_stack_top[1,,] *= #$scale$
	@node_stack_bottom[1,,] *= #$scale$
	
	// Save the top node position. Everything will shift by this amount
	// to move the top node to position 0. PF starts the fairing
	// at height 0.
	%tempShift = #$node_stack_top[1,,]$
	// Part specific adjustment
	@tempShift += #$extraNodeShift$
	
	// Scale and adjust model position
	@MODEL
	{
		%position = 0.0, 0.0, 0.0
		@position[1,,] -= #$../tempShift$
		%scale = #$../scale$, $../scale$, $../scale$
	}
	
	// Adjust node positions
	@node_stack_top[1,,] -= #$tempShift$
	@node_stack_bottom[1,,] -= #$tempShift$
	
	node_stack_connect01 = 0.5, 0.000, 0.0, 0.0, 1.0, 0.0, 0
    node_stack_connect02 = 0.5, 0.000, 0.0, 0.0, 1.0, 0.0, 0
	node_stack_connect03 = 0.5, 0.000, 0.0, 0.0, 1.0, 0.0, 0
    node_stack_connect04 = 0.5, 0.000, 0.0, 0.0, 1.0, 0.0, 0
	
	MODULE
	{
		name = ProceduralFairingBase
//		baseSize = 1.15
//		sideThickness = 0.05
//		verticalStep = 0.1
	}
	
	MODULE
	{
		name = KzNodeNumberTweaker
		nodePrefix = connect
		maxNumber = 4
		numNodes = 2
//		radius = 0.625
		shouldResizeNodes = False
	}
	
	MODULE
	{
		name = KzFairingBaseResizer
		size = #$../tempBaseSize$
		costPerTonne = 1000
		specificMass = 0.0070, 0.0260, 0.0100, 0
		specificBreakingForce = 1280
		specificBreakingTorque = 1280
		dragAreaScale = 1.5
	}
	
	MODULE
	{
		name = KzFairingBaseShielding
	}
	
	!MODULE[ModuleProceduralFairing] {}
	!MODULE[ModuleCargoBay] {}
}

+PART[bluedog_Saturn_3125mFairingBase]:HAS[@MODULE[ModuleProceduralFairing]]:FOR[Jso_Bdb_PF]:NEEDS[ProceduralFairings]
{
	@name ^= :$:_PF_adaptor:
	//@title ^= :$: PF Interstage Adaptor:
	@title = Sarnus-SIVB 3.75m PF Interstage Adaptor
	
	// Modifier for the base size to account for PF shrinking
	// the part by the fairing wall width.
	// Fairing wall width: 0.04 * scale size
	%extraBaseRadius = #$MODULE[ModuleProceduralFairing]/baseRadius$
	@extraBaseRadius *= 2
	@extraBaseRadius *= 0.04
	
	// Hold the original fairing diameter in tempBaseSize, and set scale
	// to the scale needed to get to 1 meter. PF expects a 1 meter part.
	// Scale is adjusted to account for fairing wall.
	%tempBaseSize = #$MODULE[ModuleProceduralFairing]/baseRadius$
	//%tempBaseSize = 1.5625
	%tempScaleSize = #$tempBaseSize$
	@tempScaleSize += #$extraBaseRadius$
	@tempScaleSize *= 2 
	@tempBaseSize *= 2
	@tempScaleSize /= #$tempBaseSize$
	%scale = #$tempScaleSize$
	@scale /= #$tempBaseSize$
	%rescaleFactor = 1
	// Scale the node positions
	@node_stack_top[1,,] *= #$scale$
	@node_stack_bottom[1,,] *= #$scale$
	
	// Save the top node position. Everything will shift by this amount
	// to move the top node to position 0. PF starts the fairing
	// at height 0.
	%tempShift = #$node_stack_top[1,,]$
	// Part specific adjustment
	@tempShift += #$extraNodeShift$
	
	// Scale and adjust model position
	@MODEL
	{
		%position = 0.0, 0.0, 0.0
		@position[1,,] -= #$../tempShift$
		%scale = #$../scale$, $../scale$, $../scale$
	}
	
	// Adjust node positions
	@node_stack_top[1,,] -= #$tempShift$
	@node_stack_bottom[1,,] -= #$tempShift$
	%node_stack_top1   = 0.0, 3.0, 0.0, 0.0, 1.0, 0.0, 2
	
	node_stack_connect01 = 0.5, 0.000, 0.0, 0.0, 1.0, 0.0, 0
	node_stack_connect02 = 0.5, 0.000, 0.0, 0.0, 1.0, 0.0, 0
	node_stack_connect03 = 0.5, 0.000, 0.0, 0.0, 1.0, 0.0, 0
	node_stack_connect04 = 0.5, 0.000, 0.0, 0.0, 1.0, 0.0, 0
	
	MODULE
	{
		name = ProceduralFairingBase
//		baseSize = 1.15
//		sideThickness = 0.05
//		verticalStep = 0.1
	}
	
	MODULE
	{
		name = KzNodeNumberTweaker
		nodePrefix = connect
		maxNumber = 4
		numNodes = 2
//		radius = 0.625
		shouldResizeNodes = False
	}

	MODULE
	{
		name = ProceduralFairingAdapter
		baseSize = 3.75
		topSize  = 2.5
		height=3
		extraHeight = 1.90
		costPerTonne=1000
		specificMass=0.0064, 0.0130, 0.0098, 0
		specificBreakingForce =6050
		specificBreakingTorque=6050
		dragAreaScale = 1.5
	}
	
	MODULE
	{
		name = ModuleDecouple
		ejectionForce = 0
		explosiveNodeID = top1
	}
	
	MODULE
	{
		name = KzFairingBaseShielding
	}
	
	!MODULE[ModuleProceduralFairing] {}
	!MODULE[ModuleCargoBay] {}
}

@PART[bluedog*,Bluedog*]:HAS[@MODULE[ModuleProceduralFairing]]:AFTER[Jso_Bdb_PF]:NEEDS[ProceduralFairings]
{
	!extraNodeShift = delete
}

@PART[bluedog*,Bluedog*]:HAS[@MODULE[ProceduralFairingBase]]:FOR[Jso_Bdb_PF]:NEEDS[ProceduralFairings]
{
	!extraNodeShift = delete
	!extraBaseRadius = delete
	!tempBaseSize = delete
	!tempScaleSize = delete
	!tempShift = delete
}

or just manually add:

@PART[bluedog_Skylab_Airlock]:BEFORE[Jso_Bdb_PF]:NEEDS[ProceduralFairings]
{
	@extraNodeShift = -1.0 // insert correct vertical shift here.
}

 

GameData\Jso\Bdb\PF\bdb_pf_side.cfg :

+PART[KzProcFairingSide1]:NEEDS[Firespitter]
{
    @name = bluedog_ProcFairingSide1
    @title = Bluedog Procedural Egg-Shaped Fairing
    @MODEL
    {
        %texture = fairing1, Jso/Bdb/PF/bdb_Logofairing
    }
    MODULE
    {
        name = FStextureSwitch2
        objectNames = model
        textureRootFolder = Jso/Bdb/PF/
        textureNames = bdb_Logofairing;bdb_fairing;bdb_Titanfairing;bdb_Etoh;bdb_Etoh_test
        textureDisplayNames = Bdb Logo;Bdb;Bdb Titan;Bdb Etoh;Bdb Etoh Test
       
        switchableInFlight = false
        updateSymmetry = true
        showListButton = false
    }
}

+PART[KzProcFairingSide2]:NEEDS[Firespitter]
{
    @name = bluedog_ProcFairingSide2
    @title = Bluedog Procedural Conic Fairing
    @MODEL
    {
        %texture = fairing1, Jso/Bdb/PF/bdb_Logofairing
    }
    MODULE
    {
        name = FStextureSwitch2
        objectNames = model
        textureRootFolder = #$@PART[bluedog_ProcFairingSide1]/MODULE[FStextureSwitch2]/textureRootFolder$
        textureNames = #$@PART[bluedog_ProcFairingSide1]/MODULE[FStextureSwitch2]/textureNames$
        textureDisplayNames = #$@PART[bluedog_ProcFairingSide1]/MODULE[FStextureSwitch2]/textureDisplayNames$

        switchableInFlight = false
        updateSymmetry = true
        showListButton = false
    }
}

+PART[KzProcFairingSide3]:NEEDS[Firespitter]
{
    @name = bluedog_ProcFairingSide3
    @title = Bluedog Procedural Blunt Fairing
    @MODEL
    {
        %texture = fairing1, Jso/Bdb/PF/bdb_Logofairing
    }
	@MODULE[ProceduralFairingSide]
	{
		//@noseConeShape=0.5, 0.0, 0.7, 0.35
		@noseConeShape=0.5, 0.0, 0.6, 0.0
		@baseConeShape=0.3, 0.3, 0.7, 0.7
		@baseConeSegments=3
		@noseHeightRatio=2
	}
    MODULE
    {
        name = FStextureSwitch2
        objectNames = model
        textureRootFolder = #$@PART[bluedog_ProcFairingSide1]/MODULE[FStextureSwitch2]/textureRootFolder$
        textureNames = #$@PART[bluedog_ProcFairingSide1]/MODULE[FStextureSwitch2]/textureNames$
        textureDisplayNames = #$@PART[bluedog_ProcFairingSide1]/MODULE[FStextureSwitch2]/textureDisplayNames$

        switchableInFlight = false
        updateSymmetry = true
        showListButton = false
    }
}

or just replace in line 45 with

+PART[KzProcFairingSide3]:NEEDS[Firespitter]

( 1 -> 3 )

[Gordon Dry]

@CobaltWolf What is the suggested max. apoapsis for the Mercury descent booster to manage a reentry without hassle?

 

Edit:

I think it's 150 km apoapsis, start retro burn at -10s and it's a good reentry with the Mercury pod.
200 km apoapsis is too much, after retro burning the periapsis is ~86 km.
 

Edited May 13, 2018 by Gordon Dry

[Drew Kerman]

On 2/8/2018 at 12:28 PM, Drew Kerman said:

anyone else wish the launch clamps worked like this?

On 2/8/2018 at 2:30 PM, CobaltWolf said:

Our top minds are at it as we speak.

So has there been any luck getting this to work?

[CobaltWolf]

On 5/12/2018 at 10:11 AM, Zorg said:

Consider it done! 

Thank you so much!

On 5/12/2018 at 11:31 AM, MaxZhao said:

Was just wondering if there's any patches out there that converts the BDB fairing bases to use procedural fairings?

Sorry if this has already been asked!

(Good to see you back Max!)

If I remember the issue with that patch was that the PF fairings attach at the sides of the base and the stock fairings attach at the top of the base. So getting things to work on both was hard. I suppose someone could experiment enough to find some offsets that will make it work better.

23 hours ago, Gordon Dry said:

@CobaltWolf What is the suggested max. apoapsis for the Mercury descent booster to manage a reentry without hassle?

Hrmm, I don't know. I don't think I tested it enough to know what it can do.

10 hours ago, Drew Kerman said:

So has there been any luck getting this to work?

Hrmm... someone was experimenting with it and I can't even remember who it was... in the meantime @AlphaMensae's Modular Launch Pads is dope.

 

[AlphaMensae]

10 hours ago, Drew Kerman said:

So has there been any luck getting this to work?

I looked at those FASA Redstone clamps with Collide-O-Scope, and despite their appearance they are not actually hollow, there are just two large box filling up the ring:

Spoiler

No wonnder bad things happen if you try to use them like how they look.

 

[HooHungLow]

6 hours ago, AlphaMensae said:

I looked at those FASA Redstone clamps with Collide-O-Scope, and despite their appearance they are not actually hollow, there are just two large box filling up the ring:

  Reveal hidden contents

No wonnder bad things happen if you try to use them like how they look.

 

Decoupler Shroud is a nice addon if you want to cover the engines before launch. And it's useful for a bunch of other things. 

[Drew Kerman]

10 hours ago, CobaltWolf said:

Hrmm... someone was experimenting with it and I can't even remember who it was

bummer. hope they surface

9 hours ago, AlphaMensae said:

No wonnder bad things happen if you try to use them like how they look.

Oh I know why they don't work like that, I was hoping someone was trying to re-model them to work like that

[CobaltWolf]

GEM-40 WIP.

[akron]

@CobaltWolf Dos Lattes Delta is looking awesome!

[CobaltWolf]

Just now, akron said:

@CobaltWolf Dos Lattes Delta is looking awesome!

Thank you! I feel that lately I've been struggling a bit with accidentally making things too realistic. Need to try and capture some of the chunky cartoon aesthetic again.

[akron]

1 minute ago, CobaltWolf said:

Thank you! I feel that lately I've been struggling a bit with accidentally making things too realistic. Need to try and capture some of the chunky cartoon aesthetic again.

I feel the textures still capture a pretty good feel. Rocket detail is fine, the tanks are discarded fairly quickly anyway. If you want to worry about it a bit, I'd save it for the manned parts or those in later stages that may stay up in orbit a while.

[Kablob]

1 hour ago, CobaltWolf said:

Thank you! I feel that lately I've been struggling a bit with accidentally making things too realistic. Need to try and capture some of the chunky cartoon aesthetic again.

"Detailed but not photo-realistic" really is the best aesthetic for KSP parts.

[MaxZhao]

22 hours ago, CobaltWolf said:

(Good to see you back Max!)

Yes, after some intense uni stuff I'm back to KSP!

Edit: By the way, I tried the patch Gordon mentioned and it seems to work reasonably well so far with the current version of PF and BDB!

Edited May 14, 2018 by MaxZhao

[Pappystein]

On 5/14/2018 at 9:28 AM, CobaltWolf said:

GEM-40 WIP.

 

NICE!!!   Do my eyes deceive me, are they narrower than before?  

Re-purpose the old model for Castor IV?  Those had a Strong-back like the old GEM model yes?

 

[Kardea]

Firstly, I recently came across this mod and I must say thanks to CobaltWolf for the massive collection of parts. Absolutely loving it.
That being said, my apologies if this has been covered elsewhere in the thread, but I searched and didn't seen anything, so I'm asking now:

I'm using Nerta's Cryogenic Engines/Tanks modset and I noticed that the Bluedog mod has the Inon series of LH2/O cryo tanks, which is great (because they look good and are the right size for a rocket I'm building). However, it appears that the Inon series don't have the "Enable Cooling" button that Nerta's do, so how does one prevent boiloff on the Inon series of tanks? Seems kinda critical, seeing as a mere Minimus mission would result in a full boiloff halfway through...

[Saltshaker]

45 minutes ago, Kardea said:

Firstly, I recently came across this mod and I must say thanks to CobaltWolf for the massive collection of parts. Absolutely loving it.
That being said, my apologies if this has been covered elsewhere in the thread, but I searched and didn't seen anything, so I'm asking now:

I'm using Nerta's Cryogenic Engines/Tanks modset and I noticed that the Bluedog mod has the Inon series of LH2/O cryo tanks, which is great (because they look good and are the right size for a rocket I'm building). However, it appears that the Inon series don't have the "Enable Cooling" button that Nerta's do, so how does one prevent boiloff on the Inon series of tanks? Seems kinda critical, seeing as a mere Minimus mission would result in a full boiloff halfway through...

The BDB fuel tanks do not have a default cooling option,  so you may just have to deal with boiloff or use LFO engines. You can try writing a MM patch to enable cooling, though.

[Zorg]

2 hours ago, Kardea said:

Firstly, I recently came across this mod and I must say thanks to CobaltWolf for the massive collection of parts. Absolutely loving it.
That being said, my apologies if this has been covered elsewhere in the thread, but I searched and didn't seen anything, so I'm asking now:

I'm using Nerta's Cryogenic Engines/Tanks modset and I noticed that the Bluedog mod has the Inon series of LH2/O cryo tanks, which is great (because they look good and are the right size for a rocket I'm building). However, it appears that the Inon series don't have the "Enable Cooling" button that Nerta's do, so how does one prevent boiloff on the Inon series of tanks? Seems kinda critical, seeing as a mere Minimus mission would result in a full boiloff halfway through...

I also like the fact that boiloff exists but also like having the option to refrigerate using EC for interplanetary missions. For me the solution was to get procedural parts for when I really need a cooled tank since BD tanks don't support cooling.

If you have cryo tanks, there is an included compatibility patch for procedural tanks which adds cryo tanks' LH2 tanks variations via B9 partswitch. Unfortunately the current config file does not include boiloff for procedural tanks so I added the following to the file CryoTanksProceduralFuelTanks.cfg  (see spoiler). This will behave as an un-insulated tank so you will have to manually enable cooling in the menu and the EC cost for cooling will be the same as stock tanks.

Spoiler

    MODULE
    {
        name =  ModuleCryoTank
        CoolingCost = 0.09
        CoolingEnabled = False
        BOILOFFCONFIG
        {
            FuelName = LqdHydrogen
            // in % per hr
            BoiloffRate = 0.05
        }
    }

I just sent an Inon on the way to Duna carrying relays to prepare for the first expedition and I used a procedural tank to fit the Inon diameter. Its a good solution as you can easily resize procedural tanks to Bluedog's myriad part diameters.

Basic Procedural Textures has some nice textures that will not clash with the Bluedog aesthetic, I would recommend getting that if going the PP route. The pic below though uses a texture based on Ven's stock revamp from KerbalHacks. (links to both below)

Its not too bad but its still a bit sad my planned kerballed mission Duna, which will use the VFB module and the S-IVB upperstage will not look quite as pretty with a procedural tank and textures. Oh well.

 

https://forum.kerbalspaceprogram.com/index.php?/topic/174103-14x-basic-procedural-textures/

https://forum.kerbalspaceprogram.com/index.php?/topic/134889-12x-kerbal-hacks-procedural-parts-textures-asphalt-tiles-unusual-parts-other-hacks/

Edited May 16, 2018 by Zorg

[CobaltWolf]

Last I heard there were talks between @Jso and @Nertea about an expansion to the cryogenics systems, giving better + more accurate representation of how such systems work IRL. As far as I know there really isn't a method for just using electricity to keep them pressurized - liquid hydrogen is a bit too complicated for that - it wants to turn into a gas, and the gas particles are so small they can even leech through solid metal. Some things that we talked about are sun shades, which would significantly slow the rate of boiloff by essentially preventing the sun from adding energy to the system.

There's also IVF systems, like what is going into ULA's new ACES upper stage (I know there are a lot of SpaceX fans here, but what ULA is doing with ACES is the groundwork for a proper, sustainable orbital tug system and we should all be excited about that despite the mismanagement by ULA's parent companies), which store the gaseous hydrogen as it vents and uses it to generate electricity, attitude control etc. The ACES is estimated to have an orbital endurance measured in *years* with some additional fanciness - keeping it facing the sun end-on, to minimize the surface area exposed to sunlight, for example.

As part of the eventual Ares part set, instead of simply including EC-consuming tanks I wanted to have special radiators with visible extra hardware for heat pumps to keep forcing the energy out of the cyrogens at the cost of EC.

And of course, there's also the classic "bring more cryogens that you need to compensate for boiloff".

Now, that doens't help anyone right now. My 2c on the issue (and please remember this is more an attempt to reconcile the fact that we don't currently have a non-boiloff solution for BDB) is perhaps remember the tech level that BDB generally lives at (since I haven't gotten all the advanced post-Apollo stuff in yet...) would be when the orbital lifetime of cryogens is still measured in hours except for things like special, heavy duty hydrogen tanks in the Apollo CM for its fuel cells. That's why storable propellants are still such a big deal in real life - they're, well, storable! There are some pretty significant tradeoffs between performance and endurance.

With all that said... @Jso how hard would it be to have EC-consuming-to-prevent-boiloff cryogenic tanks in the interim?

If I remember from the discussions, there were some significant fears about introducing these more expanded gameplay options. In particular, worries about large negative performance impacts for things like calculating surface-area-exposed-to-sun and issues calculating boiloff for vessels outside of physics range.

(Can anyone tell I'm sick and hopped up on cold meds?)

14 hours ago, Pappystein said:

NICE!!!   Do my eyes deceive me, are they narrower than before?  

Re-purpose the old model for Castor IV?  Those had a Strong-back like the old GEM model yes?

Same diameter (0.625m) - I think its more that the details are less blown up. The 'strongback' is closer to the IRL proportions, etc.

The old model is getting tossed - I would make a new model before I attempted to reuse that one. Especially since it would need new UVs, etc and making that simple of a model doesn't take that long.

The Castors are in a weird place. Partially because the main one is shackled to the Scout, which needed it to be 0.625m which is overscaled and more appropriate for the much-larger GEM-40... *sigh*.

@TimothyC also asked for an inline GEM-40 variant (for the proposed upgrade path for Conestoga) but I'm not sure I left myself room on the GEM texture sheet for it...

 

Anyways, IRL is still fairly crazy right now. I don't expect significant further work on BDB until June.