RadarManFromTheMoon

Nah, shouldn't be a problem. You can use a mac compatible IDE like MonoDevelop.

You can find the sources here Any experience with programming/C#? I'm asking because seemingly you don't know how to compile the sourcecode. Seriously, its not a trivial task if you don't know what you are doing.

Please be a little more specific, what exactly do you want to do? You can change the length of the decoupler in its config file. Don't forget to also change the min and maxDiameter. Otherwise you will get problems in career and science mode.

I'm glad you like it! Unfortunately, I haven't done any texturing myself yet. All the textures where already there when I started to maintain the mod. Have you tried asking MainSailor? Maybe he knows whats wrong. Nope, I'm working on something else at the time. (More on that later) But its definitely on the todo-list. Like on this one? Not really planned, but I like the idea. Maybe in the not so near future.

Hi FreeThinker, I think you will need to include KSPAPIExtensions to make this work properly. If you don't want to do that, you could alternatively provide a function like "VolumeChanged(float)" that PP can find and call via reflection or Unitys own Message system. ProceduralParts generally uses m³ for volume (in code often refered to as kL). The volume name is something KSPAPIExtensions comes with. I think its meant to provide the possibility to differentiate between different types of volume a part can have. For example a part can contain a 1m³ fuel tank and a 3m³ habitat at the same time. PP usually just sends "tankage" as volume name and the volume of the whole tanks shape in m³.

Decouplers do not have fairings. Engines add fairings when something is attached to their bottom. Would be nice to customize these, indeed. But thats beyond the scope of this mod.

Thanks for the heads up. I'm on it.

This is a minor hotfix for DRE compatibility. Change log compatibility with DRE 7.1.0 heat shield mass now scales correctly with size download

PP comes with it's own FuelSwitch. Its generally no problem to use an alternative (like RealFuels) instead. But PP must be able to send a message when the volume of a tank has changed (it normally does this via the KSPAPIExtension part message service). So it's not so much a matter of PP supporting InterstellarFuelSwitch, but more about IFS supporting a way to tell it about a change in volume.

I don't know. Is it just about adding a new resource, or what exactly would be necessary? Yep, definitely not good. I've seen this bug a couple of times and it seems to be around a while now but I always failed to reproduce it.

Changelog Collider meshes now include the parts end caps (needed for FAR support) Fixed weirdness caused by choosing a part diameter of 0 Ore Tank can now jettison its content Fixed a bug that caused heat shields to have wrong mass in flight Procedural heat shields now automatically get a fairing when something gets attached to its bottom. As always, you can get it from the github repository

It works pretty much like the stock heatshield fairings. They go from the heat shields top to the bottom node. The tweakable is for the thickness of the fairing ring. Yemo: Thanks, I will do some more tests tomorrow. edit: Tested it and seriously, I'm really running out of ideas. For me, the whole TweakScale thing works like a charm. Can you please see if you can reliably reproduce the bug and then tell me exactly what you did? And when I say exactly, I mean literally everything. Explain it like I'm five and have never heard of KSP in my entire life. The whole thing is like a phantom to me. Also: Are you running KSP on linux? 64 bit?

Click here for a little sneak peek. What do you think? It's still not perfect. But much better isn't it?

Here is the github issue. If someone else encounters the bug and knows how to reproduce it. Please let me know. Regarding the dev builds in the github repository: I don't think that is a good idea. Dev builds are for developers and developers are able to compile the code themself. Everyone else should not mess around with unstable stuff.

I see. Thanks for the report and elaboration. It will be fixed with the next release.

Lets see what the future brings Can you give me precise reproduction steps? It seems to work for me. Normally yes. However there is a bug causing FAR to not voxelize PParts correctly. Will most probably be fixed in the next release. I don't think welding procedural parts is a good idea and I'm actually not much inclined to officially support it in the future. PP is complicated enough already. 1) Not sure what you mean. What exactly is wrong with the heatshield? Can you give me reproduction steps? 2) I will look into the RCS-tank tech restrictions and see what can be improved. At the moment all restrictions get nullified with meta-materials. I agree. I'll put it on the list.

It's true. The collider PP generates, does not include the "end caps". I'm working on it and hopefully can provide a fix soon.

Thats odd... No idea whats possibly wrong there. Normally the curve should be switchable if allowCurveTweaking is set. I will get back to you when a solution comes to my mind. Sounds like a missing or corrupted KSPAPIExtension.dll. Please make sure ProceduralParts is installed correctly by deleting your previous ProceduralParts installation completely and installing again. If that doesn't help can you please give me your output.log? See here on how to get it. edit: Whoops refreshing the page before posting is apparently a good idea

There are actually two types of cone modules. "ProceduralShapeCone" and "ProceduralShapeBezierCone". The first one is a simple cone and the other one is the one with the selectable curves. Make sure you have the right module on your part and set its tech requirement. @MODULE[ProceduralShapeBezierCone] { @techRequired= XXX }

Changelog Part icons in editor show the correct mesh and texture Ore tank got an oreish grey texture Fixed the bug that crashes KSP when launching a craft consisting of exclusively PP parts No procedural drag cube generation if FAR is installed ReRoot tool no longer breaks procedural parts Batteries now compatible to new tech-tree Loading an empty SRB no longer crashes the game download

There is none, it is not released yet. Thanks for the report. I'll see whats going on there.

jrandom: You need to set allowCurveTweaking=true in your techlimit

Svm420: Okay, sorry. Classic misunderstanding. I never had problems with the nosecone and FAR and "item taken down to" somewhat implied active user action to me. So I assumed you somehow figured out to create a Nosecone with a bottom diameter of 0 (through MM patches). Which is of course an impossible shape. I just tried to reproduce the error and for me the nosecones work perfectly fine with the official FAR release 0.15. Could it be that you use a devbuild?

Ahh, I see. Alright that explains it. Instead of bruteforce stripping all modules from the part you could also just do something like this: @PART[*]:HAS[@MODULE[ProceduralPart]]:Final { @MODULE[ProceduralPart] { @TechRequired = start !TECHLIMIT[*],*{} } } That should remove all TECHLIMIT Nodes from all procedural parts. The remaining standard values should be pretty much freestyle. A nosecone with a diameter of zero is, well, impossible. no wonder it causes problems. The solution is to choose feasible minimum values The standard value for diameterMin is 0.01. Should be small enough. The mod contains structural parts. I guess you could use them to recreate something like that. Another solution would be to create such a part from scratch (or find someone who does it) and then scale it with TweakScale.

I agree. Balancing needs some work anyway. Stock balancing is a bit inconsistent though, so it might take some time and will involve tweaking curves and other lovely tasks. So... yeah, lets first fix all the little bugs and kinks and after that, I will be happy to discuss balancing issues. When does the lag occur? When changing a pPart, KSP needs to recalculate the drag cube for it and I guess that might lead to some lagging. You're welcome. But I didn' t do it alone. BenChung, NathanKell and futrtrubl helped. (Hope I didn't forget anyone) I'm not sure I get what you mean. FAR refuses to revoxelize the craft when you edit tech restrictions per module manager patch? Thats odd. Actually the voxelization has nothing to do with tech constraints. (handled in different modules) The shape part modules just send a message to FAR after rebuilding the model, which then triggers FAR to revoxelize the craft. FAR showing the debug log message without actually voxelizing sounds more like a bug within FAR. Maybe an incompatibility with another mod? Humm? Thats weird. I tried to reproduce that (command pod with procedural SRB beneath) and it triggered the the contract immediately after launch. Maybe KSP just glitched out.