swamp_ig

Fusty was working on this, not sure how it's going, haven't heard in a while. In answer - probably not too hard. The tricky part would be the IVA and getting that to scale sensibly. If you didn't care about the IVA, then probably pretty easy. I haven't actually looked into it much.

I'm a bit of a maths nerd, but I always find the geometry and calculus the most fun to work out. I saw your quadrilateral diagram, just wasn't quite sure how that corresponded to a 3D structure. There's a whole family of different hexahedrons http://en.wikipedia.org/wiki/Hexahedron . You might want to consider extending ProceduralAbstract shape directly, rather than SoR because that's really for surfaces of revolution. The downside to this is you'll need to do all the shape building plus implement AddAttachement, which requires a lot of thought to get it right (there's other 1000 LoC in AbstractSOR, it took me ages to write and perfect). If you want to proceed with this I can let you know how it works in a PM. Edit: If what you want is an extrude, might be worth waiting until I do the abstract base class for extrudes. Don't ask if you can do that for me however, cos I wouldn't give that up for anything

So you're having this an an extruded shape - like having a constant profile quad taken along a length? I'm going to handle generalized extrudes not too far in the future. Then you can specify whatever shape you like.

Not easily - the issue is one of tank density - since KSP resource densities (which are mass per unit of resource) have very little to do with real-world density (mass per unit volume, where one unit of volume == one unit of resource), the only way to figure out density is to get a part of a similar size to an existing part and calculate it by hand. Once you've done that however it's pretty easy just to code up a part to handle the resource, which is exactly what Eggman has done for some common mods.

Anything built with the current version will *not* work in the next version (at least not without a bit of save file editing), so might be worth holding out for a bit. A bit will not be much longer. Got the issue fixed but I have another feature in progress which isn't releasable yet.

To clarify: Use the latest version of real fuels (v5.1) Install ProceduralParts.xxx.zip Install ProceduralParts.RealFuelsSupport.xxx.zip That's it. You don't need to delete things or anything. There's a module manager file in RF support which will hide the other tanks. If you really want to save every bit of memory, you can delete the Tanks subfolder in Parts if you want. This probably won't make much of a difference in total memory use in the grand scheme of things.

Oh yeh, can do that easy enough Edit: This wouldn't really fit with the stock configuration as they all have the same 'utilization' in any case. Certainly with the RF part it's an option

I will have to double check, but I think the new DLL will have the updates in it as required, so you don't need to worry about my version.

Will have a look into this. Might well be already fixed in the dev version.

You can mimic utilization by scaling the unitsPerT or unitsPerKL in the config file by whatever factor you like. The aim is to mimic stock, which is what the current settings do. Otherwise you're making the PP tanks worse than stock For the real fuels tanks, there is a config value for utilization as part of the TankContentSwitcherRealFuels, you can tweak that if you want to.

Just put it there for the future. At the moment it won't work of course This is true for most, but not for the oscar-B or the toroidal - they have a poorer payload fraction. The fuel per volume is more variable, but that's less of a big deal. The RCS tanks are all over the place, and the liquid fuel tanks (as in fuselage) only give you a slight advantage over a mixed tank which is drained of ox. Have a look at this spreadsheet for details: https://github.com/Swamp-Ig/ProceduralParts/blob/master/Source/StockParts.xlsx

The liquid tanks for example have a 9:3 ratio (or something like that) between liquid:ox when full. For your TAC tanks you might want to have different ratios of one resource to another - like waste to o2 or something... don't know. Why don't you add a flag forceEmpty=true in the RESOURCE config part. I'll make sure the next version honours this in the VAB.

You're basically talking about a torus section. Not planning on making a torus part at this stage - the use case is too narrow. I might consider this at some stage, but there's bigger fish to fry

If you make a wider bottomed SRB, then you can have more thrust. (The limit is there to stop the bell being bigger than the base) If you're really keen you can fiddle with the config file - find the thrustScaleFactor and change it to a bigger number. That way the bell will be smaller for the same thrust. The other thing you could fiddle with is bellChokeDiameter. This is set to 50% of the real value so the bell is max half the diameter of the base. If you double it you can get four times more thrust as the thrust / scaling has a sqrt scale factor. Be aware you may get overheats and explosions with too much thrust per mass of tank.

I think one. The main reason why I have separate tanks is to allow for tech dependent limits - for example fuel tanks are generally a lot larger than RCS tanks. Since this doesn't apply, then leave it all as one tank. You might want to default to a different texture set for life support tanks, but the texture shouldn't be tied to the tank type. As you said, you can have combo tanks, but you can't alter the ratios between the sub-tanks. I could have alterable ratios as a feature in the future I guess. You're really getting into real fuels territory with that They don't do this with stock either! Sometimes the fuel / dry mass ratio works better than the fuel / volume ratio. You can use either (or even both) in the config file. I deliberately haven't implemented non-linear scaling - this would mean that it would be more mass effective to have a bunch of small tanks that add up to a large one if you get what I mean.

This does sound like a cool idea. You'd have to limit the spoke / ring count for the size / length of the cylinder. The other issue would be what to do with stuff that's already attached when you change the attachment count. Easiest way to get around that would be to lock the options once anything is attached. Will add this to the tracker.

Looks like joints are changed in the new version, will take a look at this and see what the go is.

Probably better proportional to the volume or dry mass (which amounts to the same thing). You could argue surface area too (which you could also do for mass, but in stock it's more more proportional to volume so I made it that way). The only issue is - when do you incur the cost with the economy mods, is it on launching? Because if it's on buying the part that is going to have obvious issues . If you would like to give me reasonable constants of proportionality, I'd be more than happy to put this into the next release. The first step would be to have a look at this spreadsheet: https://github.com/Swamp-Ig/ProceduralParts/blob/master/Source/StockParts.xlsx and fill in a column for cost for all the parts. If you're keen raise an issue: https://github.com/Swamp-Ig/ProceduralParts/issues and give me the numbers.

Great! cool. Will get back to you after this weekend.

Hmm... Might rethink something I've done there with regards to breaking saves. Problem is that to undo it will break saves again Don't build anything until the next version is out that you want to keep!

You might find some save games work, but no promises. There's no easy way around that unfortunately - the part mass issue needs at least a relaunch to fix. I guess this is the thing with 'beta' software It's deliberate that you can't make the bottom smaller than the top on cones. It solves some aesthetic and functional issues which I won't delve into here. You can always turn the cone upside-down if you need to.

This issue is now fixed, see first post to download.

Ok, first post updated. Enjoy, am going camping for the weekend

OK haven't updated the first post yet, but here it is: https://github.com/Swamp-Ig/ProceduralParts/releases/tag/0.8.0 I suspect there may be some munging of the configs of the SRBs for Real Fuels, I don't really use it so I've just taken a guess at how it should work.

Yeh tis all working. Just been trying to get RF working nicely. It's going now, so just a bit of config tweaking for balance and hopefully will release when I get home from work today.