[1.3.x] SETI, Unmanned before Manned [Patreon]

[Faster]

Maybe just something to point out on the compatible mod list (since this isn't really a SETI issue): early contracts can be difficult or impossible to complete when using SETI with Procedural Parts and Real Fuels, since the "Procedural Real Fuels SRB" is broken when RF 8.4 is present and the PP SRB is all SETI makes available.

[update] Forgot to mention that the "0 Procedural HRB" can't be used as a workaround if you make it to the second tech level in this scenario as it's non-functional, perhaps due to using "Oxidizer" rather than LOX. So might be better to say Real Fuels and SETI aren't currently compatible?

Edited March 23, 2015 by Faster

[FreeThinker]

I'm not sure you want to go the electric realism route because it would lead to extreme differences. For KSPI, I had to lower the power by a factor of 500 just to get NFT-E / Stock power levels.

[Yemo]

I'm facing the same issue with resource transfers using SM. Already I've been asked how this will scale, how densities / volumes will affect it, and what the impact would be. As I mentioned in my thread, I'm proposing a ModuleResourceXferPump, where we can configure transfer rates, ec consumption, etc. I'll be interested to see what you find out...

I like the idea of the pump module, though that might result in problems with mods which do not integrate the pump module.

I can see how it works very well in a controlled environment, like SETI, but for the "wild" it would really need wide support.

Maybe it would be easier to specify transfer costs for the different resources in a ShipManifest config which can be changed via module manager.

Though that would probably result in a lot of work for you, to set up and maintain, not sure if that is worth it.

The main issue at the moment seems to be gases like hydrogen and oxygen, which do not conform to the 1unit = 1liter convention.

With the upcoming stock ksp update to 1.0 and the changes to the resource system, as well as the planned update for the CommunityResourcePack by RoverDude, anything more than a stop gap solution might not be worth the effort at the moment.

Maybe just something to point out on the compatible mod list (since this isn't really a SETI issue): early contracts can be difficult or impossible to complete when using SETI with Procedural Parts and Real Fuels, since the PP 1.0.2 SRB is broken when RF 8.4 is present and the PP SRB is all SETI makes available.

Thank you for the feedback!

Over a week ago I wrote a pm to karamozovnew, the author of Real Fuel Stock Tank Prices, about SETI integration (since I do not have the time to rebalance it myself, but I will support him where I can, if he wants to do it).

So far, I did not get a reply, so I m not sure if he wants to do that.

I can try to fix the PP SRB as a stop gap, but I have very limited experience with real fuels and with the EC rebalance, there is a lot of other stuff on my plate.

I'm not sure you want to go the electric realism route because it would lead to extreme differences. For KSPI, I had to lower the power by a factor of 500 just to get NFT-E / Stock power levels.

I tried to avoid the EC rebalance since I started with SETI, but now with all the additions, I really need at least some kind of framework.

So essentially the pain of adjusting to the stock ec mess has grown so much, that it now seems to be larger than the massive pain of rebalancing EC...

And using reality as a very loose framework at least frees me from the work of coming up with something else.

So realism in that regard is not my aim, I just use it as a reference, when it makes my life easier.

And I ignore it, if it results in gameplay issues and/or major work without gameplay improvements...

[FreeThinker]

Say Yemo, I was wondering if you used (Fire Spitter) FSfuelSwitch. I fixed and modified it myself for Interstellar to allow in flight switching the fuel contents after emptying it. It should allow for reuable tanks which can be reconfigured during the mission. For KSP Interstellar this is ideal as it allows you to launch with dense propelants like ammonia/methane/hydrazine and convert them to hydrogen when needed for propulsion. Another usage is when your in the wild and you simply collect what ever you can find for propulsion. Another advantage of the fuelswitch is that you need less parts. I intend to further integrate with Cryostat functionality, which will require power to keep it contents at low temperature and boiloff fuel when insufficient/unpowered.

Edited March 23, 2015 by FreeThinker

[Yemo]

Say Yemo, I was wondering if you used (Fire Spitter) FSfuelSwitch, I modified it myself for Interstellar to allow in flight switching the fuel contents after emptying it. It should allow for reuable tanks which can be reconfigured during the mission. Another advantage of the fuel switch is that you need less parts. I intend to further integrate with Cryostat functionality, which will require power to keep it contents at low temperature and boiloff fuel when insufficient/unpowered

SETI only uses procedural parts for tanks and I m not sure, but seem to remember that FSfuelSwitch is incompatible with procedural parts (since they already have TankTypeOption).

Unfortunately I do not know of a way to allow changing of the procedural TankTypeOption in flight, that would be very helpful.

About Cryostat, I thought about that problem of different storages and power requirements as well, though I did not come up with anything yet.

The general problem might have some overlap with the fuel transfer energy costs proposed/implemented by Papa_Joe for ShipManifest.

Essentially every resource would require energy for transfer and some resources require energy for storage as well...

Maybe some unified approach to that general problem could be developed.

Unfortunately I m currently I currently have more than enough on my plate, with all the ec rebalances, half-done mode integration and bug fixes.

[Chonner]

Maybe just something to point out on the compatible mod list (since this isn't really a SETI issue): early contracts can be difficult or impossible to complete when using SETI with Procedural Parts and Real Fuels, since the "Procedural Real Fuels SRB" is broken when RF 8.4 is present and the PP SRB is all SETI makes available.

[update] Forgot to mention that the "0 Procedural HRB" can't be used as a workaround if you make it to the second tech level in this scenario as it's non-functional, perhaps due to using "Oxidizer" rather than LOX. So might be better to say Real Fuels and SETI aren't currently compatible?

How is the Procedural Real Fuels SRB broken? I've got SETI + Procedural Parts + Real Fuels + RF Stockalike Engine Configs + Karamazovnew's Real Fuel Stock Tank Prices all installed and the SRBs work fine.

The HRB unfortunately doesn't due to the Oxidizer vs LiquidOxygen compatibility issue, but I've been thinking of taking a look into the configs to see if it is an easy fix, but I also don't miss them too much as everything can be done with a combination of Solid and Liquid. (Also helps that I have RoverDude's Sounding Rockets installed that gets you the science for the first couple of tech nodes).

Edit: The HRB is easy to fix, the following MM code just swaps out the Oxidizer for RF LqdOxygen and all works fine after that. Another option would be to use NitrousOxide instead which is more common with real hybrid motors, but wasn't sure on whether it would need changing of ratios and tank volumes so LqdOxygen is just the simple solution. Also note this is only my second ever MM cfg code written, so it is probably really poor syntax but it works!

@PART[proceduralTankHRB]:AFTER[SETI]
{
    @MODULE[ModuleEngines]
    {
        @PROPELLANT[Oxidizer]
            {
                @name = LqdOxygen
            }
    }
    @MODULE[TankContentSwitcher]
    {
        @TANK_TYPE_OPTION[SolidFuel]
            {
                @RESOURCE[Oxidizer]
                {
                    @name = LqdOxygen
                }
            }
    }
}

I'll post this over in Karamazovnew's thread aswell so people are aware of it there.

Edited March 23, 2015 by Chonner

[FreeThinker]

2. Solar Panels

Solar panels are way too efficient for their size, by a factor of 10.6 or more, but are also much too heavy for their size...

To distort them not too much, I plan to use a 2-way approach:

a) Increase their model size by a factor of about 1.65 or 2.3.

Lower their energy output by a factor of 4 or 2, so that they would either produce only 25% or 50% or their current output.

c) Adjust the mass, somehow. Any input is very welcome!

