Jump to content

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


OtherBarry

Recommended Posts

That would be awesome! Minimum?

I created a MM config that I use for this.


+PART[proceduralStructural]:NEEDS[ProceduralParts]:FINAL
{
@name = proceduralCrewTube
@title = Procedural Crew Tube


@MODULE[ProceduralPart]
{
!TECHLIMIT,* {}

TECHLIMIT {
name = start
diameterMin = 0.5
lengthMin = 0.5
volumeMin = 0.09
diameterMax = Infinity
lengthMax = Infinity
volumeMax = Infinity
}
}


!MODULE[ModuleConnectedLivingSpace],* {}

MODULE
{
name = ModuleConnectedLivingSpace
passable = true
surfaceAttachmentsPassable = true
}
}

Link to comment
Share on other sites

I created a MM config that I use for this.


+PART[proceduralStructural]:NEEDS[ProceduralParts]:FINAL
{
@name = proceduralCrewTube
@title = Procedural Crew Tube


@MODULE[ProceduralPart]
{
!TECHLIMIT,* {}

TECHLIMIT {
name = start
diameterMin = 0.5
lengthMin = 0.5
volumeMin = 0.09
diameterMax = Infinity
lengthMax = Infinity
volumeMax = Infinity
}
}


!MODULE[ModuleConnectedLivingSpace],* {}

MODULE
{
name = ModuleConnectedLivingSpace
passable = true
surfaceAttachmentsPassable = true
}
}

Nice a simple Mm patch. I love it! Thank you.

Link to comment
Share on other sites

I've found an issue where you can't load a vessel if you have a procedural cone with one end tweaked down to 0m. If you try, the game will freeze and spam the crash log until you force quite the game, I got a log to 280Mb once! I manually edited the craft file, adjusted 2 cones from 0m to 0.1m and the craft loaded fine.

Edited by Falcon Coupe
Link to comment
Share on other sites

I've found an issue where you can't load a vessel if you have a procedural cone with one end tweaked down to 0m. If you try, the game will freeze and spam the crash log until you force quite the game, I got a log to 280Mb once! I manually edited the craft file, adjusted 2 cones from 0m to 0.1m and the craft loaded fine.

That's very strange. Does this happen just with Cone and not with Smooth Cone? I always use smooth cone and never have had the issue.

Link to comment
Share on other sites

I created a MM config that I use for this.


+PART[proceduralStructural]:NEEDS[ProceduralParts]:FINAL
{
@name = proceduralCrewTube
@title = Procedural Crew Tube


@MODULE[ProceduralPart]
{
!TECHLIMIT,* {}

TECHLIMIT {
name = start
diameterMin = 0.5
lengthMin = 0.5
volumeMin = 0.09
diameterMax = Infinity
lengthMax = Infinity
volumeMax = Infinity
}
}


!MODULE[ModuleConnectedLivingSpace],* {}

MODULE
{
name = ModuleConnectedLivingSpace
passable = true
surfaceAttachmentsPassable = true
}
}

I love it. I have made a few tweaks of my own for cost, size and techtree and submitted it as a pull request for Realism Overhaul. With any luck it will be adopted.

Link to comment
Share on other sites

Problem/Issue:

  • The FL-T400 holds 180 units of Liquid Fuel and 220 units of Oxidizer.
  • The PP LFO tanks (1.25 diameter by 1.875 length), holds 180.4 and 220.5 of LF and O respectively.
  • So PP and stock are pretty much in agreement given same-size tanks.
  • The MK1 fuel tank holds 400 units of LiquidFuel.
  • But a PP LiquidFuel-only tank (no oxidizer) only holds 294.5 units of LiquidFuel (not approximately 400).

The tank only lets you carry 73% of what it ought to. Why are stock LiquidFuel-only tanks so much better than PP's?

Solution:

  • unitsPerT for PP LiquidFuel tanks should be changed from 1280 to 1739.13 (significant buff)
  • unitsPerT for PP Oxidizer tanks should be changed from 1563 to 2125.603 (significant buff)
  • unitsPerT for PP Mixed tanks should be changed from (720 / 880) to (718.2761 / 877.893) (negligible nerf)

This will result in PP liquid tanks having the exact same amount of fuels as their same-size stock counterparts (although dry-masses will still negligibly differ).

To temporarily test these recommendations, you can apply this cfg patch:


@PART[proceduralTankLiquid]{
@MODULE[TankContentSwitcher] {
@TANK_TYPE_OPTION[Mixed]{
@RESOURCE[LiquidFuel]{
@unitsPerT = 718.2761 // previously 720
}
@RESOURCE[Oxidizer]{
@unitsPerT = 877.893 // previously 880
}
}
}
}


