We've just published KSP v1.0.1. This is a small revision patch to address some of the most noticeable bugs we encountered since the release of 1.0.
Some of these we knew about for a while, but couldn't fix in time for the release (as we approach publishing time, the risk of code-breaking and delaying the entire release outweighs any benefits in the potential fix), others we found out about during the weekend livestreams, and some others we found from your own feedback.
This patch isn't meant to cover every single bug, of course, just the more relevant ones. We're going to keep on with the bugfixing and tweaking as we move into development of version 1.1.
Thermal: * Temperature gauge system. * Vessels which are splashed will now have much higher convective coefficients making them cool to ambient temperature faster. * Removed node size from being taken into account for stack occlusion. Added custom drag cubes for remaining hollow parts. * Parachute heating/burning. * Fix for bug in FI dealing with unpacking vessels at analytic warp (>=1000) rates. * Fixed conduction on service bays. Added Module Conduction Modifier to help service bays not incinerate their contents & configs updated * Updated emissivity for spaceplane configs. * Lowered heat production on LV-N.
Resources: * Replaced overheat mechanic of the ISRU and drills with a skill-based mechanic. * Removed Overheat Throttle mechanic. * Increased mass of Ore tanks to match wet/dry ratio of stock tanks. * Aerodynamics * New values for physics global drag and lift multipliers. * Added a CoP offset calculation to procedural fairings * Fix for the aero debug drag arrows switching directions. Added body lift arrows (cyan) * Fixed occlusion on mk2 docking port. * Fix for Laythe's atmosphere.
Solar Panels: * Solar panels now use the proper inv square from FI's solar flux. * Removed obsolete power curves from solar panels. * Rebalanced solar panels against each other.
Career: * Doing science at the flagPOLe, the north POLe, or the south POLe, will no longer mark Pol as visited with the progress tracker. * Science contracts and science World Firsts can no longer be triggered with science gained by reverse engineering recovered vessels. You have to transmit or recover an actual experiment. * Ensured that if a grand tour contract includes Kerbin, that Kerbin is chosen as the final stop on the tour. * Capped amount of recovery contracts that can generate, but increased caps on station and base to increase contract variety. * Fixed "On Wheels" optional side objective not triggering on outposts when utilizing the new fixed landing gears. * ISRU contracts round their capacities up, to handle cases where the player brings exactly enough resource capacity. * Use the word "spaceflight" instead of "flight" when appropriate, to prevent player mistaking certain things for atmospheric flight. * If the game cannot find an agent listed in the save file, it will pick a random agent. * Remove some debug information from survey waypoint generation.
Parts: * Added Tier 0 rocket fin. * Added RescaleFactor to the RT-5 (preventing a potential regression bug). * Removed the allowstack option from the NBS and orbital scanners to fix a bug if they were used as the root part. * Fixed an issue where the physicsSignificance flag was set to 1 for heat shields. * Added an option to clamp the lower bound of the deploy pressure of parachutes. * Adjusted parachutes to open at a slightly higher atmospheric pressure. * Fixed fairings not initializing their masses in flight properly. * Added module info section for fairings. * Rebalanced engine entry costs.
Miscellaneous: * Moved all Part Loader part info code into a separate method which is run after drag cubes are loaded/created. Thus modules can access the partÃ¢â‚¬â„¢s drag cube information in their info. * MapSO and CBAttributeMapSO methods made virtual and member variables protected. * Made physics-less part mass effect KB mass value. * Zero part count vessels will not be run through Flight Integrator. * Increased mass on some wings. * Fixed a nullref being caused when clicking between vessels and empty space in map view. * Vessels that blow up in atmosphere properly kill off their crew members. * Added Part temperature gauges/highlighting (toggle with F10). * Part temperature overlay can now be toggled with F11 * Part aerodynamic forces overlay can now be toggled with F12
As always, you can get the latest version from our KSPStore, GOG, or get auto-updated on Steam.
This is a special one! After four and a half years in development, Kerbal Space Program 1.0 is now officially released!
Kerbal Space Program 1.0 is what we envisioned when development of the game started four years ago: we set out to make a game in which the player is given ultimate control over the exploration of space: from designing their rockets to launching and flying them to their destinations, in a universe that was modeled to be realistic, but at the same time still be fun to play in.
However, our 1.0 release is more than just a new version number. ItÃ¢â‚¬â„¢s also the biggest update to the game weÃ¢â‚¬â„¢ve ever done, and contains many new and updated features, plus improvements to just about every game system, which weÃ¢â‚¬â„¢re sure will appeal to both newcomers and seasoned veterans. These are the highlights:
Aerodynamics The flight model has had a complete overhaul, meaning the lift is now calculated correctly to all lift-generating parts, which includes lifting bodies. The drag simulation has also been completely revised, and uses automatically pre-calculated data based on the each partÃ¢â‚¬â„¢s geometry, to be finally applied based on not just the orientation of parts in flight, but also taking other parts into consideration. Stack mounted parts are now occluded from drag by neighboring parts, and lift induced drag is also properly simulated. Both the lift and drag are dependent on air density and the speed of sound, which are calculated from temperature and pressure. Be careful when flying aircraft in this new update: stalls are now properly simulated as well, and spontaneous craft disassembly during high-G maneuvers is now a very real thing.
Heating A new heating simulation has been implemented together with the improved aerodynamics. Now, not only temperature but also energy flux is considered when making heat calculations, meaning radiative, conductive, and convective heating and cooling are all simulated and all parts have their individual thermal properties. Parts will emit a blackbody radiation glow if they get hot enough. Although part temperatures can now be affected by such things as being exposed to sunlight and hypersonic flight heating, they can be properly occluded from these effects as well. Atmospheric temperature (and density) takes into account latitude and the position of the Sun. Celestial bodies now accurately emit thermal radiation that makes nearby craft warmer. Finally, ablative heat shields (with a finite, editor-tweakable ablation material) have been added to protect the parts behind them from reentry heating.
Fairings You can now add fairings to your rockets! Fairing construction starts with a base part which will allow you to procedurally create a fairing after you place it. The design of the fairing is left up to you: shape individual sections of fairing with an intuitive visual system which gives you total control over the shape of any fairing.
Once you've placed the fairings you can still edit your payload! Mousing over the fairing will make it transparent and will give you an exploded view, allow you to access anything that's inside. If you later want to edit a fairing, simply right-click the fairing base to modify it as needed.
Fairings will shield anything inside them from drag and heat, making them an ideal tool for making payloads survive even more aggressive aerodynamic stresses. Like cargo bays and service modules, they will also prevent wings from generating lift, as well as science experiments, solar panels and antennas from deploying, which means all these new parts should be a big part of your mission design.
Resource Mining Mining for Resources is now a part of Kerbal Space Program: set out to find Ore, which can be found throughout the Solar system, including on asteroids. To do this you'll have access to several different scanners to map out and find the best places to mine, drills to extract it, specialised holding tanks to store it, and a processor / refinery unit to convert it into usable fuels. To help you find the Ore, new map overlays have been implemented on all celestial bodies, and new UI elements have been added to various pieces of equipment. Also, Kerbal engineers are particularly good at keeping those drills humming at peak efficiency.
As always, you can find the complete changelog here:
=================================== v1.00.0 ============================================================* New:Editor:- New Engineer's Report Toolbar App, provides warnings and advice during construction, notifying players of possible design issues with their ships.- Added 'Cross-Section Profile' Filter to Parts List.- Added Thumbnail images for Craft files in both Launch Dialog and Craft Browser screens.- Added 'Merge' button to Load dialog, allowing ships to be loaded without replacing the current one- Added confirmation dialogs when overwriting a save, launching or leaving editor without saving.Aerodynamics:- Complete overhaul of the flight model.- Lift is now correctly calculated and applied for all lift-generating parts.- Drag is now pre-calculated automatically based on part geometry, and applied based on part orientation in flight.- Both lift and drag are dependant on density and the speed of sound; both properly calculated from temperature and pressure.- Stack-mounted parts can occlude each other for drag calculations.- Lift-Induced drag now properly simulated.- Stalls are now properly simulated.- A new body-lift system meaning parts can induce lift even if they are not designed to do so.Heat Simulation:- Completely revised part heating model, energy flux is considered, not merely temperature.- All game temperatures changed from Ã¢â‚¬ËœKervinÃ¢â‚¬â„¢ to proper Kelvin.- Radiative, conductive, and convective heating and cooling are simulated.- Parts can have individual radiative, conductive, and convective properties.- All parts now emit a blackbody radiation glow if they get hot enough.- Conduction between attached parts is more accurately modelled.- Parts can occlude other parts from being exposed to sunlight, celestial body albedo/radiation and supersonic flow.- Reentry/hypersonic flight heating is now simulated.- Added difficulty Setting to scale aerodynamic heating.- Atmospheric temperature, and thus density, takes latitude and sun position into account.- Celestial bodies accurately emit thermal radiation making nearby craft warmer.- Service modules, fairings and cargo bays can be used to protect parts inside from heat.- Heat shields provide (finite) ablation-based protection for parts behind them.Parts:- New procedural Fairings added, in 3 sizes- New Heat Shields added, in 3 sizes- Service Bay parts added in 1.25m and 2.5m sizes- Several new Landing Gear parts added, in many sizes.- Many New large airliner and shuttle style wing sections added.- Large wing sections have internal fuel tanks.- All old spaceplane parts overhauled with a more up-to-date style.- Old Avionics Nose Cone overhauled and repurposed as a standalone, non-autonomous SAS module.- New atmosphere scanner part added.- New Inline Xenon Tank part added.- New RT-5 'Flea' Solid Rocket Booster added.- New Fuel Cell parts added (small and large), convert LiquidFuel and Oxidizer into Electricity when turned on.- New models for Circular and Ram air intake parts.- New models for Engine Nacelle parts.- Several new nose cones and tail sections.- New Airbrake part. - New module for Airbrake parts, responds to Brakes input and can also be used as pitch/yaw actuator.Internal Spaces:- Added new IVA space for the Mk1 Inline cockpit- Added new IVA space for the Science Lab- Added new IVA space for Mk3 Shuttle Cockpit- Added new IVA space for Mk3 Passenger Cabin- Added new IVA space for Mk2 Passenger CabinResources:- Added 'Ore' resource, which can be mined across the Solar System- New drill part added- Ore container tanks added- ISRU Ore processor unit added, converts Ore into Liquid Fuel, Oxidizer or MonoProp- Three new Ore scanner parts added- Added new MapView overlays displaying Ore density for all Celestial Bodies.- Support for moddability of resources added (including atmospheric and oceanic)- New Difficulty Setting to scale resource abundance (both stock and modded).- Asteroids can also be mined for Ore.- Engineer Kerbals are able to Ã¢â‚¬ËœoverdriveÃ¢â‚¬â„¢ drilling equipment for increased yield (and less safety).Kerbals:- Female Kerbals added, with new randomly-generated female names - Valentina Kerman (Pilot) added to initial Crew Roster- Kerbals are now able to clamber onto ledges within reach, because their jobs werenÃ¢â‚¬â„¢t dangerous enough already.- Kerbals can now climb out of ladders onto ledges.- Tourist Kerbals added. They have zero skills, are unable to control vessels, and are required to keep their heads inside the vessel at all times.- Kerbals now cost increasingly larger amounts of Funds to hire in Career Games.R&D:- R&D Tech Tree completely revised. Several new nodes added; many, many parts reassigned for a better progression.- Kerbal Scientists are now able to restore inoperable experiment modules.- The Science Lab has been retooled to run long-term research on experiment data, providing much higher amounts of science over time.Graphics:- New Smoke effects added to Launchpads- New Surface Effects added whenever rocket engines fire near terrain- New Water Effect added whenever rocket engine fire near water- Revised all part shaders for improved rendering of lighting effects and shadows.- Main Flight UI can now be made transparent.Career:- Added new Tourism contracts and tourist kerbals.- Added ISRU resource extraction contracts.- Added Grand Tour contracts.- Replaced Rescue contracts with Recovery contracts, which can ask the player to recover a part, a kerbal, or both, and can spawn on the surface of planets, with Ã¢â‚¬Å“propsÃ¢â‚¬Â nearby.- Added two 'immediate' Strategies to convert existing Reputation and Science into Funds.- World First contract line now extends all the way out to Eeloo, and is dependent on player progression.- Record contracts are now always active, and will complete in order even over the course of a single mission.Tutorials:- All tutorials revised and rewritten to explain most game features.- Expanded Flight Basics Tutorial to cover the essentials of launching into orbit.- Added new Return from Mun tutorial.- Added new Science and R&D Tutorial.- Added new Docking tutorial.Flight:- 'Warp To' action added to orbit context menu. Allows warping to a specific spot along your trajectory.- 'Warp to next morning' button added to KSC toolbar.- Asteroids can now be found orbiting near Dres.- Engine thrust now varies according to Isp and throttle setting, instead of the other way around.Controls:- Completely revised Input Mapping system. - Flight input bindings is now much more straightforward and more flexible as well.- Duplicate control bindings for Docking/Staging modes now replaced by a much more robust system based on secondary key bindings.- Joystick Axes are now consistently enumerated and persist across sessions.- Up to 10 joysticks with 20 axes each now supported.- Added secondary channels for Axis Bindings.Cameras:- New 'Chase' Camera mode added, old mode now called 'Locked'.- Added Camera wobble/vibration effects during flight (engine vibration, explosions, ground roll, G-force, and many more)- TrackIR support added to all game views (toggleable independently in game settings). (FreeTrack also reported to work)- Added FOV control to main flight camera. (Hold ModKey and zoom)* Bug Fixes and Tweaks:Editor:- Fixed several issues with editor attachments, attachment node orientation and symmetry.- Shift+Clicking a 'frozen' part in the editor will detach it from its parent.- Fixed several bugs with cloned parts and persistence.- The editor no longer requires a full scene reload to load new craft files.UI:- The KnowledgeBase panel for Vessels now shows 'Max Accel' and 'Estimated burn time to 0m/s' (as shown on navball) fields.- Several part context menu actions now properly apply to symmetry counterparts automatically.- Added new custom cursors.Simulation:- Fixed 'infiniglide' bug.- Switching SOIs no longer causes the next orbit to change at high time warp rates.- Added a warp speed limit when approaching an SOI transition.- Kerbal EVAs should no longer fly off when disembarking in space.- SAS now disengages autopilot modes automatically (and falls back to stability assist) in cases where the target vectors would change very rapidly.- Parachute deployment should no longer cause vessel disassembly at high physics warp rates.- Deployed parachute sway now actually has an effect on the vessel.Parts:- LV-N Ã¢â‚¬Å“NervÃ¢â‚¬Â Engine now runs solely on Liquid Fuel and has no gimbal.- OSCAR-B tank can now be surface attached- Air-breathing engines now drain fuel evenly from all tanks in a vessel.- Fixed radial decouplers not applying ejection forces correctly.- Parachutes no longer cause massive G spikes when opening.- Control Surfaces can now be deployed as flaps, controllable via context menus and Action Groups.- Stats of Antennas revised for a proper progression with the more advanced models.- Added nicknames to all engine parts.- Revised and balanced part costs.- Balanced fuel amounts for Mk2 and Mk3 tanks.- Balanced engines (Isp/thrust/mass) in line with the new aerodynamics.- Added fuel gauge to LV-1 Ã¢â‚¬Å“AntÃ¢â‚¬Â engine.- Materials Bay now faces away from the part itÃ¢â‚¬â„¢s radially attached to.- RoveMate rover body is now a probe body as well.- The unshrouded solar panels are now non-retractable.- Balanced probes electric charge usage, mass and crash tolerance.- Lowered crash tolerance of the Structural Pylon to 70 from 999!- All parts given Ã¢â‚¬Ëœbulkhead profileÃ¢â‚¬â„¢ tags in cfg files. Profile tags inferred automatically for parts missing this field.- Cargo bays now properly detect enclosed parts, and can be grouped to make larger bays.- Experiment Modules, Solar Panels, Antennas and such will not deploy while stowed inside a fairing or cargo bay.- RCS thrusters will not function if stowed inside a closed cargo area (or fairing).- Lifting surfaces will not generate lift if stowed inside a closed cargo area (or fairing).Audio:- Much improved flight ambience sounds for Kerbin and other bodies with atmospheres- Added new sound effect when pulling high G forces.- Eliminated audible gaps on several looping clips.Effects:- Improved sound/particle effects for all Air-Breathing engines- Splashdown effects no longer spawn underwater.General:- All part textures converted to DDS format, load times are now 3x faster.- Fixed a serious persistence bug which prevented Scenario/Training saves from updating scenario modules properly.- Fixed persistence bugs which caused state data from Upgradeable Facilities to carry over to other saves.- Fixed an issue which caused Kerbals to not be generated randomly enough, which led to slowdowns with larger Crew Rosters.- Fixed issues with the terrain during scene switching making scene load times faster.- Fixed terrain scatter generation which was causing memory leaks.- Ã¢â‚¬ËœElon KermanÃ¢â‚¬â„¢ added to name pool.- Crew name generator can now output 10,000+ female names - Fixed an issue with markers in the KSC scene potentially causing the game to lock up.- Restructured GameData folder, integrated the NASA folder into the Squad one.- Valentina Kerman added to Main MenuÃ¢â‚¬â„¢s Space scene. Gameplay:- All contracts other than World Firsts or Records are halted until the player reaches space.- Prevent Ã¢â‚¬Å“stackingÃ¢â‚¬Â of various contract types.- Resource parts added into satellite, station, and outpost contracts.- Prose of contracts involving kerbals re-evaluated with gender appropriate text.- All contracts in career given balanced income for all three currencies.- Science and reputation no longer scale with the celestial body of a contract, and are handed out more conservatively in general.- All strategies in career given equivalent exchange rates.- Aggressive Negotiations strategy given a discount on building repair/upgrade.- Recovery Transponder strategy now lowers maximum recovery rate, while raising minimum recovery rate.- Facility upgrade costs re-evaluated, lowered by about a quarter overall.- Kerbals now properly receive experience for suborbital flights.- Part Test contracts now request much saner flight parameters.- Survey contracts choose much saner locations to survey.- Sensor Experiment Modules are now able to perform experiments in all situations.Debugging/Modding:- The R&D Tech tree is now defined in a cfg-file. - The cfg file for the Tech Tree is defined separately for each save.- GameVariables methods are now all virtual and can be overwritten by mods.- Added a new set of debug tools to tweak Physics parameters.- Added a new set of debug tools to tweak R&D tech tree nodes and part assignments.
There is a lot more we could talk about, but weÃ¢â‚¬â„¢ll let you discover that on your own!
The update is now available on the KSP Store, Steam and GOG.
We hope you will enjoy Kerbal Space Program 1.0 as much as we enjoyed making it.
We're very pleased to announce that you will be able to buy Kerbal Space Program in two more places very soon: we've partnered with GOG and Gamer's edition to bring the game to your preferred retailer and offer you a collectors edition!
We're partnering up with Gamer's Edition to bring you a collectors edition of Kerbal Space Program which will include not only a copy of the game but several physical collectibles as well!
The image above gives you a preview into what we're currently planning to include in this package, but be sure to follow up on the news through our own official channels or by following Gamer's Edition on Twitter, Facebook or their website.
GOG is famous for its policy of distributing games that are DRM free only. We share this vision of DRM free software and so it's a logical step to see Kerbal Space Program end up in GOG's storefront.
Starting next Monday you will be able to find Kerbal Space Program on GOG.
These two vendors will join the KSP Store, Steam, Green Man Gaming and the Humble Store as places you can buy Kerbal Space Program from.
As you might know we're working overtime to get KSP version 1.0 to you guys, and as a part of this update we'll be introducing female Kerbals. With today being Valentine's day we thought we'd ask our community to get their creative mindset on and speculate a bit about what our number one female kerbonaut Valentina Kerman will look like. That's right, today is Valentina's day!*
The contest Although the official artwork for female Kerbals has not yet been released, we want you to show us your vision of Valentina Kerman. The goal is to create an image that showcases that our #1 female Kerbonaut, Valentina, is just as bad-ass as Jeb, as ingenious as Bill or as smart as Bob. You can submit your entries in [thread=110612]this thread[/thread], or on Twitter by using the hashtag #ValentinaKerman <img src="http://i.imgur.com/zGR3IDb.png" style="float: right;" /> The prizes The best entries will get featured by us on our Facebook and Twitter accounts throughout the contest. The eventual winner will receive a unique piece of artwork in poster format featuring Valentina, which will also be autographed by the KSP team in Mexico. We also have two smaller autographed posters ready for the runners up.
The rules To make sure there's no confusion about who and what, there's a few simple rules to this contest:
All entries must adhere to our Community Rules.
You can enter as many times as you like, though each entry should be a unique piece of artwork.
You can only enter with your own creations.
The contest runs from now until Monday, February 23rd 23:59 GMT. The winners will be announced on Friday, February 27th.
Squad reserves the right to unilaterally make a decision as to the validity of an entry
The winning entries will be picked by Squad (be sure to support your favourites though!).
As many of you will most definitely know, Kerbal Space Program has a Windows 64-bit version available to players. WeÃ¢â‚¬â„¢ve offered this version for a number of past releases of KSP and as of late (0.25 and 0.90, in particular), it has become very apparent that this version has been consistently less stable than all others. This level of instability means that the Windows 64-bit build falls far short of what we would consider a release-worthy product, and we will therefore not be releasing it for version 1.0 of Kerbal Space Program*.
WeÃ¢â‚¬â„¢ve spent a considerable amount of time investigating the reasons for these issues. The QA & Experimental Testing Teams have assisted in this research as have the community - something that we are very grateful for.
However, despite these efforts and although we have identified a number of probable causes for the instability, there is a very hard limit on what can be done on our end. Most platform-specific issues stem from parts of the engine we have no direct access to, and we simply canÃ¢â‚¬â„¢t debug these problems in the same way weÃ¢â‚¬â„¢d do with normal KSP bugs. We often canÃ¢â‚¬â„¢t even reproduce them in our development environment, so weÃ¢â‚¬â„¢re limited to guessing at both the causes and solutions.
In short, there are no easy fixes we can do here, and we feel that the time we would be potentially wasting on attempting to increase the stability of the Windows 64-bit version of KSP would be far better spent on other improvements which would reach as many players as possible. We can all agree there is no shortage of other things we could be working on.
WeÃ¢â‚¬â„¢re not giving up on the 64-bit build for Windows, though. The most we can do at the moment, however, is continue testing the Windows 64-bit build at each new version of Unity, and release it if viable. Additionally, we must take this opportunity to stress that Unity 5 - while a definite leap in the capabilities, performance and development power of the engine - is not going to inherently be a Ã¢â‚¬Ëœcure allÃ¢â‚¬â„¢ for issues, particularly in the matter of the instability of the Windows 64-bit build.
WeÃ¢â‚¬â„¢re aware that some of you have come to embrace the Windows 64 bit version by this point and that our decision to discontinue development for this particular build may be an inconvenience to some, but we trust everyone will understand the necessity that prompted this decision. At any rate, we want to thank everyone for their efforts in assisting in all bug finding and bug fixing efforts for KSP, as well as the modding community for their efforts in dealing with a rather unstable platform.
We hope youÃ¢â‚¬â„¢re all looking forward to 1.0! WeÃ¢â‚¬â„¢ll be sharing more news with you as development continues.
*Note that this doesn't affect those that run KSP on 64-bit versions of Windows, only those that run the 64-bit Windows version of KSP. Additionally, the 64-bit build for Linux is still planned to be released for 1.0.
It seems from yesterday's dev notes there were a lot of pending doubts as to how the cargo bays would function excatly, so here's my attempt to explain it in more detail.
First off, I should make it clear that with Cargo Bay, I mean the cargo bay Part Module, as in the bit of code used to make them functional. This module mostly deals with containment detection, and it should be possible to apply it both to the existing cargo bays and to new fairing parts, when we get to that. For now though, the purpose of the cargobay module is twofold: To detect (as efficiently and accurately as we can) which parts are inside the bay and which aren't, and to flag those parts as not exposed to the outside world (aka shielded).
This cargo bay module isn't entirely new in fact. It was first written sometime last year, during the blur that was the last months of the 0.90 release, and it was pretty much working already. The problem then was that by itself, it was deemed to be too little to count as an improvement over the existing (old) aero model, so we decided to leave it out until we got to a point where we could tackle aerodynamics properly (aka now).
Another thing that needs to be made clear is that the following method is used to detect containment relative to Cargo Bays, and cargo bays only. This is not the same method used to handle aerodynamic occlusion for the new drag system. That is an entirely separate thing, which would be the subject of an entirely separate (and equally long) post.
So, the first problem to solve is that of containment. There were a number of potential pitfalls we needed to have our solution avoid:
The first issue is that we saw early on that we couldn't rely on any of the 'standard' ways we usually use to work with part relationships. A cargo bay can contain parts attached to the same vessel, but then again, it might contain detached debris (or Kerbals taking a zero G joyride), so we can't rely on the vessel hierarchy, or any of its lists of parts to detect which are contained in the bay, as that wouldn't include parts that don't belong to the vessel at all.
Also, we have the problem of parts which may be partially inside, or surface-mounted to the internal or external walls of the cargo bay. That means we can't rely on the part transform.positions either, as those often are placed at extreme ends of parts, which means they aren't accurate representations of where parts really are.
Furthermore, mesh containment is in itself a complex problem to solve with full accuracy in software. A complete solution would require going through every vertex in every mesh, in every part against again, all verts in all meshes of the cargo bay. Not exactly fast... needless to say. That means our solution must also not be computationally impractical, so we're looking for something that falls in the 'good enough' zone, where it works as you'd expect without reducing the game to a slideshow. Fortunately, we don't have to solve for contained parts every frame, so we have some headroom, albeit not a lot.. But a very complex solution would also give us very complex results to deal with, which would become an issue all of their own... We could easily get caught in a never-ending spiral of complexity there, and that's the most dangerous pitfall of them all, because there is no limit to how complex a system can be made.
So taking a step back, what we really need is a solution that hits the 'predictability' zone, where if something looks like it should be contained, it should be contained. The emphasis is on the word 'looks' there, you'll see why in a bit.
Here's how we tackle the problem of detecting containment:
* The cargo bay first detects all parts inside a spherical radius that entirely encloses it. Those are the nearby parts that will be tested. This detection method is independent of vessel relationships, being solely dependent on the position of parts. A lot of the parts in this first list will be outside the bay, and that's fine. We just do this to avoid having to iterate through every single part in every single vessel.
* Next, we compute a centroid point for the part, based on its renderer bounds. That centroid is then a product of the part's visual mesh, not dependent on attachment position, center of mass or even colliders. It's the visual center of the part. This is now our reference to test the part in a visually accurate way.
* We then rule out any part whose centroid lies outside the merged visual bounds of the cargo bay itself. This is just a sanity check to avoid performing needless calculations on parts that are clearly outside the cargo area already. The merged bounds are a bounding box we calculate off all renderer bounds, to encompass the entirety of the part. This is necessary as cargo bays (or fairings) can potentially be made out of multiple objects, meaning multiple renderers, and multiple bounds, hence the need to merge them.
* So, we now end up with a much shorter list, comprised of nothing but parts which are in a reasonable range to warrant further testing. Now it's time to really check whether we are in or out of the bay.
[a quick note here to explain that all this is done with the assumption that the bay doors are closed. If they are open, no part would be considered as shielded by that cargo bay, so that's something we can safely not worry about]
* The test itself is simply a raycast, from each part's visual centroid to the bay's own centroid. Now, the thing with raycasts is that they can (and do) hit any parts along the way, and we don't want that. We are just concerned with the bay itself and each part, in isolation. This testing then is done against only the bay's own colliders.
* From this we can now determine if a part is inside or outside of the bay with a pretty decent level of accuracy. If the raycast reaches the bay centroid without hitting anything, we can be quite sure it's inside the bay. If it hits anything, it must by necessity have been a wall of the bay itself, and therefore must be outside the bay.
Now, you may be wondering then, what of the open sides of the bays then? Surely there is no wall there. Indeed there isn't, but that doesn't mean we can't add a 'wall' that only exists to catch a raycast. Trigger type colliders will do just that in fact, so for all testing purposes the open ends of the cargo bays are effectively closed. This still lets you pass though the open spaces normally, but catches the raycasting so we have a fully enclosed volume which defines the cargo bay.
As for the shielding itself then, after the containment is solved for, it becomes much simpler. We can now flag parts as being shielded, which is then used by each part's modules to determine how a part should behave if shielded. This way, we can prevent surfaces from generating lift while inside a closed bay, protect them from any heating from atmo friction, prevent them from receiving drag forces, and keep some parts (like parachutes and such) from functioning at all until the bay (or fairing) is open.
The only limitation of this method is that there is no support for partial shielding. A part is either inside or outside the bay. This I believe is fine, as it still means we meet all the initial requirements for the parts: We can protect payloads from being exposed to drag forces and air friction, we allow you to pack lift-producing parts inside the cargo area and not have to worry about those affecting the ship's handling (especially useful if launching a flying thing meant to do its flying off-Kerbin), and we can exclude the enclosed parts from being affected by drag, which is the primary purpose of cargo bays (and fairings). Plus, the solution is very simple to work with, which is also a good thing as we get to keep our sanity.
This method also works independently of vessel hierarchy relations (or parts even belonging to the same vessel), and reliably works in tricky cases, like parts being side-mounted to the bay, which could potentially have their transform positions at the wrong side of the bay walls. It works based on the visual mesh, so if it looks like it should be shielded, it probably will be.
Hopefully that explains the process enough to answer most of the questions about how cargo bay occlusion will work.
As development in Beta has progressed, one thing has become very apparent, Kerbal Space Program is about to reach a state in which every single one of the original goals for the game has been reached, and we can say that our original design document has been fulfilled.
Because of this, the next update will be our 1.0 release, and with it we will be leaving Early Access. This is a landmark moment for us at Squad, as after over four years of development, we feel that KSP is finally ready to be viewed by all as a complete game. However, this is not the end by any means.
What does 1.0 mean for everyone then? Most noticeably, it means KSP will be leaving the Early Access program. And while this does mean we are ready to call KSP a complete game after the next release, it does not mean development itself is complete. Far from it, in fact.
We see no better way to follow up on reaching our initial goals than to continue development on Kerbal Space Program, beyond Beta, past our original plans. This means that after 1.0 is out, we will continue on with free updates 1.1, 1.2, and so on.
This has only been made possible by the astounding, incredible support we have gotten from you all. Consider everything that will come after 1.0 as our way of saying thank you, for believing in our crazy little rocket-launching game, for supporting us through four incredible years, for sticking with us all the way here, and in advance already for staying around for 1.0 and beyond.
So lets talk about the nearby future then, hereÃ¢â‚¬â„¢s what we plan to have on update 1.0.
* New Drag Model: WeÃ¢â‚¬â„¢ve redesigned the way drag is calculated, now it will take into account things such as part occlusion, facing, and got rid of the calculation being based on part mass.
* New Lift System: Corrected the lift so that it is now (properly) a function of the square of velocity, not linear. This allows for far more effective, and accurate, wings.
* Aerodynamic Stability Overlay: A new part of the UI that shows you the stability of your crafts as you build them, so you can easily tell at a glance how air-worthy (or not) your design is, and see the effects of any changes as you build.
* EngineerÃ¢â‚¬â„¢s Report: A new panel in the VAB and SPH which will warn you of crucial (and generally frustrating) issues in your design, such as a lack of fuel tanks, engines or landing gear, among many other advanced concepts like those.
* TimeWarp To: Fumble with timewarp and mess up your burns no more, with this new feature you can choose a point along your orbit and the game will take you there as fast as physically possible.
* Deep Space and Planetary Refueling: Adding a new system and a set of parts that will allow you to collect matter from Asteroids and other bodies, then process it into useful things, like Fuel or Oxidizer.
* Game Over: Be careless with your funds and reputation and you might promptly find you no longer have a job at the Space Center.
* New Landing Gears: With the much larger Mk3 parts, we too felt the need for equally much larger landing gears. WeÃ¢â‚¬â„¢re giving you larger and more diverse ones to fix that.
* New, Larger Wings: Mk3 crafts also require you to make large wings out of way, way too many small ones. WeÃ¢â‚¬â„¢re adding wings that are not only larger than all others, they also carry fuel, so you can finally make room for a properly massive payload area.
* Kerbal Clamber: Kerbals can now climb over small obstacles and out of ladders up onto flat surfaces; because their job wasnÃ¢â‚¬â„¢t dangerous enough already.
* Female Kerbals: Long time in the making, finally joining the team at KSC.
* Economic Systems Rebalance: Strategies, Part costs, contract payouts, they all needed to be fixed, and have all gotten a much needed balancing pass.
* Part Stats Rebalance: WeÃ¢â‚¬â„¢re making sure no part is too light, too heavy, too powerful, or too weak. Exploiters beware!
* New Contracts: We aim to bridge the gap between the early and late game contracts, as playtesting showed the difficulty curve could use some easing.
* Tier 0 Buildings: The originally revealed buildings have been enhanced and modified to meet our original vision for them.
* Sound Overhaul: Adding sounds to several parts of the game and interface that needed them, as well as improving some existing ones.
* Bugfixes: A lot of long standing bugs are being fixed, and we do mean a lot of them. Beta means bugfixes, after all.
As always, we ask you to please keep in mind that the items above are not a commitment on our part. Plans can and do change as development progresses, and this update is no different. Same as always, you'll find the complete changelog on the release notes once the update is out, or stay tuned for our development notes every Tuesday to hear the news as they develop.
It's time to talk aerodynamics. More specifically, about what we have in mind for the upcoming patch and what you should (and shouldn't) expect from it.
First off, though, let me go ahead and say that our main goal with this is to make the game more fun. We are not looking to make things more realistic just for the sake of being realistic. If it doesn't make the game more enjoyable overall, then it's not worth adding.
That said, there are many planned changes that will indeed improve the realism of the flight model, because in many ways, a more realistic model means a more intuitive model, and more intuitive does mean improved overall enjoyment of the game.
You should keep in mind at all times, however, that KSP is a game first, a simulation second. We are constantly trying to maintain this precarious balance between too much realism vs too much simplicity. Both would frustrate some part of our players. Ultimately though, this is about making the game more fun.
So, let's first talk about the problems of the current system, from a gameplay point of view. Realism aside, what are the gameplay limitations we have at the moment?
* Cargo bays and nose cones have no use. This is a big one. Nose cones and cargo bays are no more than dead weight (and wasted Funds) if they offer no advantage over launching an exposed payload.
* Streamlined designs don't fly any faster than non streamlined ones. This is important from a gameplay POV because it's counterintuitive. If I build a javelin-shaped ship, I would expect it to cut through the air with far less resistance than a disk-shaped craft flying flat-side-first. This isn't happening with the current system, and it should be improved, if nothing else just because it makes sense that streamlined looking things should fly faster than flat-looking things.
* Wings are inefficient, making it overly difficult to design a spaceplane that will reach orbit with a meaningful amount of payload At the moment, the lift and control surfaces are producing less lift than they ought to, which of course, affects gameplay negatively in that you need excessive wing parts or excessive speed to lift any amount of payload. This is further aggravated when climbing out of the thicker parts of the atmosphere, as the reduced air density provides even less lift there.
* Spaceplanes are fiddly to design and build This doesn't concern the realism of the simulation so much as it does the UI around building spaceplanes. At the moment, there isn't enough information displayed to help players intuitively build aircraft that will fly properly and be controllable.
There are, of course, other issues, but these are our main concerns for the upcoming overhaul. Some of these issues will in fact require solutions that improve realism. Others will require some lateral thinking.
Another big concern that must be kept in mind here is that many players are already used to the existing system, and have build their fleets of spaceplanes based on the existing conditions. As much as possible, we want to ensure existing functional designs will still perform acceptably. It would be no fun to find out your spaceplanes aren't controllable anymore because of the new system. That wouldn't be an improvement at all from a fun point of view.
So that brings us to the core of the matter. These are the changes we are planning to change as of today (needless to say, this is all subject to change as we develop further):
* Improved Lift Model We are revising the lift model on lift and ctrl surface modules so that the lift force follows the standard lift equation, where lift is a function of the square of velocity. This will mean all lifting surfaces will produce a lot more lift as speed increases.
Increased lift output will change quite a lot more than just how much payload you can carry. With wings requiring less speed or less air density to produce enough force to take off, we can tune other parameters to solve other problems, without compromising the air-worthiness of existing craft. Furthermore, early testing shows that planes now fly at much more reasonable angles of attack, fly faster at low altitudes (due to less drag from wing surfaces at lower AoAs), and remain controllable when flying fast at high altitudes. This was already a marked improvement even without any changes to the drag itself.
* Improved Drag simulation The current drag model is flawed not just because it isn't unrealistic. It precludes nose cones and cargo bays from being of any use, and generally behaves in unauthentic and unintuitive ways. This goes beyond the problem of realism. The current drag model isn't capable of simulating things that are essential aspects of a space program, like ejecting fairings and the importance of a streamlined design.
There is one caveat however. The drag model as it is has one good aspect to it: it is far more forgiving to outrageous designs than a more realistic one. To some this further compounds the problem, but from a gameplay standpoint, being able to construct ridiculous designs and get away with it (if you can manage) is a good thing. It wouldn't be much fun if the game simply made it impossible to control those ridiculous contraptions that are so entertaining to build and attempt to fly.
The solution here then must be in either a happy middle ground, which may not exist; or, if that's the case, be somehow adaptable to each player's style of playing. Needless to say, this is not an easy problem to tackle, as it's quite clear to us that a move in either direction will upset some group of players. Too simple will upset those who like things to be realistic. Too realistic will upset those who like to build crazy things for fun.
This problem is further complicated by the very nature of the system we are trying to simulate. Airflow is a notoriously complicated system to simulate accurately, and even more so when you can't know in advance the flight characteristics of the aircraft. All flight simulations use approximations, in varying degrees of realism, for how air behaves around an aircraft. So whatever solution we come up with must not only fit the gameplay requirements above, it must also be computationally viable to not reduce the game into a slideshow.
The main goal of a new drag model then, is to allow the game to properly simulate payloads being protected from the airstream by a cargo bay or fairing, and nose cones properly reducing the drag of parts stacked behind it.
We are implementing a new system already, which is a solution we had planned for quite a while already, but so far hadn't had enough time to attempt. It's a large-ish implementation, but it should give us a new drag model in which parts can be obscured by others, and in which pointy objects will be able to fly faster than flat-faced ones.
This level of realism is what we are aiming for. It's not going to be an intricately realistic flight model, but it should at least be accurate enough to portray the important effects which are currently missing from the game.
That is about as much as I can talk about it without getting into uncertainty territory, but there is more to the overhaul as a whole still:
* Craft Design Difficulties: From an engineering standpoint, a rocket is a much simpler machine than an airplane. Rockets essentially fire a lot of mass towards the ground, and get pushed towards the sky. That means construction-wise, as long as you've got a nicely balanced craft where engines balance out, things should be quite straightforward.
An airplane is quite another matter. They require a much more complex set of forces acting on it in carefully balanced ways in order to achieve level flight. It's no wonder that rockets existed as fireworks thousands of years before fixed-wing flight was a thing.
Airplanes fly as a result of several forces balancing out: Wings produce lift, which must be balanced so as to not cause the craft to rotate out of control. Try launching a poorly thought out paper airplane to see what an imbalanced plane flies like (it doesn't). But balance alone is not enough. To maintain controlled flight, you must be able to influence this balance to cause the plane to pitch up or down, and thus be able to keep the thing in the air. Elevators are the common solution to that, but the way they work is not immediately obvious. The tail stabilizers on most aircraft doesn't actually keep the tail up, they actually push the tail down, acting on the plane as a lever, to push the nose up. Given enough airspeed, the downforce from the tail will force the nose up enough that the wings will catch enough air to produce the proper amount of lift to counteract gravity. Level flight is achieved when all these forces are in equilibrium.
Now, all that is usually done already for you in a normal flight simulator. Your job is simply to fly using the already-there controls. In our case, however, these concepts must somehow be made apparent to players, in a way that will help you see if your airplane is going to be stable or not.
There is a little-known trick to gauge the stability of a spaceplane before flight. Turn on the CoL and CoM overlays in the editor, then grab the root part with the rotate gizmo, and pitch the craft up and down. Note how the CoL shifts as the craft is subjected to airflow from different angles. A stable craft generally is one where the CoL stays behind the CoM at all times, and flips direction when the plane pitches nose down (i.e., pushing the tail down).
Using this trick, one can almost always achieve level flight without too much trial and error, and even if it's not completely right, level flight can be achieved by trimming the craft.
We can't expect people to figure this out, however, so the plan here is to come up with an improved UI for the SPH, where a more useful overlay will display this information for you in a way which will (hopefully) be clear enough to help you construct a decently stable craft without relying on excessive trial and error.
We don't expect this UI to be enough, however, so we are also working on other systems to warn players of potential issues (possibly based on the upgrade level of the SPH also), and also planning new tutorials where the basics of spaceplane design are explained.
This about covers the extent of our plans for overhauling aerodynamics. Hopefully this will clear up what we intend to do and dispel the concerns about what to expect from it.
There is one last thing to address of course, Modding support. This I think is one of the most frequently heard concerns, that our overhaul will prevent aerodynamics mods from functioning. This, as much as possible, is something we don't want to cause. Mods may very well become incompatible after the upgrade, as they often do, but we are by no means trying to prevent mods from functioning afterwards. If the new system is not to your liking, it should still be moddable just as much as the existing system is. We are changing how the stock aeros work internally, but as much as possible, we're striving to make the transition as transparent as we can to all other components, keeping the changes contained to their original modules.
That's all for now then. More news as they develop.
From the comments it's evident that some clarification of what 'preserving functionality in old designs' should be taken to mean. First of, we don't expect any of the planned changes should require breaking the craft file format in any way, so this is a minor concern already.
But most importantly, the only way to really judge whether the new system is an improvement over the old one is to compare both under equal circumstances, and for that we need a control. The stock crafts are coming in very handy for this. We know how they handle in the old system, and for the most part, we like how they fly (with some exceptions which do need improvement).
The point is, the stock craft are our measuring stick for comparing, tweaking and tuning the many variables of the new system, and for that reason they must stay, as much as possible, compatible. This does not mean we aren't willing to compromise on a few designs if others are performing better (not in terms of service performance, in terms of feel when flying). But take for instance, the change over to the new lift model. There is one constant which is used to scale the lift coefficient of all wing sections, defined in the part cfg, so that it translates into a nice, controllable flight model. How do we tune something like that? We have to have some reference to compare it to. For now, this scale was set so the takeoff speed of most craft remains unaffected. This means the new lift model is producing values in the same order of magniture as the old one, in one particular situation, so we can start from there to have a solid basis to tune from. We will probably end up tweaking this value further based on feedback during testing, but the importance of having a basis for comparison can't be understated when working on something like this. On my first attempt, this value was set to 1.0, and ships simply exploded on physics start, because the forces were orders of magnitude off. Without a benchmark, it would have been very difficult to even find out what should be changed to fix it.
In any case, the short version is: don't worry too much about us worrying too much about backwards compatibility. It's not even likely to be such a big deal after all.