Yemo

Is there any progress on the PP Tweakscale front? So that tweakscaled Basic Jets can be attached to procedural parts, without bugging out when loading the saved design? Because on load it treats the tweakscaled part as standard size for the positioning and only after that rescales the part to the tweakscaled size. So if the part is upscaled, it clips into procedural parts on load and if eg the Basic Jet is downscaled, it loads way behind the procedural part bottom node...

Oh, I also forgot to address the 2-kerbal pod mass question: The Mk1-1 pod for 2 kerbals actually has a weight of 2.4 tons compared to the 1.1 ton Mk1 single seater, so the difference between two Mk1 and a single Mk1-1 is only 200kg. The weight difference to the 3 tons is entirely made up of the monoprop (which the Mk1 lacks totally) and the much increased ablative shielding (which is much more than I usually need, I often put only 200 in, instead of the 300 standard ones). Though 300 help when you return a little faster from interplanetary missions. Also the Mk1-1 has functioning, integrated RCS and quite a lot of KAS storage. And a little bit more life support reserves (10 days instead of 1, though that is marginal in terms of weight). The Mk1-2 weighs 3.4 tons empty, but has less KAS storage and only the same 80 monoprop without working RCS thrusters (until I support Vens StockPartRevamp). Also it has no integrated heat shield (again, until StockPartRevamp support), and thus no ablative armor to weigh it down in default configuration. Personally, the Mk1-1 is very versatile and thus it became my standard pod.

Unfortunately the SRBs in procedural parts are very costly, so with the mulipliers in the script, the HRB would probably be cheaper than the SRB without SETI. I havent gotten around to fully balancing the whole SRB, liquid fuel, engines stuff. It heavily depends on the size of the payload. The SRBs get very heavy and need lots of volume compared to relatively small standard engines. And I m not sure about the PP SRBs ISP values either... It is all a bit messy, imho. I m not sure about the procedural decoupler length. There is this comment in the PP file: // Only the diameter is tweakable, not the length or the curve So I have not tried to change the value. No idea what will happen.

It only needs Procedural Parts (and MM of course), though because of the very costly SRBs in procedural parts, it will not be cost balanced with that setup. Maybe it will be released as a microMod, at the moment it is just a rough technical implementation. Oh and about the RAM issue, SETI + AutoPruner reduces the RAM load instead of increasing it. But it should only be used for a new game. If Active Texture Management is not enough, you might want to consider switching to Linux64...

From my experience, it is better to keep all your mm files within your folders, since that has the least chance of conflict. Especially since CKAN does not support/allow overwriting of other mods folders. The CommunityTechTree works with TechManager as well and is availably via CKAN, might be a good reference.

@Northstar1989: You might want to take a look at the SETI-BalanceMod linked in my signature. Among other things it has looser PP limits and provides an AutoPruner config to get rid of the stock fuel tanks in terms of RAM usage, without deleting them.