d) Not sure what to do about the flat solar panel.

Choosing whether to go with the 25% or 50% output (and the corresponding model size increase) is a tough choice.

Perhaps for inspiration you should take a look at "FlowerChild startun unmanned mod". In this, he doesn't even give access to solar panels until mid game, and they are initialy expansive, heavy andnot so power full. Higher tech unlocks more advanced solar panels which are much lighter and more efficient. I found the expeience quite satisfying as it force you to mage hard dicisions like do I bring along enough battery power to complete a mission or do I bring along heavy but undepletable solar cells.

- - - Updated - - -

Unfortunately I do not know of a way to allow changing of the procedural TankTypeOption in flight, that would be very helpful.

Technically, there isn't a reason why they shouldn't be able to work together Edited March 23, 2015 by FreeThinker

[Faster]

How is the Procedural Real Fuels SRB broken?

The burn time can change on load seemingly at random. This usually only happens if you change a procedural parameter, so it's most noticeable when trying to make a SRB craft that won't exceed the limits of an early contract, e.g., test a chute at 2-5km at 200-500m/s. You may build in the VAB with a burn time of sixty seconds and a TRW of 2 only to find when the craft shows up on the pad the burn time has morphed to 1,200 seconds and so the TRW is essentially zero. So, depending on your mileage, which may vary, the first few contracts may be harder to do or nigh impossible.

