NoMrBond

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

New starting buildings (L0), and a new set also between the current L2 and L3 (the difference there is currently just... insane) for five total (e.g. newL0 -> currentL1 -> currentL2 -> new2.5 -> currentL3) Being able to see upcoming transfer windows and plan missions/maneuvers pre-launch which stay with a vessel (i.e. Wernher pops up and says it would be a good time to send something to Jool in three months! or something, anything) Once you can see the dV requirements (from your plan above) for the transfers, a built in dV report so you can actually see if your vessel can complete said mission Formalised testing grounds/simulations, you can already manually cheat your stuff around to see how it will do from orbit or on the ground via the alt+f12 menu, but some way of buying this as a launch sim would be great Atmospheric expansion for the rocket exhaust plumes Planetshine Clouds Rings Reflections

Well KSP does now support compound parts with adjustments at both ends, does this mean we could have a launch clamp which is a ground fixed tower with a place-able/stretchable/run-able end like struts work? You could even use Vectrosity (which KSP already uses) to make it have correctly sagging utility lines from tower to the clamp attach point

Players inflict part failures on themselves already with Testflight, Dang It! and Kerbalism (plus others I'm sure) so there's certainly an appetite for it (like RemoteTech or DRE previously) Early rockets were unreliable (11 or the first 23 Titan-II flights failed for instance), making them reliable enough to trust peoples lives to (and then only with contingencies) was part of the space race which players may want to confront. Maybe it'll be like Testflight?, perform tests and run engines (or other parts) to gather data improving their reliability Either way, I'm sure it'll be an optional On the other hand, I hope the outcomes are more fine grained rather than just 100%-to-0%, and that Kerbals might be able to field repair some failures. I also hope the temperature system is upgraded to take difficulties regarding low temperatures into account too Another thing to consider is that part failures without any kind of life support requirement would be, well, not meaningless but certainly a soft failure sort of thing, since having crew stuck somewhere doesn't come with any kind of time pressure

2.5m format 6-way hub 3.75m docking port 3.75m command module 2.5m NERVA/NTR type engine with toggleable LANTR mode 2.5m RAPIER type engine 2.5m Air intakes Larger wings/wing-sections Larger landing legs Surface mountable omni-directional light Laser illuminator 45 degree offset RCS clusters Girders/spars/trusses which use the fairing-structure method, snapping something to a node automatically makes it that long. Grid fins Ground anchor

After having the game for maybe a few hours, deciding that I should built a space station The lesson in this case being that if you're going to learn how to dock, you probably shouldn't start with massive truss sections Still, the feeling once getting docking mentally sorted out and the station started coming together in LKO was amazing

That particular post is probably locked because they don't want you to post your bugs there, but as the post says please do report your bugs on the prerelease bugtracker

All sound pretty interesting Will the Making History parts be getting normal maps in the future?

You don't have to use every attribute/key so if you looked at a light part designed with no EC cost the author probably skipped including those lines (KSP probably assumes 0/false without causing an issue)

They do, the keys are under the MODULE{} MODULE { name = lightName = useAnimationDim = lightBrightenSpeed = lightDimSpeed = animationName = resourceAmount = [Amount] useResources = [true/false] }

It looks (to me) like a naming convention change, and Unity 2017.1 is (for all intents and purposes) Unity 5.7 Unity uses Mono (a free/opensource version of the .NET platform) which is intended to let you have a common language runtime (i.e. write once, run everywhere, which is good for supporting multiple platforms as Unity does) Unfortunately the current version of the Mono runtime Unity uses is mostly .NET2.0 / C# v2 (circa 2005), and sort of .NET3.5/C# v3 (circa 2007), in a kind of uneven fashion. The new runtime version of Mono (in Unity 2017.1) is going to be .NET4.6.x / C# v6 without any weird partial behaviour/s, as well as providing all the upgraded functionality/improvements on .NET/C# Please bare in mind that while I am interested in Unity/Development I am not a programmer so my understanding of the gains/advantages of this move may be way off and/or unduly influenced by listening to programmer/dev chatter regarding the current state of Unity's Mono.

Yes, I asked in one of the earlier threads and TriggerAu confirmed it's staying on 5.4 (for 1.3 at least) [Edit 2] Honestly if Squad was going to spend devtime upporting to a new Unity version, I'd prefer them to target Unity 2017.1 since that will be using the .NET4.6 version of Mono (runtime upgrade at last = yes).