I made a Procedural Parts implementation of the Hybrid Rocket Booster concept for the SETI-BalanceMod (link in signature). Please note that it is primarily balanced for the SETI mod, and even that only to some degree (I do not like the densities and costs of the original Procedural Parts, and only the latter have been addressed by the BalanceMod). So it is probably cheaper than the PP SRBs, but only because those SRBs are much too expensive. //------\\ //---SETI-BalanceMod by Yemo---\\ //------\\ //---HybridRocketBooster, concept based on Hybrid Rocket Booster by Lord Aurelius: http://forum.kerbalspaceprogram.com/threads/104236 ---\\ //---Config structure based on Procedural Parts SRB by AncientGammoner, NK, Tiberion, NathanKell, Swamp Ig: http://forum.kerbalspaceprogram.com/threads/106975 ---\\ //------\\ //---HRB---\\ //------\\ PART:NEEDS[ProceduralParts] { // --- general parameters --- name = proceduralTankHRB module = Part author = Yemo, Lord Aurelius, AncientGammoner, NK, Tiberion, NathanKell, Swamp Ig // --- asset parameters --- MODEL { model = ProceduralParts/Parts/cylinderTank scale = 1,1,1 } // The model is positioned so it looks right in the icon for the VAB // If you alter the default params, then change the position MODEL { model = ProceduralParts/Parts/SRBBell position = 0.0, -1.25, 0.0 scale = 1,1,1 } // If you want to make another SRB bell, you'll need to have a good look at // the structure of these ones and keep it the same. You can add an extra // SRB_BELL node to the ProceduralSRB module below. MODEL { model = ProceduralParts/Parts/HighRatio position = 0.0, -1.25, 0.0 scale = 1,1,1 } MODEL { model = ProceduralParts/Parts/LowRatio position = 0.0, -1.25, 0.0 scale = 1,1,1 } scale = 1 rescaleFactor = 1 // --- node definitions --- node_stack_top = 0.0, 0.5, 0.0, 0.0, 1.0, 0.0, 1 node_stack_bottom = 0.0, -0.5, 0.0, 0.0, -1.0, 0.0, 1 node_attach = 0.5, 0.0, 0.0, 1.0, 0.0, 0.0, 1 fx_exhaustFlame_yellow = 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, running fx_exhaustSparks_yellow = 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, running // fx_exhaustLight_yellow = 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, running fx_smokeTrail_medium = -5.0, 0.0, 0.0, 0.0, 1.0, 0.0, running sound_vent_medium = engage sound_rocket_hard = running sound_vent_soft = disengage sound_explosion_low = flameout // --- editor parameters --- cost = 0 // 4000 category = Propulsion TechRequired = basicRocketry entryCost = 5000 subcategory = 0 title = 0 Procedural HRB manufacturer = Kerbchem Industries description = The Hybrid Rocket Booster uses liquid oxidizer in conjunction with solid fuel. This configuration leads to higher a ISP and more importantly to thrust controllability and improved safety. Unfortunately it is also more expensive than the standard SRB. // attachment rules: stack, srfAttach, allowStack, allowSrfAttach, allowCollision attachRules = 1,1,1,1,0 // --- standard part parameters --- mass = 0 dragModelType = default maximum_drag = 0.3 minimum_drag = 0.3 angularDrag = 2 crashTolerance = 7 breakingForce = 200 breakingTorque = 200 maxTemp = 3600 stagingIcon = SOLID_BOOSTER MODULE { name = ProceduralPart textureSet = German diameterMin = 0.125 // Lengths for the stock tanks are approximate as one needs to account for the bell. TECHLIMIT { // RT-10 - 1.25 x 2.4 m = 2.95 kL name = start diameterMin = 0.25 diameterMax = 0.5 lengthMin = 0.25 lengthMax = 2.5 volumeMin = 0.03 volumeMax = 1.0 } TECHLIMIT { name = basicRocketry diameterMax = 1.25 lengthMax = 3.5 volumeMax = 3.5 } TECHLIMIT { // BACC - 1.25 x 7.1 m = 8.71 kL // Sepatron - 0.15 x 0.5 = 0.009 kl name = generalRocketry diameterMax = 1.25 lengthMin = 0.125 lengthMax = 5.0 volumeMin = 0.001 volumeMax = 6.0 } TECHLIMIT { name = advRocketry lengthMax = 8.0 volumeMax = 12.0 } // Seems fair that heavy rocketry should enable 2.5 dia TECHLIMIT { name = heavyRocketry diameterMax = 3.0 lengthMax = 11.0 volumeMax = 20.0 } TECHLIMIT { name = heavierRocketry lengthMax = 14.0 volumeMax = 40.0 } TECHLIMIT { name = veryHeavyRocketry lengthMax = 16.0 volumeMax = 52.0 } TECHLIMIT { // Make everything unlimited for metaMaterials name = metaMaterials diameterMin = 0.01 diameterMax = Infinity lengthMin = 0.01 lengthMax = Infinity volumeMin = 0.01 volumeMax = Infinity } } // Don't change the default length without also altering the default position above. MODULE { name = ProceduralShapeCylinder displayName = Cylinder length = 2.5 diameter = 1.25 } MODULE { name = ProceduralShapeCone displayName = Cone // We need the bottom mode to be limit min so that it doesn't // get to small to allow the bell to be attached nicely coneBottomMode = LimitMin length = 2.5 topDiameter = 0.625 bottomDiameter = 1.25 } MODULE { name = ProceduralShapePill displayName = Fillet Cylinder length = 2.5 diameter = 1.25 fillet = 0.25 } MODULE { name = ProceduralShapeBezierCone displayName = Smooth Cone // We need the bottom mode to be limit min so that it doesn't // get to small to allow the bell to be attached nicely coneBottomMode = LimitMin selectedShape = Round #1 length = 2.5 topDiameter = 0.625 bottomDiameter = 1.25 } MODULE { name = TankContentSwitcher useVolume = true TANK_TYPE_OPTION { name = SolidFuel // The RT-10 and BACC both have similar dry density. // When you work it out, the mass of the bell is negligible. // from originall 0.174 dryDensity = 0.162 // As per StretchySRB. This is way higher than stock // dryDensity = 1.5 costMultiplier = 0.8 RESOURCE { name = SolidFuel //isTweakable = false // Again no real consistency in stock KSP. Have gone with a bit lower than RT-10 dry/wet unitsPerT = 405 // As per StretchySRB //unitsPerKL = 125 } RESOURCE { name = Oxidizer //isTweakable = false // Again no real consistency in stock KSP. Have gone with a bit lower than RT-10 dry/wet unitsPerT = 495 // As per StretchySRB //unitsPerKL = 125 } } } MODULE { name = ModuleEngines thrustVectorTransformName = thrustTransform throttleLocked = False exhaustDamage = True ignitionThreshold = 0.1 minThrust = 0 maxThrust = 52 heatProduction = 157 useEngineResponseTime = False engineAccelerationSpeed = 10.0 engineDecelerationSpeed = 10.0 allowShutdown = True fxOffset = 0, 0, 0 PROPELLANT { name = SolidFuel ratio = 0.9 DrawGauge = True } PROPELLANT { name = Oxidizer ratio = 1.1 } atmosphereCurve { key = 0 10 key = 1 20 } } MODULE { name = ProceduralSRB costMultiplier = 1.0 srbBellName = SRBBell thrustVectorTransformName = thrustTransform bottomAttachNodeName = bottom selectedBellName = Surface // Thrust for the SRB on part place (default thrust). thrust = 250 // The thrust that an SRB with a 1m base could put out. // Make this higher to allow for more powerful SRBs at the same diameter. // If you don't want tiny bells, use a smaller number. If you want a higher thrust limit, use a bigger number. // Note that this goes up on the square of diameter, so a 2m diameter part will give you 2^2 * thrust1m = 2000kN max thrust. // Does not affect ships in flight (as in their bells will not rescale) thrust1m = 500 // To replicate Advanced Booster SRB // See thread here: http://forum.kerbalspaceprogram.com/threads/70676-WIP-Procedural-Parts-The-next-phase-of-Stretchy-SRBs?p=1116650&viewfull=1#post1116650 // Changing this will not affect ships in flight (but will affect anything loaded into the VAB) //thrust1m = 1500 // Heat Produced = heatPerThrust * sqrt(thrust) / (1+total mass). // All stock parts are around 50 // I realize this model is not very physical, but the way heat is handled in the game is pretty daft // Note anything with heat production much above 700 tends to explode. // Does not affect ships in flight (as in their heat production will not rescale) heatPerThrust = 40 // If heat is still causing you issues, use the old equation from stretchy SRBs which is easier //useOldHeatEquation = true // This is to enable any ships that used the old version (0.9.3 and prior) to update cleanly. // Once you've saved the ship then it's updated. The heat production will use the new version, as the old one was buggy. deprecatedThrustScaleFactor = 256 SRB_BELL { name = Surface // ISP in vacuum and kerbin surface atmosphereCurve { key = 0 280 key = 1 260 } // Degrees of gimble gimbalRange = 0.25 // Config intrinsic to the model, don't change unless you know what you're doing modelName = LowRatioBell // Diameter of the bell's choke (in the unscaled model) bellChokeDiameter = 0.55 // Ratio between the bell choke and the bottom of the SRB // Should never be > 1.0. Ideal depends on the model somewhat, but big numbers look funny. chokeEndRatio = 0.55 } SRB_BELL { name = Vacuum atmosphereCurve { key = 0 294 key = 1 245 } gimbalRange = 0.1 modelName = HighRatioBell bellChokeDiameter = 0.32 chokeEndRatio = 0.32 } } MODULE { name = ModuleGimbal gimbalTransformName = SRBBell gimbalRange = 0.25 } }