[Yemo]

How is the Procedural Real Fuels SRB broken? I've got SETI + Procedural Parts + Real Fuels + RF Stockalike Engine Configs + Karamazovnew's Real Fuel Stock Tank Prices all installed and the SRBs work fine.

The HRB unfortunately doesn't due to the Oxidizer vs LiquidOxygen compatibility issue, but I've been thinking of taking a look into the configs to see if it is an easy fix, but I also don't miss them too much as everything can be done with a combination of Solid and Liquid. (Also helps that I have RoverDude's Sounding Rockets installed that gets you the science for the first couple of tech nodes).

Edit: The HRB is easy to fix, the following MM code just swaps out the Oxidizer for RF LqdOxygen and all works fine after that. Another option would be to use NitrousOxide instead which is more common with real hybrid motors, but wasn't sure on whether it would need changing of ratios and tank volumes so LqdOxygen is just the simple solution. Also note this is only my second ever MM cfg code written, so it is probably really poor syntax but it works!

@PART[proceduralTankHRB]:AFTER[SETI]
{
    @MODULE[ModuleEngines]
    {
        @PROPELLANT[Oxidizer]
            {
                @name = LqdOxygen
            }
    }
    @MODULE[TankContentSwitcher]
    {
        @TANK_TYPE_OPTION[SolidFuel]
            {
                @RESOURCE[Oxidizer]
                {
                    @name = LqdOxygen
                }
            }
    }
}

I'll post this over in Karamazovnew's thread aswell so people are aware of it there.

Thank you very much!

Karamazovnew seems to be very quiet for the last 2 weeks or so, I hope he comes back to ksp forums.

Until then I will include your fix in the HRB config and publish it over at Lord Aurelius HRB thread, if people want to use it before 0.8.6 (which might take some time with the ec rebalance).

Perhaps for inspiration you should take a look at "FlowerChild startun unmanned mod". In this, he doesn't even give access to solar panels until mid game, and they are initialy expansive, heavy andnot so power full. Higher tech unlocks more advanced solar panels which are much lighter and more efficient. I found the expeience quite satisfying as it force you to mage hard dicisions like do I bring along enough battery power to complete a mission or do I bring along heavy but undepletable solar cells.

- - - Updated - - -

Technically, there isn't a reason why they shouldn't be able to work together

I was considering a progression approach (there was one somewhere else, I vaguely remember 60, 120 and 211 or so W/m² definitions for 3 different tech level), but that would srew with the existing games even more.

With the current plan and the resizes, I can reduce the ec production of a solar part to 25% of the value before and offset that with an energy consumption reduction for remote tech antennas by the same factor.

This would at least keep all the solar com sats balanced, since probe consumption is rather marginal anyway.

