Jacke

I have a lot of sympathy and agreement all around. I can't quite support the letter of the OP statement, but I support the spirit. And as for.... There's always the various equivalents of "I have altered the deal. Pray I don't alter it further." Because that isn't a contract in any jurisdiction. And even with a contract, you have to have the resources to deal with a dispute.

Don't quite know what to think about this. That the main KSP 2 devs immediately left Star Theory in December, especially Nate Simpson, of whom ShadowZone said "KSP 2 is HIS baby", speaks more to Star Theory being the problem. Could be one of these things that you can never learn enough about to properly judge yourself. One thing I just thought of. Why didn't Take 2 put out their story about this already? Some version of the truth almost always gets out. This isn't like ULTRA where the thousands involved kept to wartime loyalties and kept quiet for decades despite historians nibbling on the edges. EDIT: After reflection, especially because Take Two Interactive kept silent, I feel this is a wrong action by TTI who didn't care what happened and went far beyond ethical norms. This is a good post on that.

Add the command line option " -nyan-nyan" and have fun every day of the year. And it's functional! Shows you how smoothly KSP is running.

That problem was solved in the 1950s. It's why the oxidizer became IWFNA and IRFNA. N204 has this problem even less. AFAIK, the fuels (Hydrazine, UDMH, 50-50, MMH) never had tank corrosion issues. How to formulate them, how to tank and transfer them are solved problems. They really became storable. As in years. Toxic, hell yes. Tricky to handle, all propellants are one way or another.

It's also one more way to destroy the crew. There's a lot of technical questions that would need to be solved to even make any Orion drive work. One that likely not to be solved is how the repeated short sharp surges would damage the bodies of the crew and kill them, likely within a day due to the damage to blood vessels, kidneys, lungs, etc. Near future propulsion systems are interesting, but I hope they stick to having stuff that has a bit more solid ground to stand on, like various plasma drives up to potential fusion drives. And put more work into getting the basics of KSP 2 right.

The problem with career and funds wasn't early access. The problem was lack of attention to fixing it (too little too late). The aero system was dramatically changed towards the end of early access. As flawed as it still is, it does shows it's possible. Development still needs to be sufficient, paced, and appropriately focused. A unified creative vision is vital. But that doesn't preclude having feedback and providing closed/open alpha/betas/early access with enough time before release to incorporate changes. And this isn't a brand new project, it's a successor game to KSP, where connecting with the existing community of players and modders is vital to KSP 2's success. The solution isn't putting it all behind close doors, because that's a common mode of game development right now and it has a wide range of success, from very good to abject failure. In another topic, I had a post that goes into detail how to make opening the development of KSP 2 work.

The best way to think about the navball is that it's actually looking at the inside of a bowl. This translates best to the sky around the craft. Vertical space is precious, especially in the middle of the screen. If the Kerbal portraits are put there, they'd better be easily movable in the UI to some place else. Rest of your comment is awesome. However.... We can't assume the UI will change before release if we're not told it's still being worked upon. Nor get a true feel for its nature. Especially, as you do bring up, when we don't have a test article to *use*. The only thing that gives me true hope is that a delay to "Fall 2021" is much more than what I would think COVID-19 would impose. That means the KSP 2 dev team has identified that there's a lot more work to be done and have set the release date to accommodate that. But I think they need to communicate with us more. And we do need access to the game while some changes can still be done. Let's look at KSP as an example: https://wiki.kerbalspaceprogram.com/wiki/Version_history From the initial release of 0.7.3 to just before 1.0, 48 versions of KSP were released over about 4 years. 20 major versions. Although some of those point releases look like significant changes as well. I started out with 0.23. Just in my experience, KSP changed radically going to 1.0. And that change has continued to a degree. And that change was done with growing feedback from the KSP modder and player community. Sure, not at times the best quality feedback. And not at times the best use of that feedback, especially when it was good. But KSP became a better game that the vision of its initial developers partly due to it being a game actively used and reported on by its community. No one wants another 4-year 48-version 20-major-version early access before we see a polished KSP 2. But we want more information than we're getting now. And KSP 2 needs community feedback. A closed alpha/beta. An open alpha/beta. Maybe even a bit of early access. KSP 2 does not want to be an XCOM Chimera Squad. Good enough game. But also gone like a Spring snowfall.