Thank you for the detailed suggestions. The QBE was intended to be the "KAS" probe core. I wanted to scale it down, make it KAS compatible and radially attachable. But it got forgotten when I supported KAS thus besides the radially attachability, the rest was not implemented. I will have to rethink if it fits, given the proposed BoxSat and other probe core mod addons. The stayputnik is actually my most used probe core, I use it for nearly every non-massive ComSat. I just like the shape of it and ComSats usually do not need the top node, since I tend to launch them in a side by side configurations using the 1 to 2/3/4 adapters from generalConstruction. I made it lighter for 0.8.1, so now it is 10% lighter compared to the OKTO, less structural integrity necessary with only one node. The rocket control vs lightweight probe core concept sounds great, however it will take some more rebalancing. May have to wait a few versions when introducing more probe core mods, so that I do not have to rebalance them twice. Moving the larger probe cores forward also leaves the problem of the 2 unmanned tech nodes being so far back in the CTT. Not sure what else would fit there. Yeah, the data transmission is a bit strange, but I generally feel the whole electric power concept could use a major rebalance. 1ec/s fulfills the life support needs of 20 kerbals or so... That is totally imbalanced. I understand where it comes from, the reason that solar panels do not generate electricity when the vessel is not in focus. But with the Background Processing mod, there is a solution at hand. So that is definately on the agenda, but it is a major piece of work with massive balancing effects. I ll do the transmission costs in between, however after the 0.8.0 rebalance, I kind of want to primarily work on the accumulated backlog, mainly concerning part mod support. The earlier fairings are a good idea, I shifted around some parts in the north-western corner of the tech tree for 0.8.1. Since I moved the Basic Jet back to Aerodynamics (or wanted to, somehow it ended up in flightControl, will be fixed in 0.8.1), I needed a Jet for stability, which does not depend on any mods. So the Kerbonov MiniTurboJet would be kind of redundant there. I therefore rebalanced it to be a small TurboJet instead of the small Basic Jet it was originally balanced as, despite its name. The normal TurboJet was sent back to supersonicFlight in 0.8.0, while I intend to leave the Kerbonov MiniTurboJet at aerodynamics. In fact, that config is already in 0.8.0 (SETI-PartMod-SH_mods-Kerbonov.cfg), I just wanted to make configs for the other Kerbonov parts before announcing the support in the changelog. That is odd, the Fuel Line is the the first part in my Fuel Tanks catalog in the VAB. I added the 0 for part catalog sorting, like I did for the procedural parts, launch clamps and so on. So that the basic parts are always at the start and users do not need to search for them after every tech unlock/mod install. @Lord Aurelius/SwGustav: Regarding the backlog, this is an implementation of the HybridRocketBooster concept based on Lord Aurelius Hybrid Booster concept and the ProceduralParts SRB. The code can just be copied into a .cfg file within the GameData folder of your SETI install. Any feedback appreciated, it is only rudimentary balanced for SETI. If you are ok with that, I can include it into 0.8.1 for testing. Will post it into your Hybrid Rocket Booster thread as well, for exposure and of course if you want to distribute the config file. Given the changes to procedural parts by SETI, especially now with the textures from SwGustav and the HybridBoosters from LordAurelius (and probably more coming), I m also thinking about a separate download. Like the Initial Contracts for other TechTree mods, If you two are ok with that?. There is another microMod I want to publish first, so it will be for the medium run when some other changes are made as well. //------\\ //---SETI-BalanceMod---\\ //------\\ //---HybridRocketBooster, concept based on Hybrid Rocket Booster by Lord Aurelius: http://forum.kerbalspaceprogram.com/threads/104236 ---\\ //---Config structure based on Procedural Parts SRB by AncientGammoner, NK, Tiberion, NathanKell, Swamp Ig: http://forum.kerbalspaceprogram.com/threads/106975 ---\\ //------\\ //---HRB---\\ //------\\ PART:NEEDS[ProceduralParts] { // --- general parameters --- name = proceduralTankHRB module = Part author = Yemo, Lord Aurelius, AncientGammoner, NK, Tiberion, NathanKell, Swamp Ig // --- asset parameters --- MODEL { model = ProceduralParts/Parts/cylinderTank scale = 1,1,1 } // The model is positioned so it looks right in the icon for the VAB // If you alter the default params, then change the position MODEL { model = ProceduralParts/Parts/SRBBell position = 0.0, -1.25, 0.0 scale = 1,1,1 } // If you want to make another SRB bell, you'll need to have a good look at // the structure of these ones and keep it the same. You can add an extra // SRB_BELL node to the ProceduralSRB module below. MODEL { model = ProceduralParts/Parts/HighRatio position = 0.0, -1.25, 0.0 scale = 1,1,1 } MODEL { model = ProceduralParts/Parts/LowRatio position = 0.0, -1.25, 0.0 scale = 1,1,1 } scale = 1 rescaleFactor = 1 // --- node definitions --- node_stack_top = 0.0, 0.5, 0.0, 0.0, 1.0, 0.0, 1 node_stack_bottom = 0.0, -0.5, 0.0, 0.0, -1.0, 0.0, 1 node_attach = 0.5, 0.0, 0.0, 1.0, 0.0, 0.0, 1 fx_exhaustFlame_yellow = 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, running fx_exhaustSparks_yellow = 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, running // fx_exhaustLight_yellow = 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, running fx_smokeTrail_medium = -5.0, 0.0, 0.0, 0.0, 1.0, 0.0, running sound_vent_medium = engage sound_rocket_hard = running sound_vent_soft = disengage sound_explosion_low = flameout // --- editor parameters --- cost = 0 // 4000 category = Propulsion TechRequired = basicRocketry entryCost = 5000 subcategory = 0 title = 0 Procedural HRB manufacturer = Kerbchem Industries description = The Hybrid Rocket Booster uses liquid oxidizer in conjunction with solid fuel. This configuration leads to higher a ISP and more importantly to thrust controllability and improved safety. Unfortunately it is also more expensive than the standard SRB. // attachment rules: stack, srfAttach, allowStack, allowSrfAttach, allowCollision attachRules = 1,1,1,1,0 // --- standard part parameters --- mass = 0 dragModelType = default maximum_drag = 0.3 minimum_drag = 0.3 angularDrag = 2 crashTolerance = 7 breakingForce = 200 breakingTorque = 200 maxTemp = 3600 stagingIcon = SOLID_BOOSTER MODULE { name = ProceduralPart textureSet = German diameterMin = 0.125 // Lengths for the stock tanks are approximate as one needs to account for the bell. TECHLIMIT { // RT-10 - 1.25 x 2.4 m = 2.95 kL name = start diameterMin = 0.25 diameterMax = 0.5 lengthMin = 0.25 lengthMax = 2.5 volumeMin = 0.03 volumeMax = 1.0 } TECHLIMIT { name = basicRocketry diameterMax = 1.25 lengthMax = 3.5 volumeMax = 3.5 } TECHLIMIT { // BACC - 1.25 x 7.1 m = 8.71 kL // Sepatron - 0.15 x 0.5 = 0.009 kl name = generalRocketry diameterMax = 1.25 lengthMin = 0.125 lengthMax = 5.0 volumeMin = 0.001 volumeMax = 6.0 } TECHLIMIT { name = advRocketry lengthMax = 8.0 volumeMax = 12.0 } // Seems fair that heavy rocketry should enable 2.5 dia TECHLIMIT { name = heavyRocketry diameterMax = 3.0 lengthMax = 11.0 volumeMax = 20.0 } TECHLIMIT { name = heavierRocketry lengthMax = 14.0 volumeMax = 40.0 } TECHLIMIT { name = veryHeavyRocketry lengthMax = 16.0 volumeMax = 52.0 } TECHLIMIT { // Make everything unlimited for metaMaterials name = metaMaterials diameterMin = 0.01 diameterMax = Infinity lengthMin = 0.01 lengthMax = Infinity volumeMin = 0.01 volumeMax = Infinity } } // Don't change the default length without also altering the default position above. MODULE { name = ProceduralShapeCylinder displayName = Cylinder length = 2.5 diameter = 1.25 } MODULE { name = ProceduralShapeCone displayName = Cone // We need the bottom mode to be limit min so that it doesn't // get to small to allow the bell to be attached nicely coneBottomMode = LimitMin length = 2.5 topDiameter = 0.625 bottomDiameter = 1.25 } MODULE { name = ProceduralShapePill displayName = Fillet Cylinder length = 2.5 diameter = 1.25 fillet = 0.25 } MODULE { name = ProceduralShapeBezierCone displayName = Smooth Cone // We need the bottom mode to be limit min so that it doesn't // get to small to allow the bell to be attached nicely coneBottomMode = LimitMin selectedShape = Round #1 length = 2.5 topDiameter = 0.625 bottomDiameter = 1.25 } MODULE { name = TankContentSwitcher useVolume = true TANK_TYPE_OPTION { name = SolidFuel // The RT-10 and BACC both have similar dry density. // When you work it out, the mass of the bell is negligible. // from originall 0.174 dryDensity = 0.162 // As per StretchySRB. This is way higher than stock // dryDensity = 1.5 costMultiplier = 0.8 RESOURCE { name = SolidFuel //isTweakable = false // Again no real consistency in stock KSP. Have gone with a bit lower than RT-10 dry/wet unitsPerT = 405 // As per StretchySRB //unitsPerKL = 125 } RESOURCE { name = Oxidizer //isTweakable = false // Again no real consistency in stock KSP. Have gone with a bit lower than RT-10 dry/wet unitsPerT = 495 // As per StretchySRB //unitsPerKL = 125 } } } MODULE { name = ModuleEngines thrustVectorTransformName = thrustTransform throttleLocked = False exhaustDamage = True ignitionThreshold = 0.1 minThrust = 0 maxThrust = 52 heatProduction = 157 useEngineResponseTime = False engineAccelerationSpeed = 10.0 engineDecelerationSpeed = 10.0 allowShutdown = True fxOffset = 0, 0, 0 PROPELLANT { name = SolidFuel ratio = 0.9 DrawGauge = True } PROPELLANT { name = Oxidizer ratio = 1.1 } atmosphereCurve { key = 0 10 key = 1 20 } } MODULE { name = ProceduralSRB costMultiplier = 1.0 srbBellName = SRBBell thrustVectorTransformName = thrustTransform bottomAttachNodeName = bottom selectedBellName = Surface // Thrust for the SRB on part place (default thrust). thrust = 250 // The thrust that an SRB with a 1m base could put out. // Make this higher to allow for more powerful SRBs at the same diameter. // If you don't want tiny bells, use a smaller number. If you want a higher thrust limit, use a bigger number. // Note that this goes up on the square of diameter, so a 2m diameter part will give you 2^2 * thrust1m = 2000kN max thrust. // Does not affect ships in flight (as in their bells will not rescale) thrust1m = 500 // To replicate Advanced Booster SRB // See thread here: http://forum.kerbalspaceprogram.com/threads/70676-WIP-Procedural-Parts-The-next-phase-of-Stretchy-SRBs?p=1116650&viewfull=1#post1116650 // Changing this will not affect ships in flight (but will affect anything loaded into the VAB) //thrust1m = 1500 // Heat Produced = heatPerThrust * sqrt(thrust) / (1+total mass). // All stock parts are around 50 // I realize this model is not very physical, but the way heat is handled in the game is pretty daft // Note anything with heat production much above 700 tends to explode. // Does not affect ships in flight (as in their heat production will not rescale) heatPerThrust = 40 // If heat is still causing you issues, use the old equation from stretchy SRBs which is easier //useOldHeatEquation = true // This is to enable any ships that used the old version (0.9.3 and prior) to update cleanly. // Once you've saved the ship then it's updated. The heat production will use the new version, as the old one was buggy. deprecatedThrustScaleFactor = 256 SRB_BELL { name = Surface // ISP in vacuum and kerbin surface atmosphereCurve { key = 0 280 key = 1 260 } // Degrees of gimble gimbalRange = 0.25 // Config intrinsic to the model, don't change unless you know what you're doing modelName = LowRatioBell // Diameter of the bell's choke (in the unscaled model) bellChokeDiameter = 0.55 // Ratio between the bell choke and the bottom of the SRB // Should never be > 1.0. Ideal depends on the model somewhat, but big numbers look funny. chokeEndRatio = 0.55 } SRB_BELL { name = Vacuum atmosphereCurve { key = 0 294 key = 1 245 } gimbalRange = 0.1 modelName = HighRatioBell bellChokeDiameter = 0.32 chokeEndRatio = 0.32 } } MODULE { name = ModuleGimbal gimbalTransformName = SRBBell gimbalRange = 0.25 } }