I will try the firespitter fuel switch, put it will most likely have to wait until after 0.8.6.

The burn time can change on load seemingly at random. This usually only happens if you change a procedural parameter, so it's most noticeable when trying to make a SRB craft that won't exceed the limits of an early contract, e.g., test a chute at 2-5km at 200-500m/s. You may build in the VAB with a burn time of sixty seconds and a TRW of 2 only to find when the craft shows up on the pad the burn time has morphed to 1,200 seconds and so the TRW is essentially zero. So, depending on your mileage, which may vary, the first few contracts may be harder to do or nigh impossible.

That sounds very strange, and I do not know what could be the cause.

[Faster]

Another issue semi-related to Real Fuels I'm seeing is tanks reading full in the VAB sometimes show up on the pad with a portion of one fuel missing. For example, a "0 Procedural Tank" had 1,621 RP-1 and 1,729 of LOX in the VAB. It showed up on the pad with 1,621 and 1,785 respectively. Not consistent, but not infrequent either.

- - - Updated - - -

That sounds very strange, and I do not know what could be the cause.

I'm sure it's a problem between Real Fuels and Procedural Parts. I only brought it up here because when the symptom presents, it makes the first few things in SETI fairly difficult at best and so while SETI, with a few Mod Manager patches, is compatible with both RF and PP separately, the bug those two have when together means the three all at once is not a great user experience right now.

[Chonner]

The burn time can change on load seemingly at random. This usually only happens if you change a procedural parameter, so it's most noticeable when trying to make a SRB craft that won't exceed the limits of an early contract, e.g., test a chute at 2-5km at 200-500m/s. You may build in the VAB with a burn time of sixty seconds and a TRW of 2 only to find when the craft shows up on the pad the burn time has morphed to 1,200 seconds and so the TRW is essentially zero. So, depending on your mileage, which may vary, the first few contracts may be harder to do or nigh impossible.

So I actually just had this for the first time! Wondered why my vehicle wasn't getting off the pad!

Going back to the VAB and launching again seemed to fix it, but this would cause problems when that is not possible (i.e. with Kerbal Construction Time).

So I've done some digging, and something (not sure what) is causing proceduralSRBRealFuels PART to have a diameterMax = 0.2 at TECHLIMIT start, which is different to the Procedural Parts Mod Pack default of 1.75. which might have something to do with it, but I haven't been able to reliably reproduce it the glitch.

It also seems that this limit is only applied if you change the diameter from the default of 1.25 when you place it in the editor, but it might somehow be applied on the way to launch pad, sometime making the engine bell only 0.2 wide, and therefore massively increasing the burn to compensate. Has it ever happened to you in Sandbox mode? Either way I have no idea if it is a problem with SETI or Procedural Parts or Real Fuels or a interaction between them.

I've tried placing the following in a config file to see if it fixes it, but looking at the ModuleManger cache it hasn't done anything to it, so it is either wrong in someway, or the order of operations is causing it to be changed after this does (I know RealFuels seems to quite liberally use the :Final instruction).

@PART[proceduralSRBRealFuels]:Final
{
    @MODULE[ProceduralPart]
    {
        @TECHLIMIT[start]
            {
                @diameterMax = 1.75
            }
        @TECHLIMIT[basicRocketry]
            {
                @diameterMax = 1.75
            }
    }

}

I'm just taking a stab at it here, I'm not a modder by any shouts, only been using mods for a few weeks! For now on I'll have to defer to someone who knows what they are doing!

Another issue semi-related to Real Fuels I'm seeing is tanks reading full in the VAB sometimes show up on the pad with a portion of one fuel missing. For example, a "0 Procedural Tank" had 1,621 RP-1 and 1,729 of LOX in the VAB. It showed up on the pad with 1,621 and 1,785 respectively. Not consistent, but not infrequent either.

Are you using Kerbal Construction Time? This is a known bug with RealFuels and KCT with it boiling off before launch. The most recent dev version of KCT fixes this, which I think might be going to be released relatively soon based on what magico13 has been saying.

