swamp_ig

Yes that is true. I guess you could go forth and delete a pile of tanks and suchlike. So the things we can happily delete: Tanks - really for those containing stock resources. 1:1 Part adapters - these can be replaced by structural tweakables Nose cones - as above Stack Decouplers / Separators - new stack decoupler part now available Again, you could do that with a module manager config file really. That way if you want to install a new version of whatever mod, you don't have to go through removing things again. Feel free to create a few module manager configs to do those things if you like, I'll make them available in a zip file much like StretchySRBDeprecated.zip. Come to think of it really the contents of StretchySRBDeprecated would be best done as a module manager. Anyhow, got another job I can PM you about if you're keen.

I'm fine with people doing whatever they want with my code. However, for the sake of avoiding fragmentation, it's generally best to contribute rather than fork, and for the same reason it's better if one person keeps control of a project or it tends towards cruftification. Thanks to the work of jsimmonds, Decouplers are implemented and will be in the next release. Shouldn't be too hard. It's pretty well documented. You can hide parts in the VAB by setting the category in the config file to -1, you can do this pretty easily with module manager. The advantage of part hiding (rather than removing) is that existing ships with those parts don't disappear from your saves. It's really the part count on the ship you're flying that makes any difference to performance. Having parts just sitting around in the VAB makes no difference. It wouldn't really be up to me to decide what parts people won't want to use any more. Procedural parts currently replaces all the stock tanks, but the detail level is lower and probably will remain so. The stock tanks will remain more pretty, so you might never use that.

The good news: Bezier cones are implemented and working well With the exception of what's commented below, all the above reported bugs are fixed. I will release a new version quite soon (in the next day or two) The bad news: I haven't been able to track down why the rockets go unstable soon after launch. I think it's because the links between the parts need to be updated. Will have to look into this. I have a feeling StretchySRBs might have had the same issue.

That's fixed.

I think having a dedicated set of configs for real fuels would be the way to go.

Fixed. I think I might have already known that... or something TankContentSwitcher will also listen for the same message. I know how to do a shroud. (for the SRB nozzle you mean?). Haven't done it at this stage however, since I don't see it as being hugely important since SRBs are most commonly used for launch, so there's no stack attachments behind them. There's a module for it that you can add in and you point it at some meshes for the part(s) of the shroud.

So another constant that can be ignored. For SRBs since there's a constant burn rate, then there's a constant pressure. This should also hold for liquid rockets one would expect, assuming you want max efficiency at max thrust. I guess the upshot is it collapses to scale proportional to sqrt(thrust). Which does make a lot of sense physically since the area of both the throat, and the end of the bell (vent?) are proportional to the square of the scale, and you'd want a constant thrust per unit area to push against so to speak. So ultimately, a nozzle designed for a constant fuel mix and best efficiency altitude will still scale only with sqrt(thrust). Unless you got some better ideas, I'll code it up like this.

We'd have to wait until costs are integrated into stock. I imagine there'd be some kind of formula - some polynomial with surface area and volume as terms. It's all a bit moot until stock KSP integrates costs anyhow.

I guess all the constants in the formula can be neglected, since at the end of the day you have to have something that looks right - just tweak it until it looks equivalent to stock. The proportionality is important of course. So: A* = k . m / t / Pa (m = Fuel Mass, t = burn time, Pa = atmosphere pressure, k = constant) Substituting in A* = 1/4 * pi * d^2 (d= Tank Base diameter/2) and folding everything back into the proportionality constant: d > k . sqrt( m/(t*Pa) ) What about the length and end of the bell of the nozzle? Does that just stay proportional to the throat diameter?

jsimmonds: Great work! Real fuels: I've actually discussed this with Nathan at some stage, real fuels needs to listen for the same message that TankContentSwitcher listens for: UpdateTankVolume(float tankVolume) (This really needs to be renamed to UpdatePartVolume, it's a holdover from when it was just a tank) I'm not sure if RF updates the dry mass of the tank either, in which case TCS will need to detect RF and not fiddle with the fuels, rather than just remove the module completely. I'll work properly on RF integration once I complete bezier cones. That way there's full feature parity with StretchySRBs Decouplers: Awesome, I hadn't thought of that. The config is really a piece of cake too. Might be worth having a special shape for decouplers, since really the only thing you'd want to tweak would be the diameter I'd expect. Probably the easiest way would be to subclass pill shape, hide the editors for length and fillet, and make them dependent on diameter (say length = diameter /10, fillet = 2 * diameter / 10) Texture maps: This is definitely on my radar. The current texture system won't work too well when I introduce extruded shapes. I've put quite a bit of thought into the best way to handle it, haven't quite come up with a good general solution just yet but not too far away... Cubes, hexagons and octagons (as well as Mk2 and Mk3 bodies): They're really going to be next. I've actually figured out a way to reuse much of the code I've already coded up for surfaces of revolution. Gotta finish beziers first tho.