Thank you! Are you sure you researched the fuel lines? They have been shifted back to specializedConstruction (thus needing an upgrade of the R&D center to prevent early asparagus).

The fairing bases would be used if they are not weight balanced with decouplers/separators. Which would lead to problems, like the game braking bug you described, or the fact that a 1.25m fairing base put on a 3.75m part, makes this aerodynamically (FAR) less resistant than a 0.625m nose cone (tested that), killing vessels on reentry... And since it is not part of the Procedural Fairings config, I would have to deal with the ramnifications, which is imho not worth it. I m exploring the options regarding KSPI and discussing them with FreeThinker. But it would definately be based on the CTT. Final Frontier and Achievements look great, together witch KerbalContructionTime they would greatly increase the feeling of progression beside tech unlocks. Not sure if I should recommend them, little time at the moment and I wanted to support more parts in the next update. Well, my maxMods test install uses literally all of the ones in the OP without ATM, AutoPruned files or any beautification mods. When I start a new career and visit all buildings, I m at 2.3GB, compared to 1.5GB after the same procedure with Stock. So there is quite some room there, with AutoPruner and ATM... For an epic career I would add the ones listed above, but would heavily use AutoPruner and ATM and even swap mods depending on progression (like KAX vs ExtraPlanetaryLaunchpads). Also, I forgot the IR model rework and foundries in the list above... About the difference between Linux64bit and Win32ATM: For Win32ATM I would select the B9 parts I want/need, to save RAM. For Linux64, I would install the complete B9 pack and then just remove the wings and such stuff, to remove clutter from the assembly building... Yep, the squad folder is really inefficient with regards to RAM. SXT is nice in that regard, it adds lots of parts using the squad textures, thus making them more efficient. Unfortunately it conflicts with pruning them. Will have to work on SXT compatibility in the long run. Still other stuff to do before and STX is a massive pack...

