Jump to content

  • Developer Articles

    JPLRepo
    Welcome to another KSP Devblog!  This time we’re going to talk about some bugs. In particular, two, Docking Port Drift/Issues and Robotics Drift. What am I talking about when I say drift?
    A number of issues have been found and brought up on both the forum and our bug tracker regarding the new Docking Port rotation feature that was introduced in KSP 1.12 On Final Approach.These issues are similar and somewhat related to a number of issues we have known about for some time with regard to the robotic parts from the Breaking Ground DLC. Both sets of problems are inherent to the architecture of KSP due to the way it defines and saves information about the connected parts in a vessel.
    In order to address and fix these problems correctly (if indeed it can be fixed totally),we would need to spend quite a bit of time and resources, as well as consider the risk associated with making a large change to the way KSP handles this information, and also do it in a way that would not break everyone’s existing save games.
    As you all no doubt know by now, we are no longer planning any further major updates for KSP and instead the whole team is now engaged on KSP2. That said, we know how much these two issues have been hurting the community, and hurting us knowing that, so we have put together a small patch to address these two issues in the most practical way possible considering all the delivery factors.
    The Fix
    In order to address these two issues without re-architecting large parts of KSP code we have found a compromise solution that reduces the impact of these issues whilst not completely eliminating them. We hope, to a point, that means they become less of an issue for you all.
    Docking Ports and Robotic parts all have an option that allows you to “Lock” the part in place. This option is available via the Part Action Window (PAW) or right click/context menu for each part. The compromise solution involves handling the saving of all the vessel’s parts differently depending on whether a docking port or robotic part is “Locked” or not.
     

     
    What happens “under the hood” so to speak is that when a Vessel is either Put on Rails or Unloaded / Saved KSP has to Save both the position and rotation of any Unlocked Robotic parts or Docking Ports (as well as ALL of their children in the part hierarchy) so that when it is reloaded or taken off rails it can re-position these parts relative to each other. This is not usually an issue for parts, as their relative position and rotation does not change once the craft has been built in the VAB/SPH and subsequently been launched. The exception of course is the Docking Ports which can now rotate (and rotate everything attached to them) and Robotic parts that can perform rotations, movement, etc.
    The changes that have been made involve not saving the rotations and positions of all docking ports and robotic parts (and all their children in each case) if the part has been placed in the “Locked” state.
    So in summary,if you want to avoid the “drift” and rotation issues with Docking Ports and Robotic Parts, just remember to always set your Docking Ports and Robotic Parts to “Locked” state when you aren’t rotating or moving them.
    Maxsimal
    Welcome to another KSP devblog!  This time we’re going to talk about wheels.
    In KSP 1.12 Final Approach, we’ve made some improvements to our wheels to address many pesky bugs.  Another issue we’ve looked at is making it easier to drive your rovers without flipping them.
    To that end, we’ve added a new control to wheels:  Steering Adjust, which can either be in Auto or in Override.  When set to Auto, Steering Adjust will reduce the maximum angle your wheels can turn as your vehicle goes faster.   Because most players use keyboard controls, it’s been too easy to overcrank your wheels by holding a key down too long and flipping your vehicle over - keeping Steering Adjust in Auto will help you deal with that.
     
    Setting Steering Adjust to Override will preserve the old steering behavior - but also expose some new controls to help you manually tune your wheel controls.  
    Steering Angle will let you manually reduce the maximum deflection your wheels can go through.  Steering Response will change how quickly the wheels respond to inputs - how quickly they’ll turn.   Those of you who use an analogue controller will likely want to set your steering adjust to override if you like using your analogue controls to control the full range of motion of the wheel, though you can still turn down the Steering Angle to have better fine control.
    Bug Fixes
    We’ve also addressed some of the bugs that have been plaguing wheels for a while.  Check the build notes for the exact list, but notable improvements include:
    Wheels and landing legs bouncing less when docking/undocking. Wheels and landing legs bouncing less on load. Landing legs being more stable generally and especially when deployed at wide angles. Wheels and landing legs suspension now handles different gravity changes much better than before. Fixed the wheel speed on the M1 and M1-F wheels. Wheel load balancing now across all grounded wheels on a vessel. Wheel Tuning Tips Finally, I’d like to share some simple tips to make a more drivable rover. Wheel Tuning Tips
    Finally, I’d like to share some simple tips to make a more drivable rover.
    Rolling over during a turn too often?
    If you’re still rolling your rover often over too often, here’s a few things to try:

    Lower your center of mass or widen your wheel track - the horizontal distance between your wheels.  That’s always going to make your vehicle more stable. Use the Steering Adjust in Override mode, and manually lower the amount your wheels will turn.   Set Friction Control to manual and lower the friction on all your wheels - this will make your vehicle tend to skid, rather than flip. Of course, you can get crazy with reaction wheels and RCS to keep your rover pinned to the ground - it’s the Kerbal way, after all. Flipping over when you brake or accelerate,  particularly on low gravity worlds?
    If your rover flips forward or backward while braking or accelerating, try these tips:

    Make sure you have any reaction wheels turned off!  Those can easily torque your vehicle over. Adjust your Brakes% to increase it on the back wheels, reducing it on the front wheels, and your motor power to the front wheels.  . Set Friction Control to Override and lower your friction - low gravity worlds can be hard to drive on and it’s tempting to set this higher, but the low weight holding  your vehicle down has to be accounted for. Oversteering?
    Oversteering is when your vehicle tends to turn too much, and possibly go into a spin, rather than following the direction it’s driving in.  You can address this in a few ways.  
    Set your back wheels to not steer - all-wheel-steering can be great for maneuverability, but it seems you’ve got too much of that!   Either adjust the center of mass of your vehicle to put more mass on those back tires, or you can adjust friction to increase the friction of your back wheels and/or decrease the friction on your front wheels.  Setting your Friction Control to give 50% more grip in the back - while not overdoing to cause problems with flipping - can help a lot. Understeering?
    Understeering is the opposite of the above problem, where your vehicle just doesn’t want to turn.  And it can be solved by doing the opposite steps - moving mass forward, increasing the grip of the front wheels, etc.   Do note that just turning the wheels more won’t typically help - understeer occurs because the steering tires are not exerting enough torque to turn your vehicle, turning them more will just cause them to slip more.

    A Fond Farewell
    I’ve been working on KSP since version 1.6, and it’s been an absolute pleasure to work on a game with so much love and creative investment from its fans.
    However, shipping 1.12 will mark the end of my time designing for Kerbal.  It’s not a decision I came to lightly, I’ll definitely miss my teammates and the project. I know they’ll keep doing fantastic work expanding the franchise, but I’m off to do other things. I wanted to take a moment to say what an honor it has been working on something that is so much more than a game for many people, that inspires people about space exploration and educates them about the challenges and wonderful discoveries we have in reaching out into the Solar System.
    I will continue to be a fan of the franchise and you’ll likely see me kicking around in a more civilian role, feel free to say hi.
    Thank you for being amazing fans, I’m back to being one of you.
    Paul Boyle, KSP lead designer for versions 1.6 to 1.12, and the Breaking Ground DLC



     
    Maxsimal
    There’s a lot of cool stuff in 1.11 Some Reassembly Required, and the Squad team hopes you’re enjoying it all!   I’m here to share a few thoughts on some tuning changes we’ve made to the game.
    Kerbals on the Scale
    Kerbals have always had a mass in the game when they’re EVA - 93.875kg.   That included themselves, their suit, their EVA jetpack, and their parachute, plus any Snacks they managed to hide on themselves.
    Now with jetpacks and parachutes being something Kerbals can choose to go without - for better or worse we’re taking the time to update and rectify some things around this.
    On the Scales:
    First, Kerbals got a little fatter - now tip the scales at a full 94kg, fully loaded.  A little weight gain is expected after almost 10 years on a job this stressful.  Here’s how that breaks down:


    IVA Kerbals have mass now:
    Second, we’ve gone ahead and made Kerbals have a mass IVA.  Previously, whenever a  Kerbal got into a craft, their mass would be nulled out.  Now, the weight of the Kerbal itself - 45kg with their suit on, plus anything their carrying - gets added to any part they’re riding in.    
    Note: The command seat was a special case as that’s still an EVA Kerbal, and the Kerbal’s mass always counted.
    To keep everything roughly as it was before, all command pods are now automatically 94kg lighter per seat - that’s the weight of one Kerbal plus an EVA jetpack and a parachute.   All other parts that could contain a Kerbal - crew cabins and the MPL - are 45kg lighter per seat, as you hopefully won’t be kicking your untrained passenger

    This automatic readjustment can be disabled on a per-part basis for modders who might want to do so.
     
    EVA fuel has a density now:
    Kerbal EVA fuel was always a bit abstract.  With the addition of separated jetpacks and the EVA Fuel cylinders, we’ve adjusted that.  Now EVA fuel is 5kg/unit, and the Kerbal respond as you’d expect as it's burned up - jumping a little higher, being able to accelerate faster with the Jetpack.
    Crewed part tuning adjustments:
    Since we’re already messing with pod masses a bit, we went ahead and made a few changes to the tuning of certain pods.
    First, all of them have inventory capacity, to store some baggage if you’d like.  The amount of space involved depends on the part.
    Second, we’ve adjusted a few to align them more with other parts.
    PPD-10 Hitchhiker Storage Container:  Its mass was adjusted from 2.5 tons to 2.07 tons, and it now has some significant cargo storage capacity.  This makes it closer to the average .5 tons/passenger that other passenger containers had, accounting for the extra benefit of that large storage.
    Mk3 Passenger Module: Its mass goes from 6.5 to 7.18 tons:   This part was judged to be too mass efficient vs other passenger storage modules, so it got bumped up.
    PPD-12 Cupola Module: Its mass was cut from 1.8 tons to .886 tons:  Despite giving some glorious views of the cosmos, it's always been much too heavy, given how few Kerbals could get a view from inside it.  Perhaps its now being built with transparent aluminum?   Its cost was also cut in half, from 3200 to 1600.
    Mk2 Crew Cabin: Its mass goes from 2 to 1.85 tons - which is slightly less than the tuning adjustments for the passenger mass might otherwise have lowered it to,, since its built in lifting surface is now accounted for.
    There’s a lot more that’s gone into 1.11, and I hope you check all the changes out at the 1.11 intro and change log.  Feel free to add a comment here if you’d like more info on some of the details behind the game design of this update!
     
     
    Maxsimal
    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!

     
    Maxsimal
    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. 
    Propellers:
    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.
    Maxsimal
    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
    ISP ASL
    Mass
    Vac TWR
    ASL TWR
    Cost
    Cost/kN Thrust
    Tech Level
    Gimbal Range
    EC/s
    Crash Tolerance
    Entry Cost
    Ant (for comparison)
    2
    315
    80
    0.02
    10.19
    2.59
    110
    55.00
    Propulsion Systems (5)
    0
    0
    7
    1500
    Spider (for comparison)
    2
    290
    260
    0.02
    10.19
    9.14
    120
    60.00
    Precision Propulsion (6)
    10
    0
    7
    1750
    Twitch
    16
    290
    250
    0.09
    18.12
    15.62
    400
    25.00
    Precision Propulsion (6)
    8
    0
    7
    1600
    New Twitch
    16
    290
    275
    0.08
    20.39
    19.33
    230
    14.38
    Precision Propulsion (6)
    8
    0
    7
    920
    Puff (for comparison)
    20
    250
    120
    0.09
    22.65
    10.87
    150
    7.50
    Precision Propulsion (6)
    6
    0
    7
    2500
    Spark
    20
    320
    270
    0.1
    20.39
    17.20
    240
    12.00
    Propulsion Systems (5)
    3
    0
    7
    2800
    New Spark
    20
    320
    265
    0.13
    15.68
    12.99
    240
    12.00
    Propulsion Systems (5)
    3
    0
    7
    2800
    Place-Anywhere 7
    2
    240
    100
    0.03
    6.80
    2.83
    280
    140.00
    Advanced Flight Control(5)
    0
    0
    50
    4200
    New Place-Anywhere 7
    2
    240
    100
    0.02
    10.19
    4.25
    25
    12.50
    Advanced Flight Control(5)
    0
    0
    15
    800
    RV-105 RCS
    4
    240
    100
    0.05
    8.15
    3.40
    620
    155.00
    Advanced Flight Control(5)
    0
    0
    15
    3400
    New RV-105 RCS
    4
    240
    100
    0.04
    10.19
    4.25
    45
    11.25
    Advanced Flight Control(5)
    0
    0
    15
    1200
    Vernor
    12
    260
    140
    0.08
    15.29
    8.23
    1400
    116.67
    Specialized Control(6)
    0
    0
    50
    4200
    New Vernor
    12
    260
    140
    0.08
    15.29
    8.23
    150
    12.50
    Specialized Control(6)
    0
    0
    15
    1800
    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.
    Maxsimal
    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.
     
    TriggerAu
    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.
     
     
     
    TriggerAu
    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.
     
     
    JPLRepo
    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.
     
    Trees
    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.
×
×
  • Create New...