[TABLE=width: 965, align: center] [TR] [TD]WeÃ¢â‚¬â„¢re very excited to announce that Kerbal Space Program is coming to Xbox One! The Xbox version of the game will be developed by the developers at Flying Tiger.
Flying Tiger's development team has proven invaluable in the implementation of Unity 5, bringing a fresh viewpoint and years of experience that have deeply simplified the upgrade process for us. Furthermore, this cooperation has given us the opportunity to keep focussing on the PC version and the upcoming update, while reaching out to millions of console gamers at the same time.
We'll be posting an update on the development of the KSP 1.1 patch on the forums tomorrow![/TD] [/TR] [/TABLE]
Up until now, and including 1.0, KSP development was for the most part horizontal, predominantly adding in features for sandbox and then post-0.18 adding in Career mode features. While there was vertical development in a number of major areas: the VAB/SPH editor, parts, contracts, etcetera, we are now at a point where that becomes the sole focus of KSP development. In other words, we're at a point in KSP's development where we're building upon already existing features to give them even more depth!
This brings us to update 1.1. While there is still a fair chunk of 1.1 to design and plan, we do have a good idea of what we want it to include. While HarvesteR, Mu and Romfarer continue to work on the Unity 5 upgrade, RoverDude, Arsonide and Porkjet have already started planning, designing and developing a few of KSP 1.1's new features.
RoverDude, specifically, has been working on two features that we've been quite eager to tell you all about. Note that these features are still in development and are pending QA playtesting, balancing and feedback as well as community feedback. Additionally, the more challenging aspects of these features will be off or reduced on the lower difficulties in KSP.
The first feature is probe telemetry. With this, a probe must establish a connection back to Kerbin or another 'control point' via an antenna part in order to operate - be controlled by the player, or active in any way. These control points are the planet Kerbin, or a craft with an antenna, a pilot Kerbal, and optionally a large probe core.
An example of using pilots as a control point would be a mission over Duna where a piloted command module serves as the remote control point for a landed, unmanned rover. If the player has a non-pilot Kerbal on board, they can still fly the ship, but they would lose access to the probe's piloting capabilities (i.e. a ship where a player uses a probe core for control, and crews it with a non-pilot).
However, given the length of time a player would have to spend on simulating a relay network around Kerbin in order to ensure that the KSC is always reachable would be significant, we felt it would be better to have Kerbin simulating a Deep Space Network. It's a ground-based network of relay stations that attempt for complete coverage of Earth. In KSP this is translated to the Tracking Station. As a player upgrades their tracking station, the range of Kerbin's Deep Space Network will increase, eventually allowing it to receive signals all the way from Eeloo's closest approach to Kerbin - similar to New Horizon's range. In this design, the player then only has to send the signal to Kerbin, saving the triviality of waiting for the KSC to be on the facing side and breaking gameplay flow.
At this point, you may be wondering what the second feature is, you may have forgotten about it or you may have figured it out. If it's the last one, well done! RoverDude's second feature for 1.1 is antenna relay networks. It extends to range, network pathfinding and soft occlusion of celestial bodies.
In gameplay terms, this means that if you want to send data back to Kerbin, or control your probe while you're out of range from your control point, the probe will attempt to use relay satellites you've set up to communicate with a control point and the pathfinding model will simulate celestial bodies being in the way. Additionally, there's no direct pointing of antennas, meaning you won't need to have it pointing at the control point for a connection. The occlusion is slightly fuzzed or 'soft' to make it a bit more forgiving, for example Minmus won't stop you from being able to control your probe around Duna as it passes between you and Kerbin.
To go along with this we've also modeled three new advanced antenna parts to serve as relay dishes. They're heavier than existing antennas, but offer the feature of automated network relaying.
However, relays are not always required due to the nature of the Kerbin Deep Space Network we mentioned earlier. In the current design, it will be completely possible to shoot a signal directly from, say, Duna to Kerbin - with a sufficiently large antenna on your vessel. Though you will likely want to set up relays to deal with occlusion issues mentioned below. One possible use is that you may want to set up a relay network in a Duna polar orbit to allow continuous control to a landed rover.
The relay/signal occlusion is present only for celestial bodies - not vessels or asteroids - and is implemented via analytic geometry. A probe in a low Munar orbit would be blocked while on the far side of the Mun, but a probe sending a signal from Jool would likely not be blocked by Minmus - the soft occlusion angle is fully configurable on an antenna by antenna basis for modders.
We've focused on designing these features to be simple and approachable, using inspiration from some of the plugins that have implemented similar features. For example, we opted to have no flight computer, signal delay or antenna pointing. However, there is a clear distinction between the lightweight antennas used for direct communication, and the heavier, more complex antennas used for building up relay networks - the extra mass comes from the hardware required to store and forward data onto the relay network.Another area we've made more approachable is the default implementation of a built-in deep space network, where Kerbin has an ever-increasing inferred relay network, similar to what we have on Earth. The range of this network will be decreased if the player is on 'Hard' mode, effectively requiring the player to set up their own deep space network. On 'Easy' mode, relay, and antennas operate as they do today, with your only limitation being the power constraints and packet size of the antennas themselves. Furthermore, the settings will be exposed in the difficulty settings so they can be toggled in Custom Difficulty.
Of course, science will also be subject to the antenna transmission and relay rules as well, using the same pathfinding rules and access to Kerbin's Deep Space Network as probes. With the exception that science must trace a control path all the way back to Kerbin.
And there we have it! That's two of the principal features for 1.1 that will change the way you play KSP, but how much so is very dependent on how you play, what difficulty you play on and your game mode. We're pretty excited about these features and looking forward telling you more about 1.1 as development progresses; hopefully you are too!
Please feel free to leave comments on any questions and the like that you may have.
We are happy to announce that Valentina Kerman is now available at our Shapeways Store!
As part of the announcement IÃ¢â‚¬â„¢m going to explain to you how I prepare a Kerbal for 3D printing. First of all, I need to find the file with Valentina and the rig used in the game animations. Next step is to pose Val to match the rest of the crew available at Shapeways.
Next up, the model needs to be adjusted for 3D printing. You can find the requirements and technical specifications at the Shapeways Materials page. So the easiest thing to do at this point is to separate the model into different parts (here IÃ¢â‚¬â„¢m talking about internal parts, at the end one single mesh will be exported) and start closing holes.
One of the requirements for 3D printing at Shapeways is that all meshes should be watertight. That means there shouldnÃ¢â‚¬â„¢t be any Ã¢â‚¬Å“open facesÃ¢â‚¬Â. So an optimized model for the game should not work for printing. Some parts of the model, like the body of our Kerbal, work with an empty space on the interior. It should be a walled structure, with an escape hole for the excess of material. That makes the model less expensive, because it will use less 3d printed material.
Next step is to extrude the faces of the model of the sections that need support walls. For example, the head and the body. Those two have empty interiors. To extrude the faces I need to be working with mm inside of Maya for the sake of convenience. I only need to push the faces 2 units and most of the times this works just fine. Some parts, like the neck, need to be relaxed, so that faces wonÃ¢â‚¬â„¢t intersect with each other.
Now that we have a watertight model, with support walls to have an empty interior, I need to combine all the shapes into one single mesh, and export the model. Valentina is ready to be uploaded to our Shapeways account, and see if the automated tests send any problems. As you can see, the tweaking process of a model is not extremely complicated, but it needs patience, to be careful about the small details and to always have an eye at the Maya units.
Once everything is OK, we send the print to Shapeways!
Our friends at Shapeways have sent us some pictures of the printing process of Valentina at the lab. You can find over here a detailed video of the process:
Introducing Kerbal Space ProgramÃ¢â‚¬â„¢s second official mod: Asteroid Day! WeÃ¢â‚¬â„¢ve partnered with the B612 Foundation to bring you this mod which will give you four new parts, a new experiment, and a unique contract.
The Sentinel Infrared Telescope mimics the real world Sentinel mission being planned by the B612 Foundation, which plans to map 90% of the larger asteroids threatening Earth's orbit sometime between 2018 and 2024. Due to sun glare it is difficult for telescopes on Earth to observe objects passing on the planet's day side. Deploying a telescope into a solar orbit near Venus and facing it away from the Sun, back towards Earth's orbit, would cover that blind spot.
Your mission will be to recreate this mission profile in Kerbal Space Program, deploying a telescope around EveÃ¢â‚¬â„¢s orbit. When deployed with an antenna and a power source between Eve and Kerbin, aligned to face away from the Sun, and activated, the telescope will begin to map the orbit of the outer planet in a 200Ã‚Â° vision cone for passing asteroids.
Other than the telescope itself, you will have three new parts to make your unmanned missions more enjoyable:
The HECS-2 Probe Core comes with integrated batteries and SAS, to make building a compact Sentinel probe much easier.
The OX-STAT-XL Photovoltaic Panels are a much larger version of the stock solar panels, for larger probes.
The HG-55 High Gain Antenna can transmit larger amounts of data than any of the existing antennae in the game.
This pack also includes a long-term contract to map asteroids around Kerbin as well as other planets that match various specifications. It differs from other contracts in that it encourages the use of existing infrastructure. It does not require a new vessel for each contract, and each scan is faster with more telescopes deployed.
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:
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.
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!
Here's a short FAQ to help explain what the PS4 version means for the PC version.
Why bring Kerbal Space Program to PS4? As the fanbase of our game has grown, weÃ¢â‚¬â„¢ve received a constant influx of pokes and requests from people asking us to bring our game to PS4. With the power of current generation PS4 and the flexibility and ease of use of the Unity engine, bringing KSP over to the PS4 is simply a no brainer. Space is for everyone, regardless of how you prefer to play.
How will the game work on PS4? ThatÃ¢â‚¬â„¢s another thing we had asked ourselves for quite a while and simply had to make a goal: We could simply not compromise on playersÃ¢â‚¬â„¢ experience. Thankfully, the PS4 controller has systems that make building and flying rockets just as easy and intuitive as the PC version.
How are you bringing Kerbal Space Program to PS4? WeÃ¢â‚¬â„¢ve teamed up with Flying Tiger Entertainment to bring the game to PS4. They have experience and have shown us time and time again that they were simply the right choice to make sure that the players receive a quality game on their PS4, and not a lazy port.
Will this have a negative effect on the development of the PC version? Absolutely not. If anything, working in collaboration with Flying Tiger has helped us speed up processes like the Unity 5 upgrade, but in general the two will remain separate versions of the game, much like the educational version TeacherGaming works on!
As you might know we've been working with GamerÃ¢â‚¬â„¢s Edition to produce the official physical release of Kerbal Space Program. With a physical edition we didn't want to give you just a USB drive or disc with the game on it, but we wanted to make something a bit more special, that's worth investing in. Like every GamerÃ¢â‚¬â„¢s Edition, the Kerbal Space Program collection includes a Steam code, is packaged in an individually numbered presentation box and is part of a one-off run that will not be repeated.
WhatÃ¢â‚¬â„¢s in the box?
[*=left]Four hand-painted Kerbal figurines - Bill, Bob and Jebediah Kerman plus a standard Kerbalnaut, each showing varying emotional reactions to the adventure that awaits. [*=left]A stirring diorama backdrop - which optimistically suggests you have made it to the moon. [*=left]Official Kerbal Space Program mobile - allowing you to ponder the hypnotic vastness of space and the quantity of space junk and unlucky Kerbals you have scattered across it. [*=left]Official Kerbal Space Program patch - proudly displaying the Latin motto of the program: Ã¢â‚¬Å“Demum PerveniusÃ¢â‚¬Â (lit. WeÃ¢â‚¬â„¢ll Get There Eventually).
Ã¢â‚¬Å“ItÃ¢â‚¬â„¢s a real honour to partner with one of the most enthralling indie games of recent yearsÃ¢â‚¬Â, said Jon Hicks, Head of GamerÃ¢â‚¬â„¢s Edition. Ã¢â‚¬Å“Having spent many hours abandoning Kerbals to uncertain fates in orbit, on the moon, or within several feet of the launch site, I feel more than qualified to do the same in the real worldÃ¢â‚¬Â.
The Kerbal Space Program GamerÃ¢â‚¬â„¢s Edition campaign runs from today until midnight BST (4PM PDT/7PM EDT) on 29th July and costs $80 (roughly Ã‚Â£55). ItÃ¢â‚¬â„¢s available for purchase now at The GamerÃ¢â‚¬â„¢s Edition website.
If you wish to learn more about GamerÃ¢â‚¬â„¢s Edition you can find them in these places. Website: www.gamersedition.com Facebook: www.facebook.com/GetGamersEdition Twitter: www.twitter.com/gamers_edition Instagram: www.instagram.com/gamers.edition
When I started working on Kerbal Space Program, I was handed the task to bring Kerbals to life. The biggest challenge has been converting a bunch of polygons and textures into believable characters that can exist in their own Universe and laws. Kerbals needed to be more than expendable beings inside a sandbox space simulator. After a couple of years in the process, the task of bringing Kerbal girls into the game happened. The design production of the Kerbal girls has been a process of several months of work, of gathering feedback, brainstorming ideas and talk to the guys inside the team and special members of our community. Throughout the road I found some obstacles and design problems that needed to be overcome, which will get explained on this post, to the extent of creating Valentina Kerman: the most badass Kerbonaut inside Kerbal Space Program.
How to design the perfect Kerbal female?
It all began with an idea at the office. How do we make it happen? What are the social implications of having female Kerbals in the game? How are the Kerbals going to feel, experience and display it? How will they be portrayed? How to translate all the challenges, questions and concepts into one single character?
Kerbals are well known to our community, they have their own names, their own backstories, even after the names run through a name generator. Our community has given them stories, backgrounds, adventures, and recorded hours and hours of gameplay with Kerbals visiting all the planets of the known Kerbal Universe. WhatÃ¢â‚¬â„¢s the best way to add a new idea into that already expanding world?
One small step before the launch
After talking with the Lead Developer Felipe Falanghe, the producer Miguel PiÃƒÂ±a and the executive producers Ezequiel Ayarza and Adrian Goya, I thumbnailed some ideas of what the Kerbals should look like. The early drafts and concepts look significantly different than the actual model, but from the beginning we had some solid ideas to what paths we were taking. Female kerbals have slightly different proportions than men, human anatomy was taken as a starting point and modified to meet the needs of our universe. Kerbals have very specific proportions, they have noticeable anatomical limitations and need creative ways to solve their day-to-day problems.
What makes a Kerbal female?
From the beginning we knew that the whole concept of the Ã¢â‚¬Å“Female KerbalÃ¢â‚¬Â had to be in the details. Slightly longer arms, but smaller trunks. Heads rounded, against the square heads of the male counterparts. Bigger eyes but smaller mouths. But the first problem happened: what to do with the hair? Kerbal Astronauts have a generic military haircut, but they could have different hairstyles, and colors in other sections of the game. We have played most with that idea on the extended universe of Kerbal Space Program. The YouTube animations have different hairstyles and colors, Kerbalizer has a broad range of styles and wigs. But the core experience is the game. What kind of generic hair should female Kerbal Astronauts have?
If you do a quick search with the keywords: female astronauts and look at the list Wikipedia has to offer, you will find that every single one of them as a different hairstyle (as we all humans do). So the first source for references was extremely broad. Next thing to try was different hairstyles and colors. They looked good. But what do we do about the other Kerbals that are already in the game? Should we give them haircuts too?
Then the decision came: we need to save resources, give the Kerbals a personal trait, but keep them as generic as always.
Our new Kerbals started to have distinctive look and feel, and they could happen inside our Universe. At this point in development, I knew what the body of the female Kerbals was going to be like. The hair was its own problem.
Kerbal girls started to look more like young boys than female Kerbals
One of the first 3d models that I made looked more like a young Kerbal boy, than a female version of the Kerbals. The smaller size, the rounded face, could match the description of a young version of the male Kerbals. Even after doing some research, there was a missing link to make it work. I tried the idea of using a buzzcut for the girls, just like the guys, but that just pushed the young boy concept even further.
It was to that point that talking with the lead developer and producers that they should all have ponytails, and somehow show it inside the helmet, so that they look generic and Kerbal enough.
This was going to be the female Kerbal that we were going to appreciate in the game. Until one last iteration.
There was one extra detail that I added to the design that helped further the design and concept. Eyelashes. They shouldnÃ¢â‚¬â„¢t be extremely toon, but be consistent with the design. A small line surrounding the upper part of the eyes did the trick. We knew we had the base of the female Kerbals inside the game, and that we all liked the design and final result.
The most badass Kerbonaut in the game
Valentina Kerman was presented to the community as one of the main characters of the game. She has the special orange suit all veterans inside the game have. And the most important characteristic, she is an intertextuality for Valentina Tereshkova, the first woman to fly in space. After overcoming all the challenges that the design exposed, Val felt like an member of the Kerbal Universe already. She had become, as stated at the beginning of the post, more than polygons and textures. Our community quickly adopted her, she starred in fanart of the game as well as the most important missions of YouTubers. Valentina Kerman is, and will always be, the most badass Kerbonaut inside Kerbal Space Program.