Edited March 24, 2015 by Chonner

[Yemo]

@Faster: Those issues sound really annoying, hopefully we'll find the cause.

SETI changes the maxDiameter of the SRB to 0.5 at the start, through the SETI\0ProceduralParts\SETI-PartMod-PP-SRB.cfg config.

But that should not affect the real fuels SRB.

About your MM statement, maybe try using :FINAL instead of :Final, though I m not sure about that.

In which config file does RealFuels actually alter the procedural parts?

@Chonner: I bet all of us modders started with small private MM statements ;-).

[Faster]

Are you using Kerbal Construction Time? This is a known bug with RealFuels and KCT with it boiling off before launch.

I am, and I just pulled SETI and verified this symptom (missing fuel) presents with just RF and KCT and without SETI. Sorry for the confusion folks!

[Chonner]

In which config file does RealFuels actually alter the procedural parts?

Found the cause!

It was actually within Procedural Parts itself, ProceduralParts/ModuleManager/RealismOverhaul_TechLimits.cfg there was a couple of missing NEEDS[RealismOverhaul] statements which meant it was applying their tech limitations.

So the cause of the problem was like this - place Procedural Real Fuels SRB, adjust something but not diameter keeping that at the default 1.25m (>> 0.2m limit), when you launch it sometimes (seemly randomly) checks that you fall with in the tech limits on volumeMax, therefore reduces the amount of solid fuel, but doesn't alter the actual model, reducing the fuel in turn increases the Burn time greatly and reduces the thrust (not sure why it does that, seems like a separate issue that BurnTime, Thrust and Solid Fuel arn't properly proportionally linked).

Faster, the simple solution is just go and delete ProceduralParts/ModuleManager/RealismOverhaul_TechLimits.cfg, I've created a merge pull request to get it fixed if/when another version of Procedual Parts is released. This should revert it to the default maxDiameter from Procedural Parts of 1.75m, and mean you never have a Part greater than the limits actually allow. As it wasn't really a reproducible bug, I'm not sure if this completely fixes it, but I think it should!

Edited March 24, 2015 by Chonner

[Revenant503]

I am, and I just pulled SETI and verified this symptom (missing fuel) presents with just RF and KCT and without SETI. Sorry for the confusion folks!

The workaround is to use FASA Launch clamps which can do on-pad refuelling...I can't remember if RF modifies stock clamps to do the same thing

[FreeThinker]

I will try the firespitter fuel switch, put it will most likely have to wait until after 0.8.6.

Be carefull the firespitter fuel switch might be bugged, at least it was when I integrated it into Interstellar.

[Yemo]

Be carefull the firespitter fuel switch might be bugged, at least it was when I integrated it into Interstellar.

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...)

Found the cause!

It was actually within Procedural Parts itself, ProceduralParts/ModuleManager/RealismOverhaul_TechLimits.cfg there was a couple of missing NEEDS[RealismOverhaul] statements which meant it was applying their tech limitations.

So the cause of the problem was like this - place Procedural Real Fuels SRB, adjust something but not diameter keeping that at the default 1.25m (>> 0.2m limit), when you launch it sometimes (seemly randomly) checks that you fall with in the tech limits on volumeMax, therefore reduces the amount of solid fuel, but doesn't alter the actual model, reducing the fuel in turn increases the Burn time greatly and reduces the thrust (not sure why it does that, seems like a separate issue that BurnTime, Thrust and Solid Fuel arn't properly proportionally linked).

Faster, the simple solution is just go and delete ProceduralParts/ModuleManager/RealismOverhaul_TechLimits.cfg, I've created a merge pull request to get it fixed if/when another version of Procedual Parts is released. This should revert it to the default maxDiameter from Procedural Parts of 1.75m, and mean you never have a Part greater than the limits actually allow. As it wasn't really a reproducible bug, I'm not sure if this completely fixes it, but I think it should!

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

