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

[RadarManFromTheMoon]

Oh dear. I'm sorry that one of my changes caused problems! The other tanks, since they don't switch contents, don't have any problems, and still show up in the proper resource tab. I forgot to make the change to the Procedural Battery part, but I suspect it wouldn't have any problems either. I'll have to take a look at the TankContentSwitcher code to see if I can do anything about it.

No worries. Can happen. Still on the mk2/mk3 case? Any news?

I don't like this. I liked when it was transparent - made putting batteries underneath so much easier. How to modify this feature back in?

You could compare the old config file with the new. Though, I changed that because it got changed in the stock shields too. So the transparency is probably deprecated/causes problems.

Is there any chance Procedural SRBs could get adjustable thrust curves? I'd like to have that in order to maintain a smooth gravity turn, not shooting up too high or having to go too shallow and burn up.

I'll think about it but not a priority at the moment.

Its not playing nicely with Ferram Aerospace Research like it says in the OP

Every time I do anything with a procedural part, it forces a voxel update, causing lag and log spamming

I will see if I can optimize that a bit, but the message driven design of PP makes it sometimes hard to cut down on revoxelizations/drag cube recalculations.

hi,

My ksp crashes every time I select the procedural SRB

and I may have found another issue, where some parts are attached to the wrong part after loading, which leads to sponaneous combustion outside and to reorganizing inside the VAB.

Regards

Logs or it didn't happen

@NathanKell: Thanks for the OP update.

[amo28]

Logs or it didn't happen

Same crash with adding Procedural SRBs is happening for me as well. Linux x64. KSP 1.0.4

Nothing much to see in KSP.log, but this is the tail of the player.log:

Updating Untitled Space Craft

(Filename: /home/builduser/buildslave/unity/build/artifacts/LinuxStandalonePlayerGenerated/UnityEngineDebug.cpp Line: 56)

Voxelization Time (ms): 139

(Filename: /home/builduser/buildslave/unity/build/artifacts/LinuxStandalonePlayerGenerated/UnityEngineDebug.cpp Line: 56)

proceduralTankRealFuels added to ship - part count: 2

(Filename: /home/builduser/buildslave/unity/build/artifacts/LinuxStandalonePlayerGenerated/UnityEngineDebug.cpp Line: 56)

Updating Untitled Space Craft

(Filename: /home/builduser/buildslave/unity/build/artifacts/LinuxStandalonePlayerGenerated/UnityEngineDebug.cpp Line: 56)