I remember reading about that as well. I couldn't recall the formulas, but I thought for the case of KSP it wouldn't drive the range of efficient high enough to include delta-V as high as 3000m/s. But in retrospect, I think the amount of decline going to 3000m/s wouldn't be a whole lot. KSP parts are worse than the real world for having a larger fixed (engine and separation) and relative (tankage) dry mass for the amount of propellants in a stage. The first increasing usually leads to wanting greater delta-V per stage, the later increasing wanting more stages. So, depending on the vagaries of KSP parts' performances, masses, and funds costs (which as far as I know are still weird in many places), you're going to find different best designs. But for the usual size of early career 1.25m-part stages, it's going to mostly be 2 or 3-stage launch vehicles, including the mission stage of the payload. Lower payload will really push the 2-stage designs. Higher payload, due to the greater dry mass of tankage, will likely be better as 3-stage designs. It would need a massive launch vehicle to make a 4-stage design worth it.

Then please show examples. I don't think it quite applies. I've mostly made 2-stage launch vehicles to LKO, depending on the payload with the 2nd stage circularizing or the payload mission stage doing it, sometimes split between them. The division of delta-V between those 2 stages has varied widely. For rare light payloads, the 2nd stage is also the mission stage.

Your reasoning to support this?

Receives GABA. Inserts 1 Euro coin.

Obligatory XKCD https://www.explainxkcd.com/wiki/index.php/1172:_Workflow

Make a destination folder outside of tight Windows control. I suggest for the latest KSP version C:/Prog/KSP/v1.9.1/ if you don't have any of the expansion DLC, and if you do, then C:/Prog/KSP/v1.9.1E/ To that folder, copy the contents of the folder containing KSP under Steam, located at <Steam dir>/SteamApps/common/Kerbal Space Program/ In the new folder, copy the executable KSP_x64.exe and in a convenient location, paste a shortcut. Use it to launch KSP Alternate to the last, install CKAN and tell it about that copy of KSP. CKAN won't touch any mods you've installed manually, but is an easier way to manage mods. This can be made more detailed. I normally leave KSP uninstalled and its Steam directory empty. When a new version comes out, I install it first without expansion DLCs, then with. Each of them I copy as a prinstine template to a new directory, then copy again to a location to mod with CKAN and manually if needed. This way I can have multiple installs; example for KSP 1.7.3, I had a copy for testing, a copy for unspecific play, and a third for the Caveman challenge.

I would hope that devs are aware of the critical factor of almost all feedback: it's not a representative (ie. random as well as large enough) sample of the player population, so that feedback can differ greatly from the whole player base in many ways (overly positive, overly negative, overly divisive, too quiet, too much interest divergence, etc.). But if there's no effective feedback, ie. giving us a real alpha/beta release with enough time and resources to listen to any feedback and take measures considering it, it's all on them. The game may have a unified creative vision, which is vital, but the developer team is effectively just another non-representative sample from the player base. What they think of KSP 2 can be too far from what the players will think of the game. The way around this conundrum is to honestly and critically examine all feedback, from both the developers themselves and the player base who respond--like we are now--to KSP 2 information as well as from playing with alpha/beta releases. As for player feedback, we've not been able to *use* the current UI, versus seeing one still photo of it. The proof of the pudding is in the making--and the eating. To be sure we have to play with KSP 2. But if we're not given a real alpha/beta, we won't be able to play with it until it's released. At which point so many features will be fixed and virtually unchangeable. So if we don't get that alpha/beta access, all we can do is the best we can with the information that's there. And in this case, a lot of us still have concerns, both from what's been released and what hasn't been released. That can only be solved with more information on KSP 2. And hopefully, a real external alpha/beta feedback series.

