NoMrBond

In looking at 1.4 I'm surprised that some of the engines are still running on the legacy legacy fx_exhaustxxx and fx_smokexxx config lines rather than the newer EFFECTS{} system. When the update to Shuriken was in the patch notes I was hopeful that all the old fx_stuff (and maybe even MODEL_MULTI_PARTICLE) was also updated to MODEL_MULTI_SHURIKEN, and maybe we'd even see effects like plume expansion

Some people were complaining that this .dll was (the) spyware, oh well. Otherwise KSP already collected non-specific data (play session time/s, progress and technical info) but you could sort of control the extent (well, pick one of two options). This data would now be available to T2. Most of the T2 data policy involves data from a T2 account, which is not required for KSP so wouldn't apply in this case. Kinda, the "WHAT PERSONAL AND OTHER INFORMATION DOES THE COMPANY COLLECT?" section is taken from http://www.take2games.com/privacy/ which is specifically for their online services account, and doesn't apply for KSP because you don't sign up for a T2 account to play it.

Posted earlier by UomoCapra

Kerbal EDU already contains dV/TWR etc readouts too, although I believe because KerbalEDU is a separate entity they can't just grab that code slug and drop it in (although I'd hope it wouldn't be too difficult to make an agreement on that front). Even if it was hidden by default like Advanced Tweakables, plus you could progressive gate parts of it in Career saves by tech levels of various facilities.

That one annoyed me because clicking on the link took you back to the same page, requiring you to agree to another page of terms which could not be read

I keep forgetting the snap/align function of the docking ports/module isn't turned on by default, being able to turn that on with an advanced tweakable would be great I assume the ADM/APAS docking ports would be locked to connections at specific angles (if they're in Making History?)

Now if you had a parachute when ejecting in an atmosphere, and a MOOSE when ejecting in orbit that could be even more interesting

I hope we get some technical/under-the-hood insights into the engine upgrade process for 1.4 I mean we've had blogs about various technical aspects in the past (like the fonts/kerning, transform maths for smoother runways and shadows), so something about porting the launch smoke system to shuriken (if that's happening) or other particle overhaul shenanigans and other stuff happening with Unity 2017.1 for KSP 1.4 would be an interesting read for a lot of people I think I also acknowledge that writing something like that would take away from actual development time, so it's pretty conflicting.

Making History will be based on KSP 1.4 (using Unity 2017.1 at last mention), so it's a good bet that the console versions would be updated to there as well

It should send you to a short WebM/HTML5 video clip (hopefully visible below)

Something else that could be added for the existing NTR's would be a toggle-able LANTR[1] mode (uses LOx, higher thrust/worse ISP), KSP has supported multi-mode engines for a while now and such a change wouldn't require additional parts just a config tweak. With a LANTR mode around ~220kN thrust @ 520 vacuum ISP[2] it'd give you a bit more flexibility around their use Obviously that's a bit of a change-up for the LV-N, so the ability to toggle LANTR mode could be locked behind an refined atomics upgrade further along in the techtree ----- [1] https://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/19950005290.pdf [2] Using an approximation from the NTR-to-LANTR stats 3x/914s -> 11x/514s (for TWR/ISP)

Being able to buy/place these additional launch pads as a feature in career mode would be nice Even if you had to roll them out at KSC as gargantuan SuperKerbal contraptions and move them around yourself

They have cookies!

This is the KSP Weekly, not the StarMods section so yeah, these are becoming part of the game

32-bit meant that (pre-1.1) KSP could only address ¬4GB of memory (causing much lamentation and gnashing of teeth) Multi-threading and 32-bit limits on addressable memory are very different though

Unity 2017.1 has a very slight bump in PhysX (3.3.3 to 3.3.4) but that's not going to really do much for performance KSP is multi-threaded already, using the job-scheduler of Unity 5 since KSP 1.1 (it was also multi-threaded before that, just less so). Similarly the physics has been multi-threaded since KSP 1.1 with PhysX 3.3.3, with the caveat that grouped bodies are still stuck in a single thread (one vessel = one thread). Perhaps the updated C#v6 support (even the runtime update in general) will help performance (the updated garbage collector will be nice at a minimum)

The sputnik-alike one looks like Shadowmages - Textures Unlimited shaders on stock parts (Stayputnik/4x Communotron 16's/reactionwheel/Z-200 battery/2x OX-4L 1x6 Photovoltaic Panels/xenontank/PB-ION engine) Not sure about the part/s in the second picture

Not quite the way I was hoping for Unity's standard shader to make it into the game but I'll take it!

Huh, I wonder if Making History flexes something Unity 2017.1 provides (which 5.4 doesnt), or being able to use C#v6 + better GC was too good to pass up

Huh, was that UV generation bug slowing things down with the stock procedural fairings at all? Good news about the Shuriken system too, so many good toys in there.

I wonder if the Squadites have a wishlist for what they want to achieve with the 1.4 update, and which features of Unity 2017.1 they want to flex? (props to RoverDude and JPLRepo for the engine update trolling long game too ) Or if the whole thing will be played close to the chest to avoid promissory drama (a depressing possibility) Fingers crossed we'll hear more about it soon rather than soon™

True, should != will I'm simply hoping all the new features will get implemented, right to the hilt

The C#/.NET update should make the game run better (accumulated runtime/programming improvements since C#v3 in 2008) The other graphical stuff should make particle systems (engine exhausts / rocket trails) look better

KSP is (currently) running on Unity 5.4 (.0p4 I think), so there's all the updates for 5.5 and 5.6 as well as what 2017.1 is bringing (which is a lot) Basic summary would be major particle system overhaul and PhysX (to 3.3.3) update (added in u5.5), Vulkan/Metal support + script/shader based particle systems (added in u5.6) I think the big one might be the C#v6/.NET4.5 runtime support added in 2017.1 though, that's a major update from the kinda/sorta C#v3/.NET3.5 support It'll be interesting to see which new features will be flexed/implemented during the upgrade from 5.4 to 2017.1 [Edit] Maybe this will also be the point where KSP's assets are moved into assetBundles to take advantage of dynamic loading/unloading?

Hi @Starwaster, I'd like to make a request if I may, Can we please get the ability to change proc (stack) separator/decoupler height (within reason). Having the smaller radius stack decouplers still being (relatively) quite high seems a bit odd Unless this has been tried already and makes things misbehave etc