NoMrBond

Yes, turn your persistent debris amount to zero

If you have a lot of debris (and I mean a LOT) it may be easier to set your debris amount to zero to get it all cleared up than manually deleting it in the tracking station Just remember to change it back up from zero afterwards (maybe something like 25-50 rather than unlimited depending on computer specs?)

Include a toggle so players can choose fairing separation type according to their individual preference

If you convert a Unity 4 project then run the resulting Unity 5 project without checking anything then yes, very odd things can happen, including with performance Most APEX modules sound like they come with OpenCL support, but unfortunately it's unlikely that this would happen with the main PhysX functionality (still, GPGPU accelerated APEX Destruction would be cool as all hell) Upgrading KSP's engine to Unity 5 has been stated as a priority after 1.0 is released so that part at least is going to happen, although exactly how much of a performance benefit there will be is a matter of conjecture

I wonder if we will be able to choose between heat rejection (RCC/Silica-fibre/AETB) and ablative systems (SLA/PICA/SIRCA/AVCOAT) for the heat sheilds? If wing shielding is ablative, how will this affect vessels like spaceplanes which were intended for multiple re-entries (i.e. something like a Laythe surface to station shuttle)? Can you feather the re-entry gently enough to get away without shielding? The larger MK3 sized intakes and wings are cool but... we don't have anything matching enginewise to go with them like a 2.5m RAPIER? Sure you can cluster 3 or 4 1.25m turbojets or RAPIERS for equivalency but it's not quite the same And I guess, will we be able to get the fairings to come off as 'strips' (rather than per slope sections) or have curves (parabolic/eggshell/conic) on a per section or overall basis? Even if there was a little bit of curvature baked in whenever the profile changed?

I imagine the problem causing that sort of behaviour would show up very clearly in the Unity Profiler There have been enough conversion diaries detailing projects being upgraded to Unity 5 that I'm not worried about feasibility any more. Top that off with Unity 5 games which are out (like Cities:Skylines), and games still in development/early-access like The Forest or 7 Days to Die which showing lots of nice stuff (like a working win-x64 client), yeah, this is looking peachy. I'm also wondering, that since this will be such a big change, it presents an opportunity for, not quite sure how to describe it, but 'deep' fixes, changes to underlying systems which may be needed but making the fixes or updating those systems risks (or guarantees) braking a lot of downstream stuff/dependencies so they can't be made presently because of how much time it would take. [Edit] Plus stuff like Gives me hope for enhanced rover fun in the future

You could grab the TimeControl mod and watch the touchdown very very slowly? There was another mod which put effects where joint breaks happened, but depending on speed it might not be possible to differentiate that explosion from the, well, rest of the explosions

Usually the TT-70 for lower stages (for spacing, tweakscaled up depending on application) and the TT-38K for more compact upper stage (usually lander/return, tweakscaled down depending on application) applications. I never use the HDM though because of its high mass. I liked the look of the AIES decouplers, and the NP2 offset cone top ones which look like the tops of the proton 1st stage external strapons. Unfortunately I had to be really harsh with duplicate functionality parts due to the present memory limitations.

We'll get more information during the DevNotes and on the Squadcasts as the features get more presentable during experimentals progress If you keep an eye on the Steam AppID the frequency/number of builds may slow down as the number of bugs/issues dwindles Much closer to release (when release is expected within a week or so) we'll start seeing streams and videos from the media team

Reminds me of Pixologic's ZBrush or the Quixel Suite, I wish I could afford either.

Bugfixing 1.0 issues and other minor tidying (including features intended for 1.0 which could not be accommodated), followed up-porting to Unity 5 Once KSP is sitting on Unity 5 and playing nicely with the updated feature set (PBR/standard shaders, PhysX 3.3, MTJS etc) then it could be time for beautification features (like clouds, planetshine, ocean and atmospheric shaders for effects like rayleigh scattering) and more planets, which are not currently possible with the lack of performance (Physx 2.8.3, lack of thread-safe processing) and memory headroom (no stable win-64 stable client) under Unity 4. [Edit]As a side note, I really hope Squad stick with the standard shader for Unity 5 when the up-porting happens

The Worldmachine demo was pretty cool as well And the Tenkoku Dynamic Sky Unfortunately there is no timeline for Unity 5 Vulkan support (or any OpenGL update), DX12 support is due immediately following the Win-10 launch though which is coming up in a couple of next months. The branch of PhysX that Unity is using is CPU only so no GPGPU accelleration is used at this time, it's still a major update from 2.8.3 (Unity 4) to PhysX 3.3 (Unity 5) though, with support for multi-threading and SIMD FPU acceleration. Future APEX support with GPGPU acceleration via OpenCL has been mentioned, sadly not confirmed as yet though, and might only effect additional (APEX) modules (such as , Clothing, and ) and not the main PhysX component.