Poor Dres, never gets any respect. Not as distant as Eeloo. Not as tricky as Moho. How about points for returning the Kerbal(s) to Kerbin? Say again the largest amount of points from one object plus 10 per second and later bodies achieved? And points for the Kerbal(s) surviving the last landing? You've added 5 for bringing along more than one free-range Kerbals. So, how about 2 points for surviving the last landing? Guess we should get a clarification. You get points for a body even if achieved by lithobraking?

...or the points for Jool. Should be less than the points for Kerbol. It's a shame, I don't think it's possible to get both on the same Kerbal.

The link contains troubleshooting guidance; you don't report issues there. You still need to post more details in a Duna Direct topic.

The last number in a full KSP version quad is a number that increments throughout all KSP versions, shown either as 4 or 5 digits. Here's the last few. 2020 Feb 27 Thu KSP 1.9.1.02788 2020 Feb 12 Wed KSP 1.9.0.02781 2019 Oct 29 Tue KSP 1.8.1.02694 2019 Oct 16 Wed KSP 1.8.0.02686 2019 Jul 10 Wed KSP 1.7.3.02594 I assume it's an Squad internal version number. So 02782 through 02787 were used to develop KSP 1.9.1, with 02788 being the release.

I missed the comment on the Swivel. As @Spricigo pointed out, it's not an only-near-vacuum engine. It's intended for larger rockets using many 1.25m engines, either in the 2nd stage possible with very large designs (especially many 1.25m tanks clustered or Making History engine plates on larger tanks) or the sustainer stage of a rocket with solid or liquid fueled strap-on boosters.

You didn't list the points for Kerbol.

This is the development topic for Duna Direct. The release topic where you should report issues is here. I'm not the mod author, but I'll try to help here. The minimum you need to do when you have issues and want help is in the troubleshooting post at the link in my signature. That page also describes how to find the log file you need to upload to a file sharing site, then share the link in the post on the mod's topic. This provides the whole log file, which is necessary and full of details that can help when tracking down issues. You should also test out the minimum series of steps to reproduce the problem and add them in the report in your post. For various problems, you'll also have to add in other details and upload other files when that's appropriate to the issue. In this case, you need to say which engines, as the mod has more than one. Providing a .craft file of an example spacecraft with the issue would help too. The failure of sound could be caused by an issue with just Duna Direct itself, as the latest release was for KSP 1.8.1 and no one so far has report that it functions correctly under KSP 1.9.1. If it does, then it could be a mod installation error or an interaction between some of the mods. Which is why you have to provide the log file, which lists all the mods in your install, their versions, warnings and errors, as well as so much more.

We're sorry, we can't connect that call at this time. @Superfluous J, are you there?

Thinking back to my memory of astronautics texts from the 1960's as well as other things I've picked up, there's a few rules of thumb: Optimized staging tends to having the same delta-V per stage. All this interacts with choosing the ascent profile for best performance. Each stage needs enough angular authority throughout the stage to keep the rocket guiding. The 1st stage needs a TWR of about 1.25 or better. Later stages can get away with a TWR of 1 or even a bit less. But lower TWR can mean the burn time gets too long and causes trajectory issues like getting too near or passing apoapsis. Adding stages adds fixed mass for engines and separation that will offset any gain from adding a stage to the point of being worse. Adding mass to stages has greater impact on overall performance the higher the stage it's added to, offsetting any gain. What this means is for smaller KSP rockets that orbit a payload (thus about 3400m/s total delta V), especially those from the 1.25m parts, the advantages of making a 3-stage launch vehicle are often offset by other factors. Even suboptimal (in the sense of #1) 2-stage LVs can have better performance because of the effects of #6 to #8. Because of this, for smaller LKO launch vehicles, more often than not, I've made them 2-stage, usually having the payload's mission stage complete orbit circularization.

What's this about "trampoline" ? I'm assuming it's not this. I'm no great fan of Elon and he has said some very stupid things in the past. He has gotten better at not screwing up, so I'll give him the benefit of the doubt until I hear otherwise. Sigh, always "The Fruit of the Month". Did you ever stop to think that big Kerbal helmet might be functional? How do you think they fix things in space and usually so quickly? They beat their heads on it. Huge helmet => frustrating part => problem solved!

Receives a Nosy. Inserts a dime.