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

[swamp_ig]

NOTE: Procedural Parts has MOVED HERE.

ProceduralParts allows you to procedurally generate a number of different parts in a range of sizes and shapes. The parts are fully tweakable with multiple options for customization of the shape, surface texture, and other parameters.

This is nearing official release. Will concentrate on finding any more bugs and then make an official first release.

[table=class: grid, align: left]

[tr]

[td]Download[/td]

[td]Report Bugs[/td]

[td]Source GIT[/td]

[/tr]

[/table]

Features

The features include

• Everything accessible by tweaking
  
• A broad range of shapes including cylinders, truncated cones, filleted cylinders, bezier cones.
  
• New part shapes are easy to develop and plug in, so cuboid / pill shaped / whatever else you want shaped will be able to be created.
  
• Most stuff configurable in the config file, including resources and fill ratios, tech levels, available shapes
  
• Diverse support for career mode - tank shapes, dimensions, and contents all limited by researched tech
  
• All supplied parts are carefully designed to be as 'stock alike' as possible in their tech level requirements - You can't create a monster tank before you've discovered basic rocketry for example.
  
• Other mod support - tanks for RealFuels, Kethane, Extraplanetary Launchpads, and TAC. Heat shields for Deadly Reentry. (thanks to OtherBarry)
  
• Plays nicely with Ferram Aerospace Research
  
• Multiple textures available for part surfaces. These are fully compatible with StretchySRB textures.
  
• Deprecation support for StretchySRB - see below for details.
  
• A Module - TankContentSwitcher that can be applied to existing tanks (with say module manager) and allow their contents to be tweaked. Tweak any tank in the VAB into a Liquid fuel only or oxidizer tank.
  

Parts available

• Tanks Different parts supplied for different 'groups' of fuels (Liquid fuels, SRBs, Monoprop, Xenon). The multiple part approach is to allow for tech limiting of sizes and volumes.
  
• SRBs Tweakable thrust (or burn time for real fuels). Tweak between a choice of two bells that are designed for surface or vacuum, with varying ISPs.
  
• Decoupler Tweakable diameters (with tech defined limits), ejection impulse, and can be in either decoupler or separator mode (again tech dependent).
  
• Structural Part Good for fuselage, adapters, whatever. Half as light as the equivalent tank.
  
• Batteries It's a bit rough and ready, but it works well enough.
  
• Nose Cone Specialized structural part for nose cones. The shape is limited to a smooth cone with a bounded ratio of diameter to length.
  
• Heat Shield Built to the same specs as Deadly Reentry. Will shield any sized object from heat. (requires deadly reentry)
  

Screen Shots

Javascript is disabled. View full album

Installation

Just extract the zip into your KSP folder and you should be away. Some of the integration with other mods requires the latest version of ModuleManager, which is included in the zip.

Upgrades

• Make sure you delete any old versions of ProceduralParts.
  
• There's a handful of deprecated parts as was previously used for real fuels. If you didn't use these parts, then you can safely delete the PartsDeprecated folder in the main install directory.
  

Known Issues