Done already: http://forum.kerbalspaceprogram.com/threads/70676

Should be, I don't use RF however, can you try it out and let me know?

See thread main message - new release 0.6.0. Now with pill-shaped parts. I'm thinking this is pretty much ready for generalized release, rather than be in development status. Having Bezier cones would be ideal prior to general release really, just to be feature complete with StretchySRBs.

Bazz: yep, planned. Easy doable with some config tweaking

Sounds very well thought out. Im not sure I'd be interested in coding it up. Just feels a bit cheaty to me. Of course that's a personal preference, but tanks seem like they require only a bit of engineering to tweak their size, even command pods aren't that ultimately different if one tweaks the size. However,Having done some fluid dynamics in one of my Past jobs, tweaking engines just aint that simple. Having said all that I'd be more than happy to support someone who is willing to do the coding

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.

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!

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 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! 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.

Thanks guys. That's three, that will do for now. Will create a dev thread...

Hi everyone. I'm very near releasing a big upgrade to stretchy tanks. The features are: - Everything accessible by tweaking - Reduced part count - only three different parts (SRBs, Liquid fuels, Monoprop) - New tank 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 - A module 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). - For SRBs, tweakable bells that are high or low ratio. - 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 It's almost a complete re-write of the code. I've done a fair amount of testing but I expect there'll be a few extra bugs that I haven't found. Given this I'd be interested in people who would be keen on beta-testing. If I can get maybe four or so ppl that would be ideal.

Might be a bit faster to add a new game object in unity, and then tweak the location until it is right. The node coords are in the local space of the part (which might not be the same as the model if there is rotation and scaling involved)

Ok the merge request is done. Some things that might be worth mentioning in the SimplePartModule docs for life cycle: 1. All the OnXXX messages are sent from the corresponding unity message to the parent Part. The exception to this is OnActive for which I haven't traced fully where it comes from. These get called in the same order as the modules are defined in the config file. 2. When you're attaching a part with symmetry, the part *in its current state* is run through Object.Instantiate. If you modify any data in a custom class field then unless you have reserialized it for reloading in OnAwake any tweaks will be lost. Then OnActivate->OnStart (don't know if OnSave is called, probably). 3. If you want to do anything dynamic in the VAB, you need to implement Update directly, rather than getting it through the part. This is called in no particular order.

Is that what it is? Weird really since the original DLLs have nothing to do with unity really. I guess the thing is there's three different persistence mechanisms going on here: 1. Unity serialization. This uses Serializable and SerializableField attributes. This is needed to clone objects (ie: Object.Instantiate). There's a good blog post about it here: http://blogs.unity3d.com/2012/10/25/unity-serialization/ but suffice to say it doesn't seem to work for classes compiled into a DLL. Maybe there's some way of getting unity to produce some kind of asset or something to make it work, I got narked with the whole thing in the end. 2. ConfigNode stuff. This is actually pretty well developed and seems to cover most cases. This uses the Persistent and PersistentLinkable attributes. I haven't actually investigated PersistentLinkable much, but it looks like you can persist references with that. 3. KSPField attributes. These do actually work for classes, but not for arrays or lists of things which is an annoyance. You can write your own deserializer for lists of things in the OnLoad function. I don't think it works with references either. Not sure why they didn't just use the config node code as a basis for this, but *shrug* So everything loads and saves to config files fine, but anything you set up there into your own classes won't persist across Object.Instantiate, which pretty much defeats the whole purpose. I imagine if you bashed your head against unity serialization for long enough you might figure it out, but I've given up on that approach. Fortunately if you somehow store anything loaded from the part config file at the end of the OnLoad as a member, and then reinitialize it in OnAwake, then you get around the issue of Object.Instantiate not copying stuff properly. You could probably get away with storing the ConfigNode as a member marked with SerializeField actually, but I figured why not just add yet another serialization mechanism and used the standard c# way. Will do a git merge request shortly...

Here it is: void SomeFunction() { UIPartActionWindow window = FindWindow(); window.displayDirty = true; } private FieldInfo windowListField; private UIPartActionWindow FindWindow() { // We need to do quite a bit of ****-farting about with reflection to // dig the thing out. UIPartActionController controller = UIPartActionController.Instance; if(windowListField == null) { Type cntrType = typeof(UIPartActionController); foreach (FieldInfo info in cntrType.GetFields(BindingFlags.Instance | BindingFlags.NonPublic)) { if (info.FieldType == typeof(List<UIPartActionWindow>)) { windowListField = info; goto foundField; } } Debug.LogWarning("*TCS* Unable to find UIPartActionWindow list"); return null; } foundField: foreach (UIPartActionWindow window in (List<UIPartActionWindow>)windowListField.GetValue(controller)) if (window.part == part) return window; return null; }