[0.90WIP] Procedural Parts - Parts the way you want 'em 0.9.21, Dec 19

[White Owl]

I voted for the sensible relation between size, decoupler force, and mass. Remember that even at this late date, many of the stock parts stats are using numbers that were just made up because they seemed sorta right at the time. They're essentially placeholders.

Personally, I think using this fantastic mod to emulate stock parts would be a mistake. A beautiful thing about unlocking such fine control over parts dimensions is that the player is free to apply real-world engineering and problem solving to KSP creative problems. If you try to follow the flawed stock parts stats, then you're throwing away the opportunity to see KSP creations that actually make sense; vehicles that behave the way they look like they should behave.

[Rioliki]

Please note, that I say “too lightweightâ€Â, not “lighter than stockâ€Â. There are huge differences between definitions. I do (I think, we all are) want relation between size, force & mass. But current calculation model gives 0.625 m decoupler with the 4 kg mass and the 1.250 m is 15 kg. Maybe density should be little bigger and/or just add small constant mass summand, that will not make sensitive affect to big decouplers, but increase mass of the small ones till the acceptable values.

[Andrezado]

Not that I've tested this, but that seems like a fantastic idea, which I don't think will be that hard to make. I'll give at a go over the next few days, and it might work quite well as an interim procedural engine. Thrust would be scalable, but ISP would always be the same without an update to the core mod.

Yeah I thought it wouldn't be so hard since there are already SRBs that you can toggle the engine size/thrust.

[lordkrike]

As per request, the decouplers in the latest build are straighter. If you want totally straight ones (or to be able to modify the curve) have a look at the config file and comment out the line that is suggested that you comment: https://github.com/Swamp-Ig/ProceduralParts/blob/master/Parts/Structural/StackDecoupler.cfg#L60

I was toying with putting in cylinders, but that would require modification to any ships in flight, which isn't ideal really.

Awesomesauce.

Yeah, they had so much curve to them that you couldn't make them smaller than .625m or the model would get jacked up (since it had more curve than diameter). No little meekro-decouplers. If at some point you can think of a way to give the cylinder option without breaking things, that would be awesome, but I'll live either way.

Also

Incidentally - please note that the wobble issue in KSP 0.23.5 that was present prior to PP 0.9.2 should be now fixed. The primary determination for joint strength is the size of the attach node, rather than the part mass.

Very nice.

As far as decouplers go, I vote for sensible procedural measurements. It might work to have a moderate density for the explosives, but also give the decouplers a flat base mass so that the little tiny ones aren't senselessly light.

Edited April 22, 2014 by lordkrike

[RaccoonTOF]

Rioliki, you might be surprised at just how "lightweight" real-world decouplers are. The decoupler system used for many "secondary payloads" is really quite lightweight - in some cases the entire satellite weighs less than 10kg! Even for the larger decoupler systems the actual decouplers themselves are pretty lightweight, much lighter than is modelled in KSP - still small enough to not even be included separately in the total vehicle weights listed for the various Apollo missions due to "decimal truncation" (in other words, the actual decouplers for the SI/SII interstage weighed less than 10kg.) Now, KSP models more than just the decouplers themselves in the "decoupler" parts - it includes the interstage structural and other elements aside from the ullage motors/fuel as well. So those weights will be higher if using separate "decoupler" parts obviously. But the current values used in the mod are actually pretty good from both a realism and simplicity aspect (to be "really real" you would have to have multiple categories of structural types for the decouplers, just like multiple "basemass" values for tanks when using RealFuels.)

[Rioliki]

