[1.1.3] Procedural Parts - Parts the way you want 'em - v1.2.5 July 3

[RadarManFromTheMoon]

Greetings.

Sorry for not responding. I had a lot of stuff to do lately so not much time for KSP. :/

Since 1.0.5 is out now I had a quick look and, despite the incompatibility message at startup, PP seems to work fine with 1.0.5. If you encounter any problems, please let me know.

[TK421d]

This is my fav mod.. if it does not update, i dont update.. >.> Gotta have my b9 wings too.

this is one of the few that works just fine for me in 1.0.5, so go nuts! if the AVC warning annoys you, you can always just update the checker file to say .5 instead of .4

- - - Updated - - -

Greetings.

Sorry for not responding. I had a lot of stuff to do recently so not much time for KSP. :/

Since 1.0.5 is out now I had a quick look and, despite the incompatibility message at startup, PP seems to work fine with 1.0.5. If you encounter any problems, please let me know.

yep, even my custom MM misc resource tanks work just fine too

[pixeldyne]

I agree, this is by far one of the most useful/mandatory mods.

Looks like I'm not the brightest crayon in the box, I rebuilt the project and modified zzVersionChecker.cs:

return Versioning.version_major == 1 && Versioning.version_minor == 0 && Versioning.Revision == 5;

But in the end it turned out KSP refused to run because of KWRocketry, I still couldn't figure out which part but was able to save some of my manned ships with a minimum set of parts.

[Venusgate]

Suggestion for the recompile update when it comes.

Now that Squad has a mk0 engine and lf tank pretty early on, it would be convenient to change the starting tech limit for the procedural tank to be able to go as narrow as .625m

Love this mod!

EDIT- Oh, also I noticed the procedural stack decoupler under the starter lfo rocket engine leaved a gap when attached, where the stock TA-18A decoupler does not. I assume squad tweaked the model or the attachment point a smidgen.

EDIT EDIT - Also, also, question about what you might be thinking of expanding into. Whats the likelyhood, or feasibility for that matter, of procedural mk2 tanks?

Edited November 11, 2015 by Venusgate

[Xuixien]

Heatshields lose albator very quickly, any fix?

[NoMrBond]

Heatshields lose albator very quickly, any fix?

This is actually a game side correction for ablator function I think?

Previously the amount of ablator being burnt off was calculated based on the amount remaining, as [ablator remaining] got smaller it became progressively more effective

Now (1.0.5.1024 or 1.0.5.1028) the amount of ablator being burnt off is calculated based on the initial specifications of the sheild

[Xuixien]

This is actually a game side correction for ablator function I think?

Previously the amount of ablator being burnt off was calculated based on the amount remaining, as [ablator remaining] got smaller it became progressively more effective

Now (1.0.5.1024 or 1.0.5.1028) the amount of ablator being burnt off is calculated based on the initial specifications of the sheild

I'm still playing 1.0.4 as my favorite mods have yet to be updated.

[abowl]

Hello, is there a light version of this mod? I am interested in procedural tanks only, cylindrical procedural tanks with the grey texture. Thank you

[Wercho]

Heatshields lose albator very quickly, any fix?

There was some discussion a while back about the fact that the PP heat shield has very different numbers in the "ModuleAblator" module, which (I believe) result in the very high rate of ablator burnoff compared to stock heat shields. This post has the details. That was from 1.03, I think, but I'm pretty sure it is still true. I changed my own PP heatshield cfg to match, and the burnoff rate became similar to what I was familiar with for stock.

[Xuixien]

There was some discussion a while back about the fact that the PP heat shield has very different numbers in the "ModuleAblator" module, which (I believe) result in the very high rate of ablator burnoff compared to stock heat shields. This post has the details. That was from 1.03, I think, but I'm pretty sure it is still true. I changed my own PP heatshield cfg to match, and the burnoff rate became similar to what I was familiar with for stock.

