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

[AwkwardNoah]

On 11/23/2016 at 9:21 AM, Jiraiyah said:

as i mentioned few posts ago, there is a method in the git hub repo that reads the game version and compares it to the hard coded version in the mod up to sub versions. so yeah, if no one change that before recompiling, that error will pop up but the point is that the error is harmless and the mod is working, well, the exception is the bug i reported two posts above ;D

 

same for me, I think there might be some issues in the part data

[Jiraiyah]

11 hours ago, AwkwardNoah said:

same for me, I think there might be some issues in the part data

well, for time being, i am using the options before filling the tanks, when i am happy with the looks, that is when i go for the sliders, that way i will be sure that i have the correct amount

[AwkwardNoah]

On 11/28/2016 at 1:07 AM, Jiraiyah said:

well, for time being, i am using the options before filling the tanks, when i am happy with the looks, that is when i go for the sliders, that way i will be sure that i have the correct amount

i mean like they aren't even working

wait is it 1.2?

[Sol Invictus]

As @Jiraiyah was saying, a pop-up message about Procedural Parts being incompatible with KSP 1.2.1 is caused by a hard-coded version checker in ProceduralParts.dll plugin. I looked into the source, and found this paragraph inside zzVersionChecker.cs:

            /*-----------------------------------------------*\
            |    BEGIN IMPLEMENTATION-SPECIFIC EDITS HERE.    |
            \*-----------------------------------------------*/

            // TODO: Implement your own compatibility check.
            //
            // If you want to disable some behavior when incompatible, other parts of the plugin
            // should query this method:
            //
            //    if (!CompatibilityChecker.IsCompatible()) {
            //        ...disable some features...
            //    }
            //
            // Even if you don't lock down functionality, you should return true if your users
            // can expect a future update to be available.
            //
            return Versioning.version_major == 1 && Versioning.version_minor == 2 && Versioning.Revision == 0;

            /*-----------------------------------------------*\
            | IMPLEMENTERS SHOULD NOT EDIT BEYOND THIS POINT! |
            \*-----------------------------------------------*/

All it would take to fix this issue would be to change Versioning.Revision value from 0 to 1, and then recompile the whole thing. Or abandon the idea of hard-coded version checkers altogether.

Edited December 2, 2016 by Sol Invictus

[Rafael acevedo]

10 minutes ago, Sol Invictus said:

As @Jiraiyah was saying, a pop-up message about Procedural Parts being incompatible with KSP 1.2.1 is caused by a hard-coded version checker in ProceduralParts.dll plugin. I looked into the source, and found this paragraph inside zzVersionChecker.cs:

            /*-----------------------------------------------*\
            |    BEGIN IMPLEMENTATION-SPECIFIC EDITS HERE.    |
            \*-----------------------------------------------*/

            // TODO: Implement your own compatibility check.
            //
            // If you want to disable some behavior when incompatible, other parts of the plugin
            // should query this method:
            //
            //    if (!CompatibilityChecker.IsCompatible()) {
            //        ...disable some features...
            //    }
            //
            // Even if you don't lock down functionality, you should return true if your users
            // can expect a future update to be available.
            //
            return Versioning.version_major == 1 && Versioning.version_minor == 2 && Versioning.Revision == 0;

            /*-----------------------------------------------*\
            | IMPLEMENTERS SHOULD NOT EDIT BEYOND THIS POINT! |
            \*-----------------------------------------------*/

All it would take to fix this issue would be to change Versioning.Revision value from 0 to 1, and then recompile the whole thing. Or abandon the idea of hard-coded version checkers altogether.

Make this recommendation in the change log at github for the Mod owners attention

[Spheniscine]

Issue: The procedural SRB gimbal now seems to only work on the pitch axis. I suspect it may be an issue with the thrust deflection tweakable, since that tweaks on the yaw axis

edit: Apparently it's already open: https://github.com/Swamp-Ig/ProceduralParts/issues/210

Edited December 2, 2016 by Spheniscine

[Plexi]

On 18.1.2015 at 3:16 AM, OtherBarry said:

It is done then. Karbonite support will be in the next release. I'll post a config here when I finish too, so you don't have to wait.

Opened an issue a while ago on github:

https://github.com/Swamp-Ig/ProceduralParts/issues/210

[Spheniscine]

1 hour ago, Plexi said:

Opened an issue a while ago on github:

https://github.com/Swamp-Ig/ProceduralParts/issues/210

Workaround found: create a .cfg file with the following and put it into GameData/custom

@PART[proceduralTankSRB]:Final
{
   @MODULE[ModuleGimbal]
   {
      @gimbalTransformName = thrustTransform
   }
}

Downside: gimballing no longer visually affects the bell. However the thrust should deflect correctly. Disclaimer: not tested what happens if you also use preset thrust deflection

Edited December 2, 2016 by Spheniscine

[Bit Fiddler]

procedural command pods are on the list of planned items. I assume this includes procedural probe cores?  with monoprop, battery, reaction wheels, antenna etc.

and while we are at it what about just a procedural reaction wheel?