No, I`m not surprised. Actually, I am well aware about real space engineering. But the Kerbal Space Program is not the simulator of real world space exploration, it`s rather arcade, made for fun, not role-play. Of course there are mods like RSS, RF and many other ones, which bring realism to the game and some another sort of fun. Together with that mods lightweight decouplers has sense, but without them they affect to the game balance. I`m not sure is it good or bad influence (looks like no one never balancing masses of the stock parts. Nosecones for example) on the gameplay, but all options must be considered thoroughly. Besides, I never told, that procedural decouplers should have that ridiculously huge (apparently, of solid uranium) stock masses, just a slight increase.

[OtherBarry]

What module manager file, exactly?

In 0.9.3 there should be a folder called ModuleManager inside Gamedata/ProceduralParts. Inside that, there is a file called rescale1m.cfg.notused . Open it, change values from 1.25 to 2.5, save it wherever you keep your other module manager stuff without the '.notused' at the end.

This will also change the stepDiameter on all the tanks to the Realism Overhaul 2m, 4m, etc system. If you don't want this, then I suggest you edit the SRB cfg itself.

[NoMrBond]

Would it be possible to have additional options for adding

• 
  RW force
  ASAS function
  Probe Core / Remote Guidance
  Battery/Ec storage
  

To the procedural structural parts (with appropriate mass additions and for each selection)?

[OtherBarry]

Would it be possible to have additional options for adding

• 
  RW force
  ASAS function
  Probe Core / Remote Guidance
  Battery/Ec storage
  

To the procedural structural parts (with appropriate mass additions and for each selection)?

Battery and probe core are easily doable now, but reaction wheels are currently not rescalable. I could quite easily make a service module style part that has Electric charge, some rcs and a probe core if you'd like?

[swamp_ig]

Would it be possible to have additional options for adding

• 
  RW force
  ASAS function
  Probe Core / Remote Guidance
  Battery/Ec storage
  

To the procedural structural parts (with appropriate mass additions and for each selection)?

It's possible, of course. Just takes time

[White Owl]

In 0.9.3 there should be a folder called ModuleManager inside Gamedata/ProceduralParts. Inside that, there is a file called rescale1m.cfg.notused . Open it, change values from 1.25 to 2.5, save it wherever you keep your other module manager stuff without the '.notused' at the end.

This will also change the stepDiameter on all the tanks to the Realism Overhaul 2m, 4m, etc system. If you don't want this, then I suggest you edit the SRB cfg itself.

Okay, I see, we're talking about the ProceduralSRB module's thrustScaleFactor value. Default is 256, which scales to the stock SRBs. The optional Realism Overhaul fix scales it up to 320. And you're suggesting a more realistic value would be 640.

Thanks very much.

Edit: Does bellChokeDiameter control the bell scaling with thrust? Is it a visual change only, or does it affect the booster's thrust/Isp/mass?

Edited April 23, 2014 by White Owl

[OtherBarry]

Thanks very much.

No problem. I'm still not certain about the realism of 640, as I'm not entirely sure my maths is correct, so if there's an SRB you cant recreate, let me know, and I'll try and update that value.

Does bellChokeDiameter control the bell scaling with thrust? Is it a visual change only, or does it affect the booster's thrust/Isp/mass?

I'm pretty sure that bellChokeDiameter is the maximum diameter of the bottom of the SRB bell in relation to the diameter of the SRB. For example, if your SRB had a diameter of 2.5m, with a bellChokeDiameter of 1.1 (which is the current setting) then the maximum diameter of the SRB bell would be 2.75m. This relates to the maximum thrust of the SRB as with Solid fuel boosters, thrust is related to the diameter of the top of the bell, which in the case of procedural parts, scales linearly with the bottom diameter.

However, this is entirely conjecture based on my limited knowledge of how the SRB bells work, so I could be completely wrong.

I'm sure I remember an issue on github about it, but I can't seem to find it anywhere. Good luck.

Read post below instead. Also useful: http://forum.kerbalspaceprogram.com/threads/70676-WIP-Procedural-Parts-The-next-phase-of-Stretchy-SRBs?p=1014911&viewfull=1#post1014911

Edited April 23, 2014 by OtherBarry

[swamp_ig]

Edit: Does bellChokeDiameter control the bell scaling with thrust? Is it a visual change only, or does it affect the booster's thrust/Isp/mass?

Don't mess with that.

That is the diameter of the choke (small end) of the bell * 2. This controls the maximum scaling, since you can be at most 50% of the width of the base. You could double the value if you didn't mind the bell choke being large for the SRB, but not more than that otherwise the choke will end up outside the base, which doesn't really make sense

The bell scale scales with the square root of the thrust. There was discussion about the ideal scaling law about 40 pages back This makes physical sense because you'd expect a constant ideal area-of-the-end-of-the-bell / thrust ratio (ie: constant pressure at the end of the bell) for increasing thrust.

The thrustScaleFactor doesn't actually mean anything physically, it's just the thrust such that the bell isn't scaled at all from its standard model. Doubling this value will mean you'll get 2 times more thrust for the same sized bell.

so:

bellScaling = sqrt(thrust) / sqrt(thrustScaleFactor)

finalChokeDiameter = (bellChokeDiameter / 2) * bellScaling

make sense?

Edited April 23, 2014 by swamp_ig

[Eggman360]

I've dabbled with making a procedural engine, it kind of works but seems it can be REALLY powerful, turns out by using the "surface/vacuum" settings from the SRB as a template I even tried making VERY specific settings, such as:

Lifters that offer 100% thrust at surface yet only 20-10% in vacuum yet keep a low isp.

mid stages that offer a good mix between the two and a mid range isp.

A vacuum setting that will make the engine practically useless in atmosphere and act like a nuclear engine in vacuum giving 2-5% thrust and high isp on the surface yet 100% thrust in vacuum with a really high isp (yet not as high as an ion engine.)

I've also dabbled in making a setting for that can run on argon or xenon using the VASIMR settings from near future propulsion including a scalable slider in flight to alter its thrust/isp settings for "emergency thrust" when you need/want it (it won't be a shameless wrap off of that mod part and won't be as powerful at the same size.)

I also plan on making a jet engine

Any interest in me finishing and releasing these parts?

(As far as realism goes don't ask how this is realistic lol, but it WILL be balanced, lol)

Edited April 23, 2014 by Eggman360

[NoMrBond]

Battery and probe core are easily doable now, but reaction wheels are currently not rescalable. I could quite easily make a service module style part that has Electric charge, some rcs and a probe core if you'd like?

Not sure about that combined one, thanks for the offer though, even just being able to add a probe core/battery would help, since there are no 3.75m cores or batteries.

Not needing to put 4x 2.5m RW's under a PF fuselage (for FAR) to actually move those heavy 3.75m tanks would be nice, hopefully that becomes possible at some point (and there's some kind of balance pass so the numbers make sense).

It's possible, of course. Just takes time

I am enjoying the Procedural Parts immensely so far, so thank you for this mod, anything more you have the time to add would be a nice bonus

[OtherBarry]

Even just being able to add a probe core/battery would help, since there are no 3.75m cores or batteries.

Not needing to put 4x 2.5m RW's under a PF fuselage (for FAR) to actually move those heavy 3.75m tanks would be nice, hopefully that becomes possible at some point (and there's some kind of balance pass so the numbers make sense).

I know it's not procedural, but it'd be really easy for me to make a copy of the stock 2.5m probe core, rescaled to 3.75m, and with more Electric Charge, Reaction Wheels and power consumption. Otherwise, I could make a procedural part that just had batteries and a probe core, but reaction wheels wouldn't change with size. Happy to do one or the other. or both. It's pretty simple to do.

[Rioliki]

Procedural probes and batteries are interesting. But they would be twice interesting with procedural solar panels. Flat, I guess. Deployable would be too hard to implement. Or no?

[Erasmus_UK]

I'd definitely be interested in a procedural engine - though I am an unrepentent kit-basher and would want to be able to specify the thrust, iSp ranges and fuel used - However, even if I can't tweak the engines as I would want, I'd still love to see the engines done

Still want procedural command modules though..... ah, one day

[Yorik]

Great mod, this makes building rockets way more fun. Couple of suggestions I'd like to see if you get around to making them:

Make a texture type slot that's keyed to the fuel.

Make it possible in the .cfg to have an empty fuel tank.

Add TAC Life Support support.

That's it.

[Talisar]

There are workarounds for a couple of your suggestions (which doesn't mean that they shouldn't be included, just that you can accomplish what you are after)

Make it possible in the .cfg to have an empty fuel tank.

For this you can adjust the fuel levels using the tweakable interface to empty it in the VAB

Add TAC Life Support support.

This mod will do that for you

Make a texture type slot that's keyed to the fuel.

Alas, poor Yorik (sorry, couldn't resist), I don't have a suggestion about this one.

[swamp_ig]

Heh, looks like the poll is unanimous.

Next task: to figure out a sensible relationship.

Because the stock decouplers really have no relationship between their size, mass, and decoupling force I'll just pick one to be the basis for the model. TR-18A and TR-18D seem the obvious choice - the are the same size and have the same decoupling force (250)

Now there's a big aside here. As is not uncommon in KSP, the physics of decouplers is a bit wrong. The 250 which we thought was Joules, is actually not joules at all. It's added as an instantaneous force during decoupling, and in the wrong mode. If you have phys warp active you'll end up with extra force for free. Not exactly ideal. Anyhow, have reported the bug the the KSP overlords plus how to fix it so hopefully it will be fixed in the next version.

Anyhow the upshot is that all the forces as specified by ejectionForce are actually impulses, and the real impulse is (ejectionForce * 20) Ns. (newton . second). The 20 is because our standard physics frame is 0.02 s, plus masses are in ton, so you end up * 1000.

The mass of the 18D is 0.075, whereas the 18A is 0.05. The difference is the 18D has twice the 'decoupling aparatus' that the 18A has, so we can assume the mass is made up of 1 or 2 'decoupling apparatus' massing 0.025 (25kg - seems reasonable) plus 25kg of impulse producing mass.

So the ISP of our separators ends up as 5000 / 25 kg / g = 20s. This is pretty pathetic really. So that line of investigation is a bit of a fail, but lets run with it anyhow.

Next task: how does the decoupling apparatus scale with size? well you'd expect the mass of the apparatus to be proportional to the area of the surface, or to the diameter squared. Furthermore, the separators will have twice the decoupling apparatus of the decouplers. If we then take off the push mass from the existing decouplers, and then divide the remaining mass by the area we end up with a range between 20kg/m^2 and 76kg/m^2, with an average of 43 and a median of 39. There's no real relationship between the size of the decoupler and this figure, the values are more or less random. I'll use a value of 40kg/m^2

How well does this fit?

Equivalents of the TR-2V and TR-XR about right. TR-2C is 30%, 18A 48%, and 18D 64% more massive. The equivalents of the Rocomax and the 38D are about 55% of the standard parts

I guess it's not TOO bad, but not exactly ideal. Std dev in fit is 0.42

So scrap all that and go for something very simple: Mass is proportional to the area of the decoupler, no tricky bits. This actually gives a better fit - stdev 0.26, most of the stock decouplers are +/- 25% of their calculated mass, the main outlyiers being 18A at 62% of the calculated mass, and the XL at 139%. This is actually what we're already using... so big circle with little gain!

[OtherBarry]

Make a texture type slot that's keyed to the fuel.

Also can't help you there.

Make it possible in the .cfg to have an empty fuel tank.

This is doable. In this section of the .cfg, where <Resource Name> is whatever resource it is you want to be empty:

RESOURCE

{

name = <Resource Name>

//unitsPerKL = 95.6118

unitsPerT = 880

}

Change it to:

RESOURCE

{

name = <Resource Name>

//unitsPerKL = 95.6118

unitsPerT = 880

forceEmpty = true

}

Add TAC Life Support support.

As Talisar said, this mod http://forum.kerbalspaceprogram.com/threads/76156-0-23-5-Procedural-mod-resource-storage-parts will do it, although my .cfg files, which you can find here https://github.com/Swamp-Ig/ProceduralParts/blob/master/Source/CalcsAndModels/%5BIN%20DEVELOPMENT%5D%20Tanks%20for%20Mods/TankLifeSupport.cfg utilises the forceEmpty line, amongst other things, and also seems to be more accurate.

[RaccoonTOF]

Odd bug occuring with the latest version of PP. Take a procedural tank. Stack-attach a normal tank to one attach node (or any other part that is capable of both stack and surface attach). Pick up the part you just attached, then reattach it via surface attach to the procedural tank. Now pick it up again, and reattach it to the procedural tank via stack attach. Result is that the part gets attached via its center (I believe CoM) to the procedural tank node, instead of node to node. Can be kinda handy for hiding some engines inside of the procedural tanks (if the engine allows surface attaching in the first place), but definitely seems to be a bug. The only way to get proper node-to-node attachment back is to remove the part and replace it with a fresh one - no amount of moving it around and then back will resolve it.

[OtherBarry]

Odd bug occuring with the latest version of PP. Take a procedural tank......

i've noticed this before in some of the previous versions as well, but had never worked out the steps for reproducing it. You should make an issue on github for it.

[swamp_ig]

Odd bug occuring with the latest version of PP.

Thanks for the bug report. Looks like it's attaching to the node on the other end.

I'll look into it, shouldn't be too hard to fix I imagine.

Edit:

Yep, was easy fixed

Was due to a bug in KSP. I was working around for when a ST attaches to something else, but not when the ST was the parent.

Edited April 24, 2014 by swamp_ig