• Developer Articles

    1.6 has brought a lot of great changes, and we’re really thrilled with what the team has created for it. One of the changes that we've done, and something we felt strongly about doing, was tuning work that we felt would improve the quality bar of the game.

    Craft Improvements
    First, we've gone through all the stock craft, including VAB, SPH, and Making History craft, delivered for the game, with an eye toward updating them for the new parts that have been released in 1.6, and also improving the fly-ability of many of our craft.  At one point, the idea was to have some of these stock craft have flaws for the player to correct.  This did not have broad awareness in the community,  so we've improved the flight behavior of quite a few of our craft - including using features like auto-strutting that weren't around when they were first added to the game.
    In particular, all of our space planes - the Learstar, the Dynawing, and the Slim Shuttle - have been fine tuned to improve their control behavior.  They're still challenging to fly, of course, but you don't have to fight their controls quite so much.  We've also strutted and improved the fly-ability to craft like the Albatross, Muna 1 & 2, the Acapello and several others.  We encourage you to check the 1.6 change log for the full list.
    Making History Engine Rebalancing
    The other major change was adjustment to the tuning of a number of Making History parts - especially the engines.  The engine changes in particular may be more controversial, and we'd like to explain the rationale behind them. 
    The overall goal here is to put all the Making History engines in line with base game tuning.  To let them have their own niche, and to neither obsolete nor be obsoleted by other engines.  And generally, engines that are either bigger, or more specialized, will be unlocked deeper in the tech tree.  Finally, we’re trying to make as few changes as needed, so that they won't drastically change the purpose of an engine.
    NOTE: For all stats in tables - a green background indicates an improvement over the current version, a red background means it was worsened.
    Small ASL Engine Tuning
    First, let's look at the smaller ASL engines. There are three Making History engines in this size category - the Skiff, the Bobcat and the Kodiak.  Here are the relevant stats vs similar base game engines:

    Engine Comparison Thrust (Vac) ISP Vac ISP ASL Mass Vac TWR ASL TWR Cost/kN Thrust Tech Level Gimbal EC/s Crash Tolerance Cost Entry Cost Reliant 240 310 265 1.25 19.57 16.73 4.58 General Rocketry (3) 0 7 7 1100 3200 Swivel 215 320 250 1.5 14.61 11.41 5.58 Basic Rocketry (2) 3 6 7 1200 3500 Thud 120 305 275 0.9 13.59 12.25 6.83 Advanced Rocketry (4) 8 0 7 820 3500 Vector 1000 315 295 4 25.48 23.87 18 Very Heavy Rocketry (8) 10.5 3 7 18000 115000 Current Kodiak 240 305 265 1.25 19.57 17.01 5.42 Heavier Rocketry (6) 0 3 6 1300 4200 New Kodiak 260 300 285 1.25 21.2 20.14 4.23 Heavier Rocketry (6) 0 5 9 1100 4400 Current Skiff 300 330 265 1 30.58 24.56 5 Heavier Rocketry (6) 2 3 6 1500 4500 New Skiff 300 330 265 1.6 19.11 15.35 7.67 Heavier Rocketry (6) 2 3 7 2300 9200 Current Bobcat 400 310 290 2 20.39 19.07 5 Heavier Rocketry (6) 5 3 6 2000 6000 New Bobcat 400 310 290 2 20.39 19.07 5 Heavy Rocketry (5) 5 8 12 2000 800
    Kodiak:  Overall, the Kodiak need the most adjustment - it’s just entirely matched or outclassed by the Reliant, which appears earlier in the tech tree as well.  Therefore, and in keeping with its real world equivalent then RD-107, the Kodiak's stats were adjusted to give it a much better ASL ISP, a lower cost per kN of thrust, and a better durability.  This gives it a niche as a 1.25m liquid fueled booster, leaving the Reliant as the more general purpose no-gimbal engine.  The extra specialization helps to keep it at Heavier Rocketry, however, to match its historical partner, the Cub.
    Skiff: The Skiff's tuning is closer to ideal , but it turned out to be *too* good in too many categories categories - more efficient, better TWR, and lower cost/kN than other engines.  It occurs later in the tech tree, so we've chosen to keep its high efficiency at the cost TWR and cost. Now it’s a great sustainer-category engine - its ASL ISP and cost won't justify its use as a main engine anymore, but it’s fantastic as the center stage with some SRBs or Kodiak-powered boosters.
    Bobcat: The bobcat had tuning most in line with the stock, so few changes were made.  It got sturdier, and it moved earlier in the tech tree to give another ASL option in Heavy Rocketry, as we felt the end of the tech tree was getting crowded.
    Large ASL Engine Tuning
    Then let’s look at bigger ASL engines:  In this category we have the Mastodon. 
    Note: The stats for the Twin Boar reflect what they would be without the built-in tank.

    Engine Comparison Thrust (Vac) ISP Vac ISP ASL Mass Vac TWR ASL TWR Cost Cost/kN Thrust Tech Level Gimbal EC/s Crash Tolerance Entry Cost Vector 1000 315 295 4 25.48 23.87 18000 18 Very Heavy Rocketry (8) 10.5 3 7 115000 Mammoth 4000 315 295 15 27.18 25.46 39000 9.75 Very Heavy Rocketry (8) 2 12 20 115000 Twin Boar 2000 300 280 6.5 31.37 29.27 11250 5.63 Heavier Rocketry (6) 1.5 0 20 65000 Mainsail 1500 310 285 6 25.48 23.43 13000 8.67 Heavier Rocketry (6) 1.5 12 7 38000 Skipper 650 320 280 3 22.09 19.33 5300 8.15 Heavy Rocketry (5) 2 10 7 14000 Current Mastodon 1350 290 280 5 27.52 26.57 22000 16.3 Very Heavy Rocketry (8) 5 3 6 135000 New Mastodon 1350 305 290 5 27.52 26.17 8000 5.93 Very Heavy Rocketry (8) 5 8 15 32000 Mastodon: The current Mastodon has no niche, being outclassed in all categories by other large engines, and being really expensive to boot.  The new Mastodon therefore become both more efficient and significantly cheaper.  Now it is an ASL workhorse that doesn't perform QUITE as well in Vacuum as engines like the Vector and Mainsail, but it’s more flexible and a little more efficient than the Twin Boar, without quite matching the Twin Boar's amazing TWR and cost.
    Vacuum Engine Tuning
    Next we've got the vacuum engines:  In this category we've got our most controversial engine, the Wolfhound, as well as the Cheetah.  
    Note: For this chart, ISP ASL is not listed - with good reason.  It just doesn't matter for engines that are almost exclusively used in a vacuum, it's not a significant balance criteria.

    Engine Comparison Thrust (Vac) ISP Vac Mass Vac TWR Cost Cost/kN Thrust Tech Level Gimbal EC/s Crash Tolerance Entry Cost Terrier 60 345 0.5 12.23 390 6.5 Advanced Rocketry (4) 4 0 7 1600 Poodle 250 350 1.75 14.56 1300 5.2 Heavy Rocketry (5) 4.5 8 7 4200 Rhino 2000 340 9 22.65 25000 12.5 Very Heavy Rocketry (8) 4 12 7 68000 Current Wolfhound 375 412 2.5 15.29 1680 4.48 Heavy Rocketry (5) 3 8 6 6200 New Wolfhound 375 380 3.3 11.58 3000 8 Very Heavy Rocketry (8) 3 8 6 12000 Current Cheetah 125 345 1 12.74 1000 8 Heavier Rocketry (6) 3 3 6 3000 New Cheetah 125 355 1 12.74 850 6.8 Heavier Rocketry (6) 4 5 7 3400 Wolfhound: The Wolfhound is amazing in every category that matters - an ISP that's 20% higher than any other LFO engine, great TWR, unlocks relatively early, and is the cheapest cost/kn for an LFO engine.  Sorry rocketeers - the Wolfhound needed adjustment to have some valid trade-offs vs other vacuum engines.  It's still an amazingly efficient LFO engine, without having the sort of abysmal thrust & cost of a NERV, but now it doesn't completely overshadow every other LFO vacuum engine.  As a more specialized, high efficiency engine, its moved back in the tech tree with the other Making History Apollo-class parts as well.
    Cheetah: The cheetah, conversely, is too expensive and heavy to justify its relatively low TWR, low-end ISP and high cost, so several improvements were made to help it stand out.  Now it’s a bit like a smaller Wolfhound.
    Small & Maneuver Engine Tuning
    Finally we've got the small engines - for Making History, this is the Cub.

    Engine Comparison Thrust (Vac) ISP Vac ISP ASL Mass Vac TWR ASL TWR Cost Cost/kN Thrust Tech Level Gimbal EC/s Crash Tolerance Entry Cost Ant 2 315 80 0.02 10.19 2.59 110 55 Propulsion Systems (5) 0 0 7 1500 Spider 2 290 260 0.02 10.19 9.14 120 60 Precision Propulsion (6) 10 0 7 1750 Twitch 16 290 250 0.09 18.12 15.62 400 25 Precision Propulsion (6) 8 0 7 1600 Puff 20 250 120 0.09 22.65 10.87 150 7.5 Precision Propulsion (6) 6 0 7 2500 Spark 20 320 270 0.1 20.39 17.2 240 12 Propulsion Systems (5) 3 0 7 2800 Current Cub 40 320 270 0.18 22.65 19.11 1000 25 Heavier Rocketry (6) 22.5 0 6 3000 New Cub 32 310 280 0.18 18.12 16.37 800 25 Precision Propulsion (6) 22.5 0 7 3200 Cub: The Cub, relative to other maneuver engines, is too good in too many areas.  Its ISP as good or better than all others, great TWR, fantastic (though only 1-axis) gimbal range and it is surface attachable, something most engines pay a penalty.  Therefore, it got a bit of an thrust and efficiency nerf - it actually generated far too much thrust relative to its companion, the Kodiak, which helps make its TWR more reasonable as well. Finally, it moved to the appropriate tech node for maneuvering engines.
    Other Making History Tweaks
    We've also made the engine plates fall into tech nodes appropriate for their size, rather all in the same node.
    Anyway, I hope you'll appreciate these changes - we'll be watching community reaction to see how they go over!  We encourage you to comment on these changes.

    Obviously one of the core components of the Making History Expansion is the Missions themselves. Here you can read some information and get some insight (I hope) about building missions and how the MissionSystem manages these behind the scenes.
    This blog did end up a bit long, but it hopefully is all interesting
    What makes a Mission?
    In a nutshell (love that term) a mission is a series of nodes and connections where the player starts at the origin and can follow the paths from node to node until they hit an ending. For the programmatically inclined this is, in essence, a Finite State Machine (or FSM).
    ...warning dev type words ahead…
    In the mission system we do something a little different to a traditional FSM in that we don’t store every transition in the persistence. We added some logic to the nodes so that a node can be flagged as a “catch all” - which means that the mission can transition to this node from any other node. This means we can store more information in a mission file without needing to store every transition individually, and yet still unpack it to be used like an FSM in the game itself.
    So in FSM parlance the Nodes are a state and Connectors are the transitions. The game then has a parsing engine that keeps track of each mission and handles the update loops that are used to progress each mission between nodes. And the Active Node is the active state.
    It’s at the core of how a mission is played once its put together, and below well get into some of these details.

    What is the MissionSystem?
    The MissionSystem is that parsing engine I mentioned just before, It is the main class that manages missions and technically it’s what’s called a Scenario module in KSP. It loads the mission components from a save and then handles processing them and tracking where the mission is up to, when it should change nodes and when to trigger actions. Other Scenario modules in KSP include the ContractSystem, the FundingSystem, CommNetScenario, hopefully your seeing a pattern here - all things that run as components of a game and are used to load and save persistent data - then handle it during game play.
    Travelling between Nodes
    So let’s keep that terminology (of an FSM) in mind as we progress a bit further. At any point in our mission there is always a single Active Node (like states in an FSM) - it’s like highlander in that “there can be only one”.
    The MissionSystem then needs to check whether it is time to move to a new node from this one. To do this the mission system sequentially checks the nodes that the ActiveNode is connected to - this includes the nodes directly connected and any catch all nodes.
    How does the mission system know when it’s time to change nodes? Each node can have a number of modules attached to it and these help it to understand when that transition should happen as well as anything to do after the active node changes:
    The checks for when to change node are handled by the TestModule: 
    A TestModule is a class that defines logic that is tested and returns True when the test passes. Each Node can have one or more TestGroups, and each TestGroup contains TestModules.  Once all the TestModules in any TestGroup return True that node will activate and the missions Active Node changes.  If a Node has no TestGroups/Modules it will be true immediately The actions that occur when a node activates are handled by the ActionModule: Each node can have one or more ActionModules attached. These “Fire” when the node activates - but this doesn’t mean you can’t use programming structure like co-routines to have these fire immediately and perform long running actions. Now that we’ve seen the Nodes and Connectors we need the third leg of our milking stool - the Active Node. The MissionSystem looks at the active node in each update loop and checks all of the nodes that it can move to. This means any node that has a connection from the active node and any catch all nodes.
    Other Bits and Pieces
    But what about these other things I see in the Builder? what is a docked node? how do I see whats a catch all node? Well as they say a picture is worth a thousand words (although with localization that number is probably rounded) so here’s some points of things I’ve found helpful and interesting:
    The Start Node:
    Hopefully the name gives it away, but in any case this is the Active Node when a mission first starts. The mission system always starts here and then tests the connected nodes. 
    Spawnable nodes can be docked to the Start Node (only these types of nodes and no others). The first spawn vessel node docked to the start node is the starting vessel for the mission

    Docked Nodes: 
    This is a special kind of connection in that the docked node will be tested once only when the parent node (the one it is docked to) is activated. It’s a great construct to help you do things like give various scoring adjustments when a node is activated, or change the path of a mission at a specific point in time.
    So let me give you an example of that one:

    Assuming that the Go to node shown as 1 is connected to the active node, then when “My Other Vessel” reaches that location:
    The GoTo Node will become the active node.  The system will then check if the MET is less than 2h, if it is that node becomes active and no other docked nodes are tested If not then the MET < 3h30m is tested, if thats true then  that node becomes active and so one If any of the docked nodes is true then the connected action nodes will fire immediately adjusting the score then the player needs to get to 5000m above sea level to proceed further.
    Catch All Nodes:
    These are nodes that have no specific connection to their input pin. They will be tested regardless of which node is the Active Node.
    From our original annotated image you can see the catch all node there - a Vessel destroyed - which means that if at any time in the mission “Trigger’s Vessel” is destroyed then that node will activate.

    Connection Test Orders:
    How do you know what order the MissionSystem will check which node is next? For docked nodes it should (hopefully) be visually obvious - its the order they are docked, but when there are multiple connections the order can be found (and adjusted) in the node Options in the Settings Action Pane (the SAP - in the top right of the Builder)
    We’ll combine this idea with the next ones...
    Some other Node things:
    Activate Once Only - This setting is on by default, to help prevent infinite loops, but with careful work you can disable this to use some rudimentary loops in missions.
    Always True Nodes - These nodes can be used for logic structures to make things move along
    Always False Nodes - You can use these to mislead your players - yeah I said it - to change what they think the goal may be.

    This one needs explanation I know - I’ve color coded the paths to help. Let’s say you want to direct a player to EVA from one vessel and then get into the Mk1Pod in a nearby vessel. But, you want to add some pressure by blowing solar panels off the vessel until they get there (dont ask me why, maybe your that kind of kerbal). Heres how this solution for that works:
    Your player gets to Node A by EVAing a kerbal  The mission moves immediately to Node B (cause its always true) and we have also set it to be able to activate multiple times so we can loop back to it. From B it tests the nodes according to the order configured in Node B via its Node Connections Order (as below)
    So it tests if the Crew boarded the target part, then tests if its been 120 secs since we EVA’d, and so on.. Let’s assume we reach the 31 second mark.. The mission then moves to node C (via the blue line) and then explodes one of the solar panels off the vessel It then activates Node B again and starts testing again. So every thirty seconds we blow a panel off the vessel until either a) they reach and board the Mk1 pod, or b) they take too long and we find something else nasty to do.

    The End
    I know this one has been a bit long, but hopefully I’ve given you some insight and information into some of the workings and possibilities with the Making History Expansion and Missions. Catch you next time.

    As we worked on some of the historically inspired missions for Making History we came back across one of our old favorite challenges - how to name portions of a vessel. So I thought I would share some information about what we looked at and where we ended up with respect to the new Vessel Naming additions in KSP 1.4.
    The Problem
    In KSP you build (and sometimes even save) a series of craft, which when launched become vessels in the game. So you build your magical Kerpollo 11 craft, send it to the launchpad, fire off the main engines, explode on the pad, revert to the VAB, adjust a bit more, launch again, lift off, flip due to misplaced aero parts, plummet to the ground, explode in a different place, revert to VAB... alright admittedly this is how my game usually goes and I should maybe skip to the actual naming stuff...
    So we launch our sufficiently tested Kerpollo 11 and as we stage off used sections they get automagically named Kerpollo 11 Debris, or Kerpollo 11 Probe, and we end up once we reach the Mun and land with our Lander on the Mun called Kerpollo 11 and a half dozen other Kerpollo xxxx variations around the solar system. And then there's the always fun, rover scenario, where when you deploy the rover it’s called Shipname pod of the wrong type. As we were implementing some of the Making History missions we really wanted to adjust this behavior so we could name sections of a vessel and the CSM could be Kerpollo 11, the Lander "The Beagle" (cause the beagle has landed made me chuckle), and so on...
    After a quick brainstorm we came up with following solution: we’d simply change the structure so that a vessel would be made up of component parts, let’s call em vehicles, and each vehicle would have its own name... After a quick run through in a few people’s heads we then went and gave ourselves a long talking to, because while that would be a great way to do vessel naming, it would also change one of the fundamental constructs in the game, and all the knock on effects that would have for us, for the players with their existing saves, the modders with other components. And even if that worked, to solve part vessel naming and some other challenges... we still have to handle the dock/undock process
    So using our alternate thinking strategy - aka Nestor telling us to try again - we worked through a few items and came up with the following:
    Each part can have a name, and type assigned to it Each naming preference can have a priority, so when more than one part in a vessel has a name assigned to it we can work out the vessel name When the vessel changes - docking, undocking, staging, we can then reassess the assigned names to determine what each vessel should be called This idea turns out to be quite a simple solution, while also not affecting any existing systems or structures that would mean impacting players and modders.
    So what does this look like in the game?
    On any command module during construction you can open the Part Action Window and choose "Configure Vessel Naming"

    Here we can set a name, set the type that will be assigned and a priority - the higher the priority the more importance this name has over others of lower priority

    So if we look at an example of how this might work in a larger vessel, some photo manipulation magic lets me show you this

    In the example we can see
    A = Red Buggy and is a Rover (Priority 8)
    B = Yellow Buggy and is Debris (Priority 10)
    C = Blue Buggy and is a Rover (Priority 12)
    So when we save and Launch this vessel (A+B+C) it will be a Rover called Blue Buggy 
    If we then undock A we will have:
    A = Rover called Red Buggy  B+C = Rover called Blue Buggy Undock C from B and then dock it with A and we have 
    A + C = Rover called Blue Buggy  B  = Debris called Yellow (and cause its debris it will be uncontrollable - yes that caught me out too) Through this hopefully you can get the names you want on the vessels you want right from the Editor.
    Extra Credit...
    ...or at least I hope I get credit!
    By default this option only shows for Command Modules like the original rename vessel option and only in the editor (VAB/SPH), but if you want to extend that behavior then this info could be useful.
    If you add this to a parts cfg file then it too will have that option appear in editor
    showVesselNaming = True If you change this setting in settings.cfg to be true then the configure vessel naming option will show for parts configured when in flight mode
    SHOW_VESSEL_NAMING_IN_FLIGHT = True You can also configure the maximum number of priorities and the default priority from the settings.cfg
    Hope you've enjoyed this story on some of the development or 1.4.

    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.

    KSC Buildings
    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.

    Do these look familiar:

    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…


    Let's Begin!
    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?
    But that's a story for another day.

    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:

    Job Done?
    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.


    Goodbye, friends

    By KasperVld, in Developer Articles,

    Hello everyone,
    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.
    Fly safe,


    Hello everyone!
    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.
    Fly safe (preferably).

    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.


    A Fond Farewell

    By Ted, in Developer Articles,

    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.
    Thanks and all the best.