NoMrBond

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

The passgrab filter grabpass shader was not working with the terrain but that was because something was getting accidentally zeroed in the shader and he'd managed to fix it (according to their last post anyway). If KSP got updated to Unity 5.6.x its new particle system includes support for it (particles with normals etc), Roverdude and JPLRepo have been obliquely hinting at 5.6.x but until that happens, hopefuly Bahamutod and Blackrack can work something out (and it still works)?

Yeah this one; [Edit] I'm not sure if you could contact Bahamutod (Paolo Encarnacion) in some other fashion, or if they'd be willing to part-with/donate what they had for that though, hopefully?

In-flight editable action groups would be very handy Maybe it could be something you need an Engineer onboard to change (like SAS for pilots), certain Engineer levels can access different levels of action groups (10/20/30), or set certain actions.

Will the texture switch feature also come with contents switching? Switch to a mono skin = tank filled with monoprop, switch to LF skin = tank filled with LF, etc And the other question I guess is the next major release (1.4) going to be based on Unity 5.6.x, either that or @JPLRepo is having way too much fun teasing us.

You giant tease

Will the Making History events take place in the KSP system or a closer simulacrum of our real solar system? I'm just wondering because things like dealing with the inclination of your launch sites vs the Moon is something the respective sides of the space race did (and do) have to deal with Also, 5m parts kind of suggests the scale of the system for Making History is going up (or perhaps will be a difficulty option, ohhhhh please be a pickable/difficulty option), because a Saturn V with 5m S-IC/S-II stages in a KSP size system would be mighty overkill. Either that or the parts would have to be really bad (mass fraction/ISP etc) to make those 5m parts necessary, which would seem a bit odd. I'm still hoping that we'll see light/cryogenic fuels for Making History, because the US investment in cryogenic/hydrolox fuels/engines and the propulsive efficiency they provided really make the Saturn V's payload fraction possible.

...does that last sentence allude to us getting version of KSP on Unity 5.6.x in the future? /fingerscrossed

I hope that Squad considers updating to Unity 5.6.x for KSP 1.4, I mean Unity 2017.1 would be great, but probably unrealistic considering they'd need a whole new license. There's a lot of good stuff between 5.4 and 5.6 at least, and it would quite literally be the end of the line in terms of engine updates as that's the last of the Unity 5 lineage The updated particle system would provide a good basis for a smoke/exhaust update on top of the performance improvement the system overhaul provides (with at least plume expansion please!)

Can improvements (like shadow performance), or any part of BlitWorks work on the console versions come back to the PC branches, or do the different pipelines/technology make this sort of thing impossible?

The 1.3 train out of left field POW, excellent! Now I just have to wait until I've finished moving to play it... (boooooo)

I was going on discussion out of the Unity forums, /r/gamedev and /r/Unity3D where that seemed to be the general feeling, it wasn't a big discrete leap like 4-to-5, but more like a .1 iteration on existing 5.x technologies (hence my 5.7 comparison) Unless Squad are going to make a huge late 1.2.9 pre change from 5.4 to 5.6.1 (which would invalidate most, if not all, the current testing) and blow out the production timeline to an amazing degree, they'll probably stay on Unity 5.4 as TriggerAu confirmed earlier. Maybe they'll move up to Unity 5.6.x later, but if KSP 1.3 was going to use 5.6 the pre-release test builds would have deployed with it surely

Unity 2017.1 is basically Unity 5.7 (a naming convention change) rather than the huge change to the technological underpinnings that was between #4 and #5 I'd asked about this earlier, and KSP 1.3 will be staying on Unity 5.4 (not even moving up to 5.4.4, let alone 5.6.1)

Is this something Unity 2017.1 would fix as this (finally) has the updated mono/runtime (to C#v6 and .NET4.6.x)? If migrating KSP up from Unity 5.4 to Unity 2017.1 would fix it, how much devtime would that take (i.e. is it realistically a possibility)? Would updating KSP from 5.4 to 5.6.1 offer any of these benefits with commensurately lower devtime required?

Revealing their autostrut settings via advanced tweakables sounds good They continue working as they are now by default, but players can choose to change their behaviour if desired