Edited March 24, 2015 by Yemo

[Chonner]

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.

Two ways of fixing it.

1. Simply delete GameData/ProceduralParts/ModuleManager/RealsimOverhaul_TechLimits.cgf as if your using SETI you are not using RO so it won't break anything.

2. Copy this file over your GameData, which will overwrite the above mentioned file with a corrected one.

I'll maybe write a small config patch later that will apply the SETI Tech Limits to the Real Fuels SRB, but need to check it doesn't create the same bug that happened before.

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

Tested and that works perfect!

[Yemo]

Two ways of fixing it.

1. Simply delete GameData/ProceduralParts/ModuleManager/RealsimOverhaul_TechLimits.cgf as if your using SETI you are not using RO so it won't break anything.

2. Copy this file over your GameData, which will overwrite the above mentioned file with a corrected one.

I'll maybe write a small config patch later that will apply the SETI Tech Limits to the Real Fuels SRB, but need to check it doesn't create the same bug that happened before.

Tested and that works perfect!

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).

Edited March 26, 2015 by Yemo
corrected probe EC/s multiplier to 2 (5 was from older plans)

[FreeThinker]

I further improved SETI/NFT-E support for KSPI Extended: Reactor Fuel usage is scaled to lower consumption, Refinery and Science Lab requires less power

[Svm420]

Awesome when I saw better than starting manned integrate background processing I was hoping you'd do the same. Can't wait for the changes.

The mathematician in me laughs at the use of exclamation points to add emphasis as that symbol as a greater meaning n mathematics that makes those statement very absurd. ;p

[FreeThinker]

Awesome when I saw better than starting manned integrate background processing I was hoping you'd do the same. Can't wait for the changes.

Yes I still have implement a lot of Background processing as well

[Lord Aurelius]

Nice, glad to see that the EC system is getting properly rebalanced.

Also, while you're adjusting the configs for the remotetech antennas, could you consider a quick and dirty rebalance for the antennas? Right now there isn't really any consistency, especially with the weights, the stock antennas weigh basically nothing (DTS-M1 only weighs .03 tons with a range of 50Mm), but the remotetech antennas are quite heavy (.5 tons for the KR-7, with a range of 90Mm) and is unlocked later in the tech tree. The remotetech antennas aren't really balanced against each other either, the KR-8 is the heaviest antenna but only has mediocre range, and two dishes (Reflectron KR-14 and CommTech-1) have the same weight but the KR-14 is worse in every way. It would seem to me that the fixed dish antennas should be much lighter than they are currently (but still heavier than the folding antennas) and much cheaper, available sooner, and possibly also more efficient and with better range. Some of the fixed antennas could also be rescaled to different sizes, so for example we can have a 2.5m fixed antenna (current largest is for a 1.25m stack, and we have about 4 fixed dishes for that size at the moment).

Edit: Found this little bit of information on the weight of dishes, might be useful when it comes time for a full rebalance [link]

According to that link, a 5m dish should only weigh around 50Kg.

Edit: My quick and dirty proposal: (parenthesis indicate intended use for antennas)

CommTech EXP-VR-2T (for probes with mini landers, think Cassini/Huygens)

Looks decent enough for now, no changes

CommTech-1 (for large comsats in Kerbin orbit, for endgame missions to Jool/Eeloo)

Rescale to fit on a 2.5m stack, reduce weight to 0.3 (the extra weight from above can be due to heavier gauge aluminum, radio equipment, etc), increase range to 500Gm, at some point maybe add a radio telescope science experiment

Communotron 16 (early comsats, Kerbin orbit)

No changes for now

Communotron 32 (later comsats)

No changes for now

Communotron 88-88 (for probes out to Moho/Dres when paired with a KR-14 comsat around Kerbin, range out to Eve/Duna before then)

Increase cost significantly