• Sometimes if the procedural part is the lowest part on the rocket, it may explode on the launch pad. Easily worked around with a launch clamp. This is fixable but will take more effort than its worth.
  
  
  Custom Textures and Texture Packs
  Procedural Parts is compatible with all texture packs for StretchySRBs. It's easy to roll your own texture packs too.
  Here's some texture packs that other people have compiled:
  Planeguy868
  Download.
  Installation instructions: download and extract it to KSP's GameData folder.
  

  
  
  

  Ferram4's Saturn and Nova Textures
  Download.
  Installation instructions in zip.
  

  
  

  blackheart612
  Full thread!
  

  Javascript is disabled. View full album

  Compatibility with StretchyTanks / StretchySRBs
  This is essentially a completely new mod and can run alongside either of the previous mods. This is useful if you have pre-existing ships in your save file still using those parts. If you don't have any ships using those parts, then you can delete the old mod.
  There's a module manager patch file present that will hide all the StretchySRB tanks in the VAB so they don't clutter it up. If for whatever reason you want to continue using StretchySRBs, then delete ProceduralParts\ModuleManager\StretchyTanks_Hide.cfg and this won't happen.
  Integration with Real Fuels and Modular Fuel Tanks
  Integration with Real Fuels and Modular Fuels Tanks is complete. Ensure you have Real Fuels version 6.1 or newer, and Modular Fuel Tanks 5.0.1 or newer. There's one or two bugs still to get through, stay tuned for updates on those two.
  For MFT, the existing tank types are turned into the corresponding MFT type.
  For real fuels, there's an SRB which can be switched between low altitude and high altitude versions, plus a tank which can be switched between the various RF tank types.
  The old real fuels system with multiple parts for different tank types is preserved as a deprecated option (hidden in the VAB). If you don't have any old tanks on ships or craft you can delete the PartsDeprecated from the root of the install.
  Integration with other mods
  Thanks to OtherBarry, there are now tanks for RealFuels, Kethane, Extraplanetary Launchpads, and TAC.
  There's also a procedural heat-shield for Deadly Reentry.
  All part's drag models will automatically update if using Ferram Aerospace Research.
  The tank types will automatically appear if the mods are installed. They should be 'fair' compared to their unmodded versions.
  How to cheat in career mode have lower tech restrictions
  The current tech restrictions have been tailored to closely mimic stock, with a bit of room to alter the original specs. Note that this will not be changed with the out of the box config.
  

  If you'd like more generous limits, you can create a MM patch (ie: cut and paste this into a file called mycheats.cfg in your GameData dir) and tweak to your liking:
  

  
  @PART[proceduralTank*]
  {
  @MODULE[ProceduralPart]
  {
  @TECHLIMIT,*
  {
  // Increase the max length for all tech levels by 3*
  @lengthMax *= 3
  // Corresponding volume increase
  @volumeMax *= 3
  
  // Increase the max diameter by double
  @diameterMax *= 2
  // Since volume goes up on diameter^2, need to use increase^2
  @volumeMax *= 4
  }
  }
  }
  

  
  This will affect all procedural tanks and the SRB. The name of the Real Fuels SRB is "proceduralSRBRealFuels" so you'll need to make another similar patch for that one if you want to mess with that too.
  

  If you'd like to be able to use all the shapes from the early game then use the following MM patch:
  

  
  @PART

• 
  {
  @MODULE[ProceduralShape*]
  {
  -techRequired = dummy
  }
  }
  

This will affect all parts.
Future plans

• Cuboid parts, with customizable side lengths
  
• Extruded parts, such as hexagonal and octagonal pieces
  
• Add optional mounting pod for surface mounts to pod tank.
  
• Procedural command module, possibly with rescaling / tweakable IVA.
  

Features That Are Not Planned

• Shapes with 'holes' in them and concave shapes - including toroids.
  
• Procedural wings, procedural fairings - there's good mods for these already.
  
• Procedural engines - May happen one day, but not a priority.
  
  
  Acknowledgements
  ProceduralParts has an extended family tree
  
  • StretchyTanks is the original module by the great Ancient Gammoner.
    
  • StretchySRBs was created and updated by NathanKell and e-dog.
    
  • ProceduralParts is a near complete re-write by Swamp Ig.
    

Also featuring

• Extensive work on config and mod integration by OtherBarry
  
• Models by Tiberion
  
• Further textures by Chestburster and Dante80.
  
• Config code by jsimmonds
  

Licence

Remains as CC-BY-SA 3.0 Unported.

Change Log

0.9.21

• Compatible to KSP version 0.90 (thanks to @saybur for his help!)
  
• Fixed a graphical glitch that appeared when resizing procedural decouplers
  

0.9.x

• Tight integration with real fuels / modular fuel tanks.
  
• Procedural heat-shields for Deadly Reentry (Thanks to OtherBarry )
  
• Updating the drag model during tweaking of parts for Ferram Aerospace Research
  
• Procedural tanks for resources in other mods: Kethane, TAC, Extraplanetary Launchpads
  
• Better formatting of tweaker values. These now show four significant figures and an SI prefix.
  