Well, that is exactly what the SETI-BalanceMod does (link in my signature). Then use the AutoPruner file provided in the download, which gets rid of the unused parts in terms of RAM usage. Not only from Squad folders but also from eg TAC life support and other supported mods. That is at least a partial replacement of the stock parts. I have not tested it, but using StockPartRevamp from Ven and the provided AutoPruner file probably gets you even closer to "total replacement".

Forgot the fairing base in my last reply. The problem was, that there was a massive difference in mass between the fairing base and a decoupler/separator. Either it would make the decouplers obsolete (in terms of mass) or it would drastically increase fairing base mass, even if no decoupler function is needed. Eg if a multi adapter is used after the fairing base (for mass sat launches), it would make sense to have the separators beneath the individual sats (if arranged side by side). So the fairing base would become unnecessarily heavy without need for the decoupler function. I m just discussing KSPI with FreeThinker. It seems I misunderstood the development plans... KSPIextended is going even further into 6.4 scale direction, while KSPI NF integration is intended to be more stock compatible in terms of engine/reactor performance. So it would make much more sense to support KSPI NF integration for SETI. Unfortunately, KSPIextended is the version which is currently developed and which has the CTT support...

Well, the Mercury/FASA parts have different balances. Eg the mercury pod only weighs 0.76t while the Mk1CommandPod weighs now 1.1t. Also FASA uses much less potent reaction wheels which use monoprop. So be prepared to rethink your designs. For the inclusion: Since you are "changing" in the beginning, I would make sure to have no active vessels at some point (if you have RT sats on, roleplay it as a meteor/radiation storm wiping them out ) and then simply swap the GameData content. It is simply the techrequired, if you want to have it at the different node (eg flight control). But imho if you have researched flight control, it does not matter whether the part is under basicRocketry or flightControl, will stay unlocked anyway. I do not have an "epic" career game at the moment. In game I fly "missions". Eg when developing 0.8.0, I just "debugged" me science and cash and flew a mission profile with the KAX prop variant of the SETI Basic Jet. Which meant reliably reaching an altitude of 20km without boosters above a predetermined point and then landing in the small desert on the western shore of the starting land mass. If I would start an epic/progression game, I would use my maxMods testing folder as a basis, which contains all mods listed in the OP. Then I would probably add the major mods, like some version of KSPI, eg KSPI NF Integration Karbonite, MCM/MKS/OKS, ExtraPlanetaryLaunchpads and some parts/part mods depending on personal preference, like Airbrakes from B9, various other parts from B9, inline goo container from STX, Cargo Transportation Solutions fairings, USI Exploration and Survivability, Mark IV Spaceplane System, Universal Docking Port Set, and so on... Linux KSP64bit or ATM required... That decoupler looks great, will plan it for 0.8.1. I m hesitant to put in many more procedural textures. In the first days of planning SETI, I installed multiple texture packs for ProceduralParts. The main result was, that it took a while to find the texture I wanted to use from within the right-click menu when assembling the craft. It would be great if there was another slider in that context menu, allowing us to select the texture pack, which would act as a parent selction to the actual texture children. So not sure about the X200 ramake, especially details like the round parts tend to not stretch well, eg for 1.25m * 8m tanks. Which isnt a problem for decouplers, since their aspect ratio is fixed. The texture issue that bothered me from the beginning, was something that fits in with stock fuselage parts. My "fuselageWhite" was intended as a stop gap. It does not use a normal map, so it only fits with the stock fuselage parts "on average". Thus if the lighting is changed, its appearance does not change in the same way as normal fuselage parts. Nope, not specifically Snacks compatible, might work, I do not know. It is balanced for TAC and Universal Storage, as SwGustav pointed out. Even more so since 0.8.0. Use recyclers/water splitters if you want to bring less supplies with you. It has a learning curve, but if you get there, it works really well now! I recommend playing with all mods listed in the OP. It works for 32bit without Active Texture Management. Even better when you use Auto Pruner! There is even room for additions. Also, maybe you want to play with KAX in the beginning, but later uninstall it (make sure no vessel uses parts from it) and replace it with Planetary Launch pads for the later game. Yes, I do not like this part of the CTT progression. Anyway just regard it as "fundamental research" for the time being. It will lead to SabatierReactors (at ShortTermHabitation) and then even CarbonExtractors (at LongTermHabitation) for life support.

