Yemo

This is an outdated thread, please go to the SETI-Thread for an updated SETI-Greenhouse download link and support. If you are looking for a realistic greenhouse, I recommend the BioMass mod which can be found here. Using the public domain greenhouse model by zzz, it provides 2 greenhouse versions (2.5m and 3.75m) for various mod constellations. They can be used without any life support mod, just for the looks. Or they act as converters if USI Life Support or TAC Life Support are installed. This screenshot shows the 2.5m version with appropriately sized Solar Arrays (using the SETI-BalanceMod) for Kerbin Orbit and a cupola module on top (because it looks good). [TABLE] [TR] [TD] Download: SETI Greenhouse v0.9.2 (for KSP 1.0.4) - This is an thread, please go to the SETI-Thread for an updated download link and support. It has configs for USI Life Support and TAC Life Support, without those mods it just looks cool. Required Mods: none[/TD] [TD=align: center] This mod supports the Community Tech Tree [/TD] [/TR] [/TABLE] License: The model and textures are public domain by zzz The config files by Yemo follow the TAC Life Support license CC-BY-NC-SA-3.0, except for mod name and part names (which are ARR following the SETI-BalanceMod). This mod redistributes the plugin ModuleManager by ialdabaoth and sarbian under CC share-alike license. How it works: a) No Life Support mod It just looks cool on space stations. USI Life Support With the SETI-Greenhouse, 100 supplies last for 200 days per kerbal. Compared to 108 supplies for 200 days with the USI Greenhouse and 216 supplies for 200 days without a greenhouse. But the SETI-Greenhouse is available a much later than the USI Greenhouse, costs a lot more and has a mass of 2 tons compared to the 1.5 tons of the USI Greenhouse. c) TAC Life Support If you use TAC Life Support, the SETI-Greenhouse consumes all waste products of the supported number of kerbals (CarbonDioxide, WasteWater, Waste) as well as EC and "Nutrients", it then provides 100% of the kerbals Food and Oxygen needs, but only 90% of the Water requirements. It has an integrated converter, which transforms Food into "Nutrients" at a 1 to 1 rate. So in total, you only have to supply 10% of the usual water and 20% of the usual amount of food to fulfil all life support needs of a kerbal (which is transformed into nutrients and then together with the other resources back into food). Thus for a 1000 day mission with enough greenhouse capacity, you have to bring 100 days of water and 200 days of food as shown by the TAC Life Support helper window. And of course some reserves/buffer for every resource (including waste products) in addition to enough energy to run the greenhouse continuously. The Nutrient transformation is necessary to allow a planned incorporation of mined resources in the future. Shutters are just cosmetic at the moment, because those would lead to frustration with BackgroundProcessing, since your vessel does not rotate to track the sun. The SETI-Greenhouse provides configs for the following mod combinations as well as the CommunityTechTree: [TABLE=width: 800] [TR] [TD]Mods [/TD] [TD]Configuration [/TD] [/TR] [TR] [TD]none[/TD] [TD]No converters/function, but a nice looking part for space stations[/TD] [/TR] [TR] [TD]USI Life Support [/TD] [TD]108 supplies last for 200 days, 3.2EC/s required per kerbal[/TD] [/TR] [TR] [TD]TAC Life Support + BackgroundProcessing [/TD] [TD]Same as above, but uses only 1.2EC/s[/TD] [/TR] [TR] [TD]TAC Life Support [/TD] [TD]Same as above, but uses only 0.12EC/s[/TD] [/TR] [/TABLE] PS: And no, SETI stands for Space Exploration & Technology Initiative in case of the Greenhouse, or Scope, Economy & Tech Integration in case of the BalanceMod ;-)!

I can't. And since the batteries will be able to store 12 times as much energy, they are now appropriate buffers for solar panels. While the alkaline fuel cells are more like emergency fuel storage. When you really want to land on the wrong side of a moon/planet.