Thanks! I edited the cfg file accordingly. I really appreciate your help!

[RadarManFromTheMoon]

Changelog

• Rebuilt for KSP 1.0.5
  
• Procedural Heat Shield: ModuleAblator values now match with stock
  
• Procedural Heat Shield: No more 100 bucks extra cost
  
• Procedural Heat Shield: No more negative costs. They always, at least, cost their ablator resource costs
  

[Proteus]

is this mod better than tweakscale?

[Astrofox]

To an extent, yes, but to another extent, no. If you want both, uninstall them (if one is in your GameData folder), run the game once and then quit, then install both mods and then hope they both run together without conflict. This method has worked for me several times.

[juanml82]

just curious. is there a way to make rectangular shapes available? i use PP on realism overhaul and could really use some rectangular tanks for satelites and rovers.

I don't use Realism Overhaul, but I'd love rectangular tanks for rovers. And MK2 fuel tanks, if possible.

[MainSailor]

[quote name='Proteus']is this mod better than tweakscale?[/QUOTE]

They're fundamentally different mods.

TweakScale allows you to resize stock and common mod parts, including engines and structural components. In this way you [I]could [/I]expand your fuel tank sizes simply by having one set of parts (KW tanks, say) and resizing them to match all your needs.

What pParts allows you to do is create completely custom fuel tanks. Need a 6.25 meter tank because your 5 meter one just doesn't carry enough fuel? Or a tank that tapers from 1.25 to 3.75 meters, but is 10 meters tall? You make one. And make it any color or texture you'd like.

What pParts doesn't do is allow you to resize other components, as TweakScale does (other than the solid boosters.)

I use both, happily. I've removed all but a few of the stock fuel tanks (actually Ven's, but beside the point,) as pParts is a lot more ram-friendly than keeping AIES, KW, and SpaceY tanks sitting around.

[CorvusCorax]

Hi, I am playing with procedural parts as part of RealismOverhaul in 1.0.4

I have a bug with Procedural SRBs - to be exact the item named "[B]Solid Rocket Motor [Procedural][/B]" when Realism Overhaul (v10.5.0) is installed on top of Procedural parts (1.1.7) (which is a dependency)
The very same bug can also be reproduces with the item named "[B]Procedural Real Fuels SRB[/B]" when Real Fuels (rfv10.7.2) + Stockalike RF Configs (v3.0.0) is installed on top of Procedural parts (1.1.7)

The bug does [B]not[/B] affect the Procedural SRB named "[B]Procedural SRB[/B]" that is available when Procedural parts only are installed-

In the default [B]Procedural SRB[/B] the user can specify the engine Thrust in kN. This seems to work for any number of SRBs on the vehicle independenlty.

In the [B]Solid Rocket Motor [Procedural][/B] and [B]Procedural Real Fuels SRB[/B] the user instead specifies the burn time, which is flawed when more than one SRB is used in the same vehicle

If multiple SRB's are stacked with different configured burn times, then they always seem to have the same fuel consumption, usually leading to a massive increase in thrust and decrease in burn time for the upper stage:

[B]How to reproduce:[/B]
1. Build a two stage rocket with either "Realism Overhaul" or "Real Fuels + Stockalike RF Configs" and their dependencies installed on top of Procedural parts
2. Have the upper stage with a small (for example 2m x 0.4m cylinder SRB) with a long burn time (for example 120 seconds) (should barely be able to lift a stayputnik core) and optionally some stabilization fins
3. Have the lower stage with a significantly larger SRB ( 3m x 1m cylinder SRB) with a short burn time (for example 15 seconds) and optionally some stabilization fins
4. Put the thing on the launch pad

[B]Expected outcome:[/B]
When launching and staging or manually activating any engine in the stack, the lower stage should produce massive thrust for 15 seconds, the upper stage should produce low thrust for 120 seconds

