NoMrBond

This lead to the tensest game of rock-paper-booster the world has ever seen

Controlling the number of particles is under SmokeScreen from memory, on blizzy's toolbar, Smk Scrn in grey text

Try SPEEDY'S HexTruss, heavily inspired by THSS

I was expecting some traffic around KSC, when we're in the VAB there are trucks and staff and lifters and all sorts of, I don't know, scene 'texture' It would be neat to have Kerbals walking between buildings, trucks moving parts to/from the VAB/SPH or R&D, just something to give the place a bit of life really. The trucks/lifters could even be carrying parts you've unlocked (to the VAB/SPH), parts you're soon to unlock (to R&D), or even subassemblies from your save (within certain limits). Maybe even some scatter (some Kerbal flora/fauna would be neat, could even community source/contest for fitting models/drawings) would go a long way too make the place feel alive

I imagine the upcoming KSPaedia tool might address this?

After a couple of glorious, yet utterly unusable stations, I always try and minimise part count now Being able to play wins out against in-game aesthetics (to a point)

This could be related to the various competing UI systems currently in play, KSP has three different UI systems running Part of the (upcoming) 1.1 update is reworking/rebasing the entire UI system so it all runs off the (Unity 5) stock UI system Hopefully that should mean these oddities get addressed

Best you can do in stock is toggle Precision Controls on with CapsLock so that the thrust amounts are greatly reduced, unless you hold the key down for a while (or whatever you've bound under OSX which doesn't let you use CapsLock) On the mod side changing the thruster scale with TweakScale is another option with pretty fine control over your desired thrust level

The main reason to go with DX11 over DX9 under Unity 4 would be that Unity's DX9 implementation has a bug with CPU texture mirroring which inflates memory usage significantly (by keeping redundant copies of textures in system memory instead of offloading to GPU memory) which exacerbates KSP's 32 bit limitations. If this particular bug has been fixed in Unity 5's implementation of DX9 then there won't be too much difference given KSP is (relatively) graphically lightweight. DX11/12 support would be nice though for their various advances, maybe essential even if the DX9 bug still isn't fixed

Deployment cost for an SSTO is high but the recovery fraction can be almost 100% since the only thing being expended is the fuel This may float your boat, tickle your fancy, play nicely with your mod/s of choice, or simply provide a satisfying challenge

Have a good rest and good luck with the relaxation!

The NSTAR ion engine on the DAWN spacecraft makes 90mN (->0.09N or ->0.00009 kN), the in-game PB-ION makes 2kN, which makes it slightly over 2.2 million times more powerful. KSP would need to support on-rails thrust (so craft could accelerate for the necessary days/weeks/months without being focused) before the thrust levels could be reduced to anything even vaguely realistic though

If you're going to scale up size/power, then perhaps step up to VASIMR (~10x the power requirements but produces 45x the thrust) instead of simply having larger Ion drives (mN of thrust for thousands of W) That would need balancing to fit inside the game but that's hardly rocket sci... wait, ahem, it's doable, yes, doable.

Toggle between local (part relative) and absolute (VAB) alignment with F, once you're in Absolute/VAB alignment mode you can hit space to reset it straight (or manually dial it back with the widgets)

MOARdv made something similar to KerbPaint which was used in the KOSMOS-URM releases where you could set part RGB colours If you want something for changing colours then you could ask them about that part of their plugin [github link]

Could you post a picture of your (completely unfolded) Unity hierarchy?

At 40:40 Max says 'You guys are going to love the new parts, by the way' which I'm not sure what he's referencing as the prior discussion was about the 64 bit editor/engine Unfortunately yes, processing for a related group of rigid bodies (i.e. a vessel) still cannot be split.

Or it could go the way of FAR, where Ferram talked to the developers and got a 'I'll take it from here' flag in the Squad aero system so now FAR can metaphorically put up it's hand and take over. Which is why I'm hoping there is constructive dialogue happening, now is the time for someone from the RTG to contact Ted and/or RoverDude and make sure RT isn't irreparably harmed.

Best case the stock additions let the RT team do more and/or frees them from some aspects of unity engine wrangling Worst case scenario, RT still gets a bunch of new antenna models to adjust to their own taste I do hope there is constructive dialogue between the Remote Technologies Group and RoverDude regarding the feature though

It would be neat, but I also think it should be a 'tickbox' difficulty option which people can enable at/to their own peril/taste.

It is possible APEX modules (physics solver extensions) will be supported by Unity in the future (provided those modules support OpenCL), this has been hinted at but not confirmed. If this did happen mesh deformation and destruction could be handled with the APEX Destruction extension for PhysX

I suggest asking Harv/Mike/Jim/Ted et al. directly regarding your situation They might be able to address your concerns, or even incorporate something accommodating your case like the aero takeover flag Ferram got for FAR

Since it's procedural, a slider on game creation would be nice (perhaps split between non-atmospheric bodies which would have more/varied craters and atmospheric bodies which burn up / moderate a lot of impacts). Then players could choose their desired level of pockness

Sony have also said that mod support is coming for FFXIV:H (shortly after launch was the timeframe), so it sounds like some kind of mod framework is coming for PS4 (I doubt it would be exclusive to FFXIV)

Would NathanKell's Crossfeed Enabler solve this?