AVaughan

@Kernel KrakenGithub should have all the releases. https://github.com/BobPalmer/Konstruction/releases . I think v0.3.1.0 was the last version for 1.3.1. The Spacedock version seems to be very outdated.

You and @Ho Lam Kerman are both ignoring the problem that unless the descent module was designed to be refueled in orbit, then it is probably not possible to refuel it except on the ground, even if the ISS had H2O2 available. The necessary valves and fittings are probably on the outside of the capsule, and not designed to be accessed during flight. Regarding the ballistic descent being survivable, I think it will only be survivable if the descent module renters heat shield first. Without KSP's magical reaction wheels that requires the descent module's reaction control system. Which is fueled by the hydrogen peroxide.

There is also https://forum.kerbalspaceprogram.com/index.php?/topic/95645-13x-seti-unmanned-before-manned-patreon/ , but it is currently unmaintained. Since it is "All Right Reserved", no-one else can pick it up, but there is also a set of patches to it https://forum.kerbalspaceprogram.com/index.php?/topic/171481-14x-ubm-extended-techtree-configs-making-history-missing-history-and-more/ . (Whose maintainer is also lacking time to keep it upto date).

@Cubivore. There are apparently improvements to landing legs/gear coming soon with 1.5. In general I always recommend posting screenshots/craft files when you are reporting problems. Many issues are caused by poor design choices by players.

In stock radiators are still needed for drills and ISRU. Also when talking about realism, remember that in Apollo 13 the capsule got cold because the heaters were turned off to save power. ie Apollo 13 was radiating away more heat than it was absorbing from the sun. (Possibly it reached an equilibrium, but that equilibrium was colder than the designers/astronauts would have liked). So whilst heat management is something spacecraft designers need to design for, they don't always need to add radiators.

I thought the LES wasn't supposed to separate until about 40 seconds after the boosters separated. So the LES should have been available at the time of failure. The booster did seem to be turning sideways, so I guess it's possible that aerodynamic forces destroyed the LES before it could be activated. (It also possible that it was used and a translator mistranslated LES activated as LES jettisoned). If aerodynamic loads did destroy the LES before it could be used, then that sound like a design issue, and I think it's unlikely they could fix that and certify a new design in the next 3 months.

I wasn't saying "Don't update the game". What I was arguing against was squad releasing a small update every 3 months. I think the community would be better served by larger/more substantial updates 6-12 months apart. Edit: And also do enough pre-release testing that they can get the new release stable in a few weeks. Ideally on the first attempt.