DTS-M1 (for probes out to Minmus, or for within the Jool system when used with a relay)

Move later in the tech tree (should be around the same time as folding solar panels), increase cost

Reflectron DP-10 (LKO/landers/upper stages)

No changes for now

Reflectron GX-128 (for Jool/Eeloo probes/relays)

Reduce weight to 0.15

Reflectron KR-14 (for Moho/Dres comsats)

Reduce weight to 0.15, increase cost, rescale to 1.875m

Reflectron KR-7 (for Minmus comsats)

Reduce weight to 0.05

Reflectron KR-8 (for Eve/Duna comsats)

Reduce weight to 0.1, dramatically increase efficiency

Edited March 26, 2015 by Lord Aurelius

[FreeThinker]

Nice, glad to see that the EC system is getting properly rebalanced.

Also, while you're adjusting the configs for the remotetech antennas, could you consider a quick and dirty rebalance for the antennas? Right now there isn't really any consistency, especially with the weights, the stock antennas weigh basically nothing (DTS-M1 only weighs .03 tons with a range of 50Mm), but the remotetech antennas are quite heavy (.5 tons for the KR-7, with a range of 90Mm) and is unlocked later in the tech tree. The remotetech antennas aren't really balanced against each other either, the KR-8 is the heaviest antenna but only has mediocre range, and two dishes (Reflectron KR-14 and CommTech-1) have the same weight but the KR-14 is worse in every way. It would seem to me that the fixed dish antennas should be much lighter than they are currently (but still heavier than the folding antennas) and much cheaper, available sooner, and possibly also more efficient and with better range. Some of the fixed antennas could also be rescaled to different sizes, so for example we can have a 2.5m fixed antenna (current largest is for a 1.25m stack, and we have about 4 fixed dishes for that size at the moment).

Edit: Found this little bit of information on the weight of dishes, might be useful when it comes time for a full rebalance [link]

According to that link, a 5m dish should only weigh around 50Kg.

Edit: My quick and dirty proposal: (parenthesis indicate intended use for antennas)

CommTech EXP-VR-2T (for probes with mini landers, think Cassini/Huygens)

Looks decent enough for now, no changes

CommTech-1 (for large comsats in Kerbin orbit, for endgame missions to Jool/Eeloo)

Rescale to fit on a 2.5m stack, reduce weight to 0.3 (the extra weight from above can be due to heavier gauge aluminum, radio equipment, etc), increase range to 500Gm, at some point maybe add a radio telescope science experiment

Communotron 16 (early comsats, Kerbin orbit)

No changes for now

Communotron 32 (later comsats)

No changes for now

Communotron 88-88 (for probes out to Moho/Dres when paired with a KR-14 comsat around Kerbin, range out to Eve/Duna before then)

Increase cost significantly

DTS-M1 (for probes out to Minmus, or for within the Jool system when used with a relay)

Move later in the tech tree (should be around the same time as folding solar panels), increase cost

Reflectron DP-10 (LKO/landers/upper stages)

No changes for now

Reflectron GX-128 (for Jool/Eeloo probes/relays)

Reduce weight to 0.15

Reflectron KR-14 (for Moho/Dres comsats)

Reduce weight to 0.15, increase cost, rescale to 1.875m

Reflectron KR-7 (for Minmus comsats)

Reduce weight to 0.05

Reflectron KR-8 (for Eve/Duna comsats)

Reduce weight to 0.1, dramatically increase efficiency

Notice there is aslo a very big overage gap between the Communotron 88-88 and DTS-M1. In the past I proposed to add several intermediate dishes Communotron 66-66, Communotron 44-44 and Communotron 22-22

[Svm420]

Notice there is aslo a very big overage gap between the Communotron 88-88 and DTS-M1. In the past I proposed to add several intermediate dishes Communotron 66-66, Communotron 44-44 and Communotron 22-22

I just started using RT so no idea if these fill that hole, but there is this mod by sigma which expands the stock line of antenna