@PART[proceduralTankLiquid]{
@MODULE[TankContentSwitcher] {
@TANK_TYPE_OPTION[LiquidFuel]{
@RESOURCE[LiquidFuel]{
@unitsPerT = 1738.375 // previously 1280
}
}
}
}

@PART[proceduralTankLiquid]{
@MODULE[TankContentSwitcher] {
@TANK_TYPE_OPTION[Oxidizer]{
@RESOURCE[Oxidizer]{
@unitsPerT = 2124.681 // previously 1563
}
}
}
}

Link to comment
Share on other sites

Problem/Issue:

  • The FL-T400 holds 180 units of Liquid Fuel and 220 units of Oxidizer.
  • The PP LFO tanks (1.25 diameter by 1.875 length), holds 180.4 and 220.5 of LF and O respectively.
  • So PP and stock are pretty much in agreement given same-size tanks.
  • The MK1 fuel tank holds 400 units of LiquidFuel.
  • But a PP LiquidFuel-only tank (no oxidizer) only holds 294.5 units of LiquidFuel (not approximately 400).

The tank only lets you carry 73% of what it ought to. Why are stock LiquidFuel-only tanks so much better than PP's?

Solution:

  • unitsPerT for PP LiquidFuel tanks should be changed from 1280 to 1739.13 (significant buff)
  • unitsPerT for PP Oxidizer tanks should be changed from 1563 to 2125.603 (significant buff)
  • unitsPerT for PP Mixed tanks should be changed from (720 / 880) to (718.2761 / 877.893) (negligible nerf)

This will result in PP liquid tanks having the exact same amount of fuels as their same-size stock counterparts (although dry-masses will still negligibly differ).

To temporarily test these recommendations, you can apply this cfg patch:


@PART[proceduralTankLiquid]{
@MODULE[TankContentSwitcher] {
@TANK_TYPE_OPTION[Mixed]{
@RESOURCE[LiquidFuel]{
@unitsPerT = 718.2761 // previously 720
}
@RESOURCE[Oxidizer]{
@unitsPerT = 877.893 // previously 880
}
}
}
}


@PART[proceduralTankLiquid]{
@MODULE[TankContentSwitcher] {
@TANK_TYPE_OPTION[LiquidFuel]{
@RESOURCE[LiquidFuel]{
@unitsPerT = 1738.375 // previously 1280
}
}
}
}

@PART[proceduralTankLiquid]{
@MODULE[TankContentSwitcher] {
@TANK_TYPE_OPTION[Oxidizer]{
@RESOURCE[Oxidizer]{
@unitsPerT = 2124.681 // previously 1563
}
}
}
}

you assume 1 LF is the same volume as 1 O

instead consider that 294.5 is correct, and 74.5 LF is the same volume as 180 O

though if you want real balance, thats what realfuels mod is for

Link to comment
Share on other sites

you assume 1 LF is the same volume as 1 O

instead consider that 294.5 is correct, and 74.5 LF is the same volume as 180 O

LiquidFuel and Oxidizer have the same density. They're just consumed by engines unequally (9:11 ratio).

From http://wiki.kerbalspaceprogram.com/wiki/Liquid_fuel

“Liquid fuel tanks contain both liquid fuel and oxidizer while fuselages contain only liquid fuel. Rocket engines using liquid fuel and oxidizer use a volumetric mixture of 9 units of liquid fuel per 11 units of oxidizer. All but the Oscar-B Fuel Tank store liquid fuel and oxidizer in this ratio. Jet engines use intake air in a volumetric mixture of 1 unit of liquid fuel per 15 units of intake air. Because all three resources have the same density the volumetric ratio is also the mass ratio.â€Â

though if you want real balance, thats what realfuels mod is for

The goal isn't realism balance. It's about conforming to stock.

With the adjustments I proposed, PP tanks hold the same amount of fuel as stock ones.

EDIT: Here's some before and after screenshots to illustrate the difference:

Before:

Xm3dMZB.png

After:

R0m9ZMy.png

Edited by Entropius
screenshots & spelling
Link to comment
Share on other sites

If you want stock, it's simpler than that...

set unitsPerT = 1600 for both the individual LiquidFuel and Oxidizer options. This fills each per Ton of dry storage, and that's what the mixed option currently does already (720+880). Setting dryDensity = 0.1089 for both will balance the length of the tank to match stock as well. If you read the notes, it looks like they were trying to balance against the entire range of stock LiquidFuel only for (space)planes, which are a little different in terms of mass/capacity (i.e. MkII).