ArgumentNullException: Argument cannot be null.
Parameter name: key
  at System.Collections.Generic.Dictionary`2[Part,RUI.Algorithms.Vertex`1[Part]].get_Item (.Part key) [0x00000] in <filename unknown>:0 
  at RUI.Algorithms.ComponentListMaker.UpdatePartVertex (Boolean residual, .Part part, System.Collections.Generic.Dictionary`2 lookup) [0x00000] in <filename unknown>:0 
  at RUI.Algorithms.ComponentListMaker.GetStackFlowGraph (.ShipConstruct ship) [0x00000] in <filename unknown>:0 
  at EngineersReport.RunTests () [0x00000] in <filename unknown>:0 
  at EngineersReport+	.MoveNext () [0x00000] in <filename unknown>:0 

(Filename:  Line: 4294967295)

Updating Untitled Space Craft

(Filename: /home/builduser/buildslave/unity/build/artifacts/LinuxStandalonePlayerGenerated/UnityEngineDebug.cpp Line: 56)

ArgumentNullException: Argument cannot be null.
Parameter name: key
  at System.Collections.Generic.Dictionary`2[Part,RUI.Algorithms.Vertex`1[Part]].get_Item (.Part key) [0x00000] in <filename unknown>:0 
  at RUI.Algorithms.ComponentListMaker.UpdatePartVertex (Boolean residual, .Part part, System.Collections.Generic.Dictionary`2 lookup) [0x00000] in <filename unknown>:0 
  at RUI.Algorithms.ComponentListMaker.GetStackFlowGraph (.ShipConstruct ship) [0x00000] in <filename unknown>:0 
  at EngineersReport.RunTests () [0x00000] in <filename unknown>:0 
  at EngineersReport+	.MoveNext () [0x00000] in <filename unknown>:0 

(Filename:  Line: 4294967295)

Voxelization Time (ms): 177

(Filename: /home/builduser/buildslave/unity/build/artifacts/LinuxStandalonePlayerGenerated/UnityEngineDebug.cpp Line: 56)

ArgumentNullException: Argument cannot be null.
Parameter name: key
  at System.Collections.Generic.Dictionary`2[Part,RUI.Algorithms.Vertex`1[Part]].get_Item (.Part key) [0x00000] in <filename unknown>:0 
  at RUI.Algorithms.ComponentListMaker.UpdatePartVertex (Boolean residual, .Part part, System.Collections.Generic.Dictionary`2 lookup) [0x00000] in <filename unknown>:0 
  at RUI.Algorithms.ComponentListMaker.GetStackFlowGraph (.ShipConstruct ship) [0x00000] in <filename unknown>:0 
  at EngineersReport.RunTests () [0x00000] in <filename unknown>:0 
  at EngineersReport+	.MoveNext () [0x00000] in <filename unknown>:0 

(Filename:  Line: 4294967295)

OnStart

(Filename: /home/builduser/buildslave/unity/build/artifacts/LinuxStandalonePlayerGenerated/UnityEngineDebug.cpp Line: 56)

*PP* InitializeBells

(Filename: /home/builduser/buildslave/unity/build/artifacts/LinuxStandalonePlayerGenerated/UnityEngineDebug.cpp Line: 56)

This is a craft on a new save with one command module and a procedural tank (which works just fine).

I uninstalled/reinstalled via CKAN. Also reinstalled Real Fuels and remove RSS and RO to test any effect, but found no difference.

[nablabla]

hi,

I think I found a bug together with procedural fairings (http://forum.kerbalspaceprogram.com/threads/39512-1-0-4-Procedural-Fairings-3-15-%28June-27%29?p=2074516&viewfull=1#post2074516)

whenever I connect an inline fairing with its decoupler (upper node of it's three) to a procedural tank (and attach the engines aside the node just put them in symmetry mode.

It work at first, but when it reloads the vessel it is wrong (cliping into it for some meters).

Its not alwayls like that, i think its always the first fairing in the rocket, but if it happens it happens all the time restacking does not help

best regards

▼☺

[SirKeplan]

Getting the same problem with placing a procedural SRB

Ubuntu Linux 64 bit, everything installed with ckan

ckan mods list

{
    "kind": "metapackage",
    "abstract": "A list of modules installed on the default KSP instance",
    "name": "installed-default",
    "license": "unknown",
    "version": "2015.07.12.10.56.17",
    "identifier": "installed-default",
    "spec_version": "v1.6",
    "depends": [
        {
            "name": "RSSTextures8192",
            "version": "v10.0"
        },
        {
            "name": "RealismOverhaul",
            "version": "v10.1.0"
        },
        {
            "name": "TACLS-Config-RealismOverhaul",
            "version": "v10.1.0"
        },
        {
            "name": "AdvancedJetEngine",
            "version": "2.2.1"
        },
        {
            "name": "FerramAerospaceResearch",
            "version": "1:v0.15.3.1"
        },
        {
            "name": "ModuleManager",
            "version": "2.6.6"
        },
        {
            "name": "ModularFlightIntegrator",
            "version": "1.1.1"
        },
        {
            "name": "RealFuels",
            "version": "rf-v10.4.5"
        },
        {
            "name": "SolverEngines",
            "version": "v1.6"
        },
        {
            "name": "CommunityResourcePack",
            "version": "0.4.3"
        },
        {
            "name": "CrossFeedEnabler",
            "version": "v3.3"
        },
        {
            "name": "KerbalJointReinforcement",
            "version": "v3.1.4"
        },
        {
            "name": "ModuleRCSFX",
            "version": "v4.1"
        },
        {
            "name": "RealChute",
            "version": "1.3.2.3"
        },
        {
            "name": "RealHeat",
            "version": "v1.0"
        },
        {
            "name": "RealPlume",
            "version": "v0.0"
        },
        {
            "name": "SmokeScreen",
            "version": "2.6.5"
        },
        {
            "name": "B9AerospaceProceduralParts",
            "version": "0.40"
        },
        {
            "name": "BetterBuoyancy",
            "version": "v1.3"
        },
        {
            "name": "ConnectedLivingSpace",
            "version": "1.1.3.1"
        },
        {
            "name": "FilterExtensions",
            "version": "2.3.0"
        },
        {
            "name": "FilterExtensionsDefaultConfig",
            "version": "2.3.0"
        },
        {
            "name": "KSP-AVC",
            "version": "1.1.5.0"
        },
        {
            "name": "MechJeb2",
            "version": "2.5.3"
        },
        {
            "name": "ProceduralFairings",
            "version": "v3.15"
        },
        {
            "name": "ProceduralFairings-ForEverything",
            "version": "v0.0.3"
        },
        {
            "name": "FirespitterCore",
            "version": "v7.1.4"
        },
        {
            "name": "ProceduralParts",
            "version": "v1.1.6"
        },
        {
            "name": "RealSolarSystem",
            "version": "v10.1"
        },
        {
            "name": "Kopernicus",
            "version": "1:beta-02"
        },
        {
            "name": "RemoteTech",
            "version": "v1.6.7"
        },
        {
            "name": "RemoteTech-Config-RSS",
            "version": "8.1.1"
        },
        {
            "name": "SemiSaturatableRW",
            "version": "1.10.1"
        },
        {
            "name": "TACLS",
            "version": "v0.11.1.20"
        },
        {
            "name": "TextureReplacer",
            "version": "2.4.7"
        },
        {
            "name": "FASA",
            "version": "5.35"
        },
        {
            "name": "ReflectionPlugin",
            "version": "1.2"
        },
        {
            "name": "RasterPropMonitor-Core",
            "version": "v0.21.1"
        },
        {
            "name": "RasterPropMonitor",
            "version": "v0.21.1"
        },
        {
            "name": "AIESAerospace-Unofficial",
            "version": "1.5.1"
        },
        {
            "name": "AtomicAge",
            "version": "3.0"
        },
        {
            "name": "CommunityTechTree",
            "version": "2.1"
        },
        {
            "name": "DMagicOrbitalScience",
            "version": "1.0.7"
        },
        {
            "name": "ContractsWindowPlus",
            "version": "5.2"
        },
        {
            "name": "KIS",
            "version": "1.2.0"
        },
        {
            "name": "KAS",
            "version": "0.5.3"
        },
        {
            "name": "PorkjetHabitats",
            "version": "0.41"
        },
        {
            "name": "SovietEngines",
            "version": "1.1"
        },
        {
            "name": "SXT",
            "version": "20.6"
        },
        {
            "name": "VenStockRevamp",
            "version": "v1.8.1"
        },
        {
            "name": "LayeredAnimations",
            "version": "1.1"
        },
        {
            "name": "KerbalAlarmClock",
            "version": "v3.4.0.0"
        },
        {
            "name": "TransferWindowPlanner",
            "version": "v1.3.0.1"
        },
        {
            "name": "TweakScale",
            "version": "v2.2.1"
        },
        {
            "name": "InfernalRobotics",
            "version": "0.21.3"
        },
        {
            "name": "Toolbar",
            "version": "1.7.9"
        }
    ]
}

Full log

end of log file

 
(Filename: /home/builduser/buildslave/unity/build/artifacts/LinuxStandalonePlayerGenerated/UnityEngineDebug.cpp Line: 56)

Input is null

(Filename: /home/builduser/buildslave/unity/build/artifacts/LinuxStandalonePlayerGenerated/UnityEngineDebug.cpp Line: 56)

Input is null

(Filename: /home/builduser/buildslave/unity/build/artifacts/LinuxStandalonePlayerGenerated/UnityEngineDebug.cpp Line: 56)

Tac.EngineersReportLifeSupportTests[FFF3F0CC][180.56]: OnGUIEngineersReportReady

(Filename: /home/builduser/buildslave/unity/build/artifacts/LinuxStandalonePlayerGenerated/UnityEngineDebug.cpp Line: 56)

Tac.CheckSupplies[B1B9D200][180.56]: constructor

(Filename: /home/builduser/buildslave/unity/build/artifacts/LinuxStandalonePlayerGenerated/UnityEngineDebug.cpp Line: 56)

Parsing string

(Filename: /home/builduser/buildslave/unity/build/artifacts/LinuxStandalonePlayerGenerated/UnityEngineDebug.cpp Line: 56)

Getting value. Currently: False

(Filename: /home/builduser/buildslave/unity/build/artifacts/LinuxStandalonePlayerGenerated/UnityEngineDebug.cpp Line: 56)

New value: False

(Filename: /home/builduser/buildslave/unity/build/artifacts/LinuxStandalonePlayerGenerated/UnityEngineDebug.cpp Line: 56)

Parsing string

(Filename: /home/builduser/buildslave/unity/build/artifacts/LinuxStandalonePlayerGenerated/UnityEngineDebug.cpp Line: 56)

Parsing string

(Filename: /home/builduser/buildslave/unity/build/artifacts/LinuxStandalonePlayerGenerated/UnityEngineDebug.cpp Line: 56)

Parsing bool

(Filename: /home/builduser/buildslave/unity/build/artifacts/LinuxStandalonePlayerGenerated/UnityEngineDebug.cpp Line: 56)

Parsing string

(Filename: /home/builduser/buildslave/unity/build/artifacts/LinuxStandalonePlayerGenerated/UnityEngineDebug.cpp Line: 56)

Parsing string

(Filename: /home/builduser/buildslave/unity/build/artifacts/LinuxStandalonePlayerGenerated/UnityEngineDebug.cpp Line: 56)

Parsing bool

(Filename: /home/builduser/buildslave/unity/build/artifacts/LinuxStandalonePlayerGenerated/UnityEngineDebug.cpp Line: 56)

Parsing string

(Filename: /home/builduser/buildslave/unity/build/artifacts/LinuxStandalonePlayerGenerated/UnityEngineDebug.cpp Line: 56)

Getting value. Currently: False

(Filename: /home/builduser/buildslave/unity/build/artifacts/LinuxStandalonePlayerGenerated/UnityEngineDebug.cpp Line: 56)

New value: False

(Filename: /home/builduser/buildslave/unity/build/artifacts/LinuxStandalonePlayerGenerated/UnityEngineDebug.cpp Line: 56)

Create button for module Ascent Guidance

(Filename: /home/builduser/buildslave/unity/build/artifacts/LinuxStandalonePlayerGenerated/UnityEngineDebug.cpp Line: 56)

Create button for module Attitude Adjustment

(Filename: /home/builduser/buildslave/unity/build/artifacts/LinuxStandalonePlayerGenerated/UnityEngineDebug.cpp Line: 56)

Create button for module Custom Window Editor

(Filename: /home/builduser/buildslave/unity/build/artifacts/LinuxStandalonePlayerGenerated/UnityEngineDebug.cpp Line: 56)

Create button for module Docking Autopilot

(Filename: /home/builduser/buildslave/unity/build/artifacts/LinuxStandalonePlayerGenerated/UnityEngineDebug.cpp Line: 56)

Create button for module Landing Guidance

(Filename: /home/builduser/buildslave/unity/build/artifacts/LinuxStandalonePlayerGenerated/UnityEngineDebug.cpp Line: 56)

Create button for module Maneuver Node Editor

(Filename: /home/builduser/buildslave/unity/build/artifacts/LinuxStandalonePlayerGenerated/UnityEngineDebug.cpp Line: 56)

Create button for module Maneuver Planner

(Filename: /home/builduser/buildslave/unity/build/artifacts/LinuxStandalonePlayerGenerated/UnityEngineDebug.cpp Line: 56)

Create button for module RCS Balancer

(Filename: /home/builduser/buildslave/unity/build/artifacts/LinuxStandalonePlayerGenerated/UnityEngineDebug.cpp Line: 56)

Create button for module Rendezvous Autopilot

(Filename: /home/builduser/buildslave/unity/build/artifacts/LinuxStandalonePlayerGenerated/UnityEngineDebug.cpp Line: 56)

Create button for module Rendezvous Planner

(Filename: /home/builduser/buildslave/unity/build/artifacts/LinuxStandalonePlayerGenerated/UnityEngineDebug.cpp Line: 56)

Create button for module Rover Autopilot

(Filename: /home/builduser/buildslave/unity/build/artifacts/LinuxStandalonePlayerGenerated/UnityEngineDebug.cpp Line: 56)

Create button for module Settings

(Filename: /home/builduser/buildslave/unity/build/artifacts/LinuxStandalonePlayerGenerated/UnityEngineDebug.cpp Line: 56)

Create button for module Smart A.S.S.

(Filename: /home/builduser/buildslave/unity/build/artifacts/LinuxStandalonePlayerGenerated/UnityEngineDebug.cpp Line: 56)

Create button for module SmartRcs

(Filename: /home/builduser/buildslave/unity/build/artifacts/LinuxStandalonePlayerGenerated/UnityEngineDebug.cpp Line: 56)

[MechJeb2] No icon for SmartRcs

(Filename: /home/builduser/buildslave/unity/build/artifacts/LinuxStandalonePlayerGenerated/UnityEngineDebug.cpp Line: 56)

Create button for module Spaceplane Guidance

(Filename: /home/builduser/buildslave/unity/build/artifacts/LinuxStandalonePlayerGenerated/UnityEngineDebug.cpp Line: 56)

Create button for module Translatron

(Filename: /home/builduser/buildslave/unity/build/artifacts/LinuxStandalonePlayerGenerated/UnityEngineDebug.cpp Line: 56)

Create button for module Utilities

(Filename: /home/builduser/buildslave/unity/build/artifacts/LinuxStandalonePlayerGenerated/UnityEngineDebug.cpp Line: 56)

Create button for module Warp Helper

(Filename: /home/builduser/buildslave/unity/build/artifacts/LinuxStandalonePlayerGenerated/UnityEngineDebug.cpp Line: 56)

Create button for module Delta-V Stats

(Filename: /home/builduser/buildslave/unity/build/artifacts/LinuxStandalonePlayerGenerated/UnityEngineDebug.cpp Line: 56)

Create button for module Orbit Info

(Filename: /home/builduser/buildslave/unity/build/artifacts/LinuxStandalonePlayerGenerated/UnityEngineDebug.cpp Line: 56)

Create button for module Surface Info

(Filename: /home/builduser/buildslave/unity/build/artifacts/LinuxStandalonePlayerGenerated/UnityEngineDebug.cpp Line: 56)

Create button for module Vessel Info

(Filename: /home/builduser/buildslave/unity/build/artifacts/LinuxStandalonePlayerGenerated/UnityEngineDebug.cpp Line: 56)

Updating Untitled Space Craft

(Filename: /home/builduser/buildslave/unity/build/artifacts/LinuxStandalonePlayerGenerated/UnityEngineDebug.cpp Line: 56)

Voxelization Time (ms): 161

(Filename: /home/builduser/buildslave/unity/build/artifacts/LinuxStandalonePlayerGenerated/UnityEngineDebug.cpp Line: 56)

Action 'Activate' already defined.

(Filename: /home/builduser/buildslave/unity/build/artifacts/LinuxStandalonePlayerGenerated/UnityEngineDebug.cpp Line: 56)

Action 'Shutdown' already defined.

(Filename: /home/builduser/buildslave/unity/build/artifacts/LinuxStandalonePlayerGenerated/UnityEngineDebug.cpp Line: 56)

Action 'Activate' already defined.

(Filename: /home/builduser/buildslave/unity/build/artifacts/LinuxStandalonePlayerGenerated/UnityEngineDebug.cpp Line: 56)

Action 'Shutdown' already defined.

(Filename: /home/builduser/buildslave/unity/build/artifacts/LinuxStandalonePlayerGenerated/UnityEngineDebug.cpp Line: 56)

OnStart

(Filename: /home/builduser/buildslave/unity/build/artifacts/LinuxStandalonePlayerGenerated/UnityEngineDebug.cpp Line: 56)

*PP* InitializeBells

(Filename: /home/builduser/buildslave/unity/build/artifacts/LinuxStandalonePlayerGenerated/UnityEngineDebug.cpp Line: 56)

[RadarManFromTheMoon]

hi,

I think I found a bug together with procedural fairings (http://forum.kerbalspaceprogram.com/threads/39512-1-0-4-Procedural-Fairings-3-15-%28June-27%29?p=2074516&viewfull=1#post2074516)

whenever I connect an inline fairing with its decoupler (upper node of it's three) to a procedural tank (and attach the engines aside the node just put them in symmetry mode.

It work at first, but when it reloads the vessel it is wrong (cliping into it for some meters).

Its not alwayls like that, i think its always the first fairing in the rocket, but if it happens it happens all the time restacking does not help

best regards

▼☺

That bug should already be fixed. Please make sure you installed the most recent versions of both, ProceduralParts and ProceduralFairings. If it still persists please give me precise reproduction steps and logfiles so I can reproduce the bug and fix it.

I confirm the crashes when using the ProceduralSRB and RealFuels. Might be that something changed in the RealFuels engine module. Fix is in the making.

And now to something completely different.

Balancing.

My initial goal was to balance all ProceduralParts against stock parts (fuel capacity, mass, costs). When done right it would even be possible to delete the stock parts at all and play completely procedural. Saves some memory n stuff.

Stock parts scale somewhat unlinearly, but I did some tesing and it seems to actually be possible to imitate the stock scaling to a satisfying degree (SRBs are the exception, those are more complicated). Now just add some dummyparts with proper entry costs and let them unlock tech restrictions when purchased and everything should work like stock right? I wish. The problem is, in the stock tech tree, it is most of the time not actually required to research all dependencies of a tech node (I guess for err... gameplay reasons?). So it is possible to research a little tank, and after that circumvent the medium sized tanks to directly go to the huge 3.75m tanks. And thats a major f*up because the PP tech restrictions work on a min/max basis. I spent some time thinking about possible ways to get gaps into the allowed size range but couldnt come up with a solution that I'm actually sort of sure would work and wouldn't be a huge PITA to implement.

So it might be the best solution to balance the parts against stock, make them much more expensive and place tech updates later in the tech tree than their stock equivalent. That way Procedural parts would be custom made premium parts which cover the ranges in size between the standard stock parts. For people who like to delete the stock parts to replace them with procedurals, there could be an optional module manager config that adds fixed size procedural parts that mimic the stock parts.

All that does not apply to RealismOverhaul, because I think they have their own balancing.

What do you think? Any ideas?

[Yemo]

Balancing.

My initial goal was to balance all ProceduralParts against stock parts (fuel capacity, mass, costs). When done right it would even be possible to delete the stock parts at all and play completely procedural. Saves some memory n stuff.

Stock parts scale somewhat unlinearly, but I did some tesing and it seems to actually be possible to imitate the stock scaling to a satisfying degree (SRBs are the exception, those are more complicated). Now just add some dummyparts with proper entry costs and let them unlock tech restrictions when purchased and everything should work like stock right? I wish. The problem is, in the stock tech tree, it is most of the time not actually required to research all dependencies of a tech node (I guess for err... gameplay reasons?). So it is possible to research a little tank, and after that circumvent the medium sized tanks to directly go to the huge 3.75m tanks. And thats a major f*up because the PP tech restrictions work on a min/max basis. I spent some time thinking about possible ways to get gaps into the allowed size range but couldnt come up with a solution that I'm actually sort of sure would work and wouldn't be a huge PITA to implement.

So it might be the best solution to balance the parts against stock, make them much more expensive and place tech updates later in the tech tree than their stock equivalent. That way Procedural parts would be custom made premium parts which cover the ranges in size between the standard stock parts. For people who like to delete the stock parts to replace them with procedurals, there could be an optional module manager config that adds fixed size procedural parts that mimic the stock parts.

All that does not apply to RealismOverhaul, because I think they have their own balancing.

What do you think? Any ideas?

From my experience it is not worth trying to balance something against stock, since stock is extremely imbalanced itself.

I actually rebalanced ProceduralParts for my old 0.90 SETI BalanceMod (still available from the second post in the SETI thread), which was possible because I also dealt with the major stock imbalances. And for a long time the SETI-BalanceMod required PP and discarded the stock fuel tanks and stuff by default.

At the moment I m actually in the last phase of reconfiguring/extending PP for SETIctt, as before, this is mainly possible because I deal with the most horrible tech tree balancing issues of stock as well (not to the extent of the old SETI-BalanceMod, but it is at least bearable).

Again, trying to balance against a horrible imbalanced system is a headache (because it is ultimately impossible). When in doubt, just try to get close and leave the rest to "house-rules"/"roleplaying", as that is necessary for stock imbalances anyway. For example the 1 kerbal Mk1 pod has a mass of 0.8 tons, the Mk1-2 pod for 3 kerbals has a mass of 4 tons, the 4 kerbal hitchhiker has a mass of 2.4 tons (+ eg a probe core for control). There is absolutely no gameplay reason to ever use a Mk1-2 pod given the ingame stats. It is just roleplay.

If you wish, we could discuss what rebalances may be useful for stock PP as well, after I finish the next SETIctt update (today).

Edited July 12, 2015 by Yemo

[RadarManFromTheMoon]

The stock balancing actually works quite well (maybe because, with PP, I mostly deal with fuel tanks and those are not that unreasonably (un)balanced.) I made an extra part module for stock balancing, so everyone who does not like it that way can simply remove the module from the parts and it will scale the old, linear way.

Most of the time we have these types of parts: 0.625m, 1.25m, 2.5m, 3.75m. Take mass for example. The module implements a massPerkL curve for every diameter type (length and diameter in -> mass out) for diameters in between those standard diameters it just interpolates linearly between those curves. Same goes for costs. fuel capacity luckily scales linearly with mass. That way it is possible to make the parts scale exactly like their stock counterparts of the same dimensions.

The big problem is really the way the tech tree works. Unlocking techRestrictions on the same node as a comparable sized part gets unlocked feels exploity/cheaty.

[JonDahm]

No worries. Can happen. Still on the mk2/mk3 case? Any news?

I've had a lot of personal stuff happening lately, so I haven't had any time to work on mods. I'm still on the case, I just haven't gotten anything done!

The big problem is really the way the tech tree works. Unlocking techRestrictions on the same node as a comparable sized part gets unlocked feels exploity/cheaty.

I don't feel like it's any more cheaty/exploity than getting larger tanks before medium-sized tanks in the first place. It makes sense to me that if you can make a small tank and a large tank, you can make a medium tank. I wouldn't worry about people bypassing lower levels, except to ensure that if they do go back and research the lower level, doing so doesn't lower their maximum/raise their minimum possible tank sizes.

[Yemo]

I don't feel like it's any more cheaty/exploity than getting larger tanks before medium-sized tanks in the first place. It makes sense to me that if you can make a small tank and a large tank, you can make a medium tank. I wouldn't worry about people bypassing lower levels, except to ensure that if they do go back and research the lower level, doing so doesn't lower their maximum/raise their minimum possible tank sizes.

Imho tech should just unlock the max diameter of fuel tanks. Those length restrictions are imho artificial and just relevant for the part count. Anyway, thats how I set it up for SETIctt. It also makes procedural parts unlocks very simple when (nearly) all the same diameter stock tanks are at the same node.

Oh, is a ProceduralParts storage for USI LifeSupport resources planned?

[nablabla]

Hi, Bug:

- Put together: pod, procedural fairing(at the decoupler), procedural tank, thruster

- Remove everything from the pod.

- Delete the pod.

- Get a new pod.

- Add the stuff again to the pod. (I did this because I accidently removed the tac resources by 'remove all tanks' but there is no quick set-back-to-default-button)

Now if you change the shape of the tank, its glitches, i.e. the size semms to stay the same. But actually it does not.

And I have had the case that there was some hidden mass when I build a bigger rocket, at least kerbal engineer gave me very bad delta-v stats. After I replaced all tanks with new ones my stats have been okay again.

best regards,

thanks for your work

[RadarManFromTheMoon]

Good news. There is a RealFuels hotfix which fixes the ProceduralSRB crash to desktop issue. Please install, and it should work fine.

I've had a lot of personal stuff happening lately, so I haven't had any time to work on mods. I'm still on the case, I just haven't gotten anything done!

I don't feel like it's any more cheaty/exploity than getting larger tanks before medium-sized tanks in the first place. It makes sense to me that if you can make a small tank and a large tank, you can make a medium tank. I wouldn't worry about people bypassing lower levels, except to ensure that if they do go back and research the lower level, doing so doesn't lower their maximum/raise their minimum possible tank sizes.

Alright. I'm about to change a lot in the shape modules at the moment. So waiting a bit might be a good idea anyway.

The thing with the tech nodes is that I want to make the players pay for updates. Currently updates costs nothing and get unlocked as soon as a node is researched. But stock parts cost an entry purchase so I think it might be a good idea to add dummy parts which, when purchased, lets you build your procedural parts bigger. The problem is: The way the tech tree works makes it possible to purchase a more advanced update before researching the more basic ones. And thats exploity.

btw: you are right. If one can build a small and a big tank, one should be able to design a medium one. But doing so will still cost money and research capacity. So, I think its not totally unreasonable.

Imho tech should just unlock the max diameter of fuel tanks. Those length restrictions are imho artificial and just relevant for the part count. Anyway, thats how I set it up for SETIctt. It also makes procedural parts unlocks very simple when (nearly) all the same diameter stock tanks are at the same node.

Oh, is a ProceduralParts storage for USI LifeSupport resources planned?

Bigger tanks also make the rocket less wobbly. I think it makes sense to pay for extra robustness. I know many people don't like the stock tech tree but I don't find it that bad. Its just not easy to harmonize PP with it. Good thing you offer an alternative with your rebalancing mod. Its always good to have the choice.

I'll put the USI LS on the todo list.

Hi, Bug:

- Put together: pod, procedural fairing(at the decoupler), procedural tank, thruster

- Remove everything from the pod.

- Delete the pod.

- Get a new pod.

- Add the stuff again to the pod. (I did this because I accidently removed the tac resources by 'remove all tanks' but there is no quick set-back-to-default-button)

Now if you change the shape of the tank, its glitches, i.e. the size semms to stay the same. But actually it does not.

And I have had the case that there was some hidden mass when I build a bigger rocket, at least kerbal engineer gave me very bad delta-v stats. After I replaced all tanks with new ones my stats have been okay again.

best regards,

thanks for your work

Yeah, sorry, I actually have fixed that already. But wanted to wait until RF gets the ProceduralSRB issue fixed before releasing (in case that requires changes on my side). Now that there is a fix, I will release a hotfix tomorrow.

On the wrong mass issue: I will see if I can do something about that but without reproduction steps, it might take time.

Edited July 13, 2015 by RadarManFromTheMoon

[nablabla]

Yaay, thank you!

On the wrong mass issue: I will see if I can do something about that but without reproduction steps, it might take time.

no, I think the wrong mass was caused by the malicious tanks from the same error. If I find it again, I'll reproduce it.

[RadarManFromTheMoon]

Download

This is a hotfix release that fixes the broken procedural decoupler

[SirKeplan]

i've got a 3 stage rocket made from proc SRBs, and when i place it on the launch pad the burn times of the upper 2 stages drastically shorten. infact whenever i make a rocket out of solid stages an stage above the first stage has it's burn time change.This is in RO/RSS

[pozine]

Ok, i'm using procedural parts with Realism overhaul and i can't change the textures of any procedural parts

Everything works but the textures

Edited July 14, 2015 by pozine

[crashy]

I have this problem with Procedural parts with the shape editor not showing up (to change the physical base of the part): http://imgur.com/a/6REMF

[RadarManFromTheMoon]

Ok, i'm using procedural parts with Realism overhaul and i can't change the textures of any procedural parts

Everything works but the textures

I have this problem with Procedural parts with the shape editor not showing up (to change the physical base of the part): http://imgur.com/a/6REMF

*sigh* That issue has already been adressed multiple times on the thread. You need to keep all your mods up-to-date.

[crashy]

Sorry, I should've looked through the thread first. Apologies for my idiotness

[amo28]

I'm seeing strange behavior with the latest update.

In the SPH, assemble a plane with procedural tanks. Center Of Mass shows in its normal position.

Save, launch, reload to editor -- center of mass is now far forward of its previous position.

Remove procedural tank, COM goes back to normal -- delete tank and rebuild it from scratch, and you start back at square one.

Seems to only be related to a procedural tank -- procedural structural element and procedural nosecones don't seem to give me the same behavior.

I can get some pictures and logs if needed -- I was just curious if I'm the only one seeing this behavior.

[Goddess Bhavani]

For example the 1 kerbal Mk1 pod has a mass of 0.8 tons, the Mk1-2 pod for 3 kerbals has a mass of 4 tons, the 4 kerbal hitchhiker has a mass of 2.4 tons (+ eg a probe core for control). There is absolutely no gameplay reason to ever use a Mk1-2 pod given the ingame stats. It is just roleplay.

Excuse moi, polite snip for brevity

Hi,

Sorry for replying to the previous page.

I wholeheartedly agree with you it isn't really necessary to manually balance everything because that may lead to some of the roleplaying fun being drastically reduced for a lot of people. Taking the previous SRB issue discussed in the thread, the custom SRBs are actually fine as they are because they cost a lot more than the stock parts but allow for superior performance through customization. It just takes a bit of roleplaying to not use the P-SRBs if they're drastically more efficient than the stock RT-5 and 10!

In any case the P-SRBs are self-balancing in early stock career - go up too high and too fast before even unlocking decoupler tech and the flight becomes a fatal sub-orbital plunge

As for Hitchhiker vs Mk1-2 command pod. The command pod has its uses. It won't kill the crew if attempting a parachute water landing. That itself is worth the extra weight to me as ballistic re-entries sometimes take place untargeted and it's not always possible to alter a return trajectory to hit land.

[nablabla]

On the wrong mass issue: I will see if I can do something about that but without reproduction steps, it might take time.

Hi again, I think I just found that bug again. I build a rocket with 15kDv and got it to orbit. Later I wanted to start the same rocket again, but this time I use the corrected a part in the upper stages (used another thruster with the same propellant) and put the rest back on. Now for whatever reason kerbal engineer show only 13kDv, especially only 1.3kdV for the big first stage. I calculated it by hand and it was wrong.

I copied the rocket and rebuild the first and second stage exactly, now it showed 15.kDv again. I saved both versions of the craft (attached).

And I found that the incorrect version has only 44k of lqdHydorgen while the correct has 94k or something like that. While the incorrect weighted over 100t and the corrected version (the same rocket) only around 70t. When I remove all tanks and add them again, the problem is gone. Sorry that I cannot provide the exact steps to reproduce it.

Can I send or attach you the files somhow?

[Prasiatko]

Seem to be having an issue where procedural fuel tanks nose cones and decouplers (possibly others haven't checked) don't have their skin temp change during re-entry. This results in them barely heating up and acting as massive heatsinks for the rest of the ship, making it very resistant to re entry heat. I'm using DRE 7.2.1 and FAR 15.4 if either of those could be causing the issue

[funk]

Seem to be having an issue where procedural fuel tanks nose cones and decouplers (possibly others haven't checked) don't have their skin temp change during re-entry. This results in them barely heating up and acting as massive heatsinks for the rest of the ship, making it very resistant to re entry heat. I'm using DRE 7.2.1 and FAR 15.4 if either of those could be causing the issue

I think I was simultanously tracking down a similar problem with heatshields. When returning from mun at a shallow reentry path the ablator was burned really fast and I was wondering that nothing happened after there was no ablator left.

From the 1.0.3 changelog: "Heat shield thermal mass modifier increased to 0.05 to deal with increased heating. Max temp lowered to 3000 to avoid totally overpowered radiation heatloss."

So I compared the cfg files for stock and PP heatshields. There are some different values:

MODULE
{
name = ModuleAblator
ablativeResource = Ablator
lossExp = -6000
lossConst = 1
pyrolysisLossFactor = 600
reentryConductivity = 0.01
ablationTempThresh = 500
}

    thermalMassModifier = 1.0

MODULE
{
name = ModuleAblator
ablativeResource = Ablator
lossExp = -9000
lossConst = 20
pyrolysisLossFactor = 10000
reentryConductivity = 0.01
ablationTempThresh = 500
}

    thermalMassModifier = 0.001

For nosecones there are also the following nodes in stock parts which are missing in PP:

    thermalMassModifier = 6.0
    emissiveConstant = 0.95

For fuel tanks there aren't those nodes in stock, that leads to the question: What happens to a the PP liquid tank when it has the shape of a cone ?

[Prasiatko]

Further testing involving sending a tank through the atmosphere using hyper edit indicates a FAR bug possibly.

I used hyperedit to put a tank in orbit with AP 1Mm PE 22km and it flew through that atmosphere barely altering its orbit.

[Prasiatko]

Does anyone know what could be causing all procedural parts to be prefixed with a 0? I assume it is due to another mod interfering somehow. Trying to track down which.

EDIT: SETI tech tree for anyone wondering.

Edited July 19, 2015 by Prasiatko