I ll change it for the next version, thank you both!

That would be perfect, those prefixes would keep all the IR parts together, distinguish between the packs and keep the original names for identification!

@Motokid600 You might want to start a new career with 0.8.0 only with the supported mods. When you are a bit further down, like getting to the 90 science nodes, add the other mods. That would give you the early progression feeling without sacrificing the diversity of the other mods. Also, HotRockets is not working nicely with some other mods as of late, maybe try without it? Anyway, the contracts are very "open" regarding parts, if nothing else is specified within the contract. And they certainly should not throw exceptions. New Version 0.8.0 WARNING: TAC life support requires a compatibility file, link below "Download" in forum post WARNING: This patch introduces massive balancing changes New & Unused Parts New 0.625m Jet Engine derived from the Basic Jet Engine New 3.75m reaction wheel version New 2.5m TACLS Water Splitter New Procedural Life Support TankTypeOption: Hydrogen New Universal Storage Processor: Carbon Extractor C7 Brand Adapter (unslated version) removed (not per autopruner, since textures are needed for slated version) Life Support and Universal Storage Rebalances & Adjustments US and TACls recyclers moved around in the tech tree (eg to recycling branch in the CTT) Rebalanced weights and densities for Procedural Life Support Parts TAC life support Sabatier Recyclers changed to Sabatier Reactors, with appropriate resource process including Hydrogen Drastically rebalanced recyclers for life support, 3 kerbal (1.25m) and 9 kerbal (2.5m) versions, all much lighter now Universal Storage Recyclers/Converters now at 160kg and in line with TACls, providing resources for 1 Kerbal US Food and Water wedges now weigh 80kg instead of 40kg, provide 200 days life support US Oxygen wedge changed a little (400 days of life support oxygen) US Hydrogen wedge now weighs 20kg (balanced with oxygen tank) US Waste/WasteWater/CarbonDioxide tanks rebalanced as well US fuel wedges now at 80kg instead of 120kg (density balancing), with appropriate fuel levels US miniFuel Cell now has 2 fuel cells for 1 and 2 ec/s (which can be turned on and off separately), for 3 ec/s total output US standard Fuel Cell now weighs 160kg instead of 120kg, but 3 times the internal fuel US standard Fuel Cell now has 2 fuel cells for 4 and 8 ec/s (which can be turned on and off separately), total 12 instead of 16 ec/s Command and Cockpit Rebalances & Adjustments All probe cores have SAS and an integrated 160km always-on OmniAntenna (including HECS) Mk1 Command Pod weaker reaction wheel from 1.5 to 0.9 torque, only food and water for 1 day, but oxygen for 3 days Mk1-1 Command Pod, food and water for 10 days, oxygen for 12 Mk1-2 Command Pod from 3.6 to 3.4 tons, 40unit KAS storage, 80 unit monoprop, food and water for 10 days, oxygen for 12 Lander Cans have oxygen for 5 days instead of 3, increased monoprop by factor 1.5 and is filled as default Mk1 Lander Can increased KAS storage to 60 units Mk2 Cockpits heavier at 2.2 tons, gets 40 units of KAS storage Mk3 Cockpit a lot heavier, 4.0 tons instead of 3.5tons, 40 KAS storage, optional 60 unit monoprop KAX Cockpit now at 3.2 tons and 80 units of KAS storage Aircraft Parts Rebalances & Adjustments All Intakes have rebalanced (increased) mass, especially the non structural ones weigh a lot more Rebalanced aircraft engines based on B9Aerospace configs by Taverius KAX engines rebalanced (vague guesstimates, but much better than before) Added TweakScale support for Intake: Mk1 Fuselage, Engine Nacelle and Radial Engine Body Increased liquid fuel capacity for Intake: Engine Nacelle and Radial Engine Body (from 40 to 180) Basic Jet Engine (1.25m version) back to Aerodynamics (New 0.625m Jet @stability) TurboJet Engine back to SupersonicFlight Craft Files 2 versions, minMods and FAR, Jets and FAR designs use TweakScale Redesigned Basic Jet, which can easily be transformed into a prop plane Just swap circular intakes (front) and jet engines (rear) for props (front) and nose cones (rear) Redesigned Advanced Jet Redesigned Manned Rocket, uses decoupler and nose chute due to tech tree changes Other Rebalances & Adjustments Drastically rebalanced SRBs and Procedural Structural Elements (esp reduced costs) Stock Radial Parachute has increased diameter, when used with RealChute (from 17m to 18m) Procedural "Nose" Fairings to generalConstruction Mk16 and Mk2-R parachutes swapped in the tech tree Modular Girder Segment and Modular Girder Adapter to generalRocketry 6S 1m Service Compartment Tube earlier @basicRocketry Landertrons have 20% more thrust Minor Changes and Fixes Corrected KR-8 dish dimensions Added CLS support to Mk1-1 A2 Command Pod and Mk3 Cockpit and Cargo bays 2.5m Cockpits (eg KAX) use large connection node instead of medium one