But yeah, I'm finding the stock config much more useful to work from in matching tanks from other mods, like an oxidizer tank to pair with the hydrogen tanks from NFP, or if you want 3 separate fuel tanks for a hybrid system.

Link to comment
Share on other sites

If you want stock, it's simpler than that...

set unitsPerT = 1600 for both the individual LiquidFuel and Oxidizer options. This fills each per Ton of dry storage, and that's what the mixed option currently does already (720+880). Setting dryDensity = 0.1089 for both will balance the length of the tank to match stock as well. If you read the notes, it looks like they were trying to balance against the entire range of stock LiquidFuel only for (space)planes, which are a little different in terms of mass/capacity (i.e. MkII).

But yeah, I'm finding the stock config much more useful to work from in matching tanks from other mods, like an oxidizer tank to pair with the hydrogen tanks from NFP, or if you want 3 separate fuel tanks for a hybrid system.

Ah, so there is a way to fine-tune the dry mass. Thanks! Also the suggestion to change the liquid-only and oxidizer-only tanks to have the same amount of respective fuels (rather than using the 9:11 ratio between the two) is more physical than what I previously did (not that stock tanks are totally realistic to begin with).

Where I decided to depart from your suggestion is here: Rather than 0.1089 for the dryDensity (which gets PP tanks to be closer to stock, but not quite exactly there), I found a better value: 0.10864979. This gets the dry mass of a 1.25 wide by 1.875 long tank to be exactly the same as stock: 0.250 kg. And the jumbo orange tank and same-sized PP tank have the same dry-mass and fuel-units too.

Anyway my new config looks like this:


@PART[proceduralTankLiquid]{
@MODULE[TankContentSwitcher] {
@TANK_TYPE_OPTION[Mixed]{
@dryDensity = 0.10864979 // default=0.1089
}
}
}


@PART[proceduralTankLiquid]{
@MODULE[TankContentSwitcher] {
@TANK_TYPE_OPTION[LiquidFuel]{
@dryDensity = 0.10864979 // default=0.1
@RESOURCE[LiquidFuel]{
@unitsPerT = 1600 // previously 1280
}
}
}
}

@PART[proceduralTankLiquid]{
@MODULE[TankContentSwitcher] {
@TANK_TYPE_OPTION[Oxidizer]{
@dryDensity = 0.10864979 // default=0.1
@RESOURCE[Oxidizer]{
@unitsPerT = 1600 // previously 1563
}
}
}
}

Link to comment
Share on other sites

Also having the same bug with the EngineersReport class. The error only occurs when a procedural part that contains a modular Fuel tank module is attached to the root part.

Also procedural parts seems to be resetting any changes made to tank contents by MFT upon reloading the .craft file.

Edited by Thorbane
Link to comment
Share on other sites

I've been trying to create procedural tanks for CommunityResourcePack fuels with no success. For example, my ArgonGas fuel tank shows up in the VAB/SPH and I can resize it, but there is no fuel on the tank :(. Could someone please give me a hint on how could I make this work? I already made procedural parts for the USI-LS resources and it was quite easy, but I can't see what I'm doing wrong right now.

Procedural ArgonGas Tank cfg file I modified (from the orignal procedural XenonGas tank):