Personally I have no idea whether any of the mods I mentioned are using anything beyond the public API. But even if they stay to the public API, there is always a chance that any bug fix or refactoring of KSP's internal code might expose a new edge-case or bug that breaks the mod, even when the public API is unchanged. The rebuild itself only takes a couple of minutes, but as I said above testing can take much longer. Even if there are no API changes, the testing of a complex mod can take a lot longer than 5 minutes. It's potentially even worse if something is broken, and you need multiple hours to debug and then fix it, with a period of testing after attempt, and then need to retest everything afterwards, since there is always a possibility that you might have broken something else. If you are a dependency of other mods, it's also possible that you need to test against both vanilla and those mods, because otherwise you won't catch bugs that are the result of mod interactions. If you depend on other mods, then it is possible you can't even test your mod until all those other mods have made a release compatible with the new KSP version. (I'll note that RO and especially RP-0 depend on lots of other mods). According to the wiki, KSP 1.3 released on May 25, 2017. According to Github, Ferram released the 1.3 FAR version on 22 Aug 2017. (Note that is 3 months after the KSP release). KSP 1.3.1 released on 5 October 2017. The 1.3.1 version of FAR was released on 2 Apr 2018. (Note that this is after 1.4.2 was already out). Now from memory the changes between KSP 1.3 and KSP 1.3.1 were pretty minor, so I'm not sure why it took 7 months to release an official release. I'm pretty sure there were builds available for people to test months before the official release. (Maybe @ferram4 or someone else with knowledge of FAR development could comment on the reason for the delay). As I said above we still don't have an official 1.4.x FAR release, and the way things are going I'm concerned that if KSP starts releasing every 3 months, we might never get an official FAR release for the most recent version. (And without FAR, we might not get a RO release, and without RO we won't get a RP-0 release either). As I said above I view this fragmentation of the KSP versions that the modding community is trying to support as a problem, and I think that releases every 3 months will just make it worse, especially if each release is followed by 2-3 patch versions over the next month, leaving only 2 months to update large mod sets like RO/RP-0 before the next KSP release. I'll also point out that Kopernicus is version locked. Again I'm not sure why, but presumably the Kopernicus developer(s) have their reasons. Perhaps they either expect breakage with (some) new KSP versions, or want to spend time testing with a new KSP version before making an official release (perhaps to save themselves from a wave of bug reports when something does break). My whole attitude to 1.5 is pretty "ho hum" atm. It's possible I might have missed some things, but most of what you have announced seems to be new graphics with a few changes/bug fixes to core KSP. Even the change to maneuver nodes you mentioned last week isn't something that improves the game for me, since I normally have mechJeb and/or KER installed and often better burn time installed anyway. (Note I'm not suggesting that those changes aren't a welcome improvement to vanilla, but that I already have similar functionality from the mods that I install anyway). I'm way more interested in new gameplay, and can't recall anything that you have announced for 1.5 that excites me. The new graphics don't excite me. For roughly half the examples you have shown, I actually prefer the old versions. For the rest I'm concerned that the improvements in visuals will come at the cost of reduced rendering performance on my 9 year old Radeon HD5770. Note that if I actually cared about better graphics, then I'd have a better graphics card. The steam integration from 1.4.4 is another thing that I just don't care about, even though I use steam, and install mods through steam workshop for other games. (I'm not into missions, nor am I interested in downloading other people's craft files. I also move ksp to another folder outside of steam before installing mods, so I doubt that steam workshop would even work in my modded install. I'm also against adding KSP mods to steam workshop, since to the best of my limited understanding, steam workshop doesn't support installing the correct version of mods if people roll back to KSP 1.3.1 to play RO). So unless your "update and free content" is adding either new gameplay, or better performance, or better compatibility with updated hardware/operating systems, or significant quality of life improvements, then yeah I'd rather a bigger release every 12 months (with a couple of minor patch releases over the next month or two), than a release every 3 months that just adds churn and additional workload to the people trying to maintain complex mods. (Even if you are adding new gameplay, I doubt you will develop something that adds a significant new gameplay in 3 months, so just develop the new gameplay and whatever other new features/graphics you want, then push a new release when everything is ready, which is probably no more often than every 6 months anyway). Well let's talk about the previous releases. 1.2 Released 11th October, 2016. 1.2.1 Released 1st November, 2016. 1.2.2 Released 6th December, 2016. So 2 patch releases to stabilize the 1.2.x series over roughly a 2 month period. 1.3 Released 25th May, 2017. 1.3.1 Released 05th October, 2017. 1.3.1 was more a minor feature release than a bug fix release, so arguably 1.3 was stable at release, and new features were added 4 months later. Note this is 5 releases over almost exactly 12 months, 2 of which (1.2.1 and 1.2.2) were what I'll call bug-fix type releases. 1.3 followed about 7 months after 1.2, (and 5 months after the 1.2.2 patch). 1.4 Released 06th March, 2018. 1.4.1 Released 13th March, 2018. 1.4.2 Released 28th March, 2018. 1.4.3 Released 27th April, 2018. 1.4.4 Released 21th June, 2018. 1.4.5 Released 26th July, 2018. I'm going to argue that 1.4.0 was almost a public beta for the 1.4.1 "Making History" release that was scheduled for 1 week later. 1.4.2 was a bug fix release that was pushed 2 days before Easter. My personal opinion is that it was pushed without enough testing because Squad wanted us to give us an improved version to play with during Easter. I consider 1.4.3 to be a fairly stable release. So 3 or 4 patches (depending on whether you want to count the 1.4 release; personally I consider it a public beta rather than a release) to get a stable 1.4.x release over roughly 2 months, then a minor patch with new features + bug fixes for 1.4.4, and then another bug-fix release with 1.4.5. There are a few points I want to make here. Firstly both 1.2.x and 1.3.x were in better shape at release than 1.4.x. If I recall correctly, both had an opt-in public beta over a few weeks prior to release which meant many of the bugs were fixed before the official release. This meant that Squad had access to a lot more testers than it's internal QA/external testing group could provide, and could push bug-fixes quickly and get confirmation that they had indeed fixed the issues people had reported. During that test phase mod authors could easily say "I'm not supporting the beta, I'll update this mod after the official release." Secondly even with that testing it took 2 months to stabilise the 1.2.x series. What would have happened if there was a policy of a new release every 3 months in place in 2016? Would it have been possible to get something worthy of a new release out one month after 1.2.2? What about churn for mod authors with 3 releases over 3 months? (Please don't say that you would have just held most of the fixes for the release 3 months after 1.2. 1.4 demonstrated that it can take you several attempts to actually fix the bugs that people have reported). Thirdly 1.4.x looks like it was rushed out without enough testing. I think it would have benefited from a public beta like the 1.2 and 1.3 series. (I will admit that you probably wouldn't want to do a public beta for Making History, but you should have been able to do a public pre-release beta of 1.4.0, which would have let you deal with issues like the re-entry effects, jet engine sounds etc before the Making History release). I think the community would be better served by going back to public opt-in betas for new releases, and aiming for something like the 1.3 release. ie squash all the bugs you can before the official release, so that hopefully you don't need to do any patch releases. Then if you do need a patch release aim to get it out within a few weeks of the official release, then give mod developers and players 5+ months before the next release. Enough time that mod authors get to relax and play between updating their mods for new patches. Enough time that hopefully large mod packs like RO and RP-0 can hopefully get everything updated, tested and released. I'm not advocating for more releases, I'm advocating for less. Ideally one release every 6-12 months, with that release ideally being bug free enough that you don't need to do any patch releases. (If the release is buggy, then by all means push a patch release or two if necessary, but hopefully you can get it stable in a few weeks. Mod authors who don't want to do multiple build-test-release cycles can even wait a few weeks before updating especially if you are transparent and say, we plan to ship a patch release in the next couple of weeks if a patch is necessary). In my opinion maintainers of large complex mods need a larger breathing space between patches than 3 months. 6-12 months seems more reasonable to me than 3 months. (Consider a mod author who wants to update their large complex mod, then spend roughly 80-100 hours playing a campaign with it as a playtest before deciding it is ready to release. If they can can play an average of 8 hours a week, how many months is that playtest going to take)? Personally I would be more inclined to post in KerbalEdu offering to donate one or two full copies of the game to interested schools/libraries etc.

Personally I would much rather a regular new thread, than scattering the news over the week/social media. (I'm not saying that Squad shouldn't post news to social media, just that I'd rather check here once a week for news, especially since I don't use twitter or social media much. And I don't really want the news spread over a dozen forum threads per week either).

Consider complex mods that hook deep into KSP internals like FAR, Kopernicus, Sigma:Dimensions and Realistic Progression Zero. All of those probably need at least a recompile, followed by a significant amount of testing to verify things still work properly, even if they aren't affected by any API changes. (Many of these probably hook into KSP internals that aren't even mentioned in the API, so even if there are no official API changes, they might still be affected up other internal changes). So that means a rebuild and retest for every release, including each hotfix. That is potentially putting too much work on these mod developers to keep these mods up to date. Now if something like FAR isn't up to date, then mods that depend on it (eg RO) can't release an up to date version either. That means mods like Kopernicus need to potentially keep supporting older versions so that RO players can play on an older ksp version. This potentially further increases workload on the mod author. Consider if a bug is found in the 1.4.5 version of Kopernicus which also affects the 1.3.1 and 1.2.2 versions. Since FAR and RO aren't available for 1.4.x, the Kopernicus dev now has to choose whether to just fix, test and release a 1.4.5 version, or also fix, test and release a 1.3.1 version (still used by RO players) and possibly also the 1.2.2 version (which is still used by the latest official RP-0 release). I think doing a new release every 3 months is probably too often for some mod authors to keep up, especially if there are hotfix releases as well. That will further fragment the KSP community. I suggest dropping to a 6 monthly or even 12 month release cycle. (Assuming that the console version is going to get more updates, you could alternate PC release, then console release 3 or 6 months later, which would make it easier for the testing team to spend a couple of months focusing on testing the upcoming release). I also think you should go back to a public opt-in beta of 2-4 weeks. That will hopefully long enough that most new issues can be caught and fixed before the official release so that hot-fixes aren't needed. Mod authors can simply skip the beta versions. The vanilla game could even benefit from more experienced players suddenly playing without their normal mods for a few weeks.

A couple of comments. The ISRU landers I pictured above both had the landing legs at default spring and damper settings. The lower the gravity, the more important it is to come in slowly, if you want to prevent bouncing. This is especially important for a discrete time step physics simulation (which is what most games use). The low gravity also make it easier to control landing speed. eg on Gilly I can touch down at less than 0.1 m/s by holding down control, and tapping shift anytime my velocity exceeds 0.1 m/s. That is something that won't work on a higher gravity moon like the Mun. For people having trouble with landing on Gilly, what touchdown velocity are you using? (As I said earlier for Gilly I had problems at 1m/s, but only minor bounces at 0.1 m/s).

I think most FH core recoveries will be drone ship recoveries. I doubt that RTLS recovery of the core would be possible often enough to justify the cost of building and maintaining a third LZ.

No dV display will ever be 100% accurate for all possible craft configurations. eg just consider any apollo style mission. The dV calculator cannot know when in the mission the lander will separate from the command module, and hence it can't really calculate an accurate dV for the mission. It gets even worse if the player intends to refuel the lander and make multiple landings as part of the mission. But a simple dV estimate is still useful, and a player who understands how they intend to fly the mission, can use the per stage numbers to be sure that the ascent stage has enough dV to get to orbit, and same with the transfer and lander stages. Even a simple estimate of per stage dV is extremely useful. It does not need to be 100% accurate, a simple drop each stage when all engines are out of fuel is good enough to be useful. Label it "estimated vacuum dV", and calculate assuming vacuum. TWR would also be useful, but that is easier for someone with basic physics to estimate. (For stage one just add up sea-level thrust of all take-off engines and compare that to vessel mass (already available in the engineer's report) multiplied by 10).