Wasnt the arrow pointing downward on the decoupler? Will plan it in for 0.8.1, I ve already finished testing 0.8.0 for most KSP mod versions, dont want to spoil it by changing even small things now. And I already worked on some minor part integrations before releasing 0.7.6, but didnt finish. So 0.8.1 should take considerably less time than this update. I guess you could start a new career with 0.8.0, looking at the changelog. And if you are not too fast, KSPI might be in time when you get to the relevant nodes (in the 0.90 ports of KSPI, the solar panels produce not enough heat around kerbin to need radiators...).

Hm, I see that exceptions are thrown around the contracts, but I have very limited understanding of those. Nightingale, the author of ContractConfigurator, is the most likely person to help you out. The contracts are pretty standard, so you might want to ask in the ContractConfigurator thread. Those look great. However the thing I miss most is the red arrow, pointing in the "decoupling" direction. Will have a look at them ingame after the update. About the fillet tweaking, never notices, turned it on in the patch. Yeah, ProceduralParts development is rather slow (read: non-existent at the moment). And the SETI procedural parts config will see massive changes in the update... - - - Updated - - - Well, I had little time except for thursday, so the encountered ones took some time. Except for the likely fixes, 8.1 and most likely the following patches will concentrate on mod support. - - - Updated - - - What are your preferences regarding the general part support direction? Planes, general SpaceParts, Colonization, future techs (KSPI/NearFuture), somthing else?

