Jump to content


  • Posts

  • Joined

  • Last visited

Everything posted by HarvesteR

  1. 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
  2. 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
  3. 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
  4. That's actually quite right. The engine modules are now able to override the default flow logic as defined by the resource with their own, so even though turbines use the same module as SRBs and Liquid Engines, they set up their own flow logic for LiquidFuel, so that in their case, the lookup method used is the STAGE_PRIORITY method. For other modules/propellant configs which don't define a particular method, the resource default is used. As for the necessity that prompted this change, other than the improvement in long-term stability as tanks drain out, this is very much essential to support wet wings and drop tanks. Using the default stack-based flow logic means tanks in child parts (as wings tend to be) will be unaccessible unless a fuel line links them to some spot in the drainage route of the engines. Quite a chore for something that would be expected to just work. And yes, closing off tanks does still work as always. If you don't want a tank being used, you can close the valves and it'll be left unused. Cheers
  5. 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
  6. 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
  7. 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
  8. 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
  9. There used to be a level '0' for the Spaceplane hangar, but it was one of the ones we removed during the big overhaul from a few weeks ago. We removed it because it was too restrictive on players' freedom to choose a progression path. Having an empty field to start with is still an interesting idea, but I think it would require all facilities to start out that way to be a fair mechanic, and that much we don't have time to do. Keep in mind that the upgradeable facilities are still just making their first appearance. Just because this is the last gameplay system before Beta, it doesn't mean it has to be more complete than other systems were when they were first added. Beta is exactly the time when adding more content to existing systems will be our main goal (I personally can't wait). Cheers
  10. 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
  11. 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
  12. 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
  13. Possible, yes. Feasible in the time available, much less so. The interior scenes are one of the few (and very few indeed) places where we use static lightmapping to light up the scene. The outside light plays a large part in this, so creating a dynamic time-of-day effect in the editors would require us to either drop lightmapping altogether, something I really wouldn't like to do, or set up many variations for the scene lighting and switch between those too. That would be another ton on top of the tons of work we're already doing. Not saying it couldn't look cool, but there are probably more interesting features to add given a finite amount of time and manpower. Cheers
  14. 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
  15. 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!
  16. Part.GetConnectedResources() should be the method you need. It also walks the hierarchy internally, but it's 'canon' Cheers
  17. Git is a particularly awesome Version Control system. It lets us all work at the same time over the project without stepping on each other's toes all the time. What Marco called Git QA here is the first stage of QA testing all features go through. This is something we do for every new feature, to make sure nothing we add is going to break the game for everyone else. (if you think a broken game is tough to play, try developing over broken software. ) Once the most serious issues are worked out, the feature branch is deemed worthy to be integrated into the main development branch (aptly named 'develop'). Once all our planned features make their way into develop, we start experimental testing on a branch that eventually becomes the new public release version. Cheers
  18. 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
  19. Not sure what you mean. Mesh mirroring does in fact happen when using mirror symmetry. This mirroring is along the X axis though, so it's possible some parts are aligned in such a way that you wouldn't see it. This was the case with some spaceplane parts when we integrated the SP+ pack, but we fixed those so they would be flipped along the Vector3.right axis. Cheers
  20. 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
  21. 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
  22. Just a quick reminder here, that the state of Career Mode by the time we enter Beta will be roughly the same, in terms of completion, than the current state of Sandbox. Sandbox just happened to reach that state first, but both are going to be equally incomplete. Scope Complete != Feature Complete. Also, see here for my opinion on threads like these. Cheers
  23. One thing I find strange from threads like these (or the other one, whichever way), is that it seems very obvious to me that the consensus should be that it's all good, because all game modes are still available. If we had removed sandbox and imposed Career mode, sure, I'd be peeved if I were in team sandbox too, and understandably so. Same if I were on the Career team. In fact, so loath were we to replace a game mode with the addition of new features, we created Science mode to preserve the pre-0.24 style of career gameplay. The idea here is to cater to all sides. Personally though, I'm on neither side. I play all modes more or less evenly. Sandbox is nice when you get that urge to build something ludicrous and see where you can go with it (also very useful for dev testing), and Career provides the much needed structure a game needs so it can be called a game. Sure, Sandbox reached a state of completion first, so we now have devoted a lot of dev time into Career. Does that mean we consider Career as a superior game mode? Of course not! It's merely a matter of timing, and that Career depends on an existing sandbox to work (going the other way around would have been quite awkward, to say the least). I get the feeling this is something like the discussion among rollercoaster enthusiasts about wooden vs steel coasters... It's kind of pointless, since there is quite enough room for both. But before I go here, consider this: About a year ago, if you went out on the internets to gauge opinions of non-players (those can't be found in the forums), as to why they didn't want to get into KSP, the main arguments were that it was either too hard to get into (too high an entry barrier), or that they didn't care for a game without goals to pursue (lack of structure). However, if you go out today to gauge those same opinions, you'll find that those arguments are very largely gone. I'd say as far as the primary purpose of Career Mode goes, in a single-purchase standalone game that is still under development, it seems to be doing its job very well. Cheers
  24. Hi, It’s time we talk about THE FUTURE. I don’t mean hoverboards and self-tying sneakers (2015, we’re counting on you), I mean the future of Kerbal Space Program. The next update will mark a big milestone for us at Squad, as it is the last update focused on Career Mode. After the next release, Kerbal Space Program will reach an internal milestone we call “Scope Complete”. Let me back up a little here and explain what Scope Complete means, it means KSP now has all the features we considered vital to be in the game that we designed so many years ago. It doesn’t mean the game has everything we want it to have, it means everything we considered necessary for it to be Kerbal Space Program exists, even if only in a minimal form. Scope completion means that every big system that the game needed is there, some closer to completion than others, of course, but they’re all there. So, what’s next then? This is the good news: After Scope Completion, development focus shifts towards completing those unfinished features, balancing and adding some smaller stuff. No more groundwork, no more laying down infrastructure. We’ve finished building the kitchen, it’s time for us to start cooking. As soon as the next update is released, KSP will enter a new phase of development, which for want of a better term, we’re calling ‘Beta’. Beta development is going to be a new stage for the project, and that also means our development workflow will change, and by consequence, this will have an effect on the releases. There shouldn’t be any huge frameworks that we have to build for months on end and still have to release with barely more than enough content to showcase the system. Beta means we’ll be focusing on creating content, on using the tools we’ve built. It means a different approach to selecting which features go in, since we won’t be constrained by the development constraints of one feature requiring another. Priorities should level out, which means the things we consider important should also match what everyone considers important. Beta essentially means we’ll be working a lot more on stability, usability, performance, balance, aesthetics, all the while still throwing in little and some not-so-little things we hope you will enjoy. To make this clear to everyone (even those who don't read this post), we’ve decided to not call the next release version 0.26, as convention would have it. Instead once the update is out, we’ll be officially in Beta, so we’re calling the next release version 0.90.0 (zero-ninety-zero). There’s a ton of things we’re constantly discussing internally regarding what exactly we’ll add during Beta, but I figure we should at least tell you about the first two things we really want to add to the game before we can call it anything close to ready: Overhauled Aerodynamics - The current system has been fantastic at… existing, really. It can’t be beat at ‘being a system that exists and works within KSP’, but we can do better. We’ve been a long time planning a major overhaul to make it more realistic, reliable, predictable, and hopefully a lot less arcane. Deep Space Refueling - We’re aware there is one big end-game mechanic missing in the game: Being able to refuel a vessel once you’re out in Space. This is what we originally set out to achieve with the old Resource Mining plan and saw ourselves running into a very tedious dead-end. The Resources system was flawed because it overcomplicated accomplishing a basic need: To be able to find something out in space which can be used to fill up the tanks again. That’s the essence of it, and we don’t need 40+ single-purpose parts and 9 different resources to do it. In fact, all that complexity was going to be very effective at making sure most attempts to build a refueling outpost would fail. We are now planning a new, more elegant system, which hopefully will add a new, fun element of gameplay, as well as the massive boost to continuity this feature implies. Here is also a (not so) small FAQ with some answers we imagine you’ll probably be wanting to ask about: Q: You’re not pulling the plug on KSP, are you? A: Of course not! We still have a long way to go. We just want to let everyone know we’re going to reach a new stage of development soon. Q: I won’t consider KSP complete until Feature X is implemented! A: That’s not a question. However, if you asked everyone which features they would like to see in KSP, you’d get different answers from just about everybody. We all have our wishlist of ideas and features we’d like to see, us devs included. The fact is, we must be very level-headed here with what we want to do, and what we can in fact achieve in the time we have. That’s not to say of course, we aren’t planning to tackle the biggests requests from our community. Just remember that all features are judged in a big-picture perspective, and how it affects the game experience for everyone, and sometimes even what would seem like fun ideas are going to fall outside the scope of the game, or just be plain too much to take on. Time and Manpower are our main limiting resources now, and those must be spent wisely, pursuing the goals that will add the most enjoyment for everyone. Q: What about the features you “promised” on the Wiki’s Planned Feature List? A: That list is maintained by the community, and doesn’t imply any promise on our part. In fact, the best thing to do about that list is disregard it. We did implement a significant portion of it, in any case, but let me go ahead and quote the very first lines on that page: Q: Can you give us an official list of planned features for 1.0 then? A: Not without a time machine. Seriously though, any lists we publish can only result in leaving people disappointed. The problem here is that no amount of disclaimers and notices will keep everyone from taking every feature on a list as a commitment from us. We don’t want to commit to anything we’re not sure about ourselves, so if we do have to leave something out, we should be the only ones to be disappointed. It’s not great, we know, but it’s for the best. Q: Are you going to make KSP more realistic? A: That depends. Does that added realism make KSP more fun? The key point to keep in mind here is that KSP is a game first, a simulator second. We want to add realism in places where we feel those additions will make the game more enjoyable, but we aren’t just going to add realism features just for the sake of being realistic. Q: How long until 1.0 now, then? A: That’s a very good question, but I’m afraid it’s kind of the same as asking ‘when is the next release coming?’. We can’t give you a release date, because chances are high we’ll end up changing it afterwards. Knowing in advance will only lead to disappointment. Q: And after 1.0 comes out, is that the end? A: Nope. There’s still going to be a lot to be done even after that, but when we hit 1.0, KSP will be coming out of Early Access. Our main focus during the Beta phase will be to improve the overall playing experience of the game as much as possible. Once we’re outside the Early Access umbrella, KSP will have to stand on its own as-is, and not rely on upcoming features and perceived potential affecting players’ opinions. That’s not to say we rely on that now (or have ever), but that’s an unavoidable side-effect of being in Early Access. People will fill in the gaps with imagined features, and no real addition can hope to live up to everyone’s hopes and expectations. We can only try our best to have a solid game when release time comes. Q: What’s coming after 1.0 then? A: Now we’re getting way ahead of ourselves. Let’s wind this back to the near future. Q: What about Multiplayer? A: Multiplayer is something we’ve been working on for quite a while, but it still has a long way to go before it’s ready. MP is planned for after 1.0. So that’s still coming, but let’s take this one step at a time. Q: Does the term Beta really apply here? A: Not in the strictest sense, but then again, there isn’t a term that would better describe what we are planning. Beta is the period in software development when all planned capabilities are implemented, and dev focus is centered on polish and bugfixing. Yes, we do that already in experimentals, but we’re going to be doing it in a wider scope during Beta phase. For an update’s QA and Experimental periods, testing is focused mostly on the new features being added. Beta means taking a step back, and seeing all areas of the game under equal focus for testing and improvement. We know there are several bugs we haven’t fixed yet. This is the time to make those fixes and assure the game is working as well as possible. The term Beta is definitely fitting here. Q: Does that mean we’re going to have access to Experimental releases? A: No. We’re still going to go through the same branch-testing->QA->Experimentals system as we have always done. I’m just saying we’re going to work on the game under a wider perspective, more focused on the overall experience than on any single feature. This could translate to more ‘diversified’ changelogs on each release. Q: Are ‘Beta’ updates going to be released quicker? A: We hope so, but we can’t make any promises. We have tried shortening updates once before, and became aware of how the QA and experimental phases don’t really scale in proportion to the shorter update, so the result was that we spent more time testing, and less time developing, which needless to say, wasn’t very efficient. We’ll have to find our stride again for Beta, just as we did during Alpha. Q: Are updates going to be released in a regular interval? A: Most likely not. Imposing such a strict process on us would either cause features to be rushed to make a release, or some releases having very few features on them. Probably both. The plan is to play it by ear, and do a release when we feel we have something worth releasing. Q: I’m still concerned this means you’re going to abandon KSP. A: We know, and this is why we’re doing this announcement now. We want to give everyone as much early notice as possible about what’s coming up, so nobody runs into any surprises. We’re not even in Beta yet actually. There’s still the next update to go, and after that, a period of Beta updates until 1.0, and even after that, we still have more stuff planned. So worry not, we’re going to be at it for quite a while. Q: Are you going to add more whatever-it-is-you-want-added? A: We want to add as much content as we can during Beta, but time is the main limiting factor, and development manpower is finite. We’ll have to make choices through the Beta period about what we want to add, against how much time and effort that will take, compared to adding something else instead in the same span of time. As always, we’ll be weighing the gains of adding some piece of content versus another, and choosing the ones we feel will have the best effect in improving the game overall. Of course, some areas are obviously short on content at the moment (Contracts and Biomes come to mind). Those are going to be highest on our lists as they’re the least developed sets of content at the moment. The logic behind reaching for Feature-Completion and 1.0 is very similar to the logic we used to reach for Scope Completion. We focus on the area of least development. The good news now is that the area of least development is always going to be something we already have in the game, and the lack of content there is likely noticed by everyone already. Q: Are you going to integrate “Mod X” into the game? (a.k.a. Q:How can I get my mod integrated into stock?) A: This depends on several factors. First of all, we have to ask ourselves: Is this mod doing something we wanted to do ourselves already? Some mods, awesome though they are, aren’t part of what we have planned for KSP, and that’s fine. That’s why we support modding in the first place, but it also means a mod isn’t going to be auto-added just because it’s cool. Second of all, if we do find a mod that does exactly what we wanted to do ourselves, and it’s done well, follows the style of the game, all that stuff, then we get in touch with the author, and we get the conversation rolling from there. There isn’t a system for adding a mod into the game. That said, we very well might find mods that do stuff we wanted to do, and we wouldn’t want to reinvent the wheel if we can avoid it. A: Being in version 0.25 now, don’t you have 75 updates left to do before 1.0? Q: Eek, no! Thankfully, version numbers don’t work that way. The minor version (as the ‘n’ in v0.n.0 is called), isn’t a decimal fraction of the major version. There isn’t a pre-established convention in the software industry on how to increment version numbers, so each studio tends to do it in their own way. We’ve been relatively consistent with our versioning scheme, adding 1 to the minor version on each new update, and a 1 to the revision number when we release hotfixes and small patches. So the answer here is, there won’t be 75 updates between 0.25 and 1.0 in the same way we don’t have to release 10 revisions to go from 0.24.0 to 0.25.0. A: How is ‘release 26’ going to be identified as Beta then? Q: We’re going to call our first Beta version KSP v0.90.0 (zero-ninety-zero, or oh-ninety-oh if you live across the pond), to make it clear to everyone that KSP is nearing a state of completion. Of course, that doesn’t mean we plan to do exactly 10 Beta patches to reach 1.0. It could be more, it could be less, we can’t tell. If we run past 0.99. the next version could be 0.100.0, or we could change the system a bit, and increment the revision numbers instead, depending on how much we feel a release has added. In a way, Beta updates really are more like revision patches actually. We’ll keep announcing new releases as we have always done in any case, so just hang around the community and you’ll never miss a release. We want to thank you from the bottom of our heart for supporting our crazy project all the way from the earliest alphas builds up to Scope Completion, and we hope you’ll stick with us from here through Beta and up to the long-awaited 1.0 Many Cheers, The KSP Development Team, and everyone at Squad.
  25. Yep. Internal Space is a separate coordinate system, where the vessel is static both in translation and rotation. That means for anything inside IVA space, the coordinates of things from the outside world have to be converted to the IVA coordinate frame. The navball and its vectors are by far the most complicated objects in there, as you can imagine. Vector math is fun, but it can be a major headache sometimes. Cheers
  • Create New...