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

[duckhunt]

jsimmons, thanks for this i will check it out. I used realfuels so this will be handy

[K3-Chris]

Does this work with modular fuels? Looks like an interesting mod, if a bit early days, would be nice if it takes off and other mod authors support it or use it in some way, very annoying having x versions of each part of different length, could reduce part-count massively if parts could scale to your needs in a sensible fashion.

[acc]

It would be cool to be able to have a huge bell housing on a standard engine (power, TWR and ISP unchanged), then the Apollo CM could be reproduced without having a skipper in it...

Is this a separate mod or is it a continuation of stretchy tanks?

What I mean is, will my ships that I have built with stretchy tanks need rebuilding? (I`d probably do this but wouldn`t want to)

Can`t wait for the `proc pack` which (in my mind) would be the one stop shop for proc parts in a single mod.

From the first posting:

Deprecation support for StretchySRB - you can continue to use stretchy SRBs for your existing ships, but hide all the tanks so they don't appear in the VAB

[jsimmons]

Since alot of people are worried about their StretchySRB tanks breaking and also I seen people request that ProceduralParts support neither non-procedural rockets. So I have started the work to turn normal rockets to procedural rockets. This is just the start but you can see a preview of what is coming at http://www.infradead.org/~jsimmons/GooeyParts.zip

[CatastrophicFailure]

Forgive me if this has been mentioned already... But the SRB's don't seem to work with deadly reentry... The temp bounces around right near max for a while then finally explodes from overheating. Even tweaking max temp to a ridiculously high number in the cfg doesn't seem to help.

Oh and long as I'm here +1 for procedural heat shields and how about toroidal tanks too?

[OtherBarry]

Forgive me if this has been mentioned already... But the SRB's don't seem to work with deadly reentry... The temp bounces around right near max for a while then finally explodes from overheating. Even tweaking max temp to a ridiculously high number in the cfg doesn't seem to help.

There's an issue about this on the GitHub page, so essentially heat production scales with thrust and size in about the same way the stock SRB's do. I personally don't like this because if you go much larger than stock ones it will just explode. I don't have access to KSP at the moment, but I think you can change the heat output in one of the proceduralpart modules in the SRB cfg file.

[John FX]

I`ve read the OP and I still have the same question so I will rephrase it,

What should a person do who has been using Stretchy tanks (not stretchy SRB) if they want to now use this mod?

[swamp_ig]

Yeh you can change this in the config file pretty easily, there's a constant there called heatPerThrust, the value of which is better than RT-10 but worse than the BACC.

I'm happy to implement some other heat / thrust relationship if someone can suggest something realistic. Physically speaking thrust is proportional to reaction or burn rate, and if you burn more stuff you produce more heat. I guess that doesn't take into account the rate of heat radiation, which is proportional to temperature^4, so as temps get higher the heat loss goes up rapidly, but that isn't really managed well with KSP. Of note in stock the heat per thrust drops off with SRB size, from ridiculously high for the sepatron, through the RT-10, and lowest for the BACC.

[swamp_ig]

I`ve read the OP and I still have the same question so I will rephrase it,

What should a person do who has been using Stretchy tanks (not stretchy SRB) if they want to now use this mod?

You don't need to do anything in particular, you can use ST or StSRB and PP alongside if you want to. If you don't want all those old tanks hanging around in the VAB, but have some on your in-flight rockets, then hide the tanks by changing their category in the VAB to -1, or if you aren't using them any more then delete them.

[John FX]

You don't need to do anything in particular, you can use ST or StSRB and PP alongside if you want to. If you don't want all those old tanks hanging around in the VAB, but have some on your in-flight rockets, then hide the tanks by changing their category in the VAB to -1, or if you aren't using them any more then delete them.

I`ve used my google-fu and discovered that stretchy tanks had been discontinued and stretchy SRB and by implication proc parts(Which I was under the wrong impression was just a stretchy tanks addon) is the new stretchy tanks.

So I would need to rebuild my craft with the new tanks and keep the old mod for craft in flight (which should not cause issues), yes?

when you say "hide the tanks by changing their category in the VAB to -1" would that be in their cfg file? (this seems like the best way forward)

This looks very good. I will probably use both mods for a while but only do new builds with proc parts and adapt old builds over time.

[blackheart612]

If I understood what you said and what the mod says, you should be able to keep your old crafts because it will keep the models of your old craft's stretchies but it will not be anywhere in the tabs.

[jsimmons]

Swamp Ig the way you handle resources under TANK_TYPE_OPTION does not work with ModuleManager. I get the following error

[ModuleManager] A node has an empty name. Skipping it.

The double braces cause the confusion.

resouce

{

{

....

}

{

....

}

}

[John FX]

If I understood what you said and what the mod says, you should be able to keep your old crafts because it will keep the models of your old craft's stretchies but it will not be anywhere in the tabs.

That would be very cool. I`ll copy my persistence file and try it out.

[swamp_ig]

That would be very cool. I`ll copy my persistence file and try it out.

I'll make this an FAQ in the OP

[swamp_ig]

Swamp Ig the way you handle resources under TANK_TYPE_OPTION does not work with ModuleManager. I get the following error

[ModuleManager] A node has an empty name. Skipping it.

Does it work if you put in a dummy name field? I can easy change both layers of config to have name= instead of what they have currently.

[K3-Chris]

Btw could we get more shapes than circular? triangular, square, penta, hexa, etc, set the number of faces 3+, would also be nice to have the choice of picking the end-cap textures, and the foil looking ones should have end-caps with the same texture as the rest of the tank.

[OtherBarry]