I have encountered some issues, which I need to fix before publishing. Also, looking at the length of the accumulated changelog, I will release the update as version 0.8.0, instead of 0.7.7. No new mod supports, but a massive amount of rebalances...

For turning a jet (pusher) into a prop (puller), the engines have to be as close to the Center of Mass as possible. So that the CoM shifts relatively little when replacing one for the other. The Basic Jet is specifically designed for that purpose, while the Advanced Jet has the engines furthest from the CoM (but that design has other advantages). I wanted to make an Advanced Prop as well, but the main issue is, that Kerbals are unable to climb off ladders... The wing would have been right beside the cockpit for a good CoM-CoL relation, blocking the "Cockpit exit path". I tried to put the ladder on the wing, but to no avail, Kerbals cant get on again... Auto Actions and Landing Height sound great, I will include them in the OP. For the others, I have to check, but wont have time for that until next week. - - - Updated - - - As far as I know, everything that flies in FAR, flies in NEAR and stock too (though stock has a thicker atmosphere, so the craft will have different performances). - - - Updated - - - I only have to test some stuff and then 0.7.7 is ready for release within the next hours.

Yes, thank you very much for investigating this! It would basically reduce much of the clutter for TAC life support (all the HexCans for the different resources and combinations). Also there is an effort to add the MKS/OKS resources to procedural parts. So you would eg select the "Procedural KAS/TAC life support" part and then select the tank type option for it, eg water. That would allow you to make KAS containers for the 8 TAC combinations (food/water/oxygen, food, water, oxygen, waste/waste water/carbon dioxide, waste, waste water, carbon dioxide), while only using up one part slot.

You have too much "control", reduce the area of your control surfaces or reduce the control authority (eg for pitch). If your tail has all-moving-control surfaces, try setting the elevons to pitch 30, yaw 0, roll 35 or so...

The new aircraft are very versatile, but that comes at the cost of a relatively high part count (Basic Jet: 28parts). So players can pick and choose the features they need. edit: I may add thermometer and presmat, but not an antenna, because that would depend on RT, FAR and so on. That way I only need to maintain one design. Dont need the boosters, since you can reach 21km with jet engines alone? Remove boosters for 4 parts. You can reliably land horizontally? 3 radial chute parts saved. Dont need the Mk16 rear chute for horizontal landing assistance? 1 part saved. This one only if you point it at the ground , it is extremely stable/reliable to start, fly and land. Here is the alternative config, just exchanging intakes and jets for props and nose cones, no other changes: And the new Advanced Jet (27 parts):

I looked into some aero/FAR landing solutions and came across "decelerons", basically control surfaces, which can split up (eg when pressing and thus take the role of airbrakes. It would imho be a really great "long term" option for procedural (non-all-moving) control surfaces.

Which reminds me, I wanted to try to implement your Hybrid Boosters with procedural SRBs. So, a small teaser for 0.7.7: The new Basic Jet Flyable by everyone with FAR! Takeoff from mud runway: 1) press T for SAS 2) press Z for max thrust 3) press SPACE for staging 4) press and hold S, it will take off when it is fast enough Landing: a) vertically, using the 3 radial chutes horizontally, using brakes (can not flip over due to tricycle arrangement) c) horizontally, using the improvised "drogue" main chute at the rear Ceiling Height: a) can reach 21+ km without using boosters, with the right flight path easily reaches more by using boosters Max Speed: 410+ m/s, about Mach 1.2 without boosters Reconfiguration: Can easily be turned into a prop plane Remove radial intakes (front) and basic jet engines (rear) Add radial prop engines (front) and structural nose cones (rear) in their places done