also as a side note it seems the procedural parts have 2x the number of "faces" as the majority of KSP parts.  while on the surface this is no big deal (no pun intended), it is more overhead for the models.  however more importantly (for me anyway), is that they have a funny "seam" where the parts match up, as the geometry is different.   I know this is not a big deal to most people but it does cause aesthetic issues for my designs.  would it be too much to ask to cut the faces in half so the geometry is the same as the rest of KSP's cylinders?

 

 

[Benoit Hage]

Hello.

Just a quick question: I'm using this mod along with SMURFF and I noticed that each time I'm making a 2.5m SRB, it tends to overheat a lot: so hot that it makes any radial decouplers explode due to overheating. Is this behavior correct?

[Vegetal]

On 12/12/2016 at 0:08 PM, Benoit Hage said:

Hello.

Just a quick question: I'm using this mod along with SMURFF and I noticed that each time I'm making a 2.5m SRB, it tends to overheat a lot: so hot that it makes any radial decouplers explode due to overheating. Is this behavior correct?

Oh they do overheat, and I'm not even using Smurff.

On another topic, does anyone know a way to create a custom tab in the VAB with only the procedural parts? 

[Benoit Hage]

19 hours ago, Vegetal said:

Oh they do overheat, and I'm not even using Smurff.

On another topic, does anyone know a way to create a custom tab in the VAB with only the procedural parts? 

We both agree it seems, but is it intentional? Is it supposed to be some sort of limit in-game or is it just a bad "temperature" settings?

[Spheniscine]

On 12/14/2016 at 11:41 PM, Benoit Hage said:

We both agree it seems, but is it intentional? Is it supposed to be some sort of limit in-game or is it just a bad "temperature" settings?

It does appear that the most recent heat settings for this mod tend to cause a overheating problem especially if your SRB is larger.

I mainly fix it by using a ModuleManager config to turn the heatPerThrust down all the way to 1 from the default 200. (Probably too low but I was having issues with my largest launchers even after halving it)

@PART[proceduralTankSRB]:Final
{
   @MODULE[ProceduralSRB]
   {
	  @heatPerThrust = 1
   }
}

 

Edited December 16, 2016 by Spheniscine

[Benoit Hage]

20 hours ago, Spheniscine said:

It does appear that the most recent heat settings for this mod tend to cause a overheating problem especially if your SRB is larger.

I mainly fix it by using a ModuleManager config to turn the heatPerThrust down all the way to 1 from the default 200. (Probably too low but I was having issues with my largest launchers even after halving it)

@PART[proceduralTankSRB]:Final
{
   @MODULE[ProceduralSRB]
   {
	  @heatPerThrust = 1
   }
}

 

Thanks for tip!

 

[Guest]

nvm, didn't read enough of the OP

Edited December 20, 2016 by Guest

[SirusKing]

There is a serious problem with your tanks; you are basing the base mass of your fuel tanks on the volume of the tank, when in reality this is not actually true. Fuel tanks are almost always entirely hollow and so only the surface area counts, meaning the mass should be calculated from what the actual shape is and not just its volume. This is very significant, since it gives big rockets a much smaller maximum economical delta V  for things like single-stage-to-orbit rockets. This should be simple enough for conical and cylindrical tanks but tapered/rounded stuff could be ran as a function based on roundness averaging from the cylindrical to two cylinders, - the flat ends, + a sphere.

Edited December 20, 2016 by SirusKing

[Starwaster]

59 minutes ago, SirusKing said:

There is a serious problem with your tanks; you are basing the base mass of your fuel tanks on the volume of the tank, when in reality this is not actually true. Fuel tanks are almost always entirely hollow and so only the surface area counts, meaning the mass should be calculated from what the actual shape is and not just its volume. This is very significant, since it gives big rockets a much smaller maximum economical delta V  for things like single-stage-to-orbit rockets. This should be simple enough for conical and cylindrical tanks but tapered/rounded stuff could be ran as a function based on roundness averaging from the cylindrical to two cylinders, - the flat ends, + a sphere.

It's a little more complicated than that. Doing it based purely on volume might not be the best way but it takes into account structure requirements: Tank mass isn't just a matter of knowing how large the tank is: You also need to know how much mass the tank has to support. Both its own and the mass of the propellant. If propellant tank masses were only dependent on the tank's surface area then the mass ratio would follow curve as tank size increases but instead it's more linear.

Short answer is that tank mass calculations are abstracted.

[SirusKing]

7 hours ago, Starwaster said:

It's a little more complicated than that. Doing it based purely on volume might not be the best way but it takes into account structure requirements: Tank mass isn't just a matter of knowing how large the tank is: You also need to know how much mass the tank has to support. Both its own and the mass of the propellant. If propellant tank masses were only dependent on the tank's surface area then the mass ratio would follow curve as tank size increases but instead it's more linear.

Short answer is that tank mass calculations are abstracted.

The mass of the propellant would follow a linear relation with volume but the actual base mase of an empty tank wouldn't. Wider/more spherical tanks are **supposed** to hold more fluid for a given mass of tank. In real life, you would have to include the surface area of the internal compartments for seperate oxidiser/fuel tanks inside the outer hull, and also valves and such, but they wouldn't be anywhere near the mass of your current ones.

 

