NoMrBond

Parts I've had randomly explode or spontaneously disassemble have been (thus far) collider issues If you have a convex collider on both the Cylinder and Cylinder_001 meshes (I'm assuming the black and red parts respectively), then they might be clashing in a way the game doesn't approve of. You might need to make some custom simple meshes to hang the colliders on so they don't intersect

I would be fine with some 0.05 mass 'heavy strut' endpoints (making each strut/pair 0.1 mass) if that meant more strength than a fuel pipe for situations that call for it. I'm sure the current 0.0075 mass strut ends are fine for a lot of things, but something heavier for when the going gets tough and the SLS tanks are trying to do the wacky inflatable arm man dance would be very helpful.

If you're using KER 0.6.2.3 I strongly recommend getting the Padishar .dll updates Or just updating to todays brand new version (0.6.2.4) which incorporates all the Padishar simulation changes

If the the fuel line is giving more structural strength than the strut, that sounds like a bug which should be looked into

Experiencing some oddities with KAS 0.4.7 the struts seem to be, uhh, rubbery? They flex and stretch after linking and don't really seem to be holding all that well, connections are loose and reinforcing with additional connections doesn't seem to help. The part.cfg for the KAS_Strut1 has maxLenght instead of maxLength (not sure if that's relevant to the issue)? How should the KAS strut compare to the linearStrength/angularStrength (150/150) of the stock strut, or there a way to make them a bit more rigid?

Only KSP Interstellar mod has this sort of functionality I think, although you could copy the appropriate KSPI module(s) to the Salyut and/or TKS body sections of you choice to allow them to perform said research.

For Apollo Style unfail, I would suggest putting the Landing Module (LM) behind the Command Service Module (CSM) in the stack because (a) this is Apollo, and ( a landing module is a really heavy thing to have in front early on. Have the CSM do the classic flip-pickup after the TMI maneuver to pick up the LM. There's a whole thread of Apollo style missions which might give you some inspiration Otherwise get KAS and put some struts on there after you pick up your lander.

During atmospheric traverse yes, if debris (or in fact anything nearby and not on rails) gets more than 2.5Km away while you're in atmosphere it gets deleted (No scaled-composites/virgin-galactic white-knight style launches without auto-delete of the carrier plane as the rocket departs for example)

Debris will not disappear unless it is destroyed (it is hitting the water too fast), or you hit your debris limit Some parts are quite fragile (like the materials bay), the maximum speed they'll tolerate is visible in the VAB (i.e. don't land on these, or use a lot of parachutes). Have you set your debris limit to zero under game options?

Add an 'RCS' group into the action groups page (along with staging, lights, brakes, 1-10 etc) Than have engines added to this group be activated/deactivated/fired by the RCS schema ---------- Until such time however, I've been making some 'Grande' RCS thrusters for dealing with the expanded mass paradigm of the SLS parts because the 1 power stock ones just don't cut it

High rigidity docking ports (right click permanent fuse/weld the joint ) would be pretty sweet for a lot of heavy duty applications. I wonder if that could be possible with KAS which already has welding?

It's something to do with the way the particles are spawned, or perhaps propelled relative to world space (if that's even the correct term), do they move relative to the ship or space, or something like that? Sorry I remembered reading about a similar issue with HotRockets a while ago and the fix for the strange exhaust behavior was related to this setting [Edit] Relevant comment from the HotRockets! thread Which seemed to be the same graphical issue

Try adding fixedEmissions = false to the exhaust config for that part (probably under the powerflame section) Sorry I'm stuck at work, if I was at home I could check this myself and be more specific with the details

Finally! And just like FloorIt, this really needs to be part of the stock command compliment

The CUDA accelerated version is bound to NVIDIA cards (although some new features, like HairWorks, seem to also support OpenCL), however there is also a CPU branch of PhysX which is implemented on everything else. Unity only implements the CPU branch because it works across all their supported platforms (Unity 4 uses CPU PhysX 2.8.4, while Unity 5 is going to use CPU PhysX 3.3, hopefully the threaded version too so no more single physics thread limitation) The PhysX upgrade to v3.3 is a big step up, if Unity 5 also supported a native cylinder collider so they didn't have to be calculated as mesh colliders this would also be better

Not sure about that combined one, thanks for the offer though, even just being able to add a probe core/battery would help, since there are no 3.75m cores or batteries. Not needing to put 4x 2.5m RW's under a PF fuselage (for FAR) to actually move those heavy 3.75m tanks would be nice, hopefully that becomes possible at some point (and there's some kind of balance pass so the numbers make sense). I am enjoying the Procedural Parts immensely so far, so thank you for this mod, anything more you have the time to add would be a nice bonus

Hopefully Unity 5 provides a viable migration path for KSP and mitigates some of the current limitations, i.e. has a 64 bit build that works across all platforms, thread safe, implements the full 3T CPU branch of PhysX 3.3 which can be properly handled by the multi-threaded job handler. Just because seeing KSP migrate to Unity 5 is likely, while the chances of KSP migrating to Unreal is basically zero,

Would it be possible to have additional options for adding RW force ASAS function Probe Core / Remote Guidance Battery/Ec storage To the procedural structural parts (with appropriate mass additions and for each selection)?

Add a 'does nothing' module (pointing to a transform that does not exist, if applicable) to the config like //Startfix MODULE { name = ModuleRCS thrusterTransformName = notReallyAnything thrusterPower = 0.0 resourceName = MonoPropellant fxOffset = 0, 0, 0 atmosphereCurve { key = 0 260 key = 1 100 } } //Endfix Which should stop it infinite-expanding in the VAB (I have no idea why). This one was recommended by Frizzank originally (I think?) as it produces no errors (some modules don't like pointing to non-existent transforms, or having 0 values in them).

You can edit the pitch of each one if they're bothering you Go into the Beeps tab and slide the 'Beep Pitch' down for your selected beeps until they suit your tastes.

Good to know Snjo as I forgot to check, better go do that [Edit] Doesn't seem to, George just lucky I guess.

You might get some strange results there as the tanks from Stubbles Horizon package for the Zenit-3SLB don't use standard LFO amounts because their engines do not use the stock 0.9/1.1 burn mix ratio Oops, right, I'll try and figure out how to add that fix in there as well [Edit] techTree module manager file updated to also including the URM - U series tank VAB-expansion fix (please let me know if this works)

You can add a 'does nothing' module to the tank config, something like //Startfix MODULE { name = ModuleRCS thrusterTransformName = notReallyAnything thrusterPower = 0.0 resourceName = MonoPropellant fxOffset = 0, 0, 0 atmosphereCurve { key = 0 260 key = 1 100 } } //Endfix Which will stop it infinite-expanding in the VAB, if you don't want a plugin

Given that 0.23.5 is based on Unity 4.3.3, gotta hope that the (assumed) 0.24 PartTools package will resolve this since Squad would also need to 'build' using it.

Emissives and Unity 4.3 and above do not (currently) get on Unity 4.2.2 is the latest version which still works with Emissive animations