Actually it was quite simple, I just overlooked it all the time. After every converter output resource, there is a dummy variable. If that is set to True, the converter continues converting even if there is no more storage space for that resource on the vessel. If it is set to false, the converter stops if there is no space available. While I used it for other resources, I just did not think about setting that to false for EC. So now the converter config looks like this: MODULE { name = REGO_ModuleResourceConverter ConverterName = Fuel Cell 1kW StartActionName = Start Fuel Cell 1kW StopActionName = Stop Fuel Cell 1kW RecipeInputs = Hydrogen, 0.120938774549499, Oxygen, 0.061687352238298 RecipeOutputs = ElectricCharge, 1, False, Water, 0.000097851562488, True } It needs Regolith/CommunityResourcePack, though TAC life support has an even better converter (which uses a factor, so for a 12kW fuel cell, you would just set the factor to 12 instead of having to multiply all resource amounts manually...)

Imho you could just hide them until 1.0 and then remove them with the great savegame breaker. That way, you would remove the clutter from the VAB, but they would still work if people have them on their vessels. This mm snippet hides the RT-10 solid booster (in TechTree and VAB), when the SETI-BalanceMod is installed: //---RT-10 Solid Fuel Booster @PART[solidBooster]:FOR[SETI] { @TechRequired = unresearchable @category = -1 }

