There have been a steadily growing list of shadow issues since KSP moved to Unity 5. This list now included (but was not limited to) shadow issues with Trees, KSC buildings, Green lines over water and Sun shadows flickering in flight.
Looking at them one by one, each of these issues appeared to have different root causes.
So let’s look at them one by one.
As soon as I started looking at the tree issue it was quickly apparent this was a shader issue given it only affected one particular tree model and its vertex shapes.
Where do we start?
Digging into the shader being used by our tree that is causing us issues I quickly found that the alpha cutoffs and fallback shader are just not quite right because of changes Unity made in Unity 5.
A few adjustments later to the shader and we have our result.
KSP's Camera System
KSP uses a two Main camera system for the main game view. Of course there are a number of other cameras for displaying UI, Graphic FX, etc.
But these two are the ones that show you the game world. Let’s look at a picture so I can describe it.
There are two cameras located where the camera icon is in the top left of the picture. This is their location in the game world. They are both looking in the same direction and are linked to the same camera transform. The first camera, or Camera00, is known as the Near Camera. It is set to show only the first few hundred meters of the game world and it’s view of the world ends at it’s Near Camera Far clipping pane, as seen in the picture. The second camera, or Camera01, is known as the Far Camera. It is set to show the game world where the Near camera ends out to a very very long distance away.
There have been long standing issues with this system including shader issues where the two cameras overlap, or where the Near Camera’s Far Clipping Pane ends and the Far Camera’s Near Clipping Pane starts. This has been particularly visible as a green line over water.
The primary reason for why these two cameras overlap is to provide a seamless view of the game world. So changing the camera settings we can reduce the overlap to the very minimum and we see that the green line that used to be visible over water has now vanished.
The KSC buildings had also been suffering from this same two camera system since Unity had introduced changes to the way it draws shadows.
In Unity's built in shadow shaders is an automatic fade out of shadows as you approach the far clipping plane (the furtherest the camera can see).
This is why we had things like this
where the shadow would fade away, get cut, or not appear around the area of where the closest game camera far clipping plane ended. This problem has been known about for some time.
Here is a link to an article written by Harvester asking for help about the problem. Here also, is a picture by Harvester describing the problem (from the article).
So how do we fix this? Well luckily as a developer I am able to get access to the Unity built in shaders and create a modified version that does not have this fade out feature. So I take the Unity built in shader used for the building shadows and change its code to remove the fade out processing.
Once I have the shader fixed to not fade the shadows I also need to write a script (code) that will replace the built-in Unity shadow shader with our modified one.
Finally I add this script to the KSP cameras and we get a much better result.
But we weren't quite done with the building shadows. Another known issue in Unity 5 is the way sharp edges in object geometry cause gaps in shadows to appear.
Luckily this is much easier to resolve by changing the settings of the geometry on our building objects to use two-sided shading.
The Sun and Flight Scene.
Everyone has probably noticed the flickering/sliding shadow effects that have plagued the game in flight mode since the move to Unity 5.
Without a doubt the trickiest problem of the bunch and hardest to resolve. There is a combination of factors at play here. First is a known issue with the way Unity draws shadows with directional lights and the second issue, that only tends to exacerbate the problem, is floating point precision issues calculating very large numbers which represent the very large distances (even at the scale the Kerbin system is in).
The SunLight we see in the game is generated by a Unity Directional Light. This light is rotated over time based on the position of the celestial bodies.
The position and rotation is calculated every tick of the clock and the light itself is rotated based on the body positions.
Due to floating point imprecision this means the calculations between the bodies can vary even the smallest amount between clock ticks and this is exacerbated further by a known
bug in Unity with regard to shadows drawn by directional lights.
By reducing the precision of the calculations between the celestial bodies we can reduce these tiny variations so we have a solid number that gradually changes over time.
The downside of reducing the precision is that the rotation of the sun is less smooth, so we end up with a sun that tends to move in small steps rather than one fluid motion across the sky.
But the plus side is we reduce the difference between clock ticks and we don't get light shadows flickering all over the place.
This work-around solution, whilst not ideal, is the best compromise to alleviate the issue working within the known limitations and Unity issues that we have. These known issues with Unity 5.4 directional lights and shadows have been fixed and much improved in Unity 5.6. Along with improved shaders, effects and other enhancements that come with Unity 5.6.
Runways are indeed not flat. And KSP’s runways are no different.
In fact one might argue that KSP’s runways are too flat! But that’s not what you the fans (or the planes in KSP) wanted. So I was given the task of looking into the Runways.
Well hey I thought.. Can’t be that bad. They don’t look like this do they? Or maybe they do…
First impressions were this should be a simple job. Just align the models in Unity. Why hasn’t anyone done this? Well, I can tell you, it’s not that easy at all. The issue begins when you look at the size of the runway models and small inconsistencies that seem to creep in when you import the models into the Unity engine.
Unity has some tools that support object positioning. But the best tool for the job is the vertex snapping tool and this works best when your mesh (the actual triangles that make up the model) has a physics collider attached to it and these have straight, square edges. This is where the fun begins because the Runways in KSP are made up of separate sections which do not have square edges or lend themselves very well to having physics colliders added to them easily because of their shape.The ends and bases of them are rounded and extend into the ground and Unity changed the way physics colliders act from when these models were first created for KSP and the current versions of Unity KSP is running under now.
Level 3 Runway
Recreating the models was just not an option given the time that would take. So the process I came up with was to take the existing model, create cut down duplicates of the model meshes that were square so they could be used as colliders (but also had edges that matched the existing seams), line it all up in the modelling software and export.
Next we import to Unity. Using the new meshes I began adding unity physics colliders and then vertex snapping the sections together. Once this was done the Unity objects were put together into a new Runway prefab (a term in unity which creates a prefabricated object which can then be instantiated when the game is running).
Finally all the references to the new prefab must be re-generated to hook up all the code that supports destructible and upgradable facilities.
What could go wrong? Well there are a lot of these references scattered throughout the game setup. You can easily miss one or two and then wonder, “Where'd my shiny runway I spent so many hours recreating go?”
Once the runway was in the right position there were still some small gaps, and while not letting my OCD get in the way too much, I began painstakingly doing fine tuning adjustments to the positioning of the runway sections.
A bit later and finally everything is right and you get the new and improved runway ready for testing.
Rinse and Repeat
… And so the process then gets repeated with the Level 2 runway.
Luckily I've now got a workflow happening and the Level 2 runway is done in half the time.
With that done… Now what should we do with that lumpy bumpy Level 1 runway?
Preamble (or pre-ramble if you know me)
After some discussions we thought we’d make use of the Dev Articles section of the forum and post some experiences, stories and information about various development topics. Hopefully this is the first of a number of posts by members of the development team, detailing both old and new topics to do with KSP and our work.
These will not be scheduled in like regular forum posts. Rather think of them like a blog, with multiple authors (the devs), who can share info when they are able.
There’s a number of topics we have thought to talk on, but for this first one I thought I could type about something that Julioz and I have been spending a fair bit of time on - Localization and Fonts....
Localization is the process by which a product can display text and audio in a language local to the consumer. While English is a very common language there are many people who do not speak it fluently and have asked/and appreciate the ability to more easily read, comprehend and in the end play KSP.
As we would be needing a much larger range of characters and symbols to be able to handle many different languages we started by having a look at our current fonts and whether they would be up to the task. After some discussion amongst the team it was decided that we would be better served by moving to a different font by the name of NotoSans. This Open source font is similar to the OpenSans font we have been using in KSPedia, but has a much wider character set for Localization so it was decided this would be a good choice.
Getting it to “fit” KSP
You just swap in the new font and all good right? Unfortunately it’s not that simple and that’s where Julio and I have spent a bit of time. We use a plugin called TextMesh Pro to place text in KSP. It’s very flexible and easy to use, so the actual swapping of fonts wouldn’t be too big a problem. The challenge that raised its head was when we looked at the size of the fonts and how we would “fit” things.
Having a printing background in my other job I could tell you all about the Em Square and how that relates to point size, but in the interest of not boring you all to death I’ll give you the simple version: “Not all fonts are created equal.” The visible portion of a 14pt Calibri ‘A’ character is not necessarily the same height and width as a 14pt NotoSans ‘A’ character, and so on. Here’s some lovely ascii art that shows an extreme example:
The new NotoSans font is wider and taller than our existing Calibri font, so after choosing that font we then need to scale it to suit the games UI - or alternately adjust the game objects to suit the new size. We decided to scale the font down slightly to get things close to the size you are all used to and then adjust the weighting of the font to make sure it wasn’t too thin or hard to read.
Weighting it as well
Speaking of weighting (which is in essence the width of each stroke in the character), as some of the languages we are doing contain graphical characters (sorry if that’s the incorrect term) like Kanji we have to work with the font settings a bit to make sure we don’t blow out the characters by overweighting the stroke, and on the flipside we don’t make the weight too narrow that the text disappears. Heres some examples of how not to do these types of fonts…
And my personal favorite: when I forgot to change all the font sets, this sorta changes the emphasis on some things.
So after a fair bit of back and forth to make sure all of our eyeballs are correctly calibrated we end up with something like this:
Once we had that all tested, and given the green light, Julio and I could sit back and watch the rest of it all magically happen! Alright maybe not.
After that we work to ensure all the text (in all the character sets and languages) fits in the spaces of the KSP UI - this happens alongside the translation, checks of text translations, more tweaks, further checks,... and that is a whole other story.
Here endeth the first article.We’ll try and bring these to you periodically on various topics of things we are working on or that we find might be good to shed more light on.
It’s a very (very) old expression: “there is an end to everything, to good things as well”. It’s held true since it was first said, and it holds true for my time at Kerbal Space Program as well. Although I’ve always known that new things would come along, saying goodbye to a project I’m invested in as much as this one is never easy and never comes at an opportune moment.
Just under four years ago I started posting on these forums, helping out in Support where I could, and creating some rudimentary support documentation. Not long after the request came to join the experimental testers, soon followed by one to become a forum moderator. Two years ago I was then given the chance to come on board officially at Squad professionally, working my way up from Lead Moderator - taking care of the forums only - to Community Lead and taking charge of many more aspects of the community as well as PR and marketing. There’s been a lot to learn along the way, and I’m especially proud of having been able to help guide the game through it’s official 1.0 launch.
During this whole time the community never ceased to amaze me. Between forum posts, videos, livestreams, private messages, and any other avenue you can think of there was always something to brighten a day when working with you. I especially love reading about ways in which the game has touched people’s lives, and made them realize a previously undiscovered passion, or even inspired them to pursue a career or education in rocket science.
Now it’s time for me to move on to new and exciting projects, but I could never forget the time spent here. I thoroughly enjoyed working with the developers, taking care of the community, and of course playing the game. I can only hope you manage to inspire Andrea and Daniele similar to how you inspired me. To go back to where this post started: there is an end to everything, to good things as well. Thank you all for being an amazing community, I hope you never stop being that. Feel free to poke me on the forums or on Twitter at any time, and you’ll definitely still see me visit a KSP livestream every now and then.
Tomorrow Kerbal Space Program will launch on XBox One. We’re very excited to share our passion for the game, rockets and space with a lot of new players, and we hope that many of you will not only enjoy Kerbal Space Program, but that you will also be inspired to create, to share, and to explore the galaxy like so many PC players over the years.
Kerbal Space Program will be available for $39.99 or your regional equivalent in the XBox One store as a digital download at the Midnight of your locale (Pacific Time in the United States). The game will be available in Argentina, Austria, Belgium, Brazil, Canada, Chile, Colombia, the Czech Republic, Denmark, Finland, France, Germany, Greece, Hong Kong SAR, Hungary, India, Israel, Italy, Mexico, The Netherlands, Norway, Poland, Portugal, the Republic of Ireland, Russia, Saudi Arabia, Singapore, Slovakia, South Africa, Spain, Sweden, Switzerland, Turkey, the United Arab Emirates, the United Kingdom, and the United States. We’re still looking into the possibility of releasing in more countries, though we still require age ratings and other administrative certifications to do so.
We’ve received a lot (a lot!) of questions about the European release for PlayStation 4 as well. Rest assured we’re working on this. The PlayStation is not one single instance, but is divided into three regions: America, Europe and Japan. For a game to release in a certain region it needs to be certified there, regardless of previous certifications. There are further regional differences, but it’s not within the scope of this message to dive into that. We’re working to get the certification to release in Europe, and we thank everyone who has patiently followed the news on this topic. We’ll get KSP to your console as soon as possible, and we'll keep you updated during this process.
Reaching this point would’ve been impossible without the help of Flying Tiger Entertainment, who were with us every step of the way leading up to this release.
After the recent pre-release, 1.1 release and follow on patches we’ve finally had some time to look back at the overall bug tracker state and look for some areas for improvement.
There are currently about a dozen tracker projects which cover the various test teams, platforms and backlogs, and while investigating the tickets that are currently open we found ourselves wondering if we should make some bigger changes at this point in time:
Across all the trackers there are approx. 2700 open “bugs”;
On top of these are 800 feedback and feature items;
These tickets go back to the start of the tracker (back in 2012) and as a result a lot of them were most likely fixed, but not closed out in the trackers;
Doin’ the Maths
Now obviously we could start at #1 (“Docking nodes get misplaced on loading certain docked vessels”- it’s already closed, I checked) and work our way through one at a time until we have checked for duplicates, retested or confirmed and followed each one through, but simple mathematics tells us this might be a problem. If we assume it takes 20ish mins to work each of these that’s 112 eight hour days of test time, and that’s if every bug report is perfect and the steps followed don’t need any communication with the reporter to ask questions, clarify, etc.
That would be split across multiple people in reality, but it doesn’t include triage of any new bugs, or involvement in development and testing that’s underway currently or needed in the future.
The Painful Truth
Hopefully many of you reading this come to the same conclusion we did: With the amount of resources we have available within the team, it’s simply not the best use of time to go through all these bugs in this way -- but we do know that there are some very good reports in there that still need to be fleshed out and worked on.
So How Do We Tackle This?
The idea we are working towards is to tackle this in a couple of stages:
We are going to mark all open the bug reports prior to a yet to be determined date as requiring clarification;
When this is done we need you guys and girls to eyeball these tickets for clarification and let us know if they are still a bug and still important;
After a few weeks any bugs that have not been touched will be archived away – still there but removing a lot of noise for the producers and developers to see what is key;
By making these changes we hope to get down to the more important issues that are outstanding and get them front and center in planning and resource allocation. We’ll also be similarly tweaking a number of test and internal projects to help sharpen our focus internally as well.
What’s Next and What Can You Do?
We do know that this may not be a universally appreciated idea, but we do feel it’s a lot better than some of the alternatives and does give us the chance to improve as well (it’s probably better than TriggerAu’s original “Slash and Burn Festival” idea too).
Before we kick this off we will provide more details about what sort of info and updates will best help us to get to grips on each bug, so please keep your [electronic] ears open.
The involvement you all have with the tracker is massive, there are very few communities as involved or interested in the state and improvement of the games they play as this one and we do truly appreciate it. I think that together we can really clean out the ancient dust bunnies from the tracker and help clarify the key issues.
For the past four years, I’ve worked alongside the most talented, passionate and dauntingly intelligent people I’ve ever met, on a game like no other. It's come time though, to step back and focus on other things.
Four years ago, I successfully applied for a forum moderator position on the forums and spent the next six months helping run every facet of it. Due to the development model that Kerbal Space Program followed, early access to updates was available to moderators for the purposes of testing and I became very interested in that. As the game grew, so did the demand for more rigorous and organised testing, and soon I worked with the developers to expand and invigorate our Experimental Testing Team. Not long after this, around the time we moved to Unity 4, we set up the QA Team and I volunteered for one of the QA positions.
About five months later, I was employed as QA Lead and Director on KSP. I held this position through the rest of KSP’s early access and into release. It was an extremely rewarding time and one that presented a myriad of challenges that we overcame as a team.
After version 1.0 released, I moved to the role of Technical Producer. In this role I assisted the developers with organising, documenting and communicating development, oversaw the QA and Experimental phases and ran many, many meetings and standups.
Kerbal is a project like no other; it’s a game like no other, it has taught me innumerable lessons about software development, game design, QA... the list goes on. I’ve met tens, if not hundreds of absolutely amazing people who have done things that I could only hope to achieve. I’ve watched KSP affect people’s lives in ways I would never have imagined; inspiring them to pursue careers in aerospace and astronomy, enjoying time with their friends on a rainy day or just having fun.
In the time since I started working on KSP, the community has grown exponentially through a massive amount of initiative and enthusiasm from you all. The feats you’ve accomplished in-game and within the community are awe-inspiring.
Working on KSP has been a dream come true, it’s a game I have always loved to play and loved even more so to work on. Four years is a long time and after all this time, it’s time that I move on and let someone else take the reins. I couldn’t have asked for a better team to have worked with, or a better project to work on. I’ll truly miss the game, the development team and - perhaps most of all - the brilliant community. You’ve all changed my life for the better in countless ways and given me hope, not just for gaming communities, but for the brilliance of people.
We have big news to share with you today: as things stand Kerbal Space Program will be releasing on XBox One and Playstation 4 next month! After months of hard work we're finally ready to share the exciting adventures of our little green Kerbals with tens of millions more gamers around the world, hopefully inspiring them in the same way we've seen PC players affected by our game over the last four years.
"Following the huge success Kerbal Space Program has had on PC with players and critics alike, we want to give console players the opportunity to play Kerbal Space Program in this redefined user experience. It has been a long road but finally we are confident of the quality of the game on consoles. An awesome control experience awaits you, as well as easier access to the wonderful world of space exploration, where even exploding is a lot of fun. We invite everyone to enjoy the excitement of flying rockets built by yourself, landing on planets and much more!"
- Ezequiel Ayarza, CEO
Of course, we'd like to thank the amazing people at Flying Tiger for going down this road with us, and getting the game ready for release. We're expecting to give you a definitive release date in the coming week(s). Until then, fly safe!
In celebration of tomorrow's Asteroid Day events we have updated the Asteroid Day mod to be compatible with Kerbal Space Program version 1.1.3!
Last year we partnered with the B612 Foundation to bring you the Asteroid Day mod which will add a space telelscope, a new experiment, and a unique contract.
The Sentinel Infrared Telescope mimics the real world Sentinel mission being planned by the B612 Foundation, which plans to map 90% of the larger asteroids threatening Earth's orbit sometime between 2018 and 2024. Due to sun glare it is difficult for telescopes on Earth to observe objects passing on the planet's day side. Deploying a telescope into a solar orbit near Venus and facing it away from the Sun, back towards Earth's orbit, would cover that blind spot.
Your mission will be to recreate this mission profile in Kerbal Space Program, deploying a telescope around Eve’s orbit. When deployed with an antenna and a power source between Eve and Kerbin, aligned to face away from the Sun, and activated, the telescope will begin to map the orbit of the outer planet in a 200° vision cone for passing asteroids.
This pack also includes a long-term contract to map asteroids around Kerbin as well as other planets that match various specifications. It differs from other contracts in that it encourages the use of existing infrastructure. It does not require a new vessel for each contract, and each scan is faster with more telescopes deployed.
In addition to the Asteroid Day mod we've also updated the Kerbin Cup official mod to be compatible with KSP 1.1.3!
The 1.1.3 patch is now available! We’ve taken our time over the past couple of weeks to tackle as many issues as we could in this patch and the results speak for themselves: close to 100 fixes have been logged compared to the previous version of KSP, and we even found time to hide something small in the game that we’re sure a lot of long time fans will appreciate!
Here's the complete changelog:
=================================== v1.1.3 ============================================================
* Fixed game crashing during deletion of parts under certain conditions.
* Fixed Gizmos buttons not properly highlighting after loading a craft.
* Fixed Fuel tank Part Action Window sliders to dynamically update symmetry partners when adjusted in editor.
* Fixed frozen parts showing up in front of the main vessel.
* Fixed fairings being see-through when a part inside or behind is highlighted.
* Fixed certain fairing configurations causing inputlocks.
* Fixed interstage fairing panels not being properly deleted when an interstage is removed from the ship.
* Fixed Abnormal lighting and contrast.
* Fixed Re-rooting and attaching frozen parts causing improper part selection.
* Fixed an exception in FXModuleAnimateThrottle when in the editor.
* Fixed inputlock preventing pressing [Delete] key from deleting a part.
* Subassemblies can now be used as the start of a craft (fixes editor being non-responsive).
* CoM indicator now accounts for mass of physicsless parts added to parent.
* "Ground Crew" option now toggles off all animated components of VAB/SPH. Fixes increased CPU Load and Temp.
* "Place" gizmo now provides onscreen message in editor to be consistent with other gizmos.
* Fixed Circular Orbit Ap/Pe jump on exiting timewarp.
* Fixed on-rails SoI transition message to properly report both SoIs.
* Greatly reduce Apoapsis/Periapsis changing with no input, with thanks to ferram4 and eggrobin. option is toggleable in Settings->Gameplay and tunable in Physics.cfg.
* Lower the thresholds for floating origin shift and krakensbane when above the inverse rotation threshold, and use doubles when recomputing velocity during change (and do so immediately rather than via PhysxX).
* GetEccentricAnomaly now correctly returns negative eccentric (hyperbolic) anomaly values when the true anomaly is before the hyperbola's periapsis, and should be more numerically stable.
* GetEccentricAnomaly no longer spams E is NaN.
* Conic patch creation is a little more efficient.
* Ignore G spike on the frame where SoIs switch.
* Orbit reported position will no longer be a frame ahead of velocity.
* [KSPedia] Fixed Bug with KSPedia asset bundle Dependancies.
* Fixed symmetric part stage icons not expanding in stage manager.
* Fixed Quicksave filename accessibility.
* Fixed Multiple core heat producers not being properly cooled by radiator panels.
* Fixed NRE when trying to overwrite or cancel out of save folder overwrite dialog.
* Fixed E is NaN! tA: (pi) spam with some generated contracts.
* Fixed Flags no longer displaying properly in the Tracking Station Info Box..
* Fixed Flag transparency issues in editor.
* Fixed Science lab spamming the log with "Updating" warnings whenever right-click menu is open.
* Fixed funds penalties not being applied when Hiring Kerbals.
* Fixed being unable to rename vessels via Knowledge Base.
* Fixed NRE in ModuleGrappleNode.Release when parent is null.
* Fixed UI_ChooseOption - onFieldChanged being called even when the field value hasn't changed.
* Fixed Body lift missing when loading the Physics.cfg file.
* Fixed Parts Tooltip window location being misplaced when changing UI scale.
* Fixed issue with the sea level pressure display in the Knowledge Base.
* Fixed an exception in PartModule OnLoad and OnStart causing vessel load failure.
* Fixed a NaN in FlightIntegrator atmospheric thermo.
* Fixed issue in Moment of Inertia calculations.
* Fixed Rocket Exhaust FX not being moved by FloatingOrigin/Krakensbane when emitters are disabled.
* Fixed missing parachute deployment sound.
* Fixed VesselModules not being properly destroyed when a vessel object is destroyed.
* Fixed unit tests from main menu causing every test to be run 4 times.
* Fixed having an abstract UnitTest type causing TestManager to throw an exception.
* Fixed regression that was causing global gravity to be non-zero, which should help with phantom drifting, especially with wheels.
* Fixed a logical issue causing crew rotation objectives to be much rarer than intended on station and outpost contracts.
* Fixed staging requiring two activation's when resuming in flight mode.
* Fixed navigation waypoint getting stuck if a survey is killed in the middle of the flight scene.
* Fixed Waypoint Markers not showing on Navball in IVA view.
* Fixed potential error from generating if attempting to IVA an EVA kerbal that has just been loaded outside of a vessel.
* Fixed RCS TorqueProvider implementation to take thrust limiting and alternate precision mode into account.
* Fixed an issue where the NBS dialog was not resetting its coordinates properly.
* Fixed reported typos and grammatical issues in various areas of the game.
* Fixed ITargetable FlightCoMTracker.GetVessel always returning null.
* Fixed Asteroids all spawning with a mass of 150t, regardless of class.
* Fixed race condition with map filters causing asteroids to be invisible in new games until they were modified.
* Fixed asteroids sometimes appearing to be pitch black while being seemingly immune to light when rotated at certain angles.
* Adjusted science data collection range of Mk1 cabin to match other science options.
* Kerbals can no longer "Take surface sample" while in command seat.
* Fairing base purchase and entry costs adjusted to vary by size.
* Part Action Window for symmetric parts no longer needs modkey to open when a sibling window is open.
* [Modding] Additional access to fields in Mission Control.
* [EVA, Gameplay] R&D upgrade text adjusted.
* Added onVesselCrewWasModified, which consolidates many events in which crew changes on a specific vessel. Use this to fix a few issues with crew rotation objectives.
* Added ITargetable.GetActiveTargetable, which allows us to specify if a target should be allowed on something that is part of the active vessel.
* Added AeroFXIgnore layer so some parts (Gigantor e.g.) can have parts of their model ignored by AeroFX. Fixes an issue with odd Aero FX streamers.
* Added "EVA" layer, added it to various cameras, physics casts, lights, and collision matrices to behave exactly like normal parts, except suspension raycasts ignore it entirely. Prevents violent interactions when kerbals touch wheels.
* Added alwaysRecomputeLift to ModuleControlSurface so it can be set to not ignore slight actuation.
* Added wheel weight stress and slip stress multipliers to game settings, allowing players that do not want these stresses to disable them globally.
* Added onCommandSeatInteraction GameEvent, and deployableSeated to science experiments. Use these to disable scooping up surface samples when seated.
* Added Felipe to crew name generation.
* Satellite contract orbit generation made much more modular and maintainable, allowing us to validate generated orbits now. If an orbit parameter becomes corrupt through save manipulation or other means, that parameter can be regenerated without affecting the rest of the orbit.
* Clarify R&D facility upgrade text to make it clear that Kerbin is still fair game for surface samples without the astronaut complex upgrades.
* Crew Transfer more moddable.
* Game is now paused going to MissionControl, AstronautComplex, Admin, R&D and unpaused when closing them.
* Renamed Telus ladder to Kelus Ladder to avoid naming conflicts.
* Improvements to flag rendering in KB.
* Improvements in Tutorial input locks and Error checking
* Adjustments to the Repair/Downgrade costs of the Facilities
* Changed "Cancel warp" to use forward slash instead of Esc.
* When repaired, wheels become temporarily immune to weight and slip stresses, slowly rising back to normal over a period of between 30 to 90 seconds.
* Reduction in the creation of Garbage Objects in Flight scene.
* Reduction in the creation of Garbage Objects in Space Center.
* Optimize Part.GetConnectedResources and Vessel.GetActiveResources for speed and to not create garbage.
* Dramatically improve resolution of asteroid textures, while simultaneously improving their shader performance by 400%. New shader can have very subtle desaturated brown/red hues sometimes.