OtherBarry

If you don't mind hours and hours of work, then sure, probably, but why not just deprecate Stretchy Tanks parts? It's not like either mod takes up a lot of space.

Thanks for the offer Northstar. As NK said, I've already started working on it, and while I quite like your ideas on how it ought to be done, a core part of this mod is to keep it as close to stock as possible, which unfortunately means slightly less consistency, but gives the mod a more balanced feel with the game. For example, Standard fuel tanks (LF+Ox) have their priced based off Cost = 2*(LF units + Ox units), while plane fuselages use Cost = Mass*800. Depending on how cost gets implemented, it would be good to develop your ideas further once the realism mods (RSS/RO) get proper support of career mode.

I'll have to check the cfg's again, but somewhere in the heatshield cfg file is a line something like 'Allow Curve Tweaking = false' by either deleting this or making it 'true' you should be able to use the range of shapes available to other tanks, though it may also allow things like cylindrical or pill shaped heat shields, which might cause issues.

This sort of mod is precisely why that new partCost coding came in. When the all mighty NK has time free from his life and other mods, he plan's on adding cost scaling functionality amongst other things for a more final 0.24(.1) release of PP.

Not for a fair while, if at all. Requires a fair bit of coding to get non circular shapes in. Try TweakScale maybe? Personally, I feel like the stock game covers radial decouplers pretty well. If you need more force, just add seperatrons. That's what they were made for after all.

Nope. You can thank e-dog (Procedural Fairings dev) for that. He added and updated several textures, as well as adding shininess and bump maps to a few.

StretchySRB should work with 0.24. You can use that until this is updated.

It does suck, especially for RSS/RO players. I'm somewhat surprised no one over here mentioned lack of 64 bit compatibility when the hack came out.

As much as I would like too, by keeping the mod running I just meant answering questions and whatnot on the forums. Coding is not my area of expertise (though I am learning at the moment). Thankfully, NathanKell has volunteered to keep Procedural Parts alive until swamp gets back. And taniwha is also maintaining KSPApiExtensions (KAE for those of you who like three letter acronyms), as both this mod and several others rely on it.

They look great! Thanks! If your not already using them, have a look through the recent github commits, where'll you'll find a few new texture related features, such as proper bump maps and shininess. I'll see if I can get Swamp_Ig to update the OP with a link to your textures.

Nope and Nope. If your good at texturing/coding, feel free to have a try at implementing it yourself. Swamp_Ig is on leave for a while, so I'm just keeping the mod running until he gets back. Hopefully then we'll get some new features, and proper cost scaling for when 0.24 comes out.

Forgot about these. They're fantastic, especially when combined with procedural interstage fairings. On the AIES note, if you don't want the added weight of the thrust plate (they're really heavy), the smaller AIES engines will all radially attach to the bottom of tanks, which is great for smaller probes and landers.

Try TweakScale. Procedural engines are very complex to make, as well as very hard to balance. Or you could do what I do and use some part clipping and an upside-down conical tank to hide the top part of the engine so that only the nozzle sticks out. Works well for covering up gaps as well as keeping a consistent texture.

Try a fresh install, without using mod manager, as it could be installation related. Otherwise it might be related to them using or you using real fuels, as different tanks are and aren't accessible depending on if RF is installed. Also great robot work. Hopefully procedural parts will allow you to make even more awesome looking robots.

The docking module isn't something i've ever really looked at, but from what I gather, it's related to attachment node size being the same, which would theoretically already work with the current PP setup. Not saying it won't happen, but what would you need procedural docking ports for? I've never really felt limited with the stock ones.... Also, I remember you looking into this earlier, but can't remember where, so what is it that complicates SAS scaling? Edit: Looking into it, it's seems to just be just making sure that nodeType = size<x> are the same on both ports. This is a tad more complex, but still doable (eventually), assuming it works with decimal places and the like. TweakScale might work better for this sort of thing, as docking ports wouldn't look great using the current shapes.

It'd be pretty easy to make one, but you'd be limited to a set torque and power consumption. Just copy the structural element cfg file and add the sas module lines to it.

Meh, up to you. As you have now seen, If people aren't going to learn from the first post, they're probably not going to learn from yours. Nonetheless, thanks for the clear and concise bug report. It's a lot more helpful than people just complaining about things not working/exploding/whatever.

Not yet. From what I understand, that requires extruded shapes, which most likely won't be made possible for a few months. You can kind of cheat one by radially attaching a long conic tank and then clipping some parts to give it a flat base.

It depends. Is whatever it uses for radiating a resource or it's own module? If it's a resource, then it's ridiculously easy, you just have to work out the volume (or mass) to units ratio. If it's a module, then it depends. If it's just something like "radiationLevel = x" and x scales somewhat simply, then it's relatively doable. If it's anything more complex then that, it's probably possible, but might not happen any time soon.

Theres been at least 3 releases since may 19, so try the latest version and see if the issue persists. It's popped up a fair few times, so it may be a conflict of some kind if it's not fixed after updating.

Module Manager has backwards compatibility for pretty much everything, so unless your mods use pre 1.5 module manager, it should be fine

Unfortunately, that's just the laws of physics. The thrust of an SRB, or more correctly the exhaust velocity, is controlled almost entirely by the diameter of the smallest part of the nozzle. The relationship between them has a power of two in it somewhere, while mass is a power of three, as it's directly related to volume. This means that means that keeping to the same diameter/height ratio will result in the mass rather quickly eclipsing the thrust as you increase the size.

Right. Well, all the maths is legit, everything's scaling as it should. I think the problem is you want more thrust per meter of diameter than PP currently allows. This is because PP is designed to replicate stock parts, not real rockets. You can change this in the cfg file if you wish, but it won't go into the full release of the mod. The weird nozzle spawning is a known bug, an being worked on at the moment. It might be fixed in the latest version, though obviously not if your using it now.

Huh. Install MechJeb or KER and have a look at the TWRs of the boosters. See if they're consistent between editor mode and flight mode, and see if they seem to scale properly as you change the size/thrust of your booster. "MUCH faster" isn't the most accurate form measurement.

Well firstly, If your not using the realism patch then it's not surprising that you can't make realistic rockets. Secondly, it's weighs 8 times more (2*2*2 = 8), which means you probably should have a twr of not that much more than one. Also, the space shuttle SRB has a height/width ratio of 12.1, while your smaller booster has a height to weight ratio of 8, so they're pretty different.