Jump to content


  • Posts

  • Joined

Everything posted by HarvesteR

  1. After the last upgrade to our build pipes, I realized that this is a side of the project that very few people get to see, and that seemed a shame, since it's taken a considerable amount of work to develop and put together, and I thought it could be an interesting thing to showcase. I put together this chart which shows what happens when we generate a new build of the game. Each supported platform is color-coded, and the file formats are represented by different line styles.: This entire process is automated, driven by two 'Jenkins' continuous integration systems on the two build servers. These allow us to set off builds very easily. We push commits up to the git repository, and the build servers pull the latest state of the game (on any branch) and take it from there. The whole process takes about two hours to complete for a full release deployment that is meant to go public. For QA or experimental builds, we skip as many steps as possible, and that time is reduced to about 30 minutes. This system has been evolving and being improved continuously whenever we find ourselves having to do repetitive work to get builds out. It's been growing and being upgraded for almost two years now. The more keen-eyed readers will probably have noticed that the pipeline is incomplete. There are a few channels that don't cover every platform. For instance, the patcher doesn't yet support win64, and there is no installer for Linux. The pipeline is an evolving thing, and we continue to add things to it whenever we get a chance, or necessity dictates. The latest addition was related to the 'big download server'. Previously, the transferring of build files from the main server up to the download server was done manually. This process was automated now, and both 0.24.1 and 0.24.2 releases have been done without us having to do the FTP uploading ourselves. Anyhow, this is our build pipeline. Hopefully you'll find it interesting. It's quite a step up from the early days, back in versions 0.8 or thereabouts, when all of this was done manually. Cheers
  2. Hi again, I'm sure most of you have noticed a mildly infuriating bug related to right-clicking parts after yesterday's patch... So did we. It was fortunately a simple fix, and we've got a hotfix patch available now. Here's the changelog: ============================ First Contract (v0.24.2) HOTFIX: * Fixed a critical issue which prevented opening the right-click menus for several parts. As always, the latest version is available on the download page at the KSPStore, or an automatic update will be headed your way if you're on Steam. Happy Launchings, Cheers
  3. Hi, We've just released a small revision patch for KSP, version 0.24.1. This patch contains several small and some not-so-small fixes, tweaks and minor improvements, as well as a few things that were requested by mod-makers. Here's the complete changelog: ===================== First Contract (v0.24.1) Bug Fixes and Tweaks: Parts: * Fixed a relatively serious issue with module loading which could result in missing modules if loading old craft. * O-10 Maneuvering engine scaling was off. Engine rescaled to proper size (smaller). * Fixed an issue with propellant-defined resource flow modes which prevented some configurations of Vernier engines from working correctly. * Fixed an issue with some decoupler modules failing to apply ejection forces when activated. * Fixed missing FX components on root parts after resuming a saved game or reverting. * Fixed a potential issue with the internal maths in ModuleRCS, which could result in odd RCS response from center-aligned or stack-mounted RCS modules. UI: * Fixed an issue with the App Toolbar where mod apps wouldn't display/hide properly at the VAB. * Fixed an issue with custom staging icons and switching vessels. * Fixed an issue where the Messages Dialog in the VAB would drift out of place when discarding many messages. Contracts: * Fixed a bug in Rescue Kerbal contracts, where rescue by means of external seats or claws wouldn't complete the contract. Tutorials: * Fixed a save-related bug which made the Orbiting 101 tutorial impossible to complete. Flight: * Fixed vessels not leaving 'pre-launch' condition during take-off roll. * Fixed a very annoying and potentially destructive bug where approaching another vessel could mess up your control state. Game Balance: * Tweaked costs for several spaceplane and aerodynamic parts: - Advanced Canard: 900 -> 800 - Standard Canard: 1500 -> 720 - Delta Wing: 500 -> 680 - Swept Wing: 500 -> 620 - Wing Connector: 500 -> 560 - R8 Winglet: 500 -> 640 - Structural Wing: 500 -> 540 - Aerodynamic Nose Cone: 680 -> 240 - C7 NCS Nose Cone: 680 -> 320 - Rocket Nose Cone (large): 1000 -> 450 - Standard NC (small): 680 -> 180 Modding: * Added IPartCostModifier interface, to allow part modules to tweak a part's cost. As always, you'll find the new patch over at the KSP Store in zip or installer formats, or if you're on Steam, you should be auto-updated shortly (assuming you haven't turned off automatic updates, in which case you probably know what you're doing). Happy Launchings! Cheers
  4. 'Kerbal-miles', wow. That's just a coincidence, admittedly a very surprising one indeed, but the name 'Kerbal' was invented as a random cobbling together of syllables, as far as I remember. It actually used to be spelled 'Kerbo' back in the day, but over the years it evolved into 'Kerbal' as we know it. There isn't much else to the origin of the name I'm afraid.... That was quite a find though! Cheers
  5. I wouldn't go as far as calling this a bug, although it is a pretty impossible proposition. This is why we also have a 'decline' button... Actually, the impossibleness of the proposal is by no means unrealistic... if you ever worked in software development, you'll know that sort of request is actually pretty mild, considering... Cheers
  6. I'm not entirely sure what this thread is about, or even what the OP is about either... For one, 'The Kraken' is really not descriptive of any bug we know of at the moment. Also, bugs aren't a thing you can just pick up and remove, or even see clearly for that matter. Most often, bugs are caused by things which aren't happening when they should have, instead of things which do happen when they shouldn't. Even the examples given here are greatly oversimplified compared to the average bugs we get. I think there is nothing left to say on this. I'm closing this thread before it devolves into something worse. For future reference though, here's a good rule of thumb for any questions related to software development: If your question contains the words 'can't you just', the answer is automatically 'no'. (if we could just, we would have done it long ago wouldn't we?) Cheers
  7. It's a good thing if the contracts system is over-rewarding you slightly at the moment. This is what we were aiming for during balance testing actually. That may sound weird at first, but remember there are other things that will require funds, which are still not being accounted for. Hiring/assigning crews, R&D tech purchasing, and some other stuff that I'll talk about later.... Those things will all require funds in the near future, so if you've got a surplus now, that's a good thing in the long run. And in any case, even without these upcoming cash drains, this is the first iteration of budgets in the game, and we much preferred to err on the side of caution here and over-reward a bit, than leave you stranded without means of continuing as a consequence of under-rewarding contracts. We did, IIRC, 5 or more passes over the contract outputs during experimental testing. First to achieve consistency (the earlier versions had some contracts rewarding orders of magnitude higher or lower than the average), and after consistency was reached, we carefully tuned the costs of parts (probably still missed a few, but we did go over hundreds of them), and made sure that if you played it right, cash wouldn't be a restrictive factor. Game balance is a finicky subject, to say the least, and it's not an exact science. There aren't any calculations or methods you can use to pre-analyze the resulting fun-ness of a game mechanic other than sitting a large group of people down to playtest it, give feedback, tweak something, and repeat until most agree you've got something that works. This is true of any game in fact, but it happens mostly behind closed doors, during early closed beta mostly, and some final adjustments over open beta. In our case, there is no such thing. Our closed testing is to speed up the discovering and fixing of bugs, but the final release isn't really final at all. We've been following the community closely these last few days, picking up feedback from everyone to see how the balancing is working out. We've seen some players who did get stuck with no cash to continue, and many others who have made enough to not have to worry about it. That's not bad at all from a first iteration. Cheers
  8. I think the rule is that you're never more than 6 connections away from it. But do stay away from that kind of topic, or this thread will quickly be sporting a shiny grey padlock icon which, while stylish, also disables the 'reply' button. Cheers
  9. Hi, As i'm sure you all know by now, KSP:First Contract, or 0.24.0 is live now, so while you're downloading, you may be interested to read about everything that's been done on this update. I've compiled a pretty comprehensive changelog this time, going over all of our logs to make sure I didn't forget anything. Usually we only talk about the highlights of a release, but this time, we ended up with a list of changes so large, I thought it worthy of being showcased here. Plus, if your download is still not finished, it's something to do while you wait. So, here is the complete changelog for the KSP v0.24, 'First Contract' update: ChangeLog: ======= First Contract (v0.24.0) ===================== New: * Currencies: - Added Funds and Reputation as new Career Mode Currencies. - Funds are required to launch vessels. - Part Costs are now in use in Career Mode. - Resources like Liquid Fuel and Mono Propellant now have costs of their own, which figure into the cost of a launch. - Tweaking a part's resource sliders in the Editors will adjust the cost of the vessel accordingly. * Mission Control: - The Mission Control Facility is now active in Career Games. - Mission Control allows you to select Contracts, review them, and either accept or decline them. - Added Gene Kerman as advisor in the Mission Control screen, ready to give his opinion about what you're doing. - The Mission Control screen also features an 'archives' tab, where you can review previously-completed contracts. * Contracts: - Contracts require you to complete objectives, in order to gain Funds, Science and Reputation - Once accepted, contracts must be completed before the deadline expires. - Contracts will fail if the deadline expires or if some critical parameter fails (like killing a Kerbal in a mission to rescue him). - Added procedurally generated 'mission briefings' for contracts, which may even make sense sometimes. - Contracts come in three levels of Prestige ("Trivial", "Significant" and "Exceptional"). Higher levels offer greater rewards and are usually more ambitious. - Reputation regulates the amounts of each level of contracts on offer. * Early 'Starter' Contracts: - First Launch: Launch any vessel. - Altitude Records: Set a new altitude record. - Reach Space: Escape Kerbin's atmosphere - Achieve Orbit: Achieve a stable orbit around Kerbin. * Dynamically Generated Contracts: - Part Test: Perform a test of a part in a specific location, situation and within given flight parameters (when applicable). - Collect Science: Return or transmit any scientific data from a specific location. - Rescue Kerbal: Rescue a Kerbal who is stuck in orbit. - Plant Flag: Plant the Agency's flag on the surface of a given location. - Explore: Complete several exploration goals for an unexplored location. * Agencies: - Added Agencies, which offer contracts. - Each agency has its own personality traits, which affects the generation of the contracts they offer. - Agency Logos added from the winners of the Community Logo Design Contest. - Clicking the agency logo in the Mission Control screen will display extra info about the Agency. * Vessel Recovery: - Recovering vessels now refunds you for the value of recovered parts and resources. - Recovered value varies based on distance from the Space Center. Land at the Runway for 100% value. * Space Center: - Added a universal time clock to the KSC scene UI. - Added a Pause Menu to the KSC scene, instead of leaving to the main menu immediately on pressing the Quit button. - The KSC Pause Menu allows saving and loading with a custom filename. * UI: - Added new UI Toolbar, which exists in all game scenes and is mod-friendly. - Added new UI Widget to display state of ongoing Contracts in Flight, KSC and the Construction Facilities. - Added new UI Widgets to display the current amount of Science, Reputation and Funds. - Added Messages UI App, shows messages about contracts and such. - Redesigned the Resources Panel from flight as a toolbar app, overhauled panel graphics. - Overhauled the old 'Science Summary' dialog into a complete 'Mission Summary', displaying information about recovered Experiments, Parts and Crew. * Parts: - Added new "Vernor Engine", a very powerful RCS module powered by Liquid Fuel + Oxidizer. - Added new O-10 Maneuvering Engine, a low-thrust main engine powered by Monopropellant. - Gimballing Engines now respond to roll input. - 4x Engine Cluster and RAPIER Engine have gimbal roll authority even if stacked over the centerline (due to multiple nozzles). * Builds: - Added Windows 64-bit executable. * Tutorials: - Added several new tutorials. * Game: - Added 'Science' Game Mode, where Science is the only currency and Mission Control is closed (as in pre-0.24 'Classic' Career). Bug Fixes and Tweaks: * Flight: - Asteroids are now able to collide with other asteroids. - New launches now start with throttle set to 50%, like in the old days. - Saving restriction when throttled up removed. - Timewarp restriction when throttled up removed. Engaging time warp now automatically cuts throttle. - Improved logic for detecting a vessel in 'orbiting' situations. * Editors: - Fixed a bug in the editors where dragging a part off the ship and deleting it straight away would not generate an undo state. - Fixed a bug where ctrl+clicking over a part in the build area would not reveal the part in the parts list. - Orientation of VAB scenery rotated so spacecraft orientation is consistent at launchpad. - VAB Flag moved to the opposite wall. - Redesigned the Parts List UI 'Footer' section. * Tracking Station: - Fixed a bug where map objects were created but never removed, leaving dozens of 'leaked' objects behind. * Space Center: - Launchpad and Runway Launch Dialogs now show vessel costs. - Added 'Edit' Button to Launch Dialogs, which takes you to the VAB or SPH to edit the selected vessel. - Launch Dialogs and Craft Browser now allow selecting vessels with 'invalid parts' (for editing). - Added new Pre-Flight Checks to prevent launching vessels containing invalid parts or with costs exceeding available Funds. * Solar System: - Kerbin's Solar Day is now exactly 6 hours long (sidereal day is now 59 seconds shorter). - Slight optimization to Kerbin, Mun and Eve surface shaders. * Parts: - Resource flow mode can now be defined for each propellant on Engine, EngineFX and RCS Modules in the part config. - Previously useless Engine Nacelle and Radial Engine Body parts repurposed as air intake + fuel tank combos. - Tweaked Costs for almost every part. - Tweaked Mass for several parts, especially spaceplane fuselage sections and structural components. - Fixed a potentially gamebreaking issue when activating a Separator if it was the root part of a vessel. - Fixed a bug where some particle FX (mainly on newer engines) would cause a stream of errors when the vessel was unloaded with the FX active. - Fixed a bug where StrutConnectors could cause hierarchy issues if linked in certain configurations. - ModuleRCS can now use multiple resources. * Tech Tree: - Revised R&D node layout so 'control' type nodes have a more logical progression. - Moved basic RCS parts to tier 4 (from tier 5). - Added more connections into aerodynamic parts from other nodes on tiers 5 and 6. * Progress Tracking: - Fixed an issue introduced in 0.23.5 where unowned vessels could complete progress nodes. - Fixed AltitudeRecord progress node (now used for contract generation). * Crews: - Fixed crewmembers not being properly flagged as dead if their vessel was destroyed while unloaded. - Crewmembers are now keyed by name in the roster, and can properly be added and removed. - Added reputation reward and penalty for recovering and killing crewmembers. - Added new unique names for Kerbals, suggested by the Community Logo Design Contest winners. * Misc: - Fixed issue with persistence when reverting to flight. - Added rich text support to several UI text fields. - Fixed several cases of texture point-filtering issues resulting in crooked text. - Fixed potential crash related to reentry FX on Linux when no depthtexture hardware support is available. - Overhauled all UI screens and text. All text fields using Arial font now use proper Calibri. - Exposed Gameplay difficulty options to the Alt+F12 Debug Toolbar. - Updated Credits Scene. - Fixed permission issues with KSPLauncher which prevented it from properly launching the game on Linux. - Messages displayed on the upper-right corner in flight are now displayed above the crew portraits instead. - Removed a 'rogue' tooltip from the Staging Reset button at the VAB and SPH. Hey, you read through the whole thing! congrats! (or sorry for the slow DL speeds). Have fun!! Happy Launchings!! Cheers
  10. UPDATE: Click the photo above to watch a special video preview for what you can expect in Kerbal Space Program: First Contract! Hi again, As I mentioned in this week’s dev blog, we've got quite a bit of stuff done in the game to list there, so here's a new update on some of the things you can expect for Kerbal Space Program: First Contract (update 0.24). * Contracts: You probably know about this one already. The Mission Control Facility at the space center now lets you take on contracts to earn Funds, Science and Reputation. * Budget Essentials: Career Mode is greatly expanded now by the addition of Funds and Reputation. Funds are required to launch vessels, and reputation is earned (and lost) by doing contracts (or failing them). In this release, your reputation is already used to regulate the level and amount of contracts offered you. Lower reputation means fewer and less prestigious contract offers, while high reputation means more and more ambitious proposals. * Vessel Recovery: Vessel recovery is also making its first appearance. Although still not complete, the new recovery system now lets you reclaim some of the cost of all landed parts, and any resources they still contain. The Science Summary Dialog of previous versions has been overhauled to also include information about recovered parts and crew. * New UI Toolbar: User interfaces in the game have been vastly overhauled, but the largest addition is the new app toolbar, which can be seen in most scenes now, and holds buttons to flip between the messages, resources, currencies and contract panels. Also, it's mod-friendly. * New MonoPropellant-Powered Engine and LFO-Powered RCS Thrusters: The O-10 MonoPropellant Engine is a standard engine linked to main throttle controls, but powered by MonoProp. The Vernier Engine, conversely, is a Liquid Fuel+Oxidizer powered RCS unit. These should be interesting new additions to the stock parts set. * Revised Tech Tree Layout: To better fit the new engines above, we've updated the tech tree, giving the 'flight control' type nodes a much more logical progression, and added new paths to expand your way through the tree more freely. * Repurposed Engine Nacelle parts: Those grey, largely useless engine body sections are now given new purpose as combination air intake + fuel tank units, making them a lot more useful for building spaceplanes. There are many more features, tweaks and fixes all around, but these are the highlights. All in all, I'm very glad we decided to push this update further. The difference between the state of the game now compared to when we were doing the first round of experimentals is huge. It's definitely safe to say it was time well spent. Cheers
  11. I did tweak the Kerbin day slightly here so that 6h is now the length of a solar day, not a sidereal one. As a result, the sidereal days are now 51 seconds shorter, and you may get an eastward launch velocity boost of around 0.01 m/s. However, over many days, the time of 'noon' still drifts. I suspect that this is related to the year not really being an integer number of days, and there being no accounting for leap years... Anyhow, 6h for solar or sidereal doesn't really matter in any case, becuase the UT clock doens't measure local time. It measures time elapsed since game start, which is the only solid epoch really, in a game where you not only have a planetful of timezones, you have several planets, each with different day/year lengths... Really, it's much much easier to just measure local time at your position as a function of sun angle. UT time is useful though, not because it relates to any particular natural cycle, but because it is consistent. Cheers
  12. Work continues with Contracts, the weeks are starting to blur together as a continuous stream of work. As you all know by now, Chad is moving on to other projects. At this stage in the project, bringing in someone new as a straight up replacement isn't a possibility. The level of familiarity a developer gains after working for years on a project can only be gained by working, well, for years on a project. We have new people on the team as well, Hugo is doing some very good work, Rogelio is helping Dan with the animations, which frees him to take on some of the roles Chad used to do, and Nick, who modelled several of the parts in the ARM patch, is also working on other design jobs for things still some ways away. The plan then is not to replace, but to adapt to this new team structure. Not all is gloom and woe though. On the development side, we now have ahead of us what is unmistakably the last stretch for Contracts and Budgets on this update, so we shouldn’t be far now from a system which will obviously still need a lot of content added to it, sure, but should be able to handle just about any idea we can throw at it. To put this into perspective, I may have said this before, but I’m quite convinced now that the only existing system that is similar to the Contracts system in magnitude and robustness is PartModules. Now, consider that PartModules, while it made its first appearance in the 0.17 update with the LaunchClamps and got going in 0.18 with docking ports and all the other bits, the basic system itself actually entered development around the time of 0.15. About 6 months or more of development before it was even announced. it did turn out to be a system so important to the game, it was worthy of an entire talk to itself at the GDC. With Contracts, we are faced with a task that is similar in many ways. However, this time we are under very different circumstances. Most obviously, the game is now much, much larger than it was when the first Module-based parts were added, but perhaps not as immediately apparent, the level of quality expected of such a system today is orders of magnitude greater than what it was about a year and a half ago. This is by no means a bad thing. If the expectation of quality is ever rising, it means at the very least that we aren’t making the game worse. But therein also lies the main issue of recent times, and also the reason why we decided to push the 0.24 release back. If we had released Contracts as they were last week, back in the days of 0.17, it would have been pretty ok, and about on par with the rest of the game. However, because everything else is so much further developed, every new feature must be implemented, from scratch, up to the same levels of quality as the rest of the game, which is a lot of work to cram into a single update. The plan then was to split up the update into two smaller chunks: Contracts first, generate missions based on this progress-aware, semi-procedural framework, then create some placeholder contracts to make sure the thing worked. On the next update then, tie it together with budget management and add in some proper contracts. Of course, that plan didn’t quite work out. Not because of any technical problems, though, but because of a game design one. As I explained earlier on another article, there was no point to having contracts in before budgets, nor would have there been much use for budgets without contracts. The two systems, while technically separate, were one big gameplay mechanic. That was the focus of the first week or so of our ‘extended time’ with 0.24. We added enough of the budget functionality to make sure Contracts had a proper purpose and reason for being in the game, and that much I can say, has worked. Being required to purchase your vessels before you launch, and being rewarded for the things you achieve adds a whole new dimension to the game. Arguably, the missing link between a Space Exploration Sandbox and an actual Space Agency Game. There are other Career mechanics still left to add, of course, but nothing of this scale. With Contracts and Budgets in, Career Mode is now finally reaching a point in development where we can start to appreciate the entirety of what KSP will be. This not-so-distant point now, is what we set out to achieve after we declared KSP to be Sandbox-Complete, just as we finished up updates 0.19 and 0.20, and started in earnest to add Career oriented features. We are now looking, albeit still from a couple of updates away, at Scope Completion. If you weren’t around when we announced Scope Completion as our goal back then, let me recap: Scope-Complete means that every major gameplay system in the game is implemented, even if its content is limited. It means all the necessary support for the game’s content exists and can be expanded upon. I do need to make one thing very very clear: Reaching Scope Completion does not mean, by any means, that we’re done with the game, or even that the features we have are now finished and beyond improvement. Quite the opposite in fact. It means there are (or will be, as we’re not quite there yet) no more base systems left to do, and from there on, the focus shifts to improvements, optimization, and content. Of course, we have to to make sure we add enough content to show our new systems in function (imagine building yourself a top-notch gaming PC and having no games to play), but for a lot of areas, the amount of content we have added so far is symbolic at best. In some cases, like Biomes, it's actually the minimum needed to make sure the system is able to function, and scale as more content is added onto it later. This is how we’ve developed KSP from the start. Always focused on what I call the ‘area of least development’. Whichever part of the game is the least close to completion, or furthest behind in comparison to others, is the area to focus next. Working with minimal content during development isn't a bad thing for developers. I can't count how many times I've dreaded the prospect of having to go through all the 170+ parts and their configs, to make some tweak or another. Having less parts in the game would have certainly made life easier for us on many a situation... It would also have made for a much less interesting game. This, as with so many other things, is something we have to maintain in balance. Walking this line is not an easy thing to do. It's very easy to get tempted to follow some feature or another all the way through, rushing through it on that surge of ideas that pop up as you work on it. Other times, an opportunity may present itself which cannot be delayed (like a very recent one featuring asteroids, you may remember it). On yet other times, you feel the urge to just start chucking in everything that is missing, in the crudest way possible.. I don't have to explain why that last one is a bad idea... Naturally then, we have taken a few side steps along the way, adding features of opportunity here and there as they presented themselves, or killing off some annoying bug that had just pestered everyone for too long. For extremely large projects, like Multiplayer, we’re working on it in the background from several months in advance, so by the time we are ready to start focusing every effort on it, we won’t be starting from scratch. Sometimes it's worth it to leave the path to pursue something unique and interesting, other times however, we have to force ourselves to not work on that thing we've been itching to do for so long now, but won't get the game any closer to completion. In any case, the bottom line is that ever since 0.19-0.20 were released, our main goal has been to reach Scope Completion: Not finishing up what we started, but starting what still doesn’t exist. I do have to say this very clearly: Releasing 0.24 does not mark Scope-Completion. There will be at least one, possibly more updates still before that. However, after 3.5 years of work, a couple more updates is really not such a long way to go. We're getting there. Perhaps not as quickly as we would like, but we are getting where we want to be. Cheers
  13. There seems to be some confusion about what recovery means for Career and Test contracts, let me clarify: Recovery exists all the time, even in Sandbox in fact. What it is able to recover depends on the game mode, of course. For Sandbox, the only thing you can recover are crewmembers. There being no funding or science in sandbox, it wouldn't make sense to recover anything else. In Career Games, you can recover experiments (as usual), parts, and crew. Parts are always recovered, regardless of them being something you have researched already, or being an 'experimental' part, offered by a test contract. For normal parts, recovering them means you get some of its value back, which also factors in any resources you burned. So recovering an empty SRB, for instance, will yield a lot less funds than recovering an unlit one. Given that the SRB's cost is about 75% fuel, that is a sizable difference. For experimental parts, two things may happen. If you completed the contract that offered it, the part will no longer be classed as experimental, so you'll get the recovery funds for having returned it, but it won't be available anymore in the parts list until you properly research it in R&D (or you take up another contract that offers it). If you haven't yet completed the contract however, recovering the experimental part will add it back so you can launch it again for a second try. The cost of the part is independent of its status in R&D. As for the value of the recovered parts, that is still a work in progress. Currently, there isn't anything deducing the recovery value of a part other than figuring out the value of the part and the remaining resources in it, but that will likely change before release. There should always be some loss of value in recovering parts, even if you don't use it. For recovering Crew, well, this has been in the game in an understated way ever since persistence was implemented. The only difference is that now you get to see exactly who was in the vessel you recovered as part of the summary screen. Hopefully that clears up how the whole thing works. Of course, this is a first iteration for these systems, so don't expect everything to be final as if it were fully implemented yet. There will most likely be a lot of other things to add on later updates.... as with everything else. Cheers
  14. Hi, It's been a while since we had one of these... If you're new to the community, this is just a small update to let you know where we're at with developing the next update. So, here's the latest news on update 0.24: We've completed the initial features we had lined up, had them QA tested, and even got a few experimental builds up for initial testing and feedback. We worked through most bugs. But the overall feedback we got from the exp group was that the update as a whole left them wanting, which was, well, not what we would have liked to hear... but such is the way of things sometimes. This is why we test before doing public releases: Not just to catch bugs and technical issues, but also to get subjective feedback on what we have, and act on it when necessary. This was one case where acting on it was necessary. The general consensus was that the Contracts system seems to be working quite well, functionally. But at the moment, the system is just that: Functional. We've built a solid framework, but to make this interesting and release-worthy, we have to populate it with interesting content. We also realized Contracts serve no purpose if there isn't a need for the rewards they offer. That means we still have a few features that need to be added. Essentially, we're moving the core essentials of Budgets, which were originally planned for 0.25, up to 0.24. This includes, among other things, the requirement to spend your program's Funds to launch vessels and purchase parts in R&D. Naturally, this means we still have some work ahead of us before we can call this update done. I just want to make it clear that we're not as close to release as people normally start to speculate when we announce having reaching experimentals. This is why we don't announce release dates in the first place, but we are very much aware that despite that, you guys will guess, pretty accurately sometimes, so we felt it was important to share this news. We don’t want the speculation to lead to overly optimistic expectations about the release date. In the (somewhat bent) words of a wise old master: Speculation leads to Expectation, Expectation leads to Disappointment, Disappointment leads to Hate, and Hate leads to the Dark Side. Cheers
  15. The value in question would be Part.inverseStage. And yes, staging is a deceivingly complicated piece of logic. You'd think it would be something as simple as recursing through the ship and handling it as a simple tree structure, and then you get to the edge cases, and you feel like you just walked into a room full of zombies. Having the main 'pod' section of the spacecraft not share the same stage as the root of the ship (the first part you placed) causes a number of mind-bending situations... What happens to the vessel when you drop the main bits that were controlling it? That's something we call 'root-dropping', although it is a bit of a misnomer. You're dropping the core of your spacecraft, but the root of the vessel was not part of that core, so from the core's perspecting, you've 'dropped' the root of your hierarchy. We work around that by detecting whether the ship you're now in control of is still more than a piece of debris. If it's not, then we switch focus to the jettisoned bit. You can see that happen sometimes as the camera tends to jump slightly instead of flowing smoothly towards the new center of mass. Hierarchy shifts happen all the time as you play. Docking is what got that whole thing started, as as you docked, the 'docker' side of the pair would shift its internal part hierarchy so that the docking port itself was the root of the vessel, and everything from there down became children of it. Then upon undocking (assuming the vessel still contained its original root part... man, 0.18 was a pain to debug), we flip the hierarchy back again so the old root is now the parent for everybody else. Now, with the whole 'we can now shift hierarchies' thing added, we saw that there was no need to enforce that a pod be the initial part on a ship. As long as it was something you could attach other parts to, there was no reason why anything couldn't be the root, but it did create the new problem in which the command pods now were not only optional, they also were possibly placed after decouplers. Hence, root-dropping. Anyhow, I should get back to work here. Best of luck with your mod. Cheers
  16. This question has popped up in varying degrees of aggressiveness quite a few times... Thanks for asking it straight and simple. 'Merging' mods is one of those things that one the surface would appear simple, but it's actually quite a lot more complicated than it would seem. Consider that even commercial assets from Unity's asset store, which are packages made specifically to be dropped in and used in existing projects, will, for the most part, require some drastic reworking to fit them into KSP. Granted, the mods are done already over our existing codebase, and that does make the initial integration easier, but there's more to it than that. If we had a complete game, and someone came up with an awesome new mod that everybody wanted, and we had permission to fold it into the game (another issue in itself), that would probably be the end of the story... Assuming also that we wouldn't have to make any changes to the mod itself (another tall order, since mods are exactly meant to modify the game experience, by definition). That's obviously not the case here. The game is still growing, and as it grows, it's very common for us to come across bits of old code that now need to be refactored to make it work again. And that's with our own code. Now, consider how frequently mods become incompatible when we release a new update. We are blessed with a modding community here that is so solid, you're likely going to see your broken mods fixed in a short amount of time. That's done by the mod authors themselves, because they care about their projects and they put in a lot of effort to keep it nicely maintained. Now suppose we were to fold a mod into the game... That author support would now become our own burden, and given that we have our own systems to maintain as we develop already, imagine what it would be like if we started to suddenly plop down chunks containing thousands, or tens of thousands of new, unknown to us, lines of code. We'd end up with an unmaintainable mess of code. In the end, we're happiest as we are right now. The gist of the problem is that neither the game nor the mods are carven-in-stone, unchanging pieces of code. Both are living, evolving projects, which evolve alongside each other, and it takes the combined efforts of everyone to keep this organism alive. You can put it like this: A bird needs a tree to nest in and survive... But try gluing the bird to the tree to see what happens. (actually, don't try that). Cheers
  17. Ah, indeed, there is a bit of a catch there. The new stage drain logic does use the staging indices for the part, but the thing is, tanks and such are usually not the kind of parts you would see in the staging list, since they have very little to 'activate' by engaging a new stage. The thing to keep in mind here is that even though the tanks are not present in the staging list, they are still bound by the rules that control the default assignment of stage numbers to every part. That said, there may be a subtle bug here, which I would rather not poke at without having a better understanding of what's really going on internally. In that other thread, you can see that while the tanks are clearly on different stages, they appear to not have inherited the proper stage index after the decoupler. It's hard to tell any more without knowing in which order those tanks were put together, if they were placed before or after the decouplers, or if that happened before or after stages were edited, or even if you copied the other decouplers instead of using fresh ones, all that could be potentially influencing the situation. I'll try some experimenting here in any case, ideally, I would expect any part that has no purpose in staging to just inherit the staging indexing from the parent part, manually modified or not. With staging related issues, however, well... let's just say if I could pick any part of the game to go back in time and do over... staging would be right there on top on the list. Another one for when it's time to pave the tunnel, I suppose. Cheers
  18. That is actually a great idea, and taking care of those 'little things that kill' (great name for it) is something that we always try to do, whenever we get a chance. For the ARM update, in fact, I did devote an entire week to cleaning up loose ends, mainly concerning how maneuver nodes and map view features were handled... But therein also lies the catch: If you can sink an entire week in just that one area, take a step back to look at the entirety of the game. How much of the scope of the game would you say the map view and maneuver nodes represent? 10%, 15% maybe, I wouldn't dare call it any higher, what with the space center career features, craft construction, part logic, part physics (not the same), scenery, map scenery (also not the same as map view itself), persistence, and not least and probably forgetting a bunch of other bits, the UI on each scene also.... In fact, after listing thing... even 10% seems like a gross overestimation. I don't mean to complain, just to give a sense of the enormity of the job that's ahead of us to tidy up these little things. The good news is that as soon as we're done implementing the last stages of career mode, the plan is to devote more and more time to improving and tweaking everything that was left behind as we pushed forward. Things like what you suggested here will become increasingly more important. If we were building a tunnel, you wouldn't expect the road to be fully paved up to rear end of the tunnel-boring machine. The whole tunnel would be closed to traffic in fact. It's pretty much the same principle here, with the advantage you get to visit the job site and drive in it already. (ok, that's quite enough stretch on that analogy, any more and it will collapse) Cheers
  19. By default, the X52 does seem to be way too sensitive, but you can drag the sensitivity sliders on the input settings down so they respond better. Those sliders affect the response curve, so you can have less response near the center, and still max out the axis at full deflection. Sliding to the left will make it less responsive. For the x52, I've found that you probably want it toned down to around 15% or so, except for the throttle axis, which should be kept linear (same for the rotaries). In 0.23, there was an important bugfix done to joystick indexing, which affected axis mapping when multiple devices were present. That's much improved now, although there are more tweaks to do there still... like everything else. As for recognizing the buttons, that's something we don't have much control over. Unity will read up to 20 buttons from a single device. The X52, IIRC, has 39 (everything counts, Hat switches, scroll wheels, even the mode switch), so several buttons won't be mappable directly in KSP... That's why all high end devices have profiling software, very few engines are able to read every single button on an input device. Cheers
  20. Actually, a lot less than I would like to... Lately, it's been more like if I want to put in gaming hours, I have to also sleep less. Cheers
  21. Heh, they actually are from 2007. They're the oldest things in the setup at the moment. The TH2Go was the only way to have triple contiguous displays back then, Surround and Eyefinity weren't a thing yet. I still like the TH2Go better than a GPU-based setup, because it means the GPU is freely replaceable, and there's no need to fuss about with drivers... As far as the GPU knows, there is only one triple-wide display hooked into the primary output port. I know, and I would very much like to add TIR support here too, but there's always something of higher priority that needs to get done first. We'll get there eventually... Cheers
  22. From the tracking station, Backspace will focus you back to Kerbin also, as that's the camera 'home' target in that scene (as opposed to the active ship while in flight) Cheers
  23. This is something we can't really take full credit for. The Unity 4.3 update was a MASSIVE performance boost for us as well, not just in builds, the editor itself is running significantly faster also. So let me add my own thanks to the Unity team, for a crackin' update! Hats off to you sirs! On our end, the one thing I think helps improve performance is the new part joints, and even the new parts, not necessarily because they are more optimized themselves, but because with much less need to spam hundreds of struts, and heavier parts that can do the job of several smaller ones, your ships are more "optimized" as well, at a design level. Anyhow, I'm very glad to hear everyone is enjoying a nice performance boost. Most times these things tend to affect only a subset of cases, but on this update, everyone seems to be reporting nicely improved performance, so very happy to see that! Cheers
  24. That should do it! Thanks for posting that. We've got a hotfix patch on the way already, shouldn't be much longer now. Cheers
  25. Hi, I'm very happy to announce that the Asteroid Redirect Mission patch for KSP is now officially released! This is a very special update in many ways, not least of course is that it was made in collaboration with NASA, to make sure our Kerbal version of the Mission was not only true to its real-life counterpart, but that it was also fun, educational, and in keeping with KSP's style, free to be performed in any way you can think of. Want to re-enact the exact mission profile NASA is planning? Go for it. Want to send up enough rocket fuel to lift an office building and slam on the retrograde brakes? That's also an option. Want to not do any of those things and just use the Advanced Grabbing Unit to choose which Kerbals go and which stay? Erm... sure. This has been, without question, the largest update we've ever done, not just in terms of development time, but most importantly in terms of the scope of the changes made. No other update has had so many different areas improved on at the same time. We usually focus on a single area to work on, but this time, we really felt the need to make a noticeable improvement in the overall playing experience, especially around flight planning and advanced deep-space missions. So, Here are the highlights for this update: * Asteroids: Kerbin is no longer alone in its orbit. Nearby are countless objects that buzz in and out of its sphere of influence, some flying by harmlessly, others on impact trajectories. Ranging in size from just a few meters through 5 size classes up to gigantic objects weighing thousands of tons, these new objects should provide a new challenge for both new and veteran players. Each asteroid is procedurally generated, so no two are the same. Also, asteroids can have samples taken from them by EVAs, providing a constant source of valuable science data, right on the edge of Kerbin's SOI. * Object Discovery and Tracking: Before you set out after an asteroid, you first need to identify and track them using the Tracking and Discovery features on the Tracking Station Facility. Select one of the unknown objects spotted near Kerbin, and start tracking it actively to reveal more information about it. Also mind that untracked objects can be lost if they're left unobserved for too long. * The Advanced Grabbing Unit (aka "The Claw") As the name probably implies, this new part is the means by which asteroids can be captured to be redirected. Just arm the device, approach the target carefully, and the claw will do the rest. It's like a docking node, but without the need for a mate node on the other side. Better still, the AGU can be used to grab on to much more than just asteroids. In fact, it can pick up just about anything, even Kerbals. * New SLS-inspired Size 3 parts: We've added a host of new parts, featuring the largest engines and fuel tanks ever seen in KSP. These new parts were designed based on NASA's upcoming Space Launch System, and they pack a huge amount of rocket power. * Completely Overhauled Part Joints: We have completely re-done the way parts attach to one another, to allow for much greater flexibility and control over each joint. Joints are also more accurate and stable, as both jointed sides are now anchored at the attachment node (this wasn't possible before the Unity 4.3 update). There's more. This update also features a host of small, and some not-so-small tweaks and improvements to usability, giving many features added a good while ago a much needed refurbishing, and adding a lot of the little things we never got a chance to add when we first implemented them. Here's the changelog: Release Notes: * The ARM Patch (0.23.5) should not break backward-compatibility with previous saves. That said, however, do mind that we cannot account for mods, so don't expect them all to work perfectly. If you experience any problems, make sure you try a clean install of the game without any mods, and a new clean save as well. * The ARM Patch is available just as any other update. If you have the KSPStore version, you should be able to use the patcher to get yourself updated, or alternatively, download the complete package again. If you have the game on Steam, you should be auto-updated next time you run the game. Just make sure you haven't disabled Steam's auto-update system for KSP. Props to you for reading this far. I won't keep you any longer. If you don't have your copy of KSP yet, the game is available at: * The KSP Store * Steam * Greenman Gaming * Gamefly Happy Launchings, and have fun!! Cheers UPDATE: As many of you pointed out, there was a weird bug in the 0.23.5 build that caused the R&D facility to appear as closed if you loaded an existing save. We've already spotted what caused this issue and we're now testing a hotfix which should solve the problem. The revised build should restore R&D functionality, but unfortunately, if you've experienced this issue with your save, your science progress will already be reset. If you have a recent quicksave, you should be able to revert to that after the patch without problems. This issue managed to slip by undetected through testing, most likely because it requires an old save to be reproduced. New saves should not be affected by this issue at all. We'll get the hotfix build out as soon as possible, hopefully in a few hours. In the meantime, avoid loading existing saves to bypass this problem. We'll let you know as soon as the hotfix is up. Our most sincere apologies for this inconvenience. Cheers UPDATE #2: We've updated the release now with a new build, which fixes the issues with the R&D Facility being closed, and also fixes another very disruptive bug when resuming saves with Kerbals on EVA. The new build's version number is If you see that on your main menu's bottom-right corner, you should be up-to-date. The original release was, for reference. Thank you for your patience, and again, sorry for the troubles. Cheers
  • Create New...