With your tanks, if you double the radius of a cylinder, its mass increases by 4 times, which just should not happen. 

Edited December 20, 2016 by SirusKing

[Maxsimal]

8 minutes ago, SirusKing said:

The mass of the propellant would follow a linear relation with volume but the actual base mase of an empty tank wouldn't. Wider/more spherical tanks are **supposed** to hold more fluid for a given mass of tank.

It looks like you didn't understand Starwasters post.  Yes if the tank wall was exactly the same thickness regardless of the dimensions of the tank, then the tank mass would scale at a 2/3 power to the tank volume.

However, as he mentioned, tanks DON"T just scale due to fluid volume.  They are also support structures, and have to prevent the rocket from buckling under load, and that scales based off of the height of the rocket as well as the mass the tank needs support - not easily calculated.  Thus the need to do an approximation.

[SirusKing]

51 minutes ago, Maxsimal said:

It looks like you didn't understand Starwasters post.  Yes if the tank wall was exactly the same thickness regardless of the dimensions of the tank, then the tank mass would scale at a 2/3 power to the tank volume.

However, as he mentioned, tanks DON"T just scale due to fluid volume.  They are also support structures, and have to prevent the rocket from buckling under load, and that scales based off of the height of the rocket as well as the mass the tank needs support - not easily calculated.  Thus the need to do an approximation.

Then the aproximation is horrible. 

 

Using a real life example; The external fuel tank of the space shuttle. An incredibly rigid structure easily able to support its own weight, weighs 30 tonnes in total when dry. Remaking this tank using procedural tanks, makes it weigh closer to 270 tonnes, 9x as much as real life.

Spoiler

The actual massive tanks walls were less than half a center meter thick (albiet being made of more than just steel). A full steel verson would likely weigh about 60 tonnes, not 260 tonnes. This works for numerous other real life examples. If you actually just base it off size (maybe just times the total result by an extra 20% or something), you get a far better estimate than basing it off volume. The only time this "making up for supporting the weight" would actually hold up is for very large rockets, and when even the SLS tanks are almost entirely hollow, clearly this isn't that significant.

Since your surface area requires a depth too, you could have this be your scaling variable, basing the depth of the material on the volume of the overall tank, say, 0.001+0.000001*volume. For the space shuttle tank, this would give...

 

Dimensions: 8.4m diameter by 47 meter length aprox cylindrical. 

Volume: ~2900m^3

Surface Area: ~1300m^2

Density of steel: 8000kg/m^3

Volume of actual surface area: 5.07m^3

Mass of tank: 40560kg, a much better estimate.

Edited December 20, 2016 by SirusKing

[StoryMusgrave]

@SirusKing I'm assuming you are talking about PP in stock??? Or something else?

[SirusKing]

2 minutes ago, StoryMusgrave said:

@SirusKing I'm assuming you are talking about PP in stock??? Or something else?

This is stock. IDK if realism overhaul changes this, that might be why I have never noticed this.

Edited December 20, 2016 by SirusKing

[Phineas Freak]

@StoryMusgrave is right. The stock Procedural Parts settings do not make any sense for replicating existing hardware. @SirusKing using your tank example under RO i got:

• Diameter: 8.4 m
• Length: 39.8 m
• Volume: 2.05 ML
• Dry mass: 32807 Kg
• Gross mass: 763997 Kg (LH2/LOX mixture at 97% utilization)

A pretty accurate result for a Shuttle ET i have to say (SLWT variant).

(the length is of course wrong since i the "FilletCylinder" tank shape was used and no interstage exists)

Edited December 20, 2016 by Phineas Freak

[Sol Invictus]

Could someone be gracious enough to compile Procedural Parts from source by @RedAV8R? Apart from master, which is identical to the one by @swamp_ig, there are 3 branches named patch-1, patch-2 and patch-3. Those 3 branches need to be merged into one, as each differs from the master by one commit, and we need all 3 commits in order to fix the annoying hard coded version check problem. I already merged them, here is the result. I would gladly compile it myself, but I lack necessary knowledge in order to do it. If you possess that knowledge and you would compile it, then we would all be free from those irritating pop-ups while using Procedural Parts in KSP 1.2.2.

[SirusKing]

10 minutes ago, Phineas Freak said:

@StoryMusgrave is right. The stock Procedural Parts settings do not make any sense for replicating existing hardware. @SirusKing using your tank example under RO i got:

• Diameter: 8.4 m
• Length: 39.8 m
• Volume: 2.05 ML
• Dry mass: 32807 Kg
• Gross mass: 763997 Kg (LH2/LOX mixture at 97% utilization)

A pretty accurate result for a Shuttle ET i have to say (SLWT variant).

(the length is of course wrong since i the "FilletCylinder" tank shape was used and no interstage exists)

If you double the radius, does the mass also double or does it quadrouple? That does seem like a much better number.

Edited December 20, 2016 by SirusKing