Jump to content

NoMrBond

Members
  • Posts

    2,261
  • Joined

  • Last visited

Everything posted by NoMrBond

  1. How about the ability to establish new Launch Sites in general? Could require these to have vehicle requirements in career mode, i.e. need a certain tonnage of vehicles at the site with power generation, so many Kerbals, ISRU etc
  2. In a sort of related vein, will KSP's graphics API support roll upwards as well at some point? DX11 has been out for ~10 years at this point and DX11-HLSL is incredibly similar the PSSL on the PS4 (XB1 uses DX) meaning shader work could be shared between the PC-PS4-XB1 platforms with ease
  3. Can this parameter be tied to a floatcurve (like atmospheric pressure)?
  4. There is another KSP-EE patch coming according to last weeks notes;
  5. Excellent news There were 4K/High-DPI adjustments for the UI that were mentioned earlier, did those also make it in there somewhere (like sidebar/part-pic scaling for the VAB/SPH etc)?
  6. If you have the GeForce Experience app installed you may need to use ctrl+alt+F12 rather than just alt+f12
  7. I'm hoping that the cause was the same "shader interaction with part scale bug" which was affecting the re-entry shader, so it's also been fixed? Unfortunately I can see #18095, #18094 and #18303 are all on zero% (although 94/95 are pretty sparse reports, so not entirely surprised about those two) which is a bit concerning
  8. I'm not entirely sure (was thinking of #17833 & #17834), but I look forward to finding out next week!
  9. Was a solution found for the aero/re-entry shaders going a bit weird (effects showing through vessels / drastic visual changes depending on view distance)?
  10. Nah, if you prod the error you get NET::ERR_CERT_DATE_INVALID - Expires on: Mar 30, 2018 Just expired, that's all.
  11. 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
  12. 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.
  13. 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.
  14. 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
  15. 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
  16. 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)?
  17. 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?
  18. 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.
  19. ...does that last sentence allude to us getting version of KSP on Unity 5.6.x in the future? /fingerscrossed
  20. 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
  21. 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)
  22. 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?
  23. 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
×
×
  • Create New...