NoMrBond

Members
  • Content count

    2124
  • Joined

  • Last visited

Community Reputation

606 Excellent

About NoMrBond

  • Rank
    Capsule Communicator

Recent Profile Visitors

3022 profile views
  1. 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?
  2. 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)
  3. 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
  4. 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)
  5. 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?
  6. 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
  7. 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
  8. 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
  9. 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
  10. 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
  11. 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
  12. 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
  13. All sound pretty interesting Will the Making History parts be getting normal maps in the future?
  14. 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)
  15. They do, the keys are under the MODULE{} MODULE { name = lightName = useAnimationDim = lightBrightenSpeed = lightDimSpeed = animationName = resourceAmount = [Amount] useResources = [true/false] }