-
Posts
3,542 -
Joined
Content Type
Profiles
Forums
Developer Articles
KSP2 Release Notes
Everything posted by HarvesteR
-
Hi, There's no good way to ease into news like this, so here it is: I'm stepping down as Lead Developer of KSP. For the last five and a half years, I put all my work, my thoughts and my time into KSP. I've watched it grow from this little unassuming idea for a 2D game in which you'd put together rocket parts to see how high you could get, into a complete spaceflight simulator, a space agency tycoon, a planetarium of truly astronomical scale, a home for little green men and their space program, a Kerbal space program. KSP has become far more than the game I imagined half a decade ago. When we first set out to take on this project, I could not have expected anything even remotely close to what it ended up becoming. To say KSP surpassed my every expectation would be, at best, a colossal understatement. There was a time, years ago, when any single design decision of mine had the power to drastically change the direction of the project. There was the danger that by even moving ahead on development of one area instead of another, the entire feel of the game, the intent it carried, could be morphed into something else. There was a fine line we needed to stay on, lest we let the project slip and become something other than what we intended. That is no longer the case, and that's a very good thing. It means that conceptually, the game is complete. This isn't to say KSP's development is complete, however. Far from it. Plans for KSP reach far into the future, and there are enough ideas to keep us all going for years. The console versions are coming up, there are new updates in development, the list goes on. For myself, however, I desperately need to have something new, to create more than one game in my life. I need to make one thing perfectly clear: development on KSP will continue as always. No features, upgrades, bugfixes or anything of the sort are being discontinued because of my leaving. This I say with absolute confidence, because I have complete trust in every member of the KSP team, and I know they are fully capable of handling anything that comes their way. The KSP team deserves more praise than I can give them. This is a band of outstanding people, all brilliant and excellent at what they do, never tiring, never doing anything less than their best. I'm very proud of what we have accomplished together. It's something I'll carry with me for ever. I also know beyond any question that KSP would not have become what it is without every single one of them. I am forever grateful and in awe of all the work they put in. And of course, I must give all my thanks to the founders at Squad, Ezequiel and Adrian, who took this wild leap of faith with me, putting their unconditional trust in me without ever requiring any failsafes or guarantees of success. We all know games are a notoriously risky proposition in the best of times, and they nonetheless extended their full support to me, at a time when none could tell what lay ahead. Lastly, but most certainly not least, I have to thank every single one of you, the community, our players, kerbalnauts, space enthusiasts, reckless rocket engineers, our friends. All of you, who like us, believed in our weird little game and supported us throughout the years with your ever-inspired ideas, your unparalleled willingness to help, your relentless honesty and your unfailing loyalty. I cannot thank you enough for all of it, and I can only hope I am so lucky to see you again in whatever comes next. This isn’t goodbye. It’s just farewell for now. In the meantime, however, I hope you all enjoy playing KSP as much as I enjoyed being part of its making. Signing off, Felipe Falanghe, aka HarvesteR Please post comments in this forum topic.
- 1 comment
-
- 35
-
Anyone Else Recently Build A Bad@** PC in Reponse to upcoming 1.1?
HarvesteR replied to scribbleheli's topic in The Lounge
I did. I had to upgrade my rig to work properly on KSP, so I think that counts. Went from a Core i7 920 to a Core i7 4790K, OC'ed to 4.6GHz (stock 4GHz). Also upgraded the mobo to an Asus Sabertooth. That is definitely a badS piece of hardware. Compile times went from 1min+ to less than 30 seconds! Cheers -
Greetings, Kerbonauts! It has been a while, longer than we anticipated in any case, but we're now here with a new update for Kerbal Space Program: version 1.0.5! This update features content, bugfixes and rebalances that were part of the upcoming monster update 1.1, which will feature such things as multithreaded physics calculations and 64 bit support for Windows and OSX. That update is taking longer than anticipated, and we came to a point where a lot of content was ready to go through testing and be released on its own merits. With these parts ready we wanted to get them to you as fast as possible, and I think we have succeeded in a speedy delivery of this patch. Here are some of the highlights in this patch: Contextual Contracts & Contract Changes The contracts system has had a major overhaul with the goal of providing you with more varied and relevant contracts. Front and center in this overhaul are the contextual contracts, which adapt to your progress in the game. Contextual contracts will take your existing infrastructure consisting of bases, stations, satellites and rovers, and will challenge you to do things such as adding new modules, rotate crews, fly in a Kerbal with a specific skill, explore the surface around it, move the orbit and so on. The goal of the integration of the contracts with your existing missions is to integrate them more in the natural gameplay. You will be asked to use what you have built already, alongside the existing contracts that mostly ask you to launch new items. More changes can be found in the passive milestone rewards, which automatically reward you for any milestone you cross. These rewards are not only reflected in reputation gains, but also in funding and science bonuses. Higher rewards are still available to players who actively pursue a goal from a World's First contract they've accepted. New milestones are also available, targeting objectives such as space walks, crew transfer and atmospheric flights on alien worlds, and if you're not someone who spends a lot of time at mission control then a new strategy available from the Administration Building is right up your alley: leadership initiative increases the passive milestone rewards at the expense of contractual rewards, providing a boost to more independent players. Finally, the game now tracks manned and unmanned progress separately. Thermodynamic improvements Update 1.0.5 features many improvements to the thermodynamic systems. The thermodynamics ('thermo') system has been reworked to correct the various issues encountered in 1.0.4. In addition the thermodynamics at high timewarp feature more customizability, and support differential skin-internal temperatures and non-instant changes. We've also corrected some issues with the atmospheres of other celestial bodies, and better tuned re-entry and aerobraking across the board. When loading a long-unloaded vessel, unloaded thermal changes will be applied, too. The concept of core heat was also introduced, which in combination with various fixes should stop unexpected overheating of parts. Probably the best analogy of how this interacts with the rest of the thermal system (internal and skin temperature) would be to compare it to your computer’s case temperature, the temperature inside of the case, and the temperature of your CPU. For example, the ISRU should be capable of smelting materials, yet not melt the rocket it’s attached to. In game, this means that the ISRU works best with a core temperature of about 2000K, even if the part only has an internal temperature of 200-300K. This system allows us to be very expressive with the core temperature and simulate things such as warm-up time & overheating without it being directly coupled to the part temperature, which would become problematic as we enter analytics warp and temperatures equalize. New buoyancy model The water buoyancy has been completely reworked. Water is now less soupy and it's very possible to build seaplanes. In keeping with our commitment to make the game as moddable as possible all the physics values can be tweaked in config files. The density of oceans differs across celestials bodies, invoking new gameplay challenges. The impact speed not only depends on the speed of the craft when it hits the water, but also the angle at which it hits the water. New rocket and spaceplane parts A wide range of new and overhauled parts were introduced. The toroidal aerospike rocket engine has had an overhaul, as did the basic- and ramjet engines, the radial air intake and many mk.1 spaceplane parts. Among the new parts we find a complete working kit for mk.0 jet engines, the "Goliath" turbofan engine that would be a great fit on a large airliner and the "Vector" rocket engine, which mimics the Space Shuttle's main engines. The mk. 3 Cargo Ramp is a brand new part as well. This'll allow you to drive a payload into the back of an aircraft, or perhaps you want to create a docking bay on a space station with it! These are just some of the updated parts, we're hoping to see many new creations that incorporate them. We've also added new stock craft in the game for you to play around with. Bugfixes & Tweaks KSP 1.0.5 has seen a big focus on bugfixes. Over 100 issues were fixed, including launch clamps following you to orbit, . And good news for anyone with a fine eye for detail: the black stripes on the NASA tanks now line up perfectly! There were of course plenty more bugs on the 'fixed list', and a more comprehensive list is available below. As always there is much more to discover in the update, and we hope that our fantastic people on the Media Group and KSPTV have given you a taster of what to look for. Changelog =================================== v1.0.5 ============================================================ Hotfixed (build 1028+): * Reduced engine heating: less explosive decoupling. * Fixed NRE on Kerbal when the part it's on dies. * Fixed IVA breaking on crew transfer. * Fixed typo on Dynawing craft. * IntakeAir resource is now fully hidden in Resources App. * Fixed body lift (it now exists again). * Fixed every instance of part name, so root parts can be detected in all contractual instances. * Used Unity drag to avoid integration errors on splashdown. * Clamped parachute radiation. * Upgrade outdated instances of vessel situations in career saves * Included layer 19 objects in potential enclosing colliders for cargo bays Parts: * Added 'Juno' 0.625m jet engine * Added 0.625m air intake * Added 0.625m Liquid Fuel tank * Added 'Panther' afterburning jet engine * Added 'Goliath' giant turbofan engine * Added S3 KS-25-1 'Vector' Rocket engine, with super-large gimballing range * Added Mk3 size Cargo Ramp * Added Mk3 engine mount piece * Added Mk1 crew cabin, seats two * Added new Mini-ISRU part * Mk1 Cockpit model overhauled * Mk1 Cockpit IVA space overhauled * XM-G50 Air intake model overhauled * Mk1 Fuel, Structural and Intake Fuselage parts overhauled * T1 Toroidal Aerospike engine model overhauled * J-33 'Wheesley' Jet engine model overhauled * J-X4 'Whiplash' Jet engine model overhauled * Engine Nacelle and Engine Precooler parts overhauled Contracts: * Added Station and Base Contextual Contracts, requiring you to modify/expand existing bases and stations * Added Satellite Contextual Contracts, requiring maintenance operations to previously deployed satellites * Added Survey Contextual Contracts, which target existing landed vessels to request (applicable) survey missions of them * Part Test contract generation logic has been modified. Each part now has a much more specific set of constraints before it generates, to give it much more consistent and realistic altitudes, speeds, and envelopes. * Passive Progress Rewards: gives a light reward automatically to any new achievement. These are given independently of accepted World-Firsts Contracts, but are not as substantial. * Contract Decline Penalty: A small reputation penalty is incurred when a contract is declined, to prevent Mission Control from being abused as a slot machine. * New early game part haul contracts - easier part tests that only require you to bring the payload to a designated location. * Early game focused surveys balanced to be much more forgiving. * New part tests added for fairings and heat shields. * Many milestones added that involve the player doing hidden fun stuff. Strategies: * Added Leadership Initiative Strategy: increases passive rewards for achievements, at the cost of reduced contract rewards. Useful to boost self-driven playstyles. Progress Tracking: * Added new World First contract types for space walking, crew transfers, and flight on atmospheric planets. * There is also now a fourth record "track" for oceanic depth. * Many progress nodes now track progress in separate manned and unmanned tracks. This allows several contracts to appear at more relevant times. * Base and Station, plant flag, kerbal recoveries (rescues), crewed surveys, tourism, and some World Firsts contracts now require manned progress. * Satellite contracts now require unmanned progress. * The algorithm to choose planets for all contracts is now more reliable. Max CB "distance" has been reduced to two. This means you will no longer see contracts for Duna and Eve right after taking off from Kerbin. Science and Comms: * Science Transmission messages now show strategy changes to science, funds, and reputation. * All antennae now cut a transmission that has been interrupted due to power loss to prevent severely devaluing the resulting science. * Added an option to antenna context menus to manually enable partial transmissions. * Interrupted transmissions no longer delete science data. The data will attempt to return to the container it came from. * Transmission from orbital surveyors and science labs was tweaked slightly to look and behave more like standard science transmissions. NavBall: * The navball is now available on EVA to assist in surveys. * The EVA NavBall follows the orientation of the camera, rather than that of the Kerbal. This allows looking around to get your bearings. * The navball throttle and RCS lights are hooked up to the EVA jetpack. * The IVA navball now functions with survey navigation. * Survey navigation icon will now automatically target the next/closest adjacent waypoint in a survey upon completion of a targeted waypoint Thermodynamics: * Introduced the concept of 'Core Heat'. Allowing part systems to work much more expressively with temperatures, reducing unwanted cross-talk between temp effects on internal logic and heat transfer to other parts. * Radiators should have a significant impact on core heat, allowing ISRU modules to operate at peak efficiency. * Incredibly hot cores should bleed off some of their heat to the parent part, with the vessel very slowly getting warmer over time. * Parts should not explode from core overheating, but ISRU modules may shut down. * Thermal efficiency should be consistent across all warp levels - no cheating! * The mini-ISRU is balanced in that it cannot operate indefinitely. It will eventually shut down due to overheat and have to be allowed a cool-off period. * The RTG is also part of this mechanic, making it a viable heater (Kerbals have the added advantage of not requiring any potatoes for unplanned long-duration stays on desolate planets). * Fixed thermodynamics issues from 1.0.4 regarding unclamped conduction, shielded conduction, and other runaway cases. * Reworked upper atmospheres of planets for better aerocapture experience. Added convection and shockwave temperature multipliers per body. * EVA kerbals handled properly. * Lowered max internal temperatures of crewed parts. * Heating from engine exhaust rebalanced. * Thermo at high warp is now no longer instantaneous, and is moddable via new interfaces. * Unloaded vessels will have thermo applied for the unloaded time on reload. Buoyancy and Water: * Displacement is now calculated per part using dragcube information to estimate total actual volume of the part. * Bodies now have an ocean density: Kerbin/Laythe is 1 tonne/m^3, Eve is 1.5. * The lowest and highest points of parts are calculated with respect to the water, and a submerged fraction of volume is calculated to modify buoyancy force. * Impact speed (tested against crashTolerance) depends on impact angle, with a configurable minimum multiplier. * Drag in water uses drag cubes and an accurate dynamic pressure calculation. * Drag scales from high on first vessel contact down to a lower value after a few seconds. * Drag also ramps back up when the vessel is below a minimum velocity (to model the highly turbulent flow when starting from a stop, and to make sure vessels do come to a stop). * Lift behaves similarly, starting near zero for the madly turbulent flow of initial contact or first movement, up to a reasonable value. * Various hollow parts have their displacement tuned to account for hollowness. * Solar panels lose flow rate underwater, rocket engines lose Isp. * Added underwater fog and tint, fixed camera issues underwater. Physics: * PhysicsGlobals now properly create the default values when Physics.cfg is removed. It includes many new values. * Drag coefficient changes based on the same factors as turbulent convection (a Pseudo-Reynolds number). This means higher drag high up in the atmosphere, and slightly lower drag when going very fast very low. * Asteroids have correct drag cubes now. * Fixed issue with radiator dragcubes being incorrect when the panels rotate. * Add missing drag cube overrides for hollow parts. * Kerbal EVA drag cube can now be specified in Physics.cfg. * Fix issues with override drag cubes and root parts during revert/quickload/vessel switch. * Fixed issues with female kerbal ragdoll rigidbodies. * Fixed a bug in calculating how solar flux diminishes in atmosphere. * Jettisoned Fairing panels now exist in a new layer (L19) dedicated to non-part physical objects. * Contact with L19 objects does not cause vessels to shift into 'landed' state. * Kerbals are allowed to stand on L19 objects, regardless of their own landed state (similar to how they behave when on ladders). * Contact with L19 objects only allows Kerbals to stand and walk while within a surface-level altitude/speed envelope. (contact with these objects in orbit has the same effect as bumping into anything else). * Eve and Jool had upper atmosphere changes to thin the top band. Duna now shares the molar mass of Eve but has a lower presure than before, leading to the same density (and drag) at sea level but better physical characteristics. Misc: * Fix surface horizontal velocity being incorrectly calculated. * Launch clamps are now properly kept at the launch pad, they will not follow the current vessel. * Fix an issue with localisation and settings.cfg. Fix an issue with plugging/unplugging controllers breaking/losing settings. * Save and load kerbal trait in save games, trait is generated from name hash only if not specified in the save. * Fix issue with solar day length not being calculated correctly when setting Kerbin's rotational period. * Workaround for kerbals becoming debris added, to prevent serious issues. * Sped up finding a given AvailablePart (especially relevant when populating the Load Craft menu). * Sped up craft loading slightly. * Sped up FlightIntegrator and in particular the Occlusion part. * Fix some bugs in resource requests that would lower throttle or miss resources. Optimized resource calls. * Jets now use a fuel mode that draws an equal percentage from all reachable parts (no-crossfeed parts will block crossfeed). * Fixed an issue with camera pitch underwater. * Fixed an issue with error spam from failed raycasts when >600m under water. * Fix an issue with fast EVAing kerbals leading to NaNs. * Fix an issue with compound parts and zero look rotation vector logspam, also slight speedup. * Optimized several contract/progress parameters to not require any code running in update-loops (they're event-driven now) * Fixed orientation of the sun light in IVA * All older careers will have their contracts upgraded to new versions, maintaining compatibility. * Many new career cheats added. * Contracts.cfg now fully comments itself. Editor: * Fix an issue where non-root parts spawned in the editor did not have their partInfo set correctly. * Fix an issue where symmetry mode could be increased past its limits. Part Class and Modules: * Fixed some issues in RCS, made RCS toggleable in the editor and gave it a thrust percentage slider. * Solar panels and radiators: fixed curve issue with solar panel efficiency where when at high temperatures the generated EC could go negative. * Solar panels and radiators now use dynamic pressure instead of (linear) velocity when calculating breakage. * Fix Solar panels and radiators to support sun tracking drag cube changes even if no extend/retract animation is specified, add support for an offset angle when tracking the sun. * Solar panels can now extend and retract in the editor. * Solar panels now respect aero shielding regarding EC generation. * Parachutes: fixed exception spam in parachute module in the editor, fix where parachutes would cut on decouple. * Parachutes now have a disarm option when armed and not yet deployed * Parachute stack icon background shows red when unsafe and yellow when risky. * Parachutes no longer flutter identically. * Parachutes no longer instantly snap to the velocity vector. * Parachute tooltip in the editor shows safe deployment speed near sea level on Kerbin. * Allow alternators and FXAnimateThrottle to be bound to MultiModeEngine, to an indexed engine module, or to a named engine module. * Fix some issues in ModuleAlternator, add support for a threshold below which no resource will be pushed/pulled. * FXAnimateThrottle can now optionally depend on engine output or engine currentThrottle, not on the vessel/UI throttle state. Can also modify anim speed rather than time. * Added support for layers to ModuleAnimateGeneric, ModuleAnimateHeat, and FXModuleAnimateThrottle. * FXModuleAnimateThrottle can now weight its animation based on wether the engine is active or not (used with multimode engines). * Allow MultiMode engines to share throttle state when switching and to have automatic switching be disabled (and the toggle for it not show up). * Made ModuleAnimateHeat more tunable due to new thermo. * Docking ports now have gendered as an option, and support limited docking angles. * Docking ports crossfeed state is now persistent and can be toggled in the editor and by action group. * Docking ports can have their 'decouple' mode set to stageable. * Docking ports node type field supports comma-delimited lists of valid types. * Fix an issue with shielded docking port orientation causing logspam in the editor. * Various Claw bugs that could break games are fixed. * Fix Airbrake action group persistence. * Give airbrakes the same thermal tolerance as other airliner parts. * Fix issue where the airbrake had no orientation vector set, thus resulting in continues "Look rotation vector is zero" messages when trying to attach in the editor. * Lower some out-of-norm crash tolerances for aero parts. * Ladders now properly have multiple drag cubes (due to their animations). * Fixed ladder extend/retract failing after a load in the editor. * Shrouds no longer glow on revert and can be set to only detach when the node opens, not just when the part is activated by staging. * Shrouds can be toggled off in the editor. * Control surfaces deploy state is now properly persistent. * Offset cargo bay interior nodes so the inside and outside nodes do not precisely overlap, to aid in part placement. * Procedural fairings set part mass in the editor as well as in flight, properly offset CoL, CoP, CoM depending on fairing state, properly reset drag cube after deploying. * Fixed issues with intake logic and display airspeed. Intakes can now have mach curves which can affect their efficiency at different mach numbers. * IntakeAir is no longer displayed, since it was confusing, instead engines show whether their current requirements are being met. * Engine modules support new curves for modify Isp based on air density and current mach number, so multFlow no longer exists as a toggle. * Fixed an issue where throttle was not reset to zero on flameout. * Engine modules now show percentage of their current propellant requirements being met. * Fix flow cap not being used in tooltip info. * Corrected an issue with the 'fuel flow' display. * ModuleAnimateGeneric events and action can be independently enabled/disabled per scene. * Make hatch obstruction check distance tunable per part. * Allow no-activation-when-shielded to be toggleable in cfg for engines and RCS. * Fix bandwidth calculation typo for ModuleDataTransmitter. * Activate gimbals when an engine activates, not only when an engine activates from staging the part. * Fix Brake Torque tweakable on wheels to have fuller range, allow adjusting stiffness in cfg. * Fix flow cap not being set in jet engine cfgs. * Intakes and engines can be set in their MODULE config to be disabled when under water (disableUnderwater). * Decouplers can have their staging and their crossfeed toggleable. * Fixed several edge cases where CargoBays would not update the shielded status of contained parts correctly. * Connected cargo bays now propagate any state updates to all bays in the connected space, ensuring all bays refresh when any of them does. UI: * Units have been added to various part tooltips and Thermal Data, and the part tooltip has more and better information shown. * Thermal Data shows when skin temp shown is the exposed temperature only or the unified skin temperature. * Heatshields now show data when Thermal Data is enabled. * Fixed temperature gauges bug where it was using internal max temperature, not skin max temperature, despite comparing that against the current skin temperature. * Made edge highlight separately toggleable from the gauges. * The settings menu now shows the various settings, and F10 toggles through all four possible arrangements. * Flags no longer count as active flights on the Resume Game interface in the Main Menu. * Fix issues with FlightLogger's values not accounting for reference shifts. * If a part on a vessel is targeted, display the vessel label over the part, not the center of the vessel. * Fix Center of Thrust marker in the editor (was not properly calculating direction). * Fix an issue where loading a save via the Load Save menu would not properly clear, nor load, AppLauncher messages. * Fix an issue where an unreadable agent texture would break agent loading (and contracts generally). * Made crew transfer available from the part right-click menu. * Made 'rename vessel' available in flight for a vessel whether or not it is under command (though a ModuleCommand still must be present for renaming in the flight scene). * Fix issues where partname not part title was used. * Fix vector to target (on navball) to calculate from current control-from-here transform to target transform, rather than vessel root transform to target transform. * Fix an issue where a tweakable being open might spam OnVesselModified events in the editor. This also lowers memory leaks. Input: * Double-tapping RMB now enables a mouselook-toggle mode, similar to RMB behaviour in IVA views. * Added independent key binding [backslash] for mouselook toggle * Mouselook mode can be cancelled by double-tapping LMB, MMB, or by tapping RMB or Esc. * Mouselook mode will also self-cancel on any scene changes, but persists through camera mode changes, for uninterrupted panning through multiple view modes. * Tapping ModKey no longer releases mouselook in IVA. Graphics: * AeroFX now tuned better (and more tunable), leading to mach effects down low without flaming rockets at mid-altitude. * The glow parts make when they heat too much (not the same as the highlighting they get when near maximum temperature) has been tuned. * Fix issues with flags resetting to default, flags never changing for first two Pad tiers. * Fix Val's missing visor in the main menu scene. * Add RenderType to some PQS and Scaled shaders to aid in visual modding. * Allow eye position offsets specified for seats in IVA, both for normal view and for the portrait view (different variables). * Allow IVA and IVA-kerbal rescaling. * Credits scene now has column bars on screen aspects wider than 16:9 (clamping max aspect ratio to 16:9) Modding Support: * Support having KSPEvents available even when the vessel is not under command (defaults to false, can be set true for an event). * Fix an issue with VesselModule / PartModule instantiation order differing for fresh and loaded vessels. * Fix an issue where VesselModule order could not be set, they now can override GetOrder, by which all VesselModules are sorted. * VesselModules default to order = 999 but FlightIntegrator has order 0 (this will allow easy setting of some modules to run before FlightIntegrator and some afterwards, 0 is a good delimeter). * GameVariables are now aware whether they are called from the rocket (VAB/Pad) or spaceplane (SPH/runway) side. * Catch errors during ScenarioModule and Contract loading, preventing breakage when mods throw exceptions during these times. * Fix an issue in assembly dependency version checking. * Added a new interface IActivateOnDecouple that will call the stated method when the part decouples on the stated node. * ConfigNodes/values support comments (which will be serialized on write). * Add fallback tech tree URL in case the main URL fails to find a valid tech tree. * PartModules can toggle their part being in the staging list or not. * Decouplers (and docking ports, but it defaults unstaged) have it on by default. This is part of the base PartModule so all that is needed to implement is add some settings to the MODULE. * Resources now have an isVisible flag, which determines whether the resource is visible on the right-click menu. Applied it (as false) to IntakeAir. * KerbalEVA now uses the rotPower member. * Fix enum parsing in BaseFields (i.e. KSPFields). It should now work. * Support tagging models with Drag_Hidden (like Icon_Hidden) so they will not be rendered when rendering drag cubes. * Added OnFlightUIModeChanged event, fired from FlightUIModeManager. (notifies of changing between Staging, Docking and Map modes in flight) * High-warp (analytic) thermo supports three interfaces, IAnalyticTemperatureModifier, IAnalyticPreview, and IAnalyticOverheatModule for better customization, and uses new fields in Part for tuning. The update is now available on the KSP Store, Steam and will soon be available on GOG. We hope you will enjoy Kerbal Space Program 1.0.5 as much as we enjoyed making it. Happy Launchings! Cheers Update November 11th Hello everyone! As announced in the devnotes today we have published a 'silent' patch for 1.0.5. This quick patch brings a few fixes to issues that popped up in the update: - Reduced engine heating: less explosive decoupling. - Fixed NRE on Kerbal when the part it's on dies. - Fixed IVA breaking on crew transfer. - Fixed typo on Dynawing craft. - IntakeAir resource is now fully hidden in Resources App. - Fixed body lift (it now exists again). - Fixed every instance of part name, so root parts can be detected in all contractual instances. - Used Unity drag to avoid integration errors on splashdown. - Clamped parachute radiation. - Upgrade outdated instances of vessel situations in career saves. - Included layer 19 objects in potential enclosing colliders for cargo bays. (fixes some occlusion errors) Steam users will not have to do anything to have this patch applied to their game, those of you who have downloaded it through the KSP store can redownload the game, and finally if you've bought the game through GOG the patch is currently in their approval process, we'll update this thread once it's available. The build number in the main menu will jump from 1024 to 1028 after the patch is applied. The update is now available for download.
-
An open letter to the developers of Kerbal Space Program.
HarvesteR replied to Tang_Titan's topic in KSP1 Discussion
You can also rest assured knowing that every one of us has read your letter now, and I'm fairly sure I speak for everyone when I say it was truly moving. This goes well above and beyond what we set out to do when we first started this project, and I really can't express how it feels to know something we've done has had such an impact on others. I'm very glad to hear KSP has had such a positive effect on you. All the best, from the entire KSP team. Cheers! -
Hi, KSP version 1.0.3 is now live! This revision brings several much-needed bugfixes and improvements, as well as a few new parts. Most importantly, this patch introduces a big revision to the thermal system for parts. The heat simulation has been greatly improved, heat from reentry is now handled in a totally new (and more accurate) way, and we've also added five new Radiator parts, so you can have much more control over how your ship deals with excess temperatures. We've also fixed a significant amount of bugs. Here's the complete changelog: =================================== v1.0.3 ============================================================ New: Parts: * Added five new Radiator parts, three of which are deployable. Bug Fixes and Tweaks: Misc: * Fixed a bug where using the reset button with an Asteroid loaded would break the Mun tutorial. * Made part's internal highlighter much more efficient. * Disabled flashing highlighter in temperature gauges. (fixes memory leak with temperature overlay) * Fixed KSPUtil.PrintLatitude/Longitude giving wrong result for small negative values. * Fix for horizontalSrfSpd being incorrectly calculated. * Fixed unfortunate typo in the Docking Tutorial. * Fixed an issue where moving the camera using a 3D mouse would break drag-and-dropping of parts in the editors. Thermal: * 1.0.3 features a revised thermal mechanic to better balance heating/cooling between pods and spaceplanes. * Parts now have separate internal temperature and skin temperatures. * Skin temperature is the temperature used for radiation and convection, as well as engine exhaust damage. * Part internal temperature is increased by modules that generate heat and is used for part-part conduction. * Part internal and skin temperature also conduct between each other. * Solar panel efficiency is now calculated based on skin temperature. * When in an atmosphere, there is a divide between the exposed (to convection) and unexposed skin temperatures. * When not in an atmosphere, only one skin temperature is tracked; the two temperatures are unified on atmosphere exit. * Radiative outflux and influx is tracked separately for exposed and unexposed areas of skin (since the shock temperature is much higher than ambient temperature). Physics: * Added curve to control drag coefficient exponent to DCL and Physics.cs * With lowered drag for sharply-tapered cubes, wing lift and wing drag lowered to match. * Convection velocity exponent raised to 3.3 to increase reentry heat, as well as convection factor. * Convection min area typo corrected. * Newtonian convection kept pace with hypersonic convection. * Drag curves modified to lower transonic hump. * Wing curves modified to lower change in drag based on deflection. * Calculation of exposed area for convection fixed, spaceplanes no longer get as extreme heat. * Flight integrator: allow setting of newtonian density exponent (default 0.5) and use density or density^exponent whichever is greater. * Broke radiation into two parts, you get the regular background temp on your face not exposed to reentry flux, and the very high reentry one for the area that is. * Clamped convection correctly so you will never pass external temperature. * Added a factor to simulate the switch from laminar to turbulent flow (in layman's terms, if you're going too fast too low, you get a massive boost to heating). That corrects so steep reentries are in fact deadlier than shallow ones. * Added conduction-changer module to Mk1 and Mk1-2 pods (necessary to not kill chutes), buffed heat shields for new heat loads. Changed burn/rip numbers for drogue chutes. * Parachute module updated to use the new convection code. * Skin temperature variables are controllable on per-part basis. * Sped up Flight Integrator slightly by minimizing repeated loops through parts. * Better compute various vessel values This should lower phantom orbit changing and wobble! * Remove thermal mass as a factor in conduction rate: what matters is area. * Add conduction between parts' skins (as well as between the internals of parts, between a part's internals and its skin, and between the exposed and unexposed skin of a part, all of which were already in.) * Fix some small issues in conduction (better clamping), sped it up slightly. * Fixed issue with radiation (no longer have to use dirty hack to prevent parts blowing up). * Lowered skin thickness slightly globally, made magic number sane (part.skinMassPerArea is now in kg/m^2). * Added Hsp (resource thermal mass value) to Ore resource. Parts: * Updated Mk1 Inline Cockpit model. * Further decrease in LV-N heat production. * Rebalance of SRB for the new drag changes. * KR-2L description updated, mass to 9t, SL Isp to 255. * Jet thrusts rebalanced for new drag (thrusts lowered, BJE curves altered). Jet Isp halved due to increased fuel quantity and lower drag. * Lowered LV-N heat a bit, still a bit hot. * Edited KS-25x4 "Mammoth" engine description. * Update description of radial-mount engines to recommend use for extra attitude control. * Mk1 fuel tank: uses same dry mass fraction and resource filling compared to its LFO counterpart as Mk2 parts do. * Radial attachment point cost lowered. * Shielded docking port radial attach node fixed. * Aerospike mass lowered as a buff (it needed a buff to compete with late-tier engines) and tangents fixed. * Heat shield thermal mass modifier increased to 0.05 to deal with increased heating. Max temp lowered to 3000 to avoid totally overpowered radiation heatloss. * Mk3 cargo bays have override cubes (they got missed when cargo bays got custom cubes) - should now have expected drag. * New large landing gear have override cubes (cubes were reversed). * Mk3 parts have breaking forces/torques specified and should no longer break on landing. * Mk2 cockpits have same breaking force/torque as other Mk2 parts. * Ablator resource heat capacity increased. * Rebalanced LV-1 to have Sea Level ISP of 80. * Rebalanced Poodle to have Sea Level ISP of 90. * To fix spaceplane vs pod reentry and better allow hot reentries, temp is separated between part internal temperature and part skin temperature. * Fixed some occlusion issues. Occlusion is now over-generous rather than under-generous. * Buffed heat resistance of spaceplane parts. * Added in CoL and CoP offsets for wing parts, no longer at the attach node. * Fix for ablator and configs not taking skin temp into account. * Fixed Radian vs Lat/Lon bug in Overlay and made displays more consistent. * Fixed potential exploits with sci lab. * Removed transparency and added direct-attach node to heat shields. * Balanced heat shields for skin temps. A Mk1-2 straight-in reentry to Eve starting at 6.5km/sec surface (more orbital) is just barely survivable (ablator fully depletes), and regular Eve and Kerbin Munar reentries deplete about 1/6 to 1/4 the shield. * Added a tuning factor to conduction between parts with different shielded states, so a cargo/service bay won't conduct much to parts within it. Since radiation is disabled for parts within bays, they'd just increase in temperature with no way to cool during reentry, and parts in bays would be the first to blow up on reentry. * Upped non-drogue chute default full-deploy altitude since pods were crashing before the chute fully opened. * Upped non-drogue chutes' stress/thermal limits for deployment (safe speed is now around 290m/s at sea level rather than 250). Increased the time to fully deploy slightly so less of a G shock. * Increased max temp of linear RCS, slightly decreased max temp of RCS quad. * Tweaks to fairings to change the skin:internal thermal mass distribution, and better protect parts inside fairings and cargo bays. * Not-Rockomax Micronode side stack nodes corrected. * Parachutes now have deployment warnings in the Part Action menu, when it's safe to deploy etc. * Halved intakeAir requirements for jets. Slightly raises service ceiling, mainly helps mitigate flameouts due to resource transfer issues. * Balanced thermal mass of drogue chutes to correct max opening velocities. * Attach node refinements on Wing Connector Type A and Structural Wing Type A. * Removed drag from Intake context UI. Modding API: * flow multiplier curves can multiply thrust rather than flow. * Added method to convert string to ConfigNode. * Un-hardcoded altitude for navball velocity indicator to change modes. FX: * Heat animations for engine nacelles and 1.25m intakes. * SR-71 style exhaust flame for TurboRamjet. * Nose and tail cones heat animation. * Fixed incorrect transparency on the letter P on the UKSA flag. As always, the latest update is available at the KSPStore, Steam and GOG. Happy Launchings! Cheers
-
Hi, Since we didn't have a full dev note this week in light of the PS4 announcement, I figured I'd write up some lines about what's currently going on on our end, which is for the most part related to the Unity 5 port at the moment. It's worth mentioning though, that our moving to U5, which I think is fair to say is something everyone has been asking for quite a while, has been largely sped up by our collab with FlyingTiger, who are developing the PS4 version. The first step for them was to move the game into U5, and because that was something that affected the entire project, we felt the best way to go about it was to work together on upgrading the project, so the PC version wouldn't be stuck on Unity4 as they moved on. So contrary to popular belief, the move into PS4 is actually giving PC development a boost, not hindering it. Anyhow, let's get into about what's going on development-wise. First off, the biggest hurdle/opportunity we came across was the game's UI. The current UI implementation (not design, mind) is, well, let's say it's not my favorite part of the project... The lack of a robust native UI toolset in U4 and earlier meant that over the course of development, we ended up with multiple different, sometimes conflicting UI systems working alongside one another. Unity's OnGUI code-driven UI, EzGUI, and the SSUI system I wrote back in v0.3 or so, all these systems were being used at the same time, each drawing their bit of UI, and trying not to step over the other's bits. Re-doing the UI was something we all wanted to do here, but the amount of work it would require was, to say the least, discouraging. That's all of the game's UI we're talking about. From part context menus to confirmation dialogs, to flight gauges to settings screens... all of it needs to be redone. Not a small task by any measure. So it's no wonder we weren't exactly in a hurry to deal with that before, even more so because before Unity's new UI system came along, the idea of consolidating UIs meant choosing one of those systems I mentioned earlier... so we wouldn't be upgrading to anything superior then. With the new UI system in U5 though, this became a much more interesting notion. Unity's new UI combines the best features of the many UI tools out there,into a flexible, sleek and very powerful all-around system. Good, but it still meant redoing the entirety of the game's UI. The final push came from the PS4 porting side. PS4 has its own set of tech requirements, and our 'eclectic' UI implementation was evidently not quite up to par with those reqs. For the past weeks then, we've been working on a total revision of the game's UI. Currently Jim (RomFarer), Mike (Mu) and DJ from FlyingTiger are assigned to that enormous undertaking. On my end, I'm tasked with the shaders and physics side of the U5 upgrade. Shader-wise, we had a few broken ones here and there because of upgrade issues, which were for the most part easy to fix (DJ helped me out there a lot too, he had been plugging away at it while we were still in exp for the 1.0 release). The ones that were most complicated were the terrain shaders. U5 compiles shaders differently, so that meant some of our terrain shaders were now above the SM3 limit for interpolators. A shader interpolator is the process by which the GPU figures out what a pixel that sits in the space inside a triangle ought to look like. It does that by (as the name implies), interpolating values from the surrounding vertices, which were calculated earlier, to compute the final colour of each pixel... Anyhow, the problem was that SM3 (DirectX9) imposes a limit of 10 interpolators, and with U5, we were now using 11. That wasn't all bad though, it meant we just had to reduce the shader by one interpolator, which I was able to do by moving some bits of the vertex code into the pixel program, and just pack the data that those bits needed to function into already existing interpolators which had one or two unused channels. It seems if you have a vector interpolator, it doesn't matter if it's a 3D or 4D vector, it will take up one interpolator. That means you can pack extra data into the 'w' axis of 3D vectors and cheat yourself some extra headroom that way. Shader issues dealt with then, I moved on to the physics. These were largely modified in U5, and at first sight, it appeared we were in for some real trouble, because all our joints were now less stable than before. Turns out, U5 opened up the range for some joint springs, so fortunately, all we needed to do there was up the stiffness of all joints again to have the same behaviour as before. Now, however, I ran into one real problem: The wheel colliders in the new PhysX are much less stable than their older selves in U4, and all our wheels were now effectively non-functional. Wheels are deceptively crucial things. You don't realize just how important they are, even to a game taking place mostly in space, until suddently they stop working. The broken wheels meant all spaceplanes would break up immediately on spawning, and of course, those that survived had very little chance of even getting up to speed on the runway, let alone making it off the ground. The wheels were not something we could apply a quick fix for. This needed a comprehensive new solution. Fortunately, this solution already existed, and just in time actually. A package called Vehicle Physics Pro (VPP in short), which is a more realism-focused vehicle simulation by Edy, who created Edy's Vehicle Physics, a widely used vehicle asset package, but more gameplay-focused than VPP, was just recently made available in 'early access' form. It's still not in the Unity Asset Store, as it's still being developed, but the bits we needed for KSP were all there already. So, I got in touch with Edy, and got us an Early Access license to VPP. Edy has been remarkably helpful also. He even wrote a wheel controller specifically for KSP in advance. VPP is primarily focused on cars and car-like vehicles, though, for normal-ish games where vehicles are a single rigidbody and gravity points 'down'. KSP is, well... not normal in that sense. There are no 'vehicles' as such, because every part has its own rigidbody, and gravity... well, let's just leave that by saying it doesn't point down, and not get into discussng what down even means in KSP. KSP's rather unique requirements meant that VPP also needed its set of modifications to work properly. For the most part, that was just a matter of replacing any bits of code that worked under the assumption that Vector3.up actually represents something meaningful in the game world by our FlightGlobals.upAxis and friends. Then, we also needed to contend with the vehicle setups themselves. In KSP, we can't rely on vehicles being set up as a single rigidbody. Each VPP 'vehicle' for us, just represents a single wheel or landing gear part, which is attached to others by joints. In practice, that means the simulation of suspensions and tire friction (which VPP does fantastically) can't rely on the vehicle's rigidbody mass to calculate the load a wheel is supporting (aka the 'sprung mass' of the wheel). Happily, there exists a law in physics called Hooke's Law, which states that the force exerted by a spring varies in direct proportion to its compression. That is to say, we can figure out how much weight a wheel (and its suspension spring) is supporting by looking at how compressed the spring is. Replacing the rigibody.mass bits in the VPP tire friction code with this 'trueWheelLoad' value made all the difference. The wheel tire friction and resulting traction are now correctly simulated as the weight shifts and changes in the vessel on top of them. Ok then, we now have a functional solution for wheel simulation, but that is still far from saying we have functioning wheels in KSP. The wheel part modules had all been written, long ago, to work with a simple Unity wheel collider component. That means all our wheel modules are now essentially obsolete, and have to be rewritten basically from scratch. Well, it seems 'rebuilt from scratch' is the phrase of the month here, so I decided to go ahead and do just that, which was something I had been wanting to do for quite some time. When we wrote the first landing gear components, IIRC, part modules didn't even exist. A part could be either an engine, or a fuel tank, or a langing gear, and if you needed something that combined any set of behaviours from those (like a wing that carries fuel), you had to write yet another subclass of Part to do that. Part Modules then came along and changed all that, but not before our existing landing legs and gear bays had already been written under the old paradigm. So when rovers came around, after modules and all that, they were given yet another set of code that basically did the same thing again. As a result, we ended up with part modules specific to rover wheels, other modules for landing gears (with retract/deploy animation control built-in), other modules for landing legs, none of which could be combined properly without creating a despair-inducing tangle that would drive a battle-hardened developer to drink in less time than it would take the resulting mess of physics objects to come to rest after jittering themselves to bits. Needless to say then, I've been wanting to write a new, modular, all-purpose wheel system for some time now, and the move to VPP wheels were the perfect opportunity. I'm currently working on this now. I've created a set of modules that work together to simulate different aspects of any wheel. One base module creates and manages the VPP wheel component, then other modules hook in and manage their specific parts. We have modules for Steering, Suspension, Brakes, Drive (motor), Damage and Deployment, each doing no more and no less than their jobs. Setting up every wheel type in the game then should become just a matter of plugging in the features that your wheel needs. Static landing gears? Just omit the deployment module. Want steering? pop it in. Rather steer it as a tank? set it up with a differential drive steering module instead. Also, don't forget the brakes if coming to a stop is part of your mission profile. There is still a lot to do there though. At the moment I'm working on the suspension module. This one is interesting, because suspensions are tricky things in KSP. You can't just set up the springs with fixed parameteres and leave it at that. Unless tuned to the mass they are meant to support, suspensions are pretty useless and can make a vehicle even less stable than if it had none. And in KSP, we can't ever assume we know anything about the vehicle sitting above the wheels. So, instead of defining suspension parameters by the usual spring and damper values, I set up a scheme where suspensions have in their cfg definitions a 'naturalFrequency' and 'dampingRatio' values, which are then used to calculate the spring and damper internally, thus properly supporting vehicles of any mass. This means suspensions should be nice and springy no matter what sort of monstrous contraption you put together in the editor. If they are meant to break under too much weight though, that's not the job of the suspension module, we have a separate damage module for that. Next up is steering. We did have steering already as a separate module, but it was incompatible with rover wheels (or was it rover-wheels only?)... anyhow, looking into it, I was suprised at just how much code there is at making a wheel turn either left or right. I reckon there must be an easier way to do steering... so that's up next on my to-do list. And while we are doing steering, we can set up the new steering system so all wheels on a vessel will behave properly and rotate to follow their own arcs (aka Ackermann steering), instead of just all just rotating to full deflection and leaving you to deal with drifting and doing donuts with an interplanetary rover. Anyhow, that pretty much accounts for everything that's been going on on the U5 development side of things. In the meantime, Ted, Mike and the QA and Experimentals teams have been also working on bugfixes for the next update. Whether or not that update will be built with U5 already is still being discussed, but chances are that it wont' be. U5 still has quite a ways to go, and we want to deliver bugfixes as soon as we can. Conversely, we don't want to spam everyone with tiny updates unless they are for fixing emergency issues, so right now we are getting together a set of fixes and improvements that will make for an update worth downloading (and doing the whole deployment process over). That's the story up to now. More news as they develop! Cheers
-
Hi again, Just a very quick update this time, version 1.0.2 is now up: Changelog: =================================== v1.0.2 ============================================================ Bug Fixes and Tweaks: Thermal: * Fixed ships potentially overheating when splashed down. Parts * Small tweak to Mk16 parachute drag. As always, you can get the latest version from our KSPStore, GOG, or get auto-updated on Steam. Happy Launchings! Cheers
-
Hi Again, 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. Here's the patch changelog: =================================== v1.0.1 ============================================================ Bug Fixes and Tweaks: 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. Happy Launchings! Cheers
-
Greetings, Kerbonauts! 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. Happy Launchings! Cheers
-
I'm surprised, nobody guessed it right so far! I'm not going to spoil it though, but I'll debunk a few assumptions: * It's not something I've been working on in the backburner (I wish I had that kind of spare time). * It really was implemented from scratch in the span of 2 days. And a little hint: Try to imagine it's your first time playing. Everyone's ideas are way too advanced. Have fun! Cheers
-
Hi again, 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. Cheers
-
I think it's important to make it clear that Unity 5 is very unlikely to be the magical silver bullet people are making it out to be. When we moved from unity 3 to 4, we had to deal with a LOT (and I do mean a LOT) of upgrade-related bugs which we didn't expect. Furthermore, the earlier versions of Unity 4 had quite a few bugs of their own which we had to work around (or hang tight) until fixes came along. My point is, moving to Unity 5 is very unlikely to be a straightforward transition, and by no means I expect KSP to be stable or even playable (let alone improved) after simply upgrading the project over. I would be very happy to be wrong in that one, I must add, but historically, every time we upgraded to a new major version of unity, we came across new issues we had to contend with, so please don't get overexcited about Unity 5 just yet. This late in a project, most games tend to freeze engine versions when they find something stable that fits their needs. Regression issues is in fact the main reason why Unity stuck with PhysX 2.8 until now. If breaking mods and saves is an issue for us, imagine their case, where instead of mods and saves, they risk breaking hundreds of commercial projects. We have it easy by comparison really... Anyhow, we don't plan to freeze engines, but I just wanted to clarify that moving to Unity 5 may not be as simple and so immediately beneficial as it may seem. At the very least, we don't plan to upgrade until A: The 1.0 release is out, and B: Until U5 is out of beta and confirmed stable. Cheers
-
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. Happy Launchings! Cheers
-
Hi again, 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. Cheers Update: 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. Cheers
-
The scaled-space version of a planet (aka, the far-away version of it) is always rendered. In fact, the atmosphere is only present in scaled space, so even at the surface, the scaled-space version is active. Being just a static mesh, it's got minimal overhead to it. The noticeable increase in performance is indeed very likely the PQS (Procedural Quadtree Sphere) surface being turned off after completely fading out of view. The crossfading is quite necessary for the transition to not look terrible, but once fully faded out, the terrain turns itself off and stops updating. This definitely would help increase performance quite a bit, especially if you're already running on the low end of framerate, so good tip there. If you plan to build big, build it at a high(er) orbit. Cheers
-
KSP has gone Beta! v0.90.0 is Officially Released!
HarvesteR posted an article in Developer Articles
Hello everyone and welcome to version 0.90.0 of Kerbal Space Program: Beta than ever! Version 0.90.0 marks the transition from alpha to beta development of the game and will introduce the final major components to career mode. This then is the version that makes the game ‘scope complete’: every major feature that the game was designed to incorporate now exists and from here on, development will shift focus from implementating new systems to improving the existing ones, adding content, polish, balancing and bug fixing. The update contains many new features and updates to previously existing systems which combined make for quite likely the largest update in the game’s three year history. Here are the highlights: Upgradable Facilities In career mode the Kerbal Space Center will advance with your space program. Start out with small buildings and limited functionality and build up your facilities into a state of the art space center with capabilities to launch and manage every mission you’ve ever dreamt of doing. Each building such as the Astronaut Training Complex, Vehicle Assembly Building and Tracking Station can be upgraded separately (and destroyed and repaired too), unlocking new and exciting capabilities and bonuses to your space program. Choose where you spend your money wisely: constructing buildings is most certainly not cheap. Kerbal Experience and Skills Your Kerbals now have specific skillsets they will develop as they gain experience: Choosing from your available applicants now mean deciding between pilots, scientists and engineers, each adding abilities specific to their skill, and unlocking further abilities as they earn experience by going on missions in outer space. Pilots are able to take over control of your spacecraft’s orientation to provide stability control during flight; Scientists are better at collecting and analyzing experiment data, so their science skills give bonuses to science collection, data transmission, and lab processing; and an experienced engineer can repair specific parts of your craft which may just save your mission. Editor Overhaul Ship Construction has been almost entirely rebuilt from the ground up. The Parts list now allows you tolook up parts not only by function (category), but also by resource, module type, tech level and much more. In case you want to add your own custom categories, that’s possible as well, you can set up lists of your favorite parts and organize your subassemblies into subfolders. As if that wasn’t enough there’s also the option to sort the filtered parts by mass, cost, size and name. Also new in the Construction Facilites are the Gizmos which will allow you to Offset and Rotate parts, giving you complete control over how they are placed. The functionality to set a new root part for your craft has also been added, so you don’t have to rebuild your entire craft if you decide the root part should be somewhere else. Other than these, we've also added many other improvements and new features: Symmetry can be toggled between Mirror and Radial modes, in both editors; Crew assignment is now fully persistent as you build; A new Stats toolbar panel lets you see your craft's total mass, part count and size; the list goes on. Mk3 parts After the major overhaul on Mk2 spaceplane parts in version 0.25 there is now a lot more to choose from when it comes to the Mk3 spaceplane parts: the old Mk3 parts have given way to a total of 15 all-new parts of unprecedented size, capable of carrying truly enormous payloads. Really. You can fit an orange Jumbo-64 fuel tank inside those cargo bays! More contracts Kerbal Space Program version 0.90.0 also brings the Fine Print mod by Arsonide into the game. This addition brings a whole new array of contract types to the table for you to choose from, adding depth and diversity to the contracts system. Survey areas, deploy satellites in precise orbits, capture asteroids, construct orbital space stations and build bases on planets or moons. This isn't a simple mod addition however. Fine Print author Arsonide has worked with us to tweak the mod into the stock game seamlessly. It’s all included and should provide any player with a challenge suited to their skill level and interests. More biomes The biomes system has seen a major overhaul for the first beta release of Kerbal Space Program. With help from KSP enthusiast and streamer Tanuki Chau every planet and moon in the game now has new biomes players can go out and explore. From the canyons of Dres to the peaks on Pol, the game now counts over 100 unique biomes. Each of these places represents another location where your Kerbals can gather, analyse, recover and send data from. These are the major changes for Kerbal Space Program update 0.90. For everything else, check out the complete changelog below: =================================== v0.90.0 Beta ======================================================= New: Editor Overhaul (Gizmos): * Added Offset and Rotation Gizmos to Editor ([2] and [3] keys) * Added Re-root tool to Editor ([4] key) * Gizmo coordinate system can be toggled between Absolute and Local with the [F] key. * Rotation and Offset gizmos can also snap to angles and to a 3D grid. * Gizmo snap can be toggled to constrain to an absolute grid or a local one depending on coordinate frame. * Holding shift during placement or while gizmos are up will decrease angle snap interval to 5° (from 15°) and grid snap interval (for offset gizmo) * WSADQE keys still work to rotate in 90° or 5° (Shift) increments, and are now more consistent with pitch, yaw and roll rotations. Editor Overhaul (Parts List): * Fully overhauled Parts List UI. * Added Filters system to allow new methods to find parts, apart from the existing category tabs. * Existing categories overhauled into 'By Function' Filter. * Split Propulsion category into Engines and Fuel Tanks. * Added 'By Resource' Part Filter: Lists parts based on resources they contain/use * Added 'By Manufacturer' Filter: Lists parts based on their manufacturers * Added 'By Module' Filter: Lists parts based on the modules (functionalities) they implement. * Added 'By Tech Level' Filter: Lists parts based on their corresponding Tier on the Tech Tree. * Custom Filters (and subcategories) can also be created and edited for user-made collections of parts. * The Parts list can now be sorted based on several criteria (to organize displayed parts after filtering). * Added Sorting by Size to parts list * Added Sorting by Cost to parts list * Added Sorting by Mass to parts list * Added Sorting by Name to parts list (default) * Subassemblies can also be sorted and arranged into custom categories. Editor Overhaul (General): * The VAB and SPH are now based on a single scene. * Editor Logic fully overhauled and rewritten using the very reliable KerbalFSM framework used for character animation and many other systems in the game. * Most editor Keyboard inputs are now remappable. * All Craft files can now be cross-loaded in the VAB and SPH. * Crew assignment is now fully persistent during construction, including detached parts. * Vastly improved placement logic for angle-snapped parts. * Symmetry methods can be toggled between Radial (VAB) or Mirror (SPH) using the [R] Key * Radial Symmetry coordinate frame can also be toggled with [F] key. Upgradeable Space Center Facilities: * All KSC Facilities can now be upgraded through levels (currently 3 levels implemented for all facilities). * Added new models for KSC facilities at each level. * KSC Facilities now start at level 1 (in Career Mode), and can be upgraded to top level separately. * Upgrading Facilities costs Funds, lots of Funds. * Repair Cost of destroyed structures varies depending on facility level. (Higher-Level Facilities are more expensive to repair) KSC Facility Upgrade Effects: * Vehicle Assembly Building / Spaceplane Hangar: - Increase part count limit - Unlock Basic and Custom Action groups * Launchpad / Runway: - Increase Mass Limit for launched vessels - Increase Size Limit for launched vessels * Tracking Station: - Unlock Patched Conics in Map View - Unlock Unowned Object Tracking * Astronaut Complex: - Unlock EVAs off of Kerbin's surface. - Increase Active Crew Limit - Unlock Flag-Planting during EVA * Administration: - Increase Active Strategy Limit - Increase Strategy Commitment Limit * Research And Development: - Increase Max Science Cost Limit - Unlock part-to-part Fuel Transfer - Unlock EVA Surface Sample experiment (requires EVA on Astronaut Complex) * Mission Control: - Increase Max Active Contract Limit - Unlock Flight Planning (Requires Patched Conics in Tracking Station) Space Center (General): * All KSC Facilities in all levels are destructible (except level 1 runway and level 1 launchpad, which are indestructible). * Hold Ctrl while Right-Clicking over KSC Facilities to display 'extra' options concerning upgrade levels. * Expanded Context Menu for KSC Facilities, to allow upgrading and viewing the current (and next) level stats. * Hovering over the Upgrade button on the Facility Context Menu will display stats for the next level. * Space Center ground sections and Crawlerway change levels based on level of neighboring facilities. * The Flag Pole in front of the Astronaut Complex will change levels based on the average level of all KSC Structures. Facility Interiors: * Editor scenery now loads independently of the editor scene. * Exterior Scenery (out-the-door view) loads based on current editor Facility (VAB or SPH) * The KSC as seen from the editor facilities will change to reflect current level and destruction state of visible facilities outside. * Interior Scenery loads based on current editor Facility and Facility Level. * Added new 3D interior scenery for Level 1 and 2 VAB * Added new 3D interior scenery for Level 1 and 2 SPH * Added new 2D interior backdrops for Level 1 and 2 Astronaut Complex UI * Added new 2D interior backdrops for Level 1 and 2 R&D UI (Archives Tab) * Added new 2D interior backdrops for Level 1 and 2 Mission Control UI * Added new 2D interior backdrops for Level 1 and 2 Administration UI Parts (Mk3 Spaceplane Set): * Added 15 new 'Mk3' parts: - Mk3 Cockpit (IVA is blank atm) - 3 Mk3 Rocket Fuel Tanks (2.5m, 5m, 10m versions) - 3 Mk3 Liquid Fuel Tanks (2.5m, 5m, 10m versions) - Mk3 MonoProp Tank - Mk3 Crew Tank (holds 16 Kerbals, IVA is blank) - Mk3 - Mk2 Adapter - Mk3 - 1.25m Adapter - Mk3 - 2.5m Adapter (slanted) - 1.25m to Mk2 Adapter - 1.25m to 2.5m Adapter - 1.25m to 2.5m Adapter (slanted) - 3.75m to Mk3 Adapter - Mk3 Cargo Bay Long - Mk3 Cargo Bay Medium - Mk3 Cargo Bay Short * Old Mk3 cockpit, fuselage and adapter removed. Parts (General): * Struts and Fuel Lines now use a common base system called CompoundPart. * New CompoundPartModule base class added to provide functionality for parts based on CompoundPart. * Added CModuleLinkedMesh CompoundPartModule, handles the mesh objects connecting between both ends of a CompoundPart. * Added CModuleStrut, creates a physical Joint between both ends of a CompoundPart * Added CModuleFuelLine, creates a fuel re-routing between both ends of a CompoundPart. * LandingGear and Rover Wheels 'Invert Steering' option now changes to 'Uninvert Steering' when inverted. * Part-to-Part Resource Transfer now possible between more than 2 parts. (In/Out options will push/pull from all other selected parts evenly) Kerbals: * Kerbals now have Skills they can develop. * Kerbals now gain experience after returning from missions. * Kerbal Experience is needed to level up crew skills. * Added Scientist Skill. Scientists increase recovery value of collected data, transmission value of uploaded data and the lab boost factor (when manning a lab). * Added Engineer Skill. Engineers are able to repair broken parts like Rover Wheels and repack parachutes. * Added Pilot Skill. Pilots provide SAS features at various levels. Basic SAS is available as long as at least one pilot is aboard. * Crews in the Astronaut Complex can now be Sacked (if available) or given up for dead (if missing). SAS Overhaul: * SAS is no longer available in any vessel for free. A pilot or an operational SAS-cabable probe core are needed for SAS to be available. * Level 0 pilots and basic probes provide basic SAS functionality (kill rotation) * Higher level pilots and more advanced probes provide new Autopilot Functions. * Added new Autopilot System featuring 8 modes: - Stability Assist (Basic SAS) - Prograde/Retrograde Hold (Level 1 Required: Automatically orient and maintain attitude towards prograde or retrograde vectors. - Radial In/Out, Normal/Antinormal Hold (Level 2 Required): Automatically orient and maintain attitude towards R+, R-, N and AN vectors. - Target/Anti-Target Hold (Level 3 Required): Automatically orient and maintain attitude towards the selected target. - Maneuver Hold (Level 3 Required): Automatically orient and maintain attitude towards the first upcoming maneuver's burn vector. * AP modes respect the current reference frame on the navball (surface, orbit or target). * Overhauled the existing ModuleSAS part module so it acts as a SAS provider in any level. * Removed ModuleSAS from all parts except probe cores. * Tweaked the R&D tech tree progression for all probe cores. * Tweaked costs and descriptions for all probe cores. * Probe cores set up with progressing levels of SAS service. New Contracts (Fine Print Mod by Arsonide): * Added asteroid redirection contracts. * Added surface outpost construction contracts. * Added orbital station construction contracts. * Added satellite deployment contracts. * Added survey contracts at specified locations on the map. * Fine Print contracts revised and overhauled with new graphics and to follow Career progression. * Fine Print contracts unlock based on KSC Facility level when applicable. * Existing contracts also revised to better follow progression of KSC facilities. * Existing and new contracts revised to be configurable. New Biomes: * Added new Biome Maps to all celestial bodies. * Over a hundred new biomes available in total. * Added cheat menu option to visualize biomes in map view. Misc: * Added a one-page 'Welcome Intro' tutorial module to all newly-started games. * Added new Edge Highlight visual effect when hovering over part icons on the staging UI, or when selecting a new root part or choosing a part to transfer crew to. * Added new Tooltips for several UI controls in the Editor, R&D, Flight and many other areas. * Added new ESA flags. * Improved some of the Loading Screen images. * Added new Craft Stats app to Editor toolbar, to display ship information like part count, total mass and size. * Craft Stats app icon will turn orange if any limit is exceeded for the current editor facility level. * Added new sound fx for gizmos and re-root in editors. * Added new destruction FX for all new facility models. * Added EditorBounds system to define part spawn point, construction boundaries, camera starting position and bounds for each editor interior. Bug Fixes and Tweaks: * KSPScenario 'Remove' creation options now work. * Added new PreSAS and PostSAS callbacks to vessel API. * Revised VAB and SPH camera behaviour so they stay within scenery bounds as best they can. * Overhauled time-of-day system for KSC emissive textures. All facilities light up at night. (except ones without lights, like lvl1 runway) * Fixed several issues with destructible building persistence. * KSC grounds grass shader now uses worldspace UV coords for consistent tiling. * KSC grounds grass shader now enforces vertex normals to smooth out the transition between PQS and KSC terrain. * Linux version now forces thread locale to 'en'. Solves most issues with installs in foreign locales. * Fixed several issues with Undo/Redo (ctrl+Z, ctrl+Y) in the editors. * Tweaked sideslip factor in landing gear (was much too strong). * Increased Mk55 Engine's ISP and gimbal range. * Fixed an issue with part rotation and placement using Mirror symmetry. * Fixed issues with symmetrical 'subgroups' after attaching a parent part using symmetry. * Re-saved all stock craft so they are fully compatible with this version. * Existing craft files from previous versions will require re-saving in the editor before they are allowed to launch in Career Mode, to calculate size data. * Crew auto-hire will respect Astronaut Complex crew limit. As always, the update is now available on the KSPStore and Steam. We hope you will enjoy Kerbal Space Program: Beta Than Ever as much as we enjoyed making it. Cheers -
I voted 'Dinosaurs', because I have no idea what that's supposed to mean. Anyhow, this will soon no longer be an issue. With the offset and rotate gizmos added, plus the longstanding issues with parts that don't attach properly becuase they are just-oh-so-slightly in contact with others, part clipping grew into such a bother that I decided to simply remove it by default. All attachments, as long as you are attaching a part to another part of the ship, are valid. If the ship explodes into a million when you detach, that's a design fault on your end. Mind though, that allowing attachments isn't the same as enabling the debug cheat. The cheat also allows you to place multiple parts on the same attach nodes. This is still not allowed because it actually adds a good risk of running into big bugs later. But really, with the new gizmos and construction modes coming, having the game deny a part from being placed just because it's clipping into another was being too much of a restriction to design. What with costs, size, part count and mass limits to deal with, there are quite enough limitations already to contend with. Cheers
-
Yes, what I meant was, I assume height to mean the distance from the base (ground) to the topmost point of whatever you are measuring, as opposed to altitude which (unless specified otherwise) is the distance of this topmost point to sea level. It is ambiguous when the tail height of an aircraft must be factored in with another height, like flight height though, but more importantly, when the yaw axis of the craft doesn't point 'up', as is the case of a rocket at the pad.. hence my search for a better term. In any case, the point is now moot. The craft size uses AABBs (axis-aligned bounding boxes) so the Y axis is always going to be 'height' in this context. Be it tail height sitting at the runway, or stack height at the launch pad. The Z axis I renamed to Length, so that's that I guess. Thanks for the help everyone! Cheers
-
I'm using tail height here ('T-Hgt' actually) for the time being, for want of a better term, and to fit in the UI space available for it... I'm surprised that there is no actual term for it though, 'height' I always assume to mean flight height above ground (as opposed to altitude), so calling the tail height of an aircraft 'height' as well is oddly ambiguous for a field so particularly specific as aeronautical engineering. Oh well. I suppose 'height' at SPH or X-section at the VAB will do then. Cheers
-
Hi, So, this struck me as a peculiar thing. I've been searching here for a term by which to call the size of a craft along its yaw axis, that is, the 'runway height' of a craft, or the 'cross section height' of a rocket sitting at the pad, and I thought it was very strange that I could find no specific term for that dimension. This seems particularly odd in a field like aerospace, where each and every possible measurement seems to have a particular name (like dihedral, chord, wingspan, and so on), that such a basic dimension of an aircraft must be referred to by the ambiguous word 'height', or by a long name like 'cross section height' or something like that. So, looking for the largest aggregation of savvy minds in this field brought me here. Does anyone know if there is a specific name for this measurement? Thanks in advance for any input. Cheers
-
I sure don't miss it either. The new struts are much more reliable, not just in physics stability, also in much less arcane and obscure configuration. We can easily tune them now, to get more or less stiffness as needed, and to do much more advanced things also (like the claw's pivoting joint). The amount of wobble still present we left in deliberately. We didn't want to make ships so stable there would be no cause for concern over their structural 'sanity'. Now, struts are needed mostly only to beef up places where you really need extra stability, and usually a couple of struts are quite enough to take care of the problem, as opposed to the dozens required before. So yeah, I'm definitely on the not-missing-the-wobble side too. Cheers
-
Eu ja vi isso acontecer! Alguém conseguiu pegar o momento em video, isso faz um bom tempo... na época da versão 0.14 mais ou menos... A chance é impossivelmente pequena, mas pode acontecer, e é totalmente destrutivo quando acontece. Cheers!
-
I think the basic criteria for being officially in an orbital trajectory is that your spacecraft should be able to simply 'coast' its way entirely around the planet. No thrust applied by the spacecraft. Decay from external perturbations wouldn't void this criteria unless the forces are strong enough to cause a free-falling body to decelerate quickly enough that it doesn't manage to complete a single revolution, something very much like what being inside the atmosphere would do to you. If you can manage to establish an orbit just inside the very edge of the cut-off point to Kerbin's atmosphere (around 69,750m altitude), you might be able to complete a full revolution before that tiny amount of atmosphere slows you down into a sub-orbital state again. That would be quite tricky, as even the lowest edge of the atmosphere still exerts some drag... Not sure if enough to decelerate you down into the no-return altitudes over the 30 minutes or so it takes to go around Kerbin, but as you lose altitude (and you will), the drag also increases, which lowers your periapsis yet more... Actually, I'd love to see someone try... Now I'm intrigued. Cheers
-
What input device(s) do you use with KSP?
HarvesteR replied to PhaserArray's topic in KSP1 Discussion
Yep. I've got a SpaceNavigator and a SpaceMouse here, both work very well using the beta drivers (which support more than one device at a time). I can't say I've tested other devices (not having other devices presents quite a challenge on that front), but even if your device isn't supported, you could be able to emulate recognizable 6DOF input using GlovePIE to translate the input from your device into 3D mouse input (I think, haven't tested, but similar kludges have worked for me in the past on other games). I definitely recommend getting one, and not just for KSP. If you do any sort of 3D work at all (even Google Earth in fact), a 3D mouse is a very good tool to have. Having broken the wheel off a mouse once midway through a grueling overnight 3Ds Max animation project, I can give you a first-hand account of just how much better it is to be able to navigate a 3D scene using a proper 3D device. Cheers -
What input device(s) do you use with KSP?
HarvesteR replied to PhaserArray's topic in KSP1 Discussion
Mostly mouse and keyboard here too, in fact. Although I also use the 3D mouse a lot (especially suitable for EVA and docking). I'm aware that joystick mapping is problematic atm, so that makes using joysticks less practical than would be desired. Hopefully during Beta we'll get a chance to improve input mapping and the input layout in general. (emphasis on 'hopefully') But when I do, I set up my trusty X52 Pro and Pro Flight Rudder Pedals. They're showing signs of age these days, but still up to the job. Can't say I've ever tried using a steering wheel though. I have a Driving Force GT here, but I get the feeling it would fall short in the amount of axes available. As for control panels... man, I dream of the day I'll have the amounts of free time building one of those requires. Cheers