PART:NEEDS[CommunityResourcePack]
{
// --- general parameters ---
name = proceduralTankArgon
module = Part
author = AncientGammoner, NathanKell, Swamp Ig, Eggman360


// --- asset parameters ---
MODEL
{
model = ProceduralParts/Parts/cylinderTank
scale = 1,1,1
}
scale = 1
rescaleFactor = 1


// --- node definitions ---
node_stack_top=0,0.5,0,0,1,0,1
node_stack_bottom=0,-0.5,0,0,-1,0,1
node_attach=0,0,0.5,0,0,-1,1


// --- editor parameters ---
cost = 0 // 4000
TechRequired = ionPropulsion
entryCost = 4000
category = FuelTank
subcategory = 0
title = Procedural Argon Tank
manufacturer = Found lying by the side of the road
description = Made from viscoelastic nanopolymers (which were discovered by accident... growing in the back of the office mini-fridge) this fuel tank can be stretched to accommodate fuel loads of a range of sizes and shapes. Hardens to a rigid structure before launch!




// attachment rules: stack, srfAttach, allowStack, allowSrfAttach, allowCollision
attachRules = 1,1,1,1,0


// --- standard part parameters ---
mass = 1
dragModelType = default
maximum_drag = 0.2
minimum_drag = 0.2
angularDrag = 2
crashTolerance = 7
breakingForce = 50
breakingTorque = 50
maxTemp = 2000

RESOURCE {
name = ArgonGas
amount = 747.5
maxAmount = 747.5
}

MODULE
{
name = ProceduralPart
textureSet = Copernicus

TECHLIMIT {
// FL-R25 - 1.25 x 0.5706054 m = 0.700238177 kL
name = ionPropulsion
diameterMin = 0.125
diameterMax = 0.75
lengthMin = 0.1
lengthMax = 0.75
volumeMin = 0.02
volumeMax = 0.2
}
TECHLIMIT {
// Make everything unlimited for metaMaterials
name = metaMaterials
diameterMin = 0.01
diameterMax = Infinity
lengthMin = 0.01
lengthMax = Infinity
volumeMin = 0.01
volumeMax = Infinity
}
}
MODULE
{
name = ProceduralShapeCylinder
displayName = Cylinder
techRequired = start

length = 0.3
diameter = 0.625
}
MODULE
{
name = ProceduralShapeCone
displayName = Cone
techRequired = start

length = 0.3
topDiameter = 0.162
bottomDiameter = 0.625
}
MODULE
{
name = ProceduralShapePill
displayName = Fillet Cylinder
techRequired = advConstruction

length = 0.3
diameter = 0.625
fillet = 0.25
}
MODULE
{
name = ProceduralShapeBezierCone
displayName = Smooth Cone
techRequired = advConstruction

selectedShape = Round #1
length = 0.3
topDiameter = 0.162
bottomDiameter = 0.625
}
MODULE
{
name = TankContentSwitcher
useVolume = true

// Dry density and fuel units per kL are all over the shop for RCS
dryDensity = 0.5801
TANK_TYPE_OPTION
{
name = ArgonGas
RESOURCE
{
name = ArgonGas
unitsPerT = 14000
}
}
}
}

Link to comment
Share on other sites

Issue / bug: The procedural heatshields seem to both heat up and lose ablator very quickly compared to the stock ones. I tested two return craft (Mk1 Pod + Mk16 Parachute + heatshield), both with Ap at 46400 km (Minmus height) and Pe at 30 km. The procedural one quickly burned it all up by about 30k (though survived the landing even though reaching orange temperatures), while the stock one completed the reentry with 173 ablator left.

100% reentry heat, no FAR, no timewarping, though the same problem persists while playing with FAR.

I have looked in the config file and it appears that there are some numbers that P-Heatshields set very differently from stock (like pyrolysisLossFactor is 10000 to stock 600, which is a factor of over 17! And thermalMassModifier is 0.001 instead of 1.0). I have tested an MMConfig that sets all values that might look important to be identical to stock, and as a result its performance is on par with stock (though the p-heatshield does expose a small "lip" from the command pod... could just be p-heatshield being "too perfect" for its size while the stock parts stick out a little).

Here is the config file for those interested: https://dl.dropboxusercontent.com/u/26985795/ksp/proceduralHeatShieldsFix.cfg

Link to comment
Share on other sites

Issue / bug: The procedural heatshields seem to both heat up and lose ablator very quickly compared to the stock ones. I tested two return craft (Mk1 Pod + Mk16 Parachute + heatshield), both with Ap at 46400 km (Minmus height) and Pe at 30 km. The procedural one quickly burned it all up by about 30k (though survived the landing even though reaching orange temperatures), while the stock one completed the reentry with 173 ablator left.

100% reentry heat, no FAR, no timewarping, though the same problem persists while playing with FAR.

I have looked in the config file and it appears that there are some numbers that P-Heatshields set very differently from stock (like pyrolysisLossFactor is 10000 to stock 600, which is a factor of over 17! And thermalMassModifier is 0.001 instead of 1.0). I have tested an MMConfig that sets all values that might look important to be identical to stock, and as a result its performance is on par with stock (though the p-heatshield does expose a small "lip" from the command pod... could just be p-heatshield being "too perfect" for its size while the stock parts stick out a little).

Here is the config file for those interested: https://dl.dropboxusercontent.com/u/26985795/ksp/proceduralHeatShieldsFix.cfg

I have the same.. Except while I time warp using FAR as soon as the Procedural Heat Shield touch the atmosphere @70000M BOOM! it explodes.

Link to comment
Share on other sites

This thread is quite old. Please consider starting a new thread rather than reviving this one.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...