swamp_ig

Of course, but what this mod gives you is tech level control over what sizes are available. Essentially you only get small variations of the stock parts at the same level of tech.

Totally Cool

Real Fuels is working - in my developer version I will need to update RealFuels a little bit for it to work to my satisfaction, but it's pretty good at the moment. That was part of the side-track

Quick update: I had planned to release the next version over the weekend, but have been side-tracked. It's not too far away.

The mod is tech dependent (that being one of the major goals of the project). You can strip out the tech dependencies by removing those sections from the config files however.

Real Fuels compatibility is not far away. pWings and pFaring - no. Not unless the authors of those mods want to integrate.

Maybe one day, but not in the near future.

I'll do the update in the near future - today or tomorrow most likely. Just got to do a bit of debugging on something else - it's more effort than it's worth to release a partial update. The issue was that KSP was wiping the updated mass on going into flight mode. I had actually had that fixed in the past but for some reason removed the code In the mean time you can keep building ships, but they'll need to be saved in the VAB prior to going to flight mode as the dry mass will get reset to 1 for all parts.

Found and fixed the problem

I'll look into it.

It's possible mech jeb isn't aware of the updated dry mass. Try building with just a tank, then using the tweaker to empty it dry. Compare mech jeb to what the tweaker says it is. Try increasing the size of the tank but leaving it dry - does mech jeb's total mass change? A possible solution might be to disconnect and reconnect the tank to the parent part. If you can post your findings here: https://github.com/Swamp-Ig/ProceduralParts/issues that would be helpful

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

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

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

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.

I'll make this an FAQ in the OP

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.

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.

This is being worked on. The main issue with crew cabins is the IVA, which would need to be rescaled. Procedural probe cores aren't too difficult, but will think about them later.

Ok, another bugfix release - 0.7.4 - is out.

Hmm... not something I personally like, but I can make the DecouplerTweaker module compatible with doing this if you want and you can roll your own configs.

Ok just released 0.7.3 - solved the tumbling issue. Next target is full integration with RF

There were a couple of bugs in 0.7.0, now up to 0.7.2 released.

New release is out See OP for details. I think RF should be working now, but will work with NathanKell to do something official for configs.

Good idea, will get that going for the next release.