Part of the problem is First.craft is a little too heavy for that landing gear, the rest is another case of not enough damping. Removing the fuel in the centre tank, and increasing the damper on all 3 wheels to max removes most of the oscillation for me. (There is still some, but it takes off and lands fine for me). Landed on Exploring Gilly without any problems if I just left the landing legs retracted. (As 5thHorseman says, you don't need landing gear on gilly. Indeed, provided you come in slowly, and have a wide enough base, you don't need landing gear anywhere in KSP). Landed on the landing legs after a lot of minor bounces. Not a craft damaging bug, but again better damping would be good.

113 ton ISRRU lander on Minmus and Gilly. (This design can lift off from the Mun's surface, rendezvous and transfer 1.5 orange tanks of fuel to another vessel, and still have enough fuel to land safely back on the Mun. 2 orange tanks worth of fuel on Minmus or Gilly). Landed on Minmus at about 1 m/s. The springs in the landing gear compressed, and then extended and managed to push it up about 1m before it settled back down. No problems on vessel load after switching to space centre. (it did have a slight problem that the drills were located a little low on the body, and lifted the vessel off the landing gear when deployed, so I slightly tweaked the Gilly lander). Landed on Gilly and the lander did rebound in a somewhat unrealistic manner. (It would have been fine in arcade game, which is probably a more common use case for Unity than something like KSP that want realistic physics). On the second attempt I landed fine at 0.1 m/s. Again no problem after switching back to the KSC. Now I never said that there were no problems with landing gear, but at least for me, they aren't a significant problem. (Better damping of landing gear would probably reduce rebound, and would be top of my list of possible improvements. No idea how easy that would be to implement) Small craft landing gear seem to have been much improved since 1.1, and so has the bumpy runway.