• Xenon tank
  
• Hiding of parts depending on what addins are installed
  
• Resource improvements - can set a tank to be empty in the VAB ( waste, Kethane ) or to have a fixed amount of resource regardless of the volume
  
• Battery Part
  
• Shape limiting on tech levels.
  

Click for full changelog

Note: swamp_ig is very busy with real life right now, and as such NathanKell and taniwha are stepping in to try to keep this maintained.

Edited January 13, 2015 by NathanKell
Release 0.9.21

[Albert VDS]

What about procedural heat shields?

[Chestburster]

Procedural spherical tanks anyone? Going to test the mod, lets see what we can find..

[likke_A_boss]

Oh! I got some! Procedural ladders! Procedural LLL tanks! Procedural a Solar panels! Procedural MK2 fuselage! Procedural MK3 fuselage! Procedural Cargo Bays! Procedural Trusses! And, Procedural structural panel!

[Mekan1k]

This is going to be so cool....

[FanaticalFighter]

Is this only tanks, or engines as well? Because if it is engines as well, then this mod will occupy a permanent spot in my game.

[Captain Sierra]

Is this only tanks, or engines as well? Because if it is engines as well, then this mod will occupy a permanent spot in my game.

How does one proceduralize engines?

[swamp_ig]

Procedural spherical tanks are very much planned - this will also include tanks like the Stratus-V Cylindrified, sphere ends with cylinder body.

Next step after that is extruded shapes - such as Hex, Octagonal, and Rectangular. This would include Mk2 / 3 fuselage.

Procedural engines are harder to do aesthetically - you can't just scale up a model because it will look totally naff. It doesn't make a lot of physical sense either - tanks are just welded together bits of metal with a bit of engineering to pump the contents around. Engines are much more heavily engineered.

As for other stuff - we'll have to see!

[Roxette]

I want to see a procedural kerbal twice the size of the VAB, throwing rockets into space as an alternative launch method.

[edit] This is wonderful, already added my own configs for procedural batteries and KAS storage tanks \o/

Edited February 24, 2014 by Roxette

[Guest]

This is quite impressive. I'm really looking forward to procedural spherical and pill-shaped tanks. Will RealFuels compatibility be included? It's rather hard to play RSS without procedural tanks.

[fusty]

Hey swamp, your latest commits are on the master branch. Should I fart around with that one if I want to try some things out?

[blackheart612]

Wanna report a bug, if it is, textures are flipped when trying to use them new tanks/SRB

[cziken20]

This looks like a grwat mod! And hey, are we able to take models and textures of the tanks, to make our own parts?

[Itsdavyjones]

well, i am gonna have to keep an eye on this one.

[blizzy78]

Please add a license to the OP as per the forum rules.

[swamp_ig]

fusty: Have forked the repo to a new repository entirely, so I've moved it to the master branch. Really there's maybe only a handful of lines of code in common with the original plugin now so it made sense. I also wanted to keep the issue list separate.

cziken20: I'm not quite sure what you mean... You won't be able to export the models out if that's what you mean - or at least I don't think you will. You're more than welcome to reuse the code, although it might be better to contribute to the project to keep things consistent.

blackheart: thanks, will fix. The textures in the core are symmetrical so hard to notice. Can you raise an issue on the the git repo?

Dragon: Yes, RF and RE will be working in the near future, if they aren't already. Have mostly been trying to get it working with stock first.

[MAKC]

Some procedural toroidal tanks for neat, compact 3rd/4th stages and landers would be nice.

[Boamere]

AHHhhhhhhhh

(pics please )

Also procedural Command pods?

[NathanKell]

blizzy78: all three of us agreed it's going to stay CC-BY-SA.

[Hammer Tech]

Along with Pwing, this will streamline my game so much. Looking awesome- can't wait to try it out.

[wasmic]

Oh! I got some! Procedural ladders! Procedural LLL tanks! Procedural a Solar panels! Procedural MK2 fuselage! Procedural MK3 fuselage! Procedural Cargo Bays! Procedural Trusses! And, Procedural structural panel!

Procedural procedures!

[FanaticalFighter]