Exactly, I would just distribute a remote tech settings file to overwrite the stock one. And sensible defaults is exactly what I would like to have for SETI. In other news: Alkaline Fuel Cells As written before, they will consume 30times the resources. But from 0.8.6 onwards, AFCs will be load dependent! That means, if activated, they will only produce EC, if there is an energy demand! If the 1EC/s cell is activated, but you only need 0.3EC/s, then the fuel cell will only produce at 30% capacity. And concerning RemoteTech, I added antenna values to the rebalance: * Reflectron DP-10 rebalanced, 0.02 EC/s instead of 0.1EC/s * Communotron 16 rebalanced, 0.04 EC/s instead of 0.13EC/s * CommTech EXP rebalanced, 0.06 EC/s instead of 0.18EC/s * Communotron 32 rebalanced, 0.16 EC/s instead of 0.6EC/s * DTS-M1 rebalanced, 0.2 EC/s instead of 0.82EC/s, later @advElectrics (behind R&D upgrade) * KR-7 rebalanced, 0.05 mass instead of 0.5, 0.2 EC/s instead of 0.82EC/s, earlier @scienceTech * KR-8 rebalanced, 0.15 mass instead of 1.2, 0.16 EC/s instead of 1.81EC/s, 0.1 cone instead of 0.01 * 88-88 rebalanced, 0.1 mass instead of 0.5, 0.21 EC/s instead of 0.93EC/s * KR-14 rebalanced, 0.2 mass instead of 1.0, 0.21 EC/s instead of 0.93EC/s * CommTech-1 rebalanced, 0.3 mass instead of 1.0, 0.3 EC/s instead of 2.6EC/s * Reflectron GX-128 rebalanced, 0.18 mass instead of 0., 0.34 EC/s instead of 2.8EC/s edit: CraftPacks Also, the FAR craft pack and the maxMods craft pack will be merged, 3 packs is just too much effort to maintain. Everything earlier than the MunProbe will only require the bold mods (Ven's Stock Part Revamp is now listed in bold), from the MunProbe onwards, the other part mods are used as well.

Hm, that poses a problem I did not consider when suggesting the 400Gm tracking station omni. With that change and root mode enabled, the Communotron 16 would be enough for everything within the Kerbin sphere of influence. And multipleAntennaMultiplier would make that even worse. Also it requires even more knowledge/online spreadsheet consultation to get the "best" out of the game. I think I will postpone those RemoteTech settings ideas, since it would need testing and fiddling around. Also it would have to be done by distributing an alternative config, so it is totally independent from the normal updates anyways.

About upscaling non-androgynous docking ports to 2.5m: Generally I would recommend making the normal version tweakscalable, since they do not attach to procedural parts, there is little risk involved. I m no expert on working with the mesh and model definitions. Though last I heard that the model one is a bit buggy. From my own experiences, do not change the scale value if you do not know what you are doing with it (and I certainly dont, afaik it affects node positions and such). That said, I would try it like this: If the original docking port part has a diameter of 1.25m? and rescaleFactor = 1, then you only have to use @rescaleFactor = 2 to bring it up to 2.5m standard. @FreeThinker: You need to clean out your inbox, I can not reply to you via pm.

Hm, it seems like I can not change the remote tech settings with module manager configs... So I would have to provide a compatibility file, again... I do not understand why people do not make their settings MM patchable. People could just write their own MM config and would not have to fiddle around each update. If I upload a changed remoteTech settings file, I will also set the signal delay to false as SETI is primarily a gameplay mod, not a realism one. - - - Updated - - - Oh, and about the tech level upgrade. I do not know how to do it for parts (for which it is certainly possible as other mods do that). Eg Procedural Part sizes unlock at tech levels, as do some other mod parts (I do not remember the name of that mod) and mechjeb functions.

After reading in the RemoteTech thread, would it make sense to give the KSC a 400Gm omni antenna? The rationale would be, that normal sats can be tracked from base stations as well. So at least for a short window every kerbal day, KSC would be able to make a direct connection to a SAT. edit: When I was still playing the game myself , I tended to go for a 2+1+1 KSO "network". One sat about 120° forward of KSC and one 120° after KSC made up the first "pair". Then the third sat opposite of KSC with more advanced Dishes and instead of a 4th sat to complete the second pair, I rolled out a rover with the latest dish and just parked that rover close to the KSC...

I can see a lot of potential uses for that large folding dish. From your radio telescope experiments to solar energy, solar sails (although it is not nearly big enough for that and folds the wrong way), or some form of particle collector. I will take a look at those mods in the future, some more command pod variety would be nice. Especially now that manned missions are more special due to the drastically increased energy requirements to keep them alive. Of course Tantares would fit very well for that as well, but would require many more parts to be rebalanced.

Yes, I've last seen the +PART in Ven's StockPartRevamp, where he uses it for duplicating quite a lot of engine configs for parts with different models and stats. Though for most cases I prefer an actual copy paste duplication of the config instead of the +PART. Because MM statements from other mods might alter the original part, but I can not be sure which of those alterations also affects the +PART. That would depend on the exact order of MM patches being applied. So use with caution.

So, realizing that an EC standardization for the whole community is not within reach/possible at the moment, I decided to do that within the "controlled environment" of the SETI-BalanceMod. Something like a controlled field experiment, providing info on how it could work out (or not). Since RoverDude pointed out that EC is out of scope for this thread and the SETI-BalanceMod will experiment with the standardization, I m looking forward to any feedback/further discussion about EC in the SETI-BalanceMod thread.

3 to 1 adapter, tweakscaled + 3 times Rockomax 48-7S or 2 to 1 adapter, tweakscaled + 2 times LV-909 or 2 Mk-55 engines, tweakscaled to 0.66 or so

If nothing major comes up again (like the hydrogen problem), I am aiming for a release "before the weekend".

There are 3 reasons: 1. Even the voyager dish uses only about 280W. 2. From 0.8.6, the solar panels/arrays/wings are much larger for the same output (rescaleFactor of 2.3 instead of 1). On the last page there is a screenshot with solar arrays tweakcaled to provide the SETI Greenhouse (1 kerbal version) with enough energy for kerbin orbit. Each of them only has a nominal output of about 10kW (10EC/s) around Kerbin. 3. Solar Panels will follow the inverse square law power curve by CaptRobau, which means, that they only provide 3.5% of their nominal kerbin output when around the joolean system. Thus one of those massive SETI-Greenhouse solar arrays would just be enough to power a probe core (40W) and a CommTech-1 (300W), with just 10W to spare. And that is certainly not enough to recharge the batteries after flying behind a moon or Jool itself. So for a real mission to Jool, you would need both of those massive arrays just for the probe core and CommTech-1. - - - Updated - - - I used the voyager dish as a reference for the CommTech-1, which has a 3.7m dish. Imho the large foldable one is rather too big (and some other ones as well, but they look cool), than the CommTech too small. But I m hesitant to reduce the size of the large foldable one, since I considered making it something of a dual purpose dish in the distant (?) future...

Chonner wrote a compatibility patch for the procedural parts HybridRocketBooster over at the SETI-BalanceMod thread. It is now added at the end of this config and should only activate if RealFuels is installed: //------\\ //---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 ---\\ //---Real Fuels MM compatibility patch by Chonner //------\\ //---HRB---\\ //------\\ PART { // --- general parameters --- name = proceduralTankHRB module = Part author = Chonner, 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 diameterMin = 0.01 lengthMin = 0.01 lengthMax = Infinity volumeMin = 0.01 volumeMax = Infinity } TECHLIMIT { name = heavyRocketry diameterMax = 2.5 } TECHLIMIT { name = veryHeavyRocketry diameterMax = 3.75 } TECHLIMIT { // Make everything unlimited for metaMaterials name = metaMaterials diameterMin = 0.01 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 } } //Real Fuels MM compatibility patch by Chonner @PART[proceduralTankHRB]:NEEDS[RealFuels]:AFTER[SETI] { @MODULE[ModuleEngines] { @PROPELLANT[Oxidizer] { @name = LqdOxygen } } @MODULE[TankContentSwitcher] { @TANK_TYPE_OPTION[SolidFuel] { @RESOURCE[Oxidizer] { @name = LqdOxygen } } } }

Thank you all for the input. Northstar1989 provided some alkalinie fuel cell info as well (thank you!), so with all that feedback in mind, those are the changes I propose: Hydrogen usage in converters The current alkaline fuel cells do not use the proper densities. They use 1oxygen for every 2 hydrogen units. While that is easy to remember, it shifts the proper mass balance, which might lead to problems with other mods using hydrogen and oxygen. Unfortunately, that formula was also used for the water splitters and sabatier reactors. To reduce future integration issues, I will probably use the correct formulae from 0.8.6 onwards. Of course that will also affect hydrogen storage. While we are on the storage topic, I might rebalance the procedural food containers as well, to improve gameplay. However the adjustments will be rather small. RemoteTech Based on the suggestions by Lord Aurelius, I propose those changes: * Antenna EC/s reduced by factor of about 2 * DTS-M1 rebalanced, 0.2 EC/s instead of 0.82EC/s, later @advElectrics (behind R&D upgrade) * KR-7 rebalanced, 0.05 mass instead of 0.5, 0.2 EC/s instead of 0.82EC/s, earlier @scienceTech * KR-8 rebalanced, 0.15 mass instead of 1.2, 0.16 EC/s instead of 1.81EC/s, 0.1 cone instead of 0.01 * 88-88 rebalanced, 0.1 mass instead of 0.5, 0.21 EC/s instead of 0.93EC/s * KR-14 rebalanced, 0.2 mass instead of 1.0, 0.21 EC/s instead of 0.93EC/s * CommTech-1 rebalanced, 0.3 mass instead of 1.0, 0.3 EC/s instead of 2.6EC/s * Reflectron GX-128 rebalanced, 0.18 mass instead of 0., 0.34 EC/s instead of 2.8EC/s Note that the DTS-M1 is shifted behind the first R&D upgrade (where the refoldable panels are, instead of adjusting to the unfoldable panels). The earlier KR-7 would take the place on initial ComSats. However I m not sure about the proposed size adjustments. At the moment, the KR-14 fits roughly into 2.5m cargo, the KR-8 into 1.875m and the KR-7 into 1.25m. Oh, and while this would be too much for 0.8.6, I wanted to speak with Sigma88 anyway, since I would really like to have a 2.7Gm dish for the Joolean System.

Wait, I do not understand. All that you wrote seems to support the 75Mm omni antenna at KSC. edit: Omni antennas can communicate with dishes, in case you did not know.

Ah, the non-androgynous ports made it! Can not wait to test them out, reconfiguring engines in space is very cool and they do look great! Thank you for the ongoing compatibility work! While I wanted to start with SETI-KSPIextended integration a week ago, all the EC rebalancing and quite some loose ends (and the SETI-Greenhouse pet project) took their toll. I hope to release 0.8.6 before the weekend and then concentrate on KSPI extended support and the compatibility washers.

Thank you very much! I linked the compatibility file in the OP under RealFuels. The Tech limits would be really nice for RealFuels, as I said, I can not test them myself. Do you use the RealFuelStockTankPrices mod by karamazovnew? As he is not around, I thought about making his tanks compatible with the SETI size limits, though I would just copy paste without real testing. Status on 0.8.6: (edit: planned to be released before the weekend) NEW dependency: Background Processing (link) Essentially all (?) energy production and consumption continues in the background, even if the vessel is not active. That was already the case with TAC life support needs and most converters (alkaline fuel cell), but with that .dll, it works for solar panels as well. I consider it a bug fix for stock, so from now on it is listed as a requirement. That opens up a lot of new possibilities, since many EC components were "held back" by that stock bug: EC rebalance: 1EC/s = 1kW = 1kJ/s There will be a new TAC life support compatibility file for 0.8.6, which increases Kerbal energy consumption by a factor of about 20! A 1 kerbal crew willl require 0.71EC/s instead of 0.036EC/s, and 3 kerbals will require about 1.275EC/s. edit: Probe Cores will require 2! times more energy, so about 0.04EC/s instead of 0.02EC/s. That finally puts probes vs kerbal EC requirements somewhat into perspective. Solar Panels will be rebalanced as well, and some are shifted around in the tech tree. For the most part, their standard energy production will not be lowered! Instead their model sizes will be increased (though only half as much as realism would suggest, to keep the "optics" of the game somewhat intact) But they will follow the inverse square law power curve by CaptRobau! Eg at Duna Apoapsis (21.8Gm) Solar Panels are only about 39% as effective as they are around Kerbin (13.6Gm) Fuel Cells had to be broken, they will consume 30! times the resources for the same EC output, but hydrogen storage will be more mass efficient. Batteries will have about 12! times the EC per mass. RemoteTech parts will be rebalanced, though non of them will require more energy than before, and the very long distance ones will require about 1/3 less. The SETI-Greenhouse is ready as well, but since the SETI config was written with BackgroundProcessing and the battery buff in mind, I will wait for 0.8.6 to release it. Model is of course the public domain one from famous modder zzz. There will be a 2.5m version for 1 kerbal, using about 12EC/s with BackgroundProcessing and 1.2EC/s without it (but it will still need the battery buff). It also contains configs for usage without TAC life support (just as a gimmick to put on your station) and for usage without SETI (further decreases in energy needs by a factor of 10). A 3.75m version will supply 3 kerbals. It is not a closed circuit, some additional water and food (or nutrients for plants) will be required and the shutters are just cosmetic (too many problems with gameplay/balancing them because of inverse square law power curve and vessel orientation). That is the 2.5m version (for 1 kerbal) with appropriately sized Solar Arrays for Kerbin Orbit and a cupola module on top (because it looks good).

Reflectron DP-10? Because every other antenna is intended for communication in space and only one is needed for launch/atmo... You could have 10 different ones for launch/atmo, but that would not make sense. This is the RemoteTech Guide: http://remotetechnologiesgroup.github.io/RemoteTech/guide/ And in my signature, you find the SETI-BalanceMod, which adds a 160km always-on omni antenna to every probe core.

Reflectron DP-10, always active. A pointy end towards direction of travel, or it brakes like the other antennas.

It misses the "mod" between "com" and "261". So it should be[removed link to defunct website]

I will, everything that switches and changes stuff in-game seems to have a high likelyhood of causing unexpected issues (procedural parts, tweakscale, firespitter, the mcm module switcher...) Thank you very much! It appears as if ProceduralParts is not developed at the moment, so if you could send me the fixed config, I could link it in the OP as a compatibility file, like I do for TAC life support. I just added your HRB patch to the HRB config, though I do not have the time to test (would require making a dedicated real fuel setup). If you could test it, I would then post it over in the HRB thread and include it in 0.8.6. SETI\0ProceduralParts\SETI-PP-HRB.cfg //------\\ //---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 ---\\ //---Real Fuels MM compatibility patch by Chonner //------\\ //---HRB---\\ //------\\ PART { // --- general parameters --- name = proceduralTankHRB module = Part author = Chonner, 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 diameterMin = 0.01 lengthMin = 0.01 lengthMax = Infinity volumeMin = 0.01 volumeMax = Infinity } TECHLIMIT { name = heavyRocketry diameterMax = 2.5 } TECHLIMIT { name = veryHeavyRocketry diameterMax = 3.75 } TECHLIMIT { // Make everything unlimited for metaMaterials name = metaMaterials diameterMin = 0.01 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 } } //Real Fuels MM compatibility patch by Chonner @PART[proceduralTankHRB]:NEEDS[RealFuels]:AFTER[SETI] { @MODULE[ModuleEngines] { @PROPELLANT[Oxidizer] { @name = LqdOxygen } } @MODULE[TankContentSwitcher] { @TANK_TYPE_OPTION[SolidFuel] { @RESOURCE[Oxidizer] { @name = LqdOxygen } } } } edit: mm checks for real fuels to apply patch

1EC = 1kJ is perfectly valid/complete. Though I agree that for most calculations, it is not as helpful as the 1EC/s = 1kW = 1kJ/s expression.