Btw could we get more shapes than circular? triangular, square, penta, hexa, etc, set the number of faces 3+, would also be nice to have the choice of picking the end-cap textures, and the foil looking ones should have end-caps with the same texture as the rest of the tank.

Structural trusses are somewhere in the development line, after fixing the current structural part, and probably after full RF/MFT integration. I assume changing the number of faces on a truss wouldn't be too hard to implement.

Choosing end-cap textures would be cool, but probably fairly low in importance. In the meantime you can just make a cone with 0.01 thickness and 0.01 top diameter to make it look the right texture.

[K3-Chris]

Could we get non-circular tanks as well?

[OtherBarry]

I assume so. No idea how easy this is, as swamp_ig and NathanKell do most of the coding, I just help out. Once the procedural trusses are working, it should be fairly simple to apply the same shapes to a tank but it depends how easy procedural trusses are to code on the first place. Not entirely sure if thats the direction the mod is heading though, as I think its branching out into different types of procedural parts; trusses and heat shields and such.

[swamp_ig]

I do the coding, and I am planning on doing other shapes. See OP

It actually won't be all that hard to do the shape bit, it's more figuring out how to manage the texture aspect of it. The current shapes are all volumes of revolution, go look at wikipedia if you don't know what that means. The next set of shapes will be extruded shapes, which includes cubes / hexes. The coding of the geometry will take a bit of effort, but it should be ultimately straightforward.

The main issue I've been thinking about really is how to manage textures. I've had a few ideas - lets discuss the proposals:

1. Choosing textures for each 'bit' of the part - eg the sides, the ends, and then other added bits like the SRB cones. This does have its pros, but an issue would be that you'd end up with lots of options to go through. Also some of the combinations would be.. odd. This would also break compatibility with existing texture packs for stretchy SRBs. The other issue would be that if you've got a hex-sided pod for example, do you choose textures for each side individually? or what? I feel that really that level of fine detailed painting is best left to a separate mod like Kerb Paint (Not that I've actually used it, but anyhow)

2. The option I'm liking at the moment is to stay with the 'texture set' scheme of things. Each bit of the part gets some identifier - like end.top and end.bottom for the ends, side for the sides (or even side.cyl for cylinders, and say side.bottom, side.top for aircraft parts), srb for the srb nozzle, ect. In the config file you have a defined name and properties for definitions for each of the available textures (is it stretched, tiled, or a circle map like the ends, ect), and then another config file that builds texture sets from those textures - eg it might map both end.top and end.bottom to one texture, and side.cyl to something else.

If you really want to go and mix and match you can then just create your own mapping definition in a text editor and apply it to your model. You could even (if you got keen) create an GUI within the game to mix then and save as a preset.

Anyhow, this is all in the future

Edit: Have created an issue to track this here: https://github.com/Swamp-Ig/ProceduralParts/issues/14

Edited March 17, 2014 by swamp_ig

[swamp_ig]

Incidentally, due to popular demand I am thinking of how to implement procedural engines. I think something good can come up.

[likke_A_boss]

Oh, Theeeeen procedural ladders?

[blackheart612]

Procedural Engine Cluster :3

[jsimmons]

Thanks swamp ig for implementing the stack decouplers. Created a prodecural SAS configuration. You can get it at http://www.infradead.org/~jsimmons/SAS.cfg. Unlike the decouplers when you go to implement the SASTweaker class please don't limit the possible shapes. The SASTweaker class would be the base class for probes and command pods. As for tweakables we have three values for its torque (PitchTorque, YawTorque, RollTorque) which appear to always to be equal but it would be a nice option that users could make them not equal. Much like decouplers we can vary the maxTorque values based on the new shape of the object. Looking at NOVA punch SAS it appears if you double the size of the SAS the torque also doubles. Don't know what the formula would be for real life.The other thing influenced by the torque values is the electric charge. It makes sense that if the torque is doubled that the electric charge usage also would double.

[swamp_ig]

The decoupler tweaker class doesn't limit the shapes itself. It does determine the maximum decoupling force based on the area of the top of the part - I felt this was the most appropriate and it fitted with existing parts more or less. Given this, changing the length of decouplers didn't make a lot of sense since it would result in increased mass without any function, which is never desirable in a rocket. Altogether this leads to limited shapes for decouplers.

There's no reason why you can't use the decoupler tweaker class and apply it to some other part, it will still determine the max decouple force based on the node it's attached to, but the other parts of the shape are free to do whatever they want.

The mechanical part for SAS modules are flywheels, which (obviously) can get larger and more massive the more volume that is available. In which case both the max torque (as in the sum across all axies) is proportional to the volume, mass should go up proportional to the actual torque (if it was tweaked back for instance). Given this, shape limiting makes less sense. The resource use will obviously need to be directly proportional to the maximum available torque.

I might well have my physics wrong on this one, but I don't know that independent torques will work. For a long ship, intuitively it would seem that the roll axis would require less torque than the pitch and yaw axies - since there's going to be less angular momentum in the roll axis. The problem arises is that say your ship starts tumbling out of control end-to-end. Because of the way gyroscopic forces work, applying a torque to slow the tumble will result in the roll of the ship increasing, and since you have less torque available in the roll axis then you've got no way to push against this and correct it. You either have to decrease the pitch torque, or deal with the excessive roll. I guess it's possible that this is counterbalanced by the decreased angular momentum in that axis.. as I said I'm not so sure of the physics, maybe someone can correct me.

Anyhow I have created an issue for further discussion here: https://github.com/Swamp-Ig/ProceduralParts/issues/15

Edited March 18, 2014 by swamp_ig