• Developer Articles

    One big change we’ve made this version is the addition of some advanced control code to the blades, to help you build helicopters and quad copters that work like the real thing.
    This blog will help you understand what the new functionality does and how you can use it.
    Advanced Blade Controls
    When you enable Pitch/Yaw/Roll control on a rotating blade now, the blades themselves will make a decision on whether the blade needs to be in cyclic or collective mode - on a per axis basis.

    Image 1: Blade COM alignment
    For this craft above, the blades are aligned with the center of mass in the forward direction - so they’ll use cyclic mode for pitch.  They’re far apart horizontally, so they’ll use collective mode for roll.  And because their axis of rotation is flat, they won’t attempt to provide any control input in yaw.
    Cyclic mode:  Cyclic mode is what a normal helicopter’s main rotor does to control the pitch and roll of the helicopter.  They will change their pitch - by the limits you set in the authority limiter control of the blade - as they spin around.   This creates more or less lift to one side or the other of the blade’s disc of rotation.

    Image 2: Cyclic Mode Pitch
    Collective mode: Collective mode is what a normal helicopter does when it wants to change how much overall lift is created.  But as you can see in the picture below, adjusting the relative lift on the two different sets of rotors will cause the craft to roll.

    Image 3: Collective Mode Roll

    Summary and Videos:
    So that’s what our blades now do in a nutshell.  However, understanding these topics can be pretty complicated.  I really recommend checking out some of these excellent Youtube videos for further study.
    Smarter Everyday’s series on Helicopters - Dustin’s videos are fantastic, and these are no different:  
    Craft Building Tips:
    Here are a few tips to help you build your helicopters/quad-copters/etc.
    Make sure to set your authority limiter pretty low.  One of the potential trouble spots you can have is if the blade pitches too much trying to generate control - if it goes OVER the stall limit and starts generating less lift, you’ll get the opposite of what you wanted.  2 or 3 degrees will often be enough. Helicopters can be finicky to control.  Even if you’ve got everything right, any change in a helicopters forward or vertical motion affects the lift on the blades, which generate input coupling.  If flying a plane is like driving a car, then flying a helicopter is like riding a unicycle - don’t be surprised if you have to constantly adjust inputs. Chinook-style craft will generate interesting and unpredictable effects due to axis coupling effects.  If you want to build a really stable Chinook style craft, consider looking into how those are actually built - they adjust their whole rotor assembly plane of rotation, rather than just using cyclic/collective.  http://www.chinook-helicopter.com/standards/Army_D_Model_AQC_Classes/Flight_Controls.pdf The blade controls will work well for using a tail rotor, blades rotating in any axis will respond appropriately.  That said - it’s still easier to manage a helicopter with two counter rotating blades. Finally - if you decide none of this is for you and you just want a helicopter without worrying about the physics so much, feel free to just turn off the Pitch/Yaw/Roll blade controls, and use a reaction wheel to generate the torque you want - no one on the dev team will accuse you of cheating, we promise!


    We’ve raced to fix bugs and add a whole bunch of new parts and functionality in this update – it’s almost a new version unto itself.
    I just want to take this time to highlight some of the additions and changes. 
    Our new propellers take a different route than jet engines in the game.  Jet engines, while historically more difficult to construct, are simpler for a pilot to manage.  Propellers are not meant to compete with them.  However, propellers do offer one unique benefit – you can build rotor craft to fly on planets without oxygen in its atmosphere with the electric rotors.

    I'll cover the basics here - but if you want a more in depth look behind the physics of propellers, this video goes into a lot of the actual real world mechanics - many of which are simulated by KSP. 

    Managing Propellers:
    So, what makes propellers so difficult to manage for a pilot?  It’s because you have to manage the angle of attack of the propeller – which is basically just a spinning wing.
    First, consider the case with a normal fixed wing aircraft, illustrated below:

    The above is easy to manage.  When you want to increase angle of attack, and get lift - at the cost of more drag – you point the nose – and your wings - above prograde.  In level flight, that just means pointing them above the horizon.

    Now, consider a spinning propeller on plane that is not flying – just sitting still with its brakes on and the propeller spinning.  In this case, all the airspeed is coming from the fact that the propeller is moving through otherwise still air – pictured below for what one section of the propeller would see.

    The angle of attack is still large and the propeller can generate a lot of lift, though it also causes a lot of both drag and the lift in a direction not fully parallel with forward – both of which the torque of the rotor has to counteract.
    Now, picture what happens when the plane starts moving.  Now the airspeed across the propeller comes from both the rotation of the propeller and the movement of the aircraft.

    Consequently, the angle of attack has gone down dramatically, and you get less lift.  This is why propeller planes either have to change the angle of propeller blades – called their pitch – or remain limited to a low airspeed.  You could increase RPM, but RPM is limited in both KSP and the real world because propellers lose effectiveness if the propeller tips go faster than mach 1.

    In KSP, you can adjust the angle of our propellers by setting their ‘Deploy’ field to ‘Extended’ in the PAW, and adjusting the authority limiter, as pictured below.  KAL-1000 can assist you with coordinating the settings on multiple sets of propellers if you build a multi-engine plane. 

    Using aero-debugging visualization – F12 by default – can assist you by letting you visualize the lift off of the propeller – your aim should be to adjust the pitch so that the yellow arrows are as long and as far forward as possible.

    Rotor Changes
    Rotors have seen a significant set of changes and improvements, as well as the addition of the liquid-fuel consuming rotors, which model a turboshaft engine for a propeller plane and for a helicopter.
    Now all rotors are set to max out at 460 RPM – near the limit that our physics engine allows.  Further, now you can reach that RPM limit regardless of how little torque is applied.  Before the rotor RPM and torque were unrealistically interrelated.  However, just as a rocket can reach any velocity in space regardless of how much thrust you use - lower thrust just means it takes more time - now a rotor can do the same, barring things like atmospheric drag that would oppose it.

    Finally, rotor RPM is more stable, you won’t see the RPM numbers vibrating as much.

    This all required retuning.  Further, our initial pass for rotor power gave too much torque.  Rather than reducing the available torque, we’ve increased the resource usage and weight/cost requirements for a given motor power.   Be aware that you absolutely don’t need to always keep the motor size at 100% - for many applications, a lot less torque will be more than enough.

    Robotics Resource Usage Changes
    While we endeavor to simulate physical systems in as realistic way as possible, that has to be balanced against fun and development feasibility.   With 1.7.3, we’ve now improved our resource usage simulation for robotics parts, though it is still by not 100% accurate to the real world.

    What this means is that in 1.7.3  the traversal or rotation rate you request from a part will now impact how much EC/LF is used by the part, where before it was not a factor in the resource usage calculations.

    Maneuver Engine Re-Balance
    Among the other features in 1.7 are a few art revamps for various maneuver engines.  And amongst the feedback for those engines, some of the community pointed out that a couple of these engines aren’t as useful as others, due to their stats.
    The team decided to take a look and yes, we did see some tuning issues – so we decided to update select numbers of the engines we’re revamping.
    As with the last blog on the tuning of the MH engines, the goal here is balance and making sure each of our engines has a niche and a use, while making the smallest number of changes possible.
    So first, here are the raw numbers of the engines we’re changing, as well as some reference numbers of similar engines that aren’t changing.
    Engine Comparison
    Thrust (Vac)
    ISP Vac
    Vac TWR
    Cost/kN Thrust
    Tech Level
    Gimbal Range
    Crash Tolerance
    Entry Cost
    Ant (for comparison)
    Propulsion Systems (5)
    Spider (for comparison)
    Precision Propulsion (6)
    Precision Propulsion (6)
    New Twitch
    Precision Propulsion (6)
    Puff (for comparison)
    Precision Propulsion (6)
    Propulsion Systems (5)
    New Spark
    Propulsion Systems (5)
    Place-Anywhere 7
    Advanced Flight Control(5)
    New Place-Anywhere 7
    Advanced Flight Control(5)
    RV-105 RCS
    Advanced Flight Control(5)
    New RV-105 RCS
    Advanced Flight Control(5)
    Specialized Control(6)
    New Vernor
    Specialized Control(6)
    And here’s the thinking behind these changes.
    Twitch & Spark:
    The twitch and spark are both relatively similar in size, use the same propellant, and the twitch unlocks later than the spark.  The twitch is a surface attached engine with a good gimbal range, but otherwise the Spark is just better in every way – TWR, cost/KN, and efficiency.  In fact, the Spark is so efficient that it outpaces many larger significantly larger engines, making clusters of them a better choice than using one of them, something we generally want to avoid as we think that both game balance and realism are better satisfied by having larger engines generally be slightly better than smaller ones, at the expense of not being as flexible in exactly how many of them you use.
    Therefore, the Twitch was made about half as costly, and its ASL ISP was increased to make it a better descent engine for probes on planets with an atmosphere, or as a Vernier.
    The Spark’s ASL ISP was lowered slightly, and its mass increased, to tilt it more toward being a Vac engine rather than just a perfect all-around engine that it was.  We’re aware that the community has been using this engine for a while and kept the changes as small as possible, but this engine stood out too much from its peers when you look at the numbers to not need to adjust it.
    RCS Engines:  
    The Place Anywhere 7, RV-105 RCS, and Vernor are all engines designed to steer your ship in space, making fine adjustments to orientation and course rather than providing raw power.   Also, RCS is a much more realistic way to adjust a large craft’s orientation rather than piling on more reaction wheels. But the cost of these engines, we felt was just too exorbitant, especially given their low efficiency & the fact that they are typically placed in symmetry, so their costs were reduced dramatically.
    The mass of the Place Anywhere 7 and RV-105 also made them a poor choice compared to the more powerful Vernor and were thus lowered.
    However, these are still engines, sensitive pieces of equipment, so the crash tolerances were set more in line with other engines.

    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,