A single RS-25E/SLS engine, probably mounted for 2.5m, sitting around 1000kN would be pretty nice.

It's possible that neither the parachute parts nor the module{} have been looked at since 0.16 Hopefully they're part of the aero/balance review that's currently happening

The existing parachute module can do this, I'm not sure why it isn't used, or rather, why its value is set so high If you want to test this for yourself you can go into your parachute configs and change deploymentSpeed = 1 to deploymentSpeed = 0.01 [Or get the SlowChutes MM patch]

Puts me in mind of the Rocketlabs Electron, carbon fibre / composite skinned rocket

I would very much like the existing 'Chase Cam' mode to stay available (with a different name), it's fixed position relative to craft orientation makes it extremely handy for docking

It's a current and valid solution to the existing problem. No debate regarding reorganising the tech tree is necessary when Squad have already announced that they're reorganising the tech tree.

Use R to turn on your Kerbal's jetpack while on EVA, then fly up to the command pod (or landing capsule). It has easily enough power (and dV) to get you up of the ground and back to the top of your ship, even on Duna (although it's pretty marginal on Duna), although Mun, Minmus, Gilly etc no problem.

Still in timewarp? I forget to cancel right out to 1x on occasion, it's usually that or I forget the correct RT antenna.

Would it be possible have a planetary config on the same level of accessibility as the proposed Tech Tree config? Whilst there are mods for the system like Kopernicus, and mods which flex them like Outer Planets (and both are great), being able to make or adjust configs just like we can make or adjust existing parts, and soon the TechTree itself would be neat. Imagine something like System.cfg SUN { name = Kerbol mesh=\[location]\ texture\[location]\ equatorialRadius = 261600000 mass = 1756567 // in 10^22 kg surfaceGravity = 17.1 rotationPeriod = 432000 scienceNearSpace = 11 scienceOuterSpace = 2 } PLANET { name = Moho mesh=\[location]\ texture\[location]\ parentBody = Kerbol equatorialRadius = 250000 mass = 0.25263617 surfaceGravity = 2.7 rotationPeriod = 1210000 scienceSurface = 10 scienceNearSpace = 11 scienceOuterSpace = 2 orbitPlot { Apoapsis = 6315765980 Periapsis = 4210510628 orbitalInclination = 7.0 orbitalPeriod = 2215754 } } PLANET { name = Eve mesh=\[location]\ texture\[location]\ parentBody = Kerbol equatorialRadius = 700000 mass = 12.244127 surfaceGravity = 16.7 rotationPeriod = 1210000 scienceSurface = 8 scienceLowerAtmosphere = 6 scienceUpperAtmosphere = 6 scienceNearSpace = 7 scienceOuterSpace = 5 atmosphereCurve { key = 0 96708.574 //end of atmosphere key = 1 506.625 //atmosphere at sea level } orbitPlot { Apoapsis = 9931011387 Periapsis = 9734357701 orbitalInclination = 2.1 orbitalPeriod = 5657995 } } MOON { name = Gilly mesh=\[location]\ texture\[location]\ parentBody = Eve equatorialRadius = 13 000 mass = 0.000012420512 surfaceGravity = 0.049 siderealRotationPeriod = 28255 scienceSurface = 9 scienceNearSpace = 8 scienceOuterSpace = 6 orbitPlot { Apoapsis = 48825000 Periapsis = 14175000 orbitalInclination = 12 orbitalPeriod = 388587 } } etc... } I'm sure there is more information which should be included, but this is more to illustrate the idea.

Unity Technologies started talking about Unity 5 features etc in March 2014 The closed Beta of Unity 5 came out October 2014 The general release (for non-Pro/non-preorder) just happened for everyone after being announced at this years GDC The next planned releases with ROSLYN/IL2CPP and the APEX extensions sound neat, still no sign of what it could do for KSP though until the Squad codemonkeys (does that make them Captain Monkey Monkey's?) get their hands (paws?) on it

One one bug report so far for KOSMOS URM release 15; the RD-191V nozzle is missing Anyone have anything else to report?

We could have Katherine Johnson for delivering the engineers report to give your your craft trajectories/stats/dV etc? An expert so respected they would only believe the computers if Katherine's maths agreed.

Scene showing the packaged default ocean shader (and some physics) for U5