[B]Actual outcome:[/B]
Even though correct low thrust forces are displayed in the engine UI in the VAB, the upper stage will actually burn for a very short time (like 2 seconds) with thrust and fuel consumption matching the rates set for the lower stage! Especially when the difference in booster size is significant this can lead to burn times of under 1 second on the smaller one.
A burn time of under 1000 ms on a SRB is IMHO no longer considered a booster - its a shaped explosive charge ;) Especially if it was supposed to last for much longer.

Is this a bug in Real Fuels or a bug in Procedural parts?

No other SRBs seem to be affected, but then again no other SRBs have configurable burn times/thrust

[COLOR="silver"][SIZE=1]- - - Updated - - -[/SIZE][/COLOR]

On having a glance into ProceduralSRB.cs and seeing the mess with the different code branches for "UsingME" versus "!UsingME" - I am pretty convinced - although of course not certain - that the bug is somewhere here.

Also I noticed that when SRBs are assigned to an engine group, one can apparently change their thrust on the fly by altering the modular engines group slider - even though SRB's are supposed to have constant thrust. Is that intended?

[COLOR="silver"][SIZE=1]- - - Updated - - -[/SIZE][/COLOR]

In function UpdateEngineAndBellScale() , part.GetComponent<ModuleEngines>().maxFuelFlow = fuelRate; - even though fuelRate is never set if UsingME is true (all such lines are commented out)

Also in function UpdateBurnTime() a division by fuelRate becomes a division by zero - causing "Infinity" to be displayed as expected burntime when in flight.

[CorvusCorax]

I found a workaround for the bug:

Removing the section:
MODULE
{
name = ModuleEngineConfigs
techLevel = 0
origTechLevel = 0
engineType = S
gimbalTransform = SRBBell
configuration = Normal
modded = false
CONFIG
{
name = Normal
maxThrust = 52
heatProduction = 157

PROPELLANT
{
name = SolidFuel
ratio = 1.0
DrawGauge = True
}
IspSL = 1
IspV = 1
}
}

from ProceduralParts/Parts/ZOtherMods/RFSRB.cfg fixes the issue for the [B]Procedural Real Fuels SRB[/B] and makes it behave like the Procedural SRB (with user specified Thrust, and multiple SRBs working independently)
I would assume the same workaround (removing the section which existence triggers the UsingME code in ProceduralSRB.cs) would work in RealismOverhaul as well, gonna test that next

[gleedadswell]

I'm running 1.0.4 in an RP-0 game. ckan just updated some mods. Now during game boot up it stalls on proceduralSRBRealFuels. I'm not sure whether it was the procedural parts upgrade that broke things or real fuels. I'm going to try the following and report back:

1. See if I can migrate everything over to 1.0.5 (I'm going to guess that at least some mods will break if I try this).
2. Manually revert back to an earlier real fuels and/or procedural parts version.

Later edit:
1. yes migrating everything to 1.0.5 doesn't look like it will work yet. There are lots of mods that don't appear to be updated for 1.0.5. It might be possible but ckan won't do it.
2. The problem is RealFuels, not Procedural Parts. Procedural Parts shows version 1.1.7, which as far as I can tell should be fine in 1.0.4. But Real Fuels has updated to 10.8. Unfortunately, I could't *find* a link to 10.7 online, but luckily it was in my ckan/downloads. Deleting RealFuels from GameData and unzipping the older version to replace it has fixed the problem. So, if you are running 1.0.4 don't let ckan update RealFuels to the latest version. Edited November 19, 2015 by gleedadswell
report back - fixed

[CorvusCorax]

[quote name='gleedadswell']I'm running 1.0.4 in an RP-0 game. ckan just updated some mods. Now during game boot up it stalls on proceduralSRBRealFuels. I'm not sure whether it was the procedural parts upgrade that broke things or real fuels. I'm going to try the following and report back:
[/QUOTE]

I didn't have that issue yesterday when you reported it despite CKAN upgrades, but I do have it today.

Happens both with RealismOverhaul and with RealFuels: Stockalike RC Config used.

log is as follows
[CODE]
[LOG 21:06:43.387] PartLoader: Compiling Part 'ProceduralParts/Parts/ZOtherMods/RFSRB/proceduralSRBRealFuels'
[LOG 21:06:43.390] Added sound_rocket_hard to FXGroup running
[ERR 21:06:43.400] Cannot find a PartModule of typename 'ModuleFuelTanks'

[ERR 21:06:43.400] Cannot find a PartModule of typename 'ModuleEngineConfigs'

[ERR 21:06:43.400] Cannot find a PartModule of typename 'ModuleEnginesRF'

[LOG 21:06:43.402] OnLoad
[LOG 21:06:43.402] OnLoad end
[LOG 21:06:43.416] PartLoader: Part 'ProceduralParts/Parts/ZOtherMods/RFSRB/proceduralSRBRealFuels' has no database record. Creating.
[LOG 21:06:43.428] DragCubeSystem: Creating drag cubes for part 'proceduralSRBRealFuels'
[LOG 21:06:43.448] *PP* InitializeBells
[EXC 21:06:43.451] ArgumentException: Unable to find engine-like module
KSPAPIExtensions.Utils.EngineWrapper..ctor (.Part part)^M
ProceduralParts.ProceduralSRB.get_Engine ()^M
ProceduralParts.ProceduralSRB.InitModulesFromBell ()^M
ProceduralParts.ProceduralSRB.InitializeBells ()^M
ProceduralParts.ProceduralSRB.GetInfo ()^M
PartLoader.CompilePartInfo (.AvailablePart newPartInfo, .Part part)^M
[/CODE]


Edit: from KSPApiExtensions: EngineWrapper.cs
[CODE]
public EngineWrapper(Part part)
{
if ((mEFX = part.transform.GetComponent<ModuleEnginesFX>()) != null)
type = ModuleType.MODULEENGINESFX;
else if ((mE = part.transform.GetComponent<ModuleEngines>()) != null)
type = ModuleType.MODULEENGINES;
else
throw new ArgumentException("Unable to find engine-like module");
}
[/CODE]

[COLOR=silver][SIZE=1]- - - Updated - - -[/SIZE][/COLOR]

Found the culrit:
The module "RealPlumes" which ckan installs together with RealFuels has the file:

GameData/RealPlume/RealPlume-RFStockalike/PP.cfg

In this it overrides configurations of the procedural SRB

[CODE]
@PART[proceduralSRBRealFuels,proceduralTankHRB]
{
PLUME
{
name = Solid-Lower //pre-fabbed plume you want
transformName = thrustTransform //which transform to attach the plume
localRotation = 0,0,0 //Optional - Any rotation needed
localPosition = 0,0,0.05 //Any offset needed
//flare|plumePosition are optional, and conflict with localPosition.
//flarePosition = 0,0,1 //If localPosition is insufficient
//plumePosition = 0,0,2 //Specify flare and plume positions separately.
//Only specify one of these
fixedScale = 1.5 //Size adjustment to resize to engine
energy = 1 //Adjust length of plume
speed = 1 //Adjust speed to fit resize,
//generally close to 1:1 with scale.
}
@MODULE[ModuleEngines*]
{
@name = ModuleEnginesRF
// = Solid-Lower
}
@MODULE[ModuleEngineConfigs]
{
%type = ModuleEnginesRF
@CONFIG,* //Add the effect to every engine config
{
%powerEffectName = Solid-Lower
}
}

}
[/CODE]

The line

@name = ModuleEnginesRF

changes the module name for any modules starting with ModuleEngine... including ModuleEngine itself
However ProceduralParts expects a module "ModuleEngine" or "ModuleEngineFX" to be present in any procedural parts, ESPECIALLY proceduralSRBRealFuels
(which by the way is originally defined in GameData/ProceduralParts/Parts/ZOtherMods/RFSRB)
- without it it will throw that exception.

So it was indeed RealFuels that broke ProceduralParts - through a modification in RealPlumes. And it would break under 1.0.5 and the newest ProceduralParts too.

Apparently the RealFules guys changed a config that is specific to a Part introduced by ProceduralParts and in doing so BROKE ProceduralParts ? Edited November 20, 2015 by CorvusCorax

[CorvusCorax]

checked again, its apparently not "RealFuels" itself but "RealFuels: Stockalike RC Config" that brings this modification with it

if you use realismOverhaul it seems to be more complicated. The same line exists in
RealismOverhaul/RealPlume_Configs/ProceduralParts/proceduralSRBRealFuels.cfg

Also the exception is identical

however removing the line from the .cfg file doesn't get rid of the exception as it did with the Stockalike RC config so I must be missing something

[antgeth]

[quote name='sisyphean']just curious. is there a way to make rectangular shapes available? i use PP on realism overhaul and could really use some rectangular tanks for satelites and rovers.[/QUOTE]
this! plus hexagonal prisms!

[CorvusCorax]

OK found it. The update that broke it for me was *drumroll*

Animate Emissive Module v1.13

With that version installed the combo of RealFuels with ProceduralParts will break the Procedural SRB in such a way KSP will not start

Without it it works in RO-0 as well as Stockalike RF Configs


Howto downgrade in CKAN:

1. Uninstall Animate Emissive Module v1.13 if its already installed in CKAN
2. Refresh module list in CKAN
3. Go to "settings" and tell CKAN to not auto-refresh the module list on startup
4. Close CKAN, edit the file CKAN/registry.json
5. find the entry section for Animate Emissive Module v1.13 and remove it. make sure to leave the 1.11 in there
6. start CKAN and reinstall RealFuels/RealismOverhaul (will pull in Animate Emissive Module v1.11)
7. re-enable auto-refresh in settings if you want but make sure NOT to upgrade Animate Emissive Module to 1.13 until this is fixed

[NathanKell]

Just merged a fix into CKAN, from Olympic1, that should fix that issue. :)