Random ideas for Procedural Engines:

There should be multiple engines with the procedural feature: eg an OMS engine, a launcher engine, an upper stage engine, a nuke.

These engines should be scalable, ie, increased in size. With increase in size, the engines increase in weight and thrust. ISP stays the same. This scaling should be so that the engines can come close to the engines already in the game - e.g. the OMS engine gets a similar amount of thrust to the LV909 when scaled to that size.

Increasing ISP for an engine should mean increase in both weight of the engine and a decrease in thrust of the engine. Meanwhile, decreasing the ISP would mean increase in thrust. Also, this increase should be different for different engines. The OMS would be able to increase its ISP to a lot more than the launcher, and so on. This feature should be limited by the tech level the player is on, ie, if the player is just starting, the hard limit on engine ISP scaling would be a lot lower than what the player would have later in the career.

Scaling an engine beyond a limit or so would mean clusturing of the engines. For example, the upper stage engine would cluster beyond 1.85m and the launcher would cluster beyond 2.5m. This would just be a visual effect.

[blackheart612]

Scaling an engine beyond a limit or so would mean clustering of the engines. For example, the upper stage engine would cluster beyond 1.85m and the launcher would cluster beyond 2.5m. This would just be a visual effect.

This. Is a neat idea. Though I am worried about the sounds/particle effects for it. Disregarding how would you actually cluster engines (because it's pretty much model resizing and model adding)

I dunno if that's possible. Meh, in good hands it is

[bs1110101]

I think the best way to do it would be to let you draw out the combustion chamber and nozzle shape, and then let you pick how it's cooled, what kind of pump it uses, if and how it vectors and if you want to have more then one chamber feeding from the same pump or anything like that. More or less it would be an engine design program that afterwards spits out a model, texture, and stats for the engine to be used in ksp. I think the best way to do it would be to draw the nozzle from cones and pre made pump models.

[EatVacuum]

How does one proceduralize engines?

Okay, I'm not a rocket engineer or one of the many very talented mod designers who may read this and scoff, so take pity on me and please only send constructive criticism. But with that proviso, here's my thoughts on how to proceduralize engines.

First, divide the procedural engine into three parts - the shrouded portion of the rocket engine, the exposed portion of the engine and the nozzle (or bell). By breaking the engine up it is possible to produce a larger number of variations with a smaller number of models. To produce 27 rocket engines could require 27 models if each is made as a unit, and as well, they might not rescale well as bigger engines should look beefier and would require more detail than smaller ones to look good. On the other hand, 3 shrouds, 3 motors and 3 nozzles, a total of nine models, also allows for 27 combinations ( 3x3x3 ), i.e. 27 different rocket motors. I think, again not being an expert or even overly familiar with the code behind the various procedural parts mods, I would think breaking the engine into a couple of simpler parts would also simplify any procedural rescaling of parts.

My reason for breaking them up into shrouded and exposed motor and nozzle rather than some other selection is as follows;

Considerations for the Engine Parts

For most rockets, most of the rocket engine is actually inside a shroud or within the rocket fuselage itself. KSP fuel tank volume seems to be calculated on the complete volume of the fuel tank, not allowing for any noticeable portion of the internal space to be taken up by the rocket engine. So there is no penalty to having a big rocket attached to a tank, and no advantage for a smaller one. Adding a shrouded part seperates out the rocket motor volume from the fuel tank, while at the same time limiting he number of models that have to be made to reflect a large number of potential different rockets. Resizing these mostly cyclindrical or perhaps slightly flared or tapered parts would seem to be well within the capabilities already demonstrated by Stretchy SRBs, and similarly a relatively small number of textures would be required to match stock, KW Rocketry, Nova Pulse, NASA or Soviet styled fuel tanks.

The exposed portion of the engine could be as simple as an adapter plate to allow single or multiple nozzles to be attached. More elaborate models would only be required for engines that have a significant amount of exposed engine components. In rare cases, an engine could be totally exposed in which case the shrouded portion might be foregone and the engine attached directly to the fuel tank. The option for multiple connectors might need to be applied to the shrouded part as well as single or multiple exposed engines might want to be simulated, not just multiple nozzles.

The maximum possible thrust that would be generated by the engine could be calculated based on the volume of the shrouded and/or exposed components as appropriate. The thrust could be modified to be lower for early tech engines and higher for later tech to reflect improved design, miniaturization of parts and better materials science. The size of the nozzle (see below) would be a limiting factor - a given size of nozzle can only handle so much exhaust.

The maximum possible Isp of the engine is defined by the fuel used - no amount of technological advance in the rocket engine can increase the Isp for a chemical rocket, poor design can only reduce the actual Isp below this. KSP however uses a generic liquid fuel plus oxidizer (LFO), so to simulate the less efficient earlier fuels like alcohol or kerosene +LOX (theoretical ISPs of 360s or lower) vs later fuels like Hydrogen+LOX (Isp 450s or so), early technology rockets should have a lower Isp built in. Even if Squad were to implement multiple fuels, or if an add on like Real Fuels is used, it would still be appropriate the reduce the earlier tech engines' Isp's to some degree to reflect less efficient design, however the Isp of the fuel would be the more significant factor. For nuclear thermal, plasma and such like engines, the Isp is defined by the maximum working temperature of the nuclear engine or power plant, the efficiency of heat transfer to the propellant and the molecular or atomic weight of the propellant itself. But again, the power would be proportionate to the volume and tech level.

Considerations for the Nozzle parts

The rocket nozzle is almost always a simple straight or slightly belled cone (ignoring aerospikes for the time being). Generally, the only noticeable elaboration to the bell is whether or not it has a gimbal mechanism at it's base, and likely that it is wrapped in a helical coil of piping that delivers coolant to the bell to prevent it from melting. Resizing the bell, essentially a cone, should be no more complicated than resizing the conical adapters already being done by Stretchy SRBs. The proportion of width to length of the bell will vary depending on whether it is optimized for use under standard sea level atmospheric pressure, in a vacuum or at some pressure level between the two. While this could probably be handled procedurally, it might produce some odd affects for the gimbal or coolant pipes if taken to extremes. Perhaps the gimbal should be moved to the engine portion rather than the bell to prevent this?

The reason why the proportions of the nozzle can vary are because if the bell is too short, it is inefficient because the exhaust gas doesn't have time to expand enough, if it is too long the exhaust jet can separate from the nozzle, which also reduces efficiency. The optimum length of the bell increases as the ambient atmospheric pressure decreases. The consequences of either type of inefficiency is lost thrust and so effectively reduced ISP. You can read more on rocket nozzle theory here if interested --> http://en.wikipedia.org/wiki/Rocket_engine_nozzle. Anyway, because the length of the nozzle can vary significantly, if not handled procedurally then several lengths of nozzle would be required to reflect the different optimizations, perhaps as little as three - a short wide one for the liftoff stage, a longer narrower one for use in space and one in between for those optimized for an intermediate pressure.

The thrust or ISP changes for the engine would need to be reflected with a "pressure curve" not that different that the velocity curves currently reflected in some KSP engines. This curve would have to be created programmatically to reflect the efficiency at various pressures which in turn would be determined by the length of the nozzle. I assume that this would have to be handled by a plugin that could analyze the nozzle measurements being created by the player.

There is one more complication for nozzles - at higher tech levels it should be possible to have nozzles that adapt to maintain optimal length for the ambient air pressure. One method of doing this is to have a nozzle that extends in order to maintain the optimum length as pressure reduces, as has been done in the NK-33. This would be reflected by a more forgiving pressure curve, and it should be reflected in an engine animation, which I think would take it out of the bounds of a procedural engine mod.

Aerospike engines avoid the problem of optimum nozzle length changing as ambient pressure decreases. From what I have seen of aerospike engines, they are visually simple, just a cone (or a wedge for linear aerospikes) narrowing to a point, i.e. the reverse of a normal nozzle which widens. Any coolant piping is on the inside to maintain a clean exhaust flow, so there is little or no detailing required, which should make them very simple to rescale compared to a standard nozzle.

What do you think?