[Revenant503]

[/QUOTE]

Just confirming it works...I didn't particularly like uninstalling all of RO and bunch of other things, so I just deleted solver Engines and downloaded a new copy of V1.11 and installed it - The way CKAN seemed to put he upgrade in was troubling.
Hopefully 1.14 when it comes around will be nicer.
Oh...it seems AJE and Animate emissive are tied together..downgrading AE requires a downgrade to Advanced Jet Engines to 2.4.1 Edited November 21, 2015 by Revenant503

[CorvusCorax]

[QUOTE]
Just confirming it works...I didn't particularly like uninstalling all of RO and bunch of other things, so I just deleted solver Engines and downloaded a new copy of V1.11 and installed it - The way CKAN seemed to put he upgrade in was troubling.
Hopefully 1.14 when it comes around will be nicer.
Oh...it seems AJE and Animate emissive are tied together..downgrading AE requires a downgrade to Advanced Jet Engines to 2.4.1[/QUOTE]

There won't be a 1.14. In fact there isn't even a 1.13. As I understand it, the animated emissives module isn't needed anymore for 1.0.5. SolverEngines 1.13 (and likely all future) don't include Animate Emissives anymore. However CKAN erroneously had SolverEngines 1.13 referenced as "AnimateEmissive 1.13" and flagged as compatible with 1.0.4 - thats why it got upgraded and installed - which broke things. Olympic1 and Nathan fixed this now :-)

If you want newer jet engine version it looks like you need 1.0.5 meanwhile RO is available for 1.0.5 and so is RSS - but I'm still missing a few key features (clouds don't work yet even though environmental modules are installed, I cant seem to upscale the hangars for large rockets, E9 procedural wings still aren't there, ...)