Search the Community

Where Do We Go Now? "Thank you for joining us with a CBS Special Report this evening. We bring you news from the Caucasus region of Southern Europe, the Armenian SSR, a member state of the Soviet Union, has declared its independence, officially forming the Republic of Armenia. There are unconfirmed reports of combat between the Soviet military and local militia, but this is denied by the Soviet government. This comes as protests in the Ukraine have ramped up and have spread to other member states. General Secretary Gorbachev has objected but has stated that he will not interfere with the will of the Armenian people. While he begins to push internal economic and political reforms within the Soviet state, citing them as necessary for the nation's survival." On the 16th of April, 1988, the Republic of Armenia is formed. The Soviet Union is facing a crisis, internal turmoil, and economic stagnation have driven Armenia to independence, and it seems as though Ukraine will follow suit eventually. Gorbachev is beginning a series of reforms to preserve the state, which may lead to a completely new Soviet Union in the coming years. But politics shmolotics, we're here for some space exploration. On that front, there is still a lot going on in the rest of 1988. For NASA, their plans have had a wrench thrown in them, as the Shuttle is now grounded at least until next year after the Enterprise incident. That mission has revealed some long-standing issues that NASA has otherwise ignored or tolerated. A Congressional hearing on February 10th has much of this come to the surface. Nobody is taking this lightly, it was a miracle that Challenger was supposed to launch 3 days later and was ready to fly. Had it not been, the crew would've had no chance of rescue. This is the first time NASA's faith in the Space Shuttle has been shaken. The Congressional hearing brings a heap of information against the Shuttle, with one particular bit being how long it has been since the Operations & Safety Manuals were updated, with the last minor revision in 1985, and the last new edition in 1982. Even that edition still contains much from the original 1977 manual, for Saturn-Shuttle. John Young has done his best to keep everyone in line, but he has found himself fighting a losing battle since around the end of '84. Those below him have run wild and although he has managed to keep the agency functioning well, a lot has slipped through the cracks. But this is a chance to right the ship and get it heading on the right path as it heads into a new decade. Seizing that chance, the Space Shuttle Future Committee is established, to determine the path forward for NASA's Space Shuttle. Different teams from both NASA and Rockwell are allowed to present their plans. But one stands out amongst the sea of pro and anti-Shuttle plans. A plan that will keep the Shuttle going, better than ever, and pave the way for a future successor down the line. This plan was originally outlined back in the January 1984 Space Shuttle Technical Report, from Dryden and Ames, but it has been presented to the committee now as a solution to the uncertain future of NASA's winged icon. It is called the Shuttle Improvement Program, or SIP. Although some of its ideas are a bit outlandish and unnecessary, it has many good solutions to the common problems the Shuttle faces. Mostly to do with the high cost of processing and maintaining it. But it also has many suggestions to improve operational safety and procedures. The committee eventually agrees to a revised version, with some removals and additions. The core components of it are changes to the TPS tiles for easier maintenance and access to the hardware behind them, and a new propellant for the OMS and RCS systems. That propellant is a mixture of Ethanol and HTP, affectionately named E-HTP. This change also means new APUs to finally rid the Shuttle of toxic hypergolic propellants. With all of these changes, Shuttle processing should become much cheaper and easier, as well as quicker. With the SIP team estimating 30-day turnarounds being possible. On top of the SIP program, NASA decided to extend the grounding of the Shuttle program until the autumn of 1989. This is to allow for a massive amount of maintenance and upgrade work to the Shuttles, which have fallen behind on upkeep due to the demanding flight rate. With only 4 Shuttles now in the fleet, and only 3 at the Cape, they need to stay in top-tier condition. They will all, besides Columbia, receive their first major round of upgrades during this extended fleet grounding. All of this means that Orpheus 4 has been delayed a whole year. But no worries, it gives more time to prepare all of the necessary hardware on the bright side. As well as giving NASA more time to review their operational safety and change things up. In June, a major step for the Magellan program is completed. The expansion of the Michoud Assembly Facility in Louisiana is completed. A new "second campus" of sorts that will be dedicated to LTV and Magellan MTV construction. Speaking of the Magellan MTV, its design has been finalized, and it has been publicly announced as the "Multi-Mission Exploration Transfer Vehicle" or MMETV. It is a single-core design, and it will use 7 of the same NTR motors used on the LTV Mk2. Optimized for carrying 50t to Mars and back, two will be used on a normal Magellan mission. NASA is committed to launching Magellan 1 in 1992, and it is to be foreseen if that target holds. Now let's talk a little about the aftermath of the Enterprise incident. In the weeks following, Enterprise was slowly recovered from the dry lakebed of Edwards Air Force Base, with major pieces being flown back in the Super Guppy. The recovery was made difficult due to a puncture in the OMS pods that had hydrazine leaking everywhere, but that was cleaned up, and the rest of the propellant drained, as it miraculously didn't explode. Nevertheless, after returning to the Cape, the components were laid out in one of the Shuttle maintenance hangars at the Cape for inspection and assessment. About 70% of Enterprise was able to be recovered, so NASA has not ruled out the potential for a reconstructed display at some point. But for now, Enterprise will be contributing to studying the Shuttle's structure under the conditions it faced, to help with SIP. On top of Enterprise, Spacelab was also damaged beyond repair, but both NASA and ESA have been talking about a brand new "Spacelab 2" of sorts for use between Skylab's de-orbit and the beginning of the successor station. That idea has been accelerated with the destruction of Spacelab. It will be similar to its predecessor, but with a flat top, to finally get rid of an emergency procedure issue the original always had. If the astronauts had to go out on EVA and manually close the payload bay doors, they would be stuck in there throughout re-entry with the original Spacelab, as they could not get back to the airlock. This will be fixed with Spacelab 2. With NASA sorting itself out for the rest of the year, the spotlight goes onto the Soviets, and wait... Japan?? That's right, Japan makes a thrilling announcement in September, that they are beginning work on their first domestic launch vehicle, moving away from licensed versions of Thor-Delta. Not much else is revealed, other than that they're starting work on it and they hope to have it ready around 1993. So not too thrilling, but certainly interesting. Otherwise, the spotlight is on the Soviets, as they take flight with Buran for the second time, with crew. That's right, with Igor Volk and Aleksandr Ivanchenko at the helm of the Soviet's shiny new Space Shuttle, they take flight on a 2-day solo mission, with a scientific payload in the back, to demonstrate manned operations. This mission takes flight on November 10th, 1988, the same day Orpheus 4 was planned to land on the Moon. Buran lands under a clear night sky at Baikonur 2 days later, with this mission again making headlines around the world. The Soviet Space Shuttle may have just arrived on the scene, but its making a name for itself even ahead of the Soviet propaganda surrounding it. With a second one now under construction, to be named Sarma, it looks as if the Soviets are committing to this fancy new spaceplane. The year wraps up with the 1988 Presidential elections, to replace Ronald Reagan, as his 2 terms are up. It comes down to his VP, George H.W. Bush, against the Democrat nominee Michael Dukakis. Bush wins in a landslide. As Reagan's VP, he championed both the Orpheus and Magellan programs since their inception and has stated throughout his campaigns his intention to continue the pro-space exploration policies of Reagan, and even expand on them. Another good administration for NASA, to be foreseen about the country. Рейс 3 в Полюс

It's been 4 months since release of early access and there is still one dominant question in the community unanswered and that is what went wrong. There are multiple interviews where the developers talk about how their focus is on rebuilding the game from the ground up to have it be performant and as buggyless as possible yet years after those interviews happened the game is the complete opposite. Note I am not saying that it's not getting better because so far the updates have been great but I and I think that the whole community would love to hear what went wrong with the development. Is it just a really hard thing to develop, was there a restart at some point, did coronavirus really affect development that much, just what happened? And another thing is the developers stated multiple times that they've played with future roadmap features and had a lot of fun and most of us wonder how that is possible since the game is still barely playable without those features?

I usually play without sound actually - Because I will not play very "active" - A lot of the time I will just be having the game running on "idle" while I talk with the kids, do other things etc. waiting between maneuvers. Also there was a point were I was listening to my own playlists while playing... and I just didn't turn it on again since x) I would advice this yes

Now, I don't want to start another parts revamp thread. We already have a few of these. What I want to talk about is the simplicity of the parts. Let's take take the HH as an example. Does this thing really have to look like this? The handle bars around the top and bottom dark rings are not usable anyway. And the gold foil needs to be covered to not look as if it was the only thing between the interior and the vacuum of space. Just keep in mind I'm not trying to make a rant of some sort. What I want to say is all the parts, including rocket, MK2 and MK3, should have as simplistic style as possible just so they can be put together and always look good. Right now it's not really possible. If you want to make a plane with hitchhikers as crew modules they will look out of place. To sum up: simplicity would be a nice way of solving the issue with all the parts not looking nice when put together. Simple cylinders with the white+grey+black (+orange accents from time to time) pattern would work best and the textures could be reused in many cases, thus making any part revamp easier to deal with.

THAT specific log. There're some more to compare with. https://github.com/net-lisias-ksp/KSP-Recall/issues/67 Do you want me to fill this thread with tons and tons of logs so your laziness can be satisfied? In a way or another, here: [WRN 17:47:49.979] [ScrapYard] Part mk1pod.v2:FFF7ABE0 has persistentId=4043188831 and it's being changed to 1590504603. The ClassID is 49675735 and the CraftId (cid) is 4294504548. [WRN 17:47:49.997] [ScrapYard] Part mk1pod.v2:FFF7ABE0 has persistentId=1808313221 and it's being changed to 1590504603. The ClassID is 49675735 and the CraftId (cid) is 4294504548. [WRN 17:48:41.567] [ScrapYard] Part mk1pod.v2:FFF7A77E has persistentId=33424378 and it's being changed to 1590504603. The ClassID is 49675735 and the CraftId (cid) is 4294504548. [WRN 17:48:41.580] [ScrapYard] Part mk1pod.v2:FFF7A77E has persistentId=151739214 and it's being changed to 1590504603. The ClassID is 49675735 and the CraftId (cid) is 4294504548. FOUR times the persistentID was changed, and no LogSpam was triggered, on the same log. Interesting, from my point of view it looks like you are cherry picking the pieces of logs I post, and completely ignoring that I posted the logs where the LogSpam happened, between a lot of logs where it didn't (and told about). Should I post them all here? Isn't easier to just check the logs I posted on the issue tracking, looking for a flaw on my Test Sessions, instead of wasting everybody times making assumptions with little to no evidence to support it? If my test sessions are flawed (it happens), pinpoint the source of the flaw. Talk is cheap, show me the code. Besides, as I had said and you conveniently ignored: There's no doubt that SYD is going to be changed. But without understanding why, you will just move the problem to another place and then someone will have to diagnose this problem again. Until I'm convinced that changing the persistentId is really the source of the problem with reproducible evidences, I will keep advocating for looking the problem somewhere else in the SYD's code (or not). AND AGAIN, I'M NOT ADVOCATING TO WORK AROUND IT SOMEWHERE ELSE, I want to understand what's happening and why.. And I was candidly ignoring a detail about this problem: exactly what happens when the LogSpam is triggered? What the real side effects to the game? Memory Leaks? Performance Issues? Savegame corruption? Until this moment, I was focusing on the symptom, because I agree we should be aware about what is happening and why. But if I create a Log filter on SYD and just omit the LogSpam from being written on the KSP.log (what would be a <piiiiii> move, to make it clear, and I do not condone it), exactly what would be the consequences? Because, you see, this may be another case of false alarm, in the same sense that damned ADDON BINDER ERROR that happens when you merely probe if an Assembly is loaded or not.

There's small implications in-game about lore and myth. I have ideas, ladies and gentlemen. I want to hear yours as well. I will include a snippet of my headcanon lore if anyone's interested though DM. It leans towards the explicit side(Greco-Roman religion+ a little bit of monotheistic flavour) so I wouldn't feel comfortable posting it directly to a thread. Let's just say it explains why females weren't introduced until the official version came out and provides insight into why things are the way they are. Dres? Who's that? Neidon, Sarnus? You're crazy.

Unfortunately, small talk is really the only thing I do when talking to new people, especially girls. I have social anxiety with large groups of people in a social gathering, and I usually just sit in a corner with a few people making awkward small talk until it's over, so small talk kind of sucks.

Firstly he'll likely not answer you. This is how things probably went down. T2 PD and IG knew the state of the game. T2 gives them all a paper on which is stated what they are allowed to tell us before and after launch. This is to ensure to not scare people of that the game is in an unfinished unplayable state. This is basic business. You as a customer has to look through all that marketing talk (The game is almost done.... only final touches left.... we have all so much fun with the game.....etc) and come to your own conclusions. My conclusion is .. i think there are passionate people behind the project, but thats not enough .... I lost all my faith in IG that they are able to accomplish what they had planned. I think everything that happened so far and let to this point that KSP2 has failed and this has a lot of reasons. Sure MAYBE we will get a final product sometime in 3-5 years, but this wasnt planned and it wont be anything we were promised over the last 3 years. Its sad. And everything i read here are excuses.

the fact that you constantly talk so much about QA and that is a process that hinders development and going further faster, you guys missed a whole lot of bugs introduced with this update. 10 minutes 10 bugs ... i just wanted to test the frame rate improvements, but i didnt get to it, cause it was too frustrating building a simple rocket. thanks for nothing

I doubt that any staff member of IG, Take Two or Private Devision will talk about their internal company politics and managment wisdom (or the obvious lack of it). At least if they want to keep their job and get another one in the industry in the future. Concerning the steam sale: I guess the publisher want to make some money. Since most people don't want to pay the normal price for the game in it's current state (I wouldn't either even if my old potato would be able to handle it) they propaby said "Hell, let's try to see how many people will buy this for that price so we have at least a little bit revenue out of this mess". I don't expect an official confirmation or denial for obvious reasons.

Yeah, I hear ya.. But's what's the point of all the talk if nothing really comes of it? What's that saying?... "Actions speak louder than words". The end result of all this "Moo with no Milk", just sets unrealistic expectations and when patch 15 comes out and doesn't address anything substantial/creates more issues, then people just get mad and the devs lose credibility. Just shut up and do the work.. Stop talking about it. We have to wait anyways, better to wait without being reminded how much everyone regrets being a part of the current KSP2 experience.. This is a joke.

Right... People should Stop listening to what the Devs are saying and just look at the results of their actions. 1) Pre Alpha EA release with many foundational problems to the most basic functionality of the software. 2) Two patches that marginally fixed some performance issues, but for the most part created even more foundational bugs. 3) Development (Coding) cadence slowed down to roughly half the rate. 4) Third patch came out and performance increased, with more added game breaking bugs. Either T2/IG want to turn this around but they can't because they don't have the skill, knowledge or the resources to do it.. Or, they don't care at this point, have decided to ride it out for as long as minimal revenue comes in, while at the same time cutting costs and laying off staff. The only reason they continue to communicate to the community, release poorly written patches and promise, is because the blind faith will support the limited revenue stream up to a certain point. The social media posts, forum posts, blogs, vlogs etc.. don't cost anything and can be done with a minimal staff. But the re-writing of broken code, the adding of content and the improvement of the product costs money and talented coders aren't cheap, especially the ones that are hired to sift through foreign code to fix a bunch of stuff they didn't write. I gave KSP2 the benefit of the doubt during the first few months, but I'm not blind and it's completely obvious that either they are, 1) Simply trying hard without the necessary resources, or, 2) Just pretending, so they can barely salvage a dying revenue stream. Rant #2 over.. Ps... I would have way more respect for the efforts of T2/IG if they just went completely silent and put their heads down and fixed this mess, to surface a year later with version 1.0 fully tested and vetted for release. The talk and BS is absolutely the fuel to my fire.

No lawyer that ever lived could talk their way around those laws.

I know this is on the no-no list, but since the devs are chatting about reviving it maybe we could offer ideas on how to implement it? If no mods feel free to lock. I think at present the devs are right to consider how life support becomes something fun, easy enough to understand, and scalable for new to veteran players, and not just an extra thing to accidentally go wrong. This especially becomes a concern when people have many multiple flights in progress, and warping one may exhaust resources on another. Worst case would be sending a probe out to Dres or Jool, and accidentally killing all your kerbals in SOI. To some degree this could be helped by an alarm clock, but even this would have to be somewhat sophisticated to be useful in order to let you know life support was running down in time for you to do anything about it. Even under decent conditions, you could end up in a very tedious place if for instance you had a crewed station around Kerbin and a flight en-route out Jool, and had to constantly break warp on your Jool ship to go back and resupply at your station. Sorting out these issues and balancing everything is no trivial task. My thinking is if it is going to work, it has to be both simple enough not to be tedious, and complex enough to still be challenging and fun. I also think it might be a good idea for the consequences of failure not to be quite so dire as to cause major rage if things go wrong. Updated 1/7/2016: So as this has become the default life support thread I'd like to open this beyond my personal musings on the topic to whomever might have fresh thoughts on how it could be included. We've discussed the topic on in this thread and others at length, the various pros and cons of TAC, USI-LS, Snacks, and what type of scheme might make sense make stock. To summarize our consensus as best I can, any stock life support system ought to: 1) Be a single, simple, LS resource that can be understood at a glance. 2) Be toggleble in the difficulty settings, and offer a less serious consequence for failure like going on strike or hibernating as well permadeath. 3) Offer a 3 to 30 day grace period, either in the form of 'hunger' as in USI-LS, or as a small standard stock for each pod to cover most Kerbin SOI missions. 4) Include a prerequisite mission pre-planner with mission time estimator and alarm clock functions so players could plan ahead and stay informed of each mission's LS status. The exact mechanics of extending and/or regenerating LS are more flexible, but the goal generally ought to be to make a system that is as simple as it can be while still asking players to consider trade-offs in terms of cost, weight, and logistics. Such a system could potentially add an important new layer to the game in which players need to think carefully about time as a cost, as well as adding the tension and urgency of surviving in a harsh environment. What follows are my own ideas on how such a system could be executed: Let's say we stuck to a single main resource: Life Support - Measured in "days" and slowly slides from green to red based on the number of kerbals on board. Different crew capsules could have different stocks, but let's assume each starts with 3 days worth for each available seat. There are however a few ways to extend this: 1) Life Support Tanks - Generally these are sized so that each kerbal consumes 4kg per day by default. Visually they could be designed to look like they hold air, water, and snacks. Tanks don't empty, they slide from green to red as they become waste. Life support/waste can be pumped from one tank to another, at which point players could easily jettison waste tanks if they desired. Small Life Support Tank - (.625m inline and spherical RCS size radial) - 0.125t - 160f - Supports 1 kerbal for 24 additional days (necessary for Minmus, but not Mun missions) Medium Life Support Tank - (1.25m inline and large RCS size radial) - 1.5t - 2400f - Supports 1 kerbal for 360d, or 3 kerbals for 120d etc. Large Life Support Tank - (2.5m Inline) - 7.4t - 12000f - Supports 1 kerbal for 1800d, or 3 kerbals for 600d, or 6 kerbals for 300d etc. 2) Scrubbers - These basically increase life support efficiency at the cost of weight and power. They will probably be essential for interplanetary missions. Because their reductions are across the board, the more kerbals using one the more cost effective it is. However, adding additional like scrubbers will not reduce consumption past the first. Waste-o-matic Jr. - (1.25m low-profile inline) - 0.6t - 1200f - Draws 0.5e/s - Kerbals on-board consume life support at 50% their normal rate (worth it for 1 Kerbal after 150d, and 3 kerbals after 50d) Waste-o-matic Sr. - (1.25m materials bay size unit) - 1.2t - 3200f - Draws 2e/s - Kerbals on-board consume life support at 25% their normal rate (worth it for 1 Kerbal after 300d, 3 Kerbals after 100d, and 6 Kerbals after 50d) 3) Greenhouses - Greenhouses use energy to convert waste into usable life support. When facing sunlight they provide some of their own power and are balanced based on average daily life support output, meaning these numbers would hold at Kerbin but more power would be needed farther from Kerbol. Greenhouses can be set to continual production, stand-down mode, or daylight auto-switching, but if left without power they become defunct and will no longer produce life support. Hydroponics Bay - (2.5m science lab size cylinder, rotates to face Kerbol) - 3t - 6000f - Draws 2e/s when not operating, and 6e/s when producing - Replenishes life support equal to 3 kerbal’s consumption every 6 hours while in operation (worth it for 3 kerbals after 300d in Kerbol or polar orbit, and 600d when not) Large Greenhouse - (3.75m dome) - 4.5t - 9000f - Draws 3e/s when not operating, and 9e/s when producing - Replenishes life support equal to 6 kerbals’ consumption. (Worth it for 6 kerbals after 275d Kerbol or polar orbit, and 550 when not) All of these factors should be calculated by the game, giving a single "Remaining Life Support" number in days both in the VAB and in the vessel resources bar in flight. This way you could play around in the VAB swapping out different parts and watch the days remaining rise and fall and aid your decision making. I think until you get to greenhouses things are intuitive enough for a new player to navigate them, while still offering some fun challenges to veterans who want to optimize off-world farming. 4) ISRU - There are a few different ways to handle this. I initially leaned toward greenhouses being indefinitely self-sufficient, so if a player set up a base or station with adequate greenhouses they could consider them safe and move on to other missions without worrying about resupply. Another simple option might to use something akin to USI-LS’s fertilizer, an intermediate resource consumed by greenhouses in order to operate. If this were the case I would advocate for this resource to be replenishable by converting ore or another harvestable resource directly into fertilizer via a large resource converter so there would be some simple method of living off the land. What also might be nice in the difficulty settings would be a softer consequence to failure than mass kerbal death. Kerbals who run out of life support could go into "hibernation" or “on strike” and wouldn't be able to steer or EVA until the vessel is resupplied. They might also lose some or all of their accumulated experience. Death could still be the consequence for harder difficulty settings. Any LS system to my mind really requires some way for players pre-plan and manage missions in flight. I actually think this could be rather simple, and really ought to be a component of the game with LS or without. All we really need is an Alarm Clock function in the Tracking Station into which maneuvers, transfers, intercepts and LS exhaustion dates would be listed, and a Mission Planner added to Mission control where a player might select "Starting Body" and "Target Body" and be supplied with: Time until next Transfer window: x [Set Alarm] Delta V to Orbit (100km): x Delta V to Transfer: x Time until Intercept: x [Set Alarm] Delta V to Capture (100km): x Delta V to Surface: x And repeat the process for the return journey. This could be staged into building upgrades or even expanded by completing gravoli scans of a given body. Then all a player would need to do is compare the dates from the Alarm clock with the life support rating in the VAB (with some padding) to know that they were properly equipped. Though this is wouldn't be strictly necessary for Life support, I thought a really simple, forgiving way of abstracting habitation for kerbals might be to include a secondary resource called “Happiness”. Happiness - Kerbals leave the launch-pad with 100% happiness and remain so for 25 days. After that, a lone kerbal will deplete at 1% per day, meaning they will reach zero and become “unhappy” in 100 days. For each additional kerbal on board, Happiness depletes at half the rate, meaning 2 kerbals will be happy for 200 days, 3 kerbals will be happy for 400 days, 4 kerbals 800 days etc. At the time of reaching a goal Experience pays out based on how happy they are at the time it was gathered. The whole experience system needs some major work, and obviously if this was part of it everything would have to be balanced around it to make interplanetary missions more rewarding. Aside from bringing extra kerbals, Happiness can be extended with the following modules (Percentages stack with multi-kerbal bonuses, but not with other module bonuses) Small Living Quarters - 2.5m cylinder - 2t - 4200F - draws 1e/s - Reduces happiness depletion for up to 3 kerbals by 75% Large Living Quarters: 3.75m cylinder - 5t - 6800F - draws 3 e/s - Reduces happiness depletion for up to 6 kerbals by 75% Inflatable Habitation Module - 2.5m inline toroid that inflates to approx 5m. - 7t - 11000F - draws 5e/s (while deployed) - Reduces happiness depletion for up to 12 kerbals by 75% Training Module - (inline Dodecahedron approx 3.75m) - 5.5t - 9500F - draws 2 e/s while dormant and 12 e/s while operating - Replenishes kerbals' Happiness up to 90% and allows level-up without returning to Kerbin So 3 kerbals with a small living quarters will arrive at Duna at 75% Happiness, and 6 Kerbals with 2 small or one large quarters will arrive at 97%. You could of course just bring a training module, but it would come at a steep cost. I guess this is a lot of modelling to request, but with about 12 new parts I think there's the bones of a real-feeling colonization platform. Even with a pretty simplified system like this there's a lot going on, and in practice I imagine keeping track of how much life support each vessel has left would still be a challenge. A big part of this would be showing the user when the vessel will deplete both in the tracking station and in map mode, so you can see early on a warning marker along its flight path where life support will exhaust. Also vehicles in the flight list would have a life-support bar showing how much remains and a red date of when it will exhaust. Update 3/28/2016: Here is my best estimate at one-way and round-trip durations for bodies in the Kerbol system, pretty valuable information for anyone thinking about scale/balance in regards to LS balance and scaling: Mun - One way: 1.25d, Round Trip: 2.5d Minmus - One way: 9.25d, Round Trip:18.5d Asteroid Missions - Round Trip, 25d - 215d Moho - One way: 110d, Round trip: 310d Eve - One way: 165d, Round trip: 890d Duna - One way: 300d, Round trip: 1170d Dres - One way: 555d, Round trip: 1290d Jool - One way: 1050d, Round trip: 2530d Eeloo - One way: 1560d, Round trip: 3320d Anyhoo this is my best crack at it. Love to hear others' ideas.

Personally, if it doesn't have an ascent autopilot and a landing autopilot, I'm probably not going to play much until a mod comes out that adds such. Or maybe I will play it, but I for sure will be intentionally over-designing my craft to compensate. I'm not a terrible pilot, but MechJeb is simply superior in every way to my skills, especially in the ascent autopilot part. Also, I've been playing since KSP 0.13.3 when they just added Minmus (no other planets) and you still only had like 20 parts in the game in total. KSP used to be an entirely different game, where you tried to get into space and who knows if you make it or not until you do or don't. There's plenty of remnants of that in modern-day KSP 1, and some of them need to be shown the door. Which one am I going to talk about today? This persistent community opinion of "do it yourself before you have the thing do it for you". IRL, not a single rocket has ever flown to orbit under manual control. They've all been on essentially MechJeb (of varying degrees of complexity). IRL, EVERYTHING except maybe the most final of the final parts of docking and landing are all 100% computer-controlled. Yes, there were a few times that the Space Shuttle was hand-flown thru reentry, just to prove it was possible. Apparently, RTLS of the Shuttle should it have a problem on ascent was also to be flown more or less manually. However (and I know this is going to be controversial), the Space Shuttle shouldn't have ever had wings for the job it was stated to do, that happened because the Air Force wanted to do "a stunt in space" and I do mean "stunt" as in movie stunt because it's about as practical. That stunt is to fly into a polar orbit (something the Shuttle never did in operation) directly into a rendezvous with a foreign spy satellite or something of that nature, put it in the cargo bay (somehow, nobody's ever shown me how they intended to secure the thing so it didn't throw off the CG of the orbiter, or how they'd measure the satellites mass so quickly), and then deorbit and land right close to where they launched from, ALL WITHIN A SINGLE ORBIT. You want a hollywood stunt, you look no further, that's the biggest stunt that's ever been proposed. Could the shuttle have theoretically done it? I won't say the chance is zero, but it's certainly not good odds, and IMO chances are high that they'd get shot down over Russia by ASAT weapons for trying. Did that make the shuttle's design incredibly tightly constrained to the point that it's what we have in museums today? Oh very much yes, we could have had something much more attainable and reliable and affordable if it hadn't had to pull this crazy "air force on drugs" stunt that nobody seems to have said "hey this is crazy, you can take your idea and pound sand" to. Just look at the Chrysler SERV. Much more modest spaceplane, with a fully recoverable first and 2nd stage, and it still has a pretty big payload bay so yes you can loft your own spy satellites with it. But going back to the talk of the autopilot. The fact that the shuttle did a few stunts doesn't invalidate the fact that literally every rocket to reach a stable orbit has done so fully under the automatic control of a computer of some sort, or at the very least a heading hold autopilot and an autopilot that tells the rocket to "pitch to this angle to the horizon at this time" with many data points, to emulate a gravity turn. Ascent autopilots don't have to be crazy complex to work well. Like I said, they can be as simple as a heading hold and a smooth or not-so-smooth transition from vertical flight to horizontal acceleration. But please, PLEASE, let me have an ascent and a landing autopilot sooner rather than later. I guess I could be asked to prove it 3 times, but I'm just going to build a rocket dedicated to unlocking that and then be done with that design forever, it's going to be unmanned if that's at all possible, and it's going to have very generous performance margins that I know I can do the mission in, unlike the vehicles I would be building WITH that automation, which I would be able to design with much tighter margins because even if the automation isn't as efficient as a human player pilot CAN be, what it DOES beat a human player pilot at (especially when that player is inexperienced), is consistency. Given the same design, same starting conditions, and the same target (either of an orbit or of a location on the surface), that automation will do exactly the same thing every time, because computers are deterministic machines, and if you feed one the same data, it always outputs the same result. Because of this deterministic nature, the autopilot could actually be USED TO TEACH the player the very things some people in this thread are saying need to be proven by the player before the automation would be unlocked. So, say you have just loaded up the game for the first time, and you've built a rocket you think can reach orbit. You click on the launch button, and instead of your rocket launching, the game saves the scene and loads something else. What you get presented with is a tutorial about gravity turns and how getting to orbit is more about going fast sideways than it is about gaining altitude. This would be followed by a demonstration scene loading with an example rocket, and this rocket (since the autopilot is deterministic) would perform the ascent and gravity turn as the tutorial's parameters told it to, thereby demonstrating with ACTUAL in-game gameplay about how to get to orbit, with the gameplay pausing at certain moments to point out what the autopilot is doing at certain points (such as "vertical ascent", "gravity turn", "Ap fine-tuning", "Coast to circularization", "circularization", and if needed, "fine tuning orbital plane and LAN/ArgPe" if the craft's design is slightly inefficient and perhaps biased to fly left better than right, for example). See, IMO the animated tutorials can be nice, but nothing beats showing the player what it should look like when things are going right. You could go even further and show what it looks like when certain common things go wrong, for instance "TWR too low early in ascent" (could even make reference to the famous "More boosters" line here), "boosters hit center core" (show player that the Sepratron is great for preventing that), "Upper stage TWR is too low" (burns up in the atmosphere before it can make orbit), or the most frequent one of all: "Rocket is not aerodynamically stable" (but make it super obvious by putting a lot of fins on the front and showing that it wants to fly backwards). You could even use this "guided simulation tutorial" kind of experience to build up a simulation in the vein of a "How to not go to space" video. IMO it would start out best with some (to seasoned players) "monstrosity" of a crazy looking rocket that "should be obvious that it never gets to space" (again, according to seasoned players), and as things go wrong (the first thing that should go wrong is "check yo staging"), the rocket's design changes according to the advice given, gradually evolving thru a series of "intentionally shown mistakes" in to a rocket that is finally perfectly capable of reaching orbit with enough fuel left to deorbit or maybe reach the Mun. EDIT: Why do it this way? Well it's simple. This game is INCREDIBLY complex, and if anyone's familiar with the concept of a "learning curve", KSP doesn't have one. KSP has a pretty much vertical "learning fortress wall" that is incredibly tall and is angled at like 89.999 degrees relative to horizontal. In other words, it's incredibly difficult to understand these things about spaceflight without having your hand held the whole way thru the process. Can that be annoying to people that know what they're doing? Of course, so an option to skip these tutorials should be present (and unlike the skip options in some video games, it should in actuality skip literally the whole tutorial, the only advice the player should be given should they hit the skip button is to point out where to find the button to start the tutorials again). But if they don't skip the tutorials, the player should be shown the concepts needed to get a rocket into orbit (or whatever the tutorial is trying to teach). A concerted effort needs to be made to break each concept up into small digestible bits of info that won't make the player's eyes glaze over, we're talking about complex science here (there's a good reason people compare complex things to being "like rocket science", and if KSP doesn't use rocket science I don't know what does) and "eyes glazing over combined with inability to process the information presented" is an entirely too common reaction to science subjects, so we need to be aware of that and work to prevent it from happening (somehow, not sure how, but it needs to happen if this game is going to be popular). :END EDIT

Can't talk about artificial gravity and not mention thrust gravity. KSP2 lets us have proper torch ships with persistent thrust and can be left alone to burn in background. Those need to be considered too. I'm quite sure that time will be quite short between that gameplay loop coming in and someone modding in an Epstein drive or the like.

Maybe - tbh I didn't know the forum before I started to bug report. I used to only engage casually with KSP1 - mostly just watching youtube videos of the game. How ever, I have been low key following the KSP2 since it was announced 3 years ago. But up until release I started to read what I could find about it and figured it would be like paying to Beta or Alpha test the game - I wanted to support the developers and bought it. It lived up to my expectations... and since release I have clocked 344h as of now - which i think is quite impressive giving im also juggling a full time study and being a father to 2 small children x) Maybe - but maybe its directed at the wrong place. Was it the devs that decided to launch now? was it the men in suits? - was it launched now because otherwise it would not get out? In my experience the people actually building the game are very passionate about their projects and want to release them in as good a state as possible. I dont know.. I've read quite a few posts from veteran KSP1 players who say that KSP1 also had a rocky start when it was in beta - sure you can talk about the price.. I guess its high - but its you who decide to buy or not. When I bought the game. I knew that it was buggy, had little to no features and was gonna be like beta testing the game - meaning its more about finding and reporting bugs and investigating bugs than playing. I knew the roadmap was without dates - I accepted that they didn't want to put dates because dates are seldom met any way (which is also my experience with previous early access games) and that was the foundation that I decided to do my purchase on.

As of now the multiplayer is planned to be added to the KSP 2. That's the one of a many ways how you can enrich the cooperative experience of players. But what about missions? Now we have weekly challenges posted by the KSP team. Why not to make this a game mechanic, where all the players can design the mission goals and share those with the community. I mean the missions like those from the KSP 1. The ability and the creativity of the developers team is enormous yet limited. Some dedicated players can set the scene and develop an unique scenario, nobody else could even imagine. I don't talk about the goal setting only. I think it might be cool to allow users spawn vehicles and kerbals in their scenarios (remember rescue missions from ksp 1).

They didn't. Generally, they don't go into any kind of detail on gameplay systems. They might show some parts, but don't talk about the systems behind them. Even on colonies we only have the very old information that there are some kind of population boom events and that milk runs will be automated, but no details on anything.

So I know its been a couple of years since any of the mod creators for this have replied, so I'm not too hopeful for an answer, but I am curious if we're supposed to be using "useRealisticMass=false" or not for this? I've tried multiple combinations and it feels like leaving the settings on "true" leads to fairly small rockets, while setting either of the options to false leads to comically oversized rockets (i.e. just to put a single Kerbal in orbit takes an absurdly large rocket and is nearly impossible with early tech). In searching through the thread I noticed at one point there was some talk about an update to rebalance things and remove the reliance on the setting, but looking at the patch notes there was only one update after that before it development stopped and its unclear if that rebalance happened in that update. So basically, I'm left with the following question: Have the configs been reworked such that we're just supposed to use the default RF settings, or are the current configs not rebalanced and we're supposed to set realistic mass to false and really work hard to engineer workable rockets? Thanks

Another great and transparent upnate Nate, but i do have some notes and concerns i'd like to share with the teams about this one: First, on 'wobbly' rockets. While i am really glad to see the teams view seems to mostly line up with what the majority of the community wants, i did want to point out this; To be quite frank: wobbly rockets should not be a thing, under virtually any circumstance. This sentiment of wobbly rockets being a core part of the KSP experience is in essence a glorification of a bug that got accepted by the community over time, born out of nostalgia. I want to remind the team that KSP2 can, and should, be its own distinct work. There's nothing wrong with wanting to keep features that made the original so beloved, but you really shouldn't be afraid to do away with features that just dont fit into the vision for KSP2. If you keep wobbly rockets now, you risk having to have to come back on that decission once builds start to exponentially increase in size, which will eventually happen as big features like colonies and interstellar get added. To illustrate, here is a space station i made consisting of 1K parts, with no struts attached. The results speak for themselves: In my personal view, a craft like this should not require 100's of struts eating up the partcount just to prevent it from folding in on itself. Autostrut isnt the answer either, and i agree that it should only be applied as a last-ditch effort. I believe any and all craft that have a part tree comprised of same-sized parts and appropriate adapters between different sized parts, even radially, should stay perfectly rigid in any situation. This also means that rotated or offset parts should have no effect on rigidity as long as they comply with the above rule. Same applies to docking ports. The only exceptions where wobbly-ness should be applied are crafts consisting of a stack of mismatched and differrently sized parts, or boosters under thrust that are connected to the main rocket using insufficiently large radial decouplers/ibeams/trusses. Concerning wings, you said: i agree with this, but i dont think wings themselves should be completely rigid. Long wings with a thin root thickness should have some flex to them, but it should be applied to the wing itself rather than its joint. My views on this are based on how rockets and aircrafts behave in reality; even the craziest of rocket designs usually dont have any flex to them as long as they are pressurised, even in extreme situations (like Starship doing flips going above mach 1 with 2 holes in its side recently). Jetliners and gliders with long wings on the other hand, do allow for some flex in their wings. i don't see any reason why this should be different in KSP2. While i understand there is a certain nostalgia about this whole topic, do not forget that it is ultimately still a bug that should be eradicated if you truly want to 'slay the kraken'. Secondly, i wanted to say a few words about the decision to reintroduce Biomes for Science Mode: as someone who has completed nearly all science experiments in all possible situations in KSP1, please implement this differently from the way KSP1 did. Biomes in and of itself are not a bad thing, but if you allow players to do each science experiment in every biome to gain science, it quickly becomes a chore rather than a joy. Having to biome hop from one bland, boring terrain to the next that looks virtually identical just to do the same experiments, both makes the process extremely boring and too easy. You are probably well aware of the fact that the tech tree in KSP1 was easily completable without ever leaving the Kerbin system in KSP1, which was a direct consequence of this issue. For starters, each biome should be unique and provide the player with a distinct feature of the celestial body. Good examples of this are Oceans, Beaches, Mountains, Craters and points of interest like the Mohole and Dres canyon. Bad examples of biomes are Lowlands, Midland, Highlands and patches of regular non-outstanding terrain/ocean that were just given a different name. A much better system for biomes would be a mix of microbiomes and larger visually/scientifically interresting biomes. For example: Ice Geysers, Volcanoes, Rock/Ice formations, Icebergs, Fissures, meteorite remains and similar small-scale surface features would make for great micro biomes. Examples of good 'mayor' biomes include (as mentioned before) Beaches, Oceans, Rivers, Craters/Crater rims, Regolith Patches, Mountains, Plateaus, Poles/Ice caps, Ancient River Deltas, Basaltic Plains/Mares, (Salt) Flats, Canyons/Cliffs, and all the one-of-a-kind point of interests. There is one big caveat with these though: all of them should only be able to provide science once. Naming different craters and having each be a different biome does not make a lot of sense in the context of science gain and quickly inflates the possible science gain from any given body. Entering a new location with the promise of a new biome, just to have it be one you've previsouly visited but with a different name, was one of the biggest dissapointsments and sources of tediousness with the KSP1 biome system. Another change from KSP1 that would tremendously increase the fun to be had in science mode is assigning each biome/situation with its own specific set of experiments instead of just allowing all of them. An example of this would be to have for example a Regolith Patch biome have experiments like 'regolith composition analysis', 'surface sampling' and 'test kinetic deformation', while a biome like the Crater could have 'Analyse Ice composition', 'measure light level' and 'Collect Meteorite Sample' as experiments. Some of these experiments could be made to randomly fail, forcing the player to move to a different closeby location where they have more luck (eg Ice might not be present in every crater). Some experiments could also be mutually exclusive; if already collected a meteorite sample from a 'Meteor Remains' microbiome, the experiment wouldn't be available in the Crater biome anymore. I understand that this would make for a very complex and intricate science system, but it would greatly improve the diversity of collecting science, balance science gains on any particular body, and break with the monoty of just performing the same experiments in the same situations over and over again. And implementing science in this manner also opens up what i think is a huge possibility: Abandoning science points entirely, and instead directly connecting branches of the tech tree doing experiments in specific situation. To illustrate this, lets look at a theorethical 'ground parts' tech branch in the tech tree; to unlock the first basic landing legs, you could simply have to recover a vessel after a flight on Kerbin. To unlock the next, you might have to either collect a surface sample or perform a rock analysis on a regolith patch, basaltic planes or salt flats biome biome on the Mun, Minmus. To unlock the next legs and/or wheels, you could either have to do the same thing but on a more difficult body to reach (like Ike or Gilly), perform a more advance experimenton the previous bodies, or collect Data from more biomes, and so on for the next level of tech in the branch. Having the tech tree work in this way adds a fun challenge while still alowing the player some freedom to choose how they go about aquiring a new part. It would also greatly compliment the new Mission system! Discovering different biomes was another one of KSP1s more lackluster aspects of science mode. This could very easily be remedied by having a family of parts that tell you which biomes ,are near, in what direction they are, and display the current biome on the HUD. these could be either different parts that each provide their own function, or one part for different tech levels that progressively adds more feauters. Another really handy feature to have would be a notification when the players enters a biome/situation where new science is available for the experiments that are present on the craft (could also be done with a dedicated part, or just be an option in the settings) Finally, a quick word on this sentence: The way KSP1 required you to bring back most experients, sometimes even multiple times, for full science gain was not only annoying but also not very realistic. For the sake of gameplay, most science experiments in KSP2 should be a 'do it once and you're done' kinda thing, where transmitting the experiment gives you all science immediately. The exception to this would be surface samples and/or colected rock fragments, which would have to be returned to either Kerbin or a Colony/Space Station with processing facilities. This would greatly encourage the usage of science probes, and add some much needed functionality to space stations (and not in the 'put your science here and we'll double it' way). If you really want to add science experiments that cant be completed instantly, having some experiments that require time to complete would be a much better hands-off way to do it. Collecting data on a planets upper atmosphere for low orbit for example could be an experiment that requires ~a month of in-game time or so to complete, and would require you to do nothing more than place the science experiment in low orbit, start it, and come back later once you get the notification that it's finished. Sorry for the ted talk, this got a bit out of hand! This is the first time i've shared so much feedback under a dev post, so i hope i've done so in a respectful and comprehensive way. I did this because i really feel strongly about these features in particular and believe i am somewhat qualified to share my opinion on them. I truly believe that if even some of this advice is taken to heart, it could lead to a better science mode especially than anyone could have ever expected. However you may choose to tackle these issues tho, i wish the teams the best of luck with them and can't wait to see what they come up with!!

yes ! It's : warning_24.png. Other mod having this issue for instance was the Notes mod, texture pathing name is ok as well, I had checked before, that's why this seemed weird to me. I compared it to the what the log complains about, and it's litteraly the same texture path to the letter... I'm actually running Windows 11 ! French ! Horrible haha And this is what it does indeed, texture turn purple, accompanied with a slight freeze due the error logging. I went around that by placing the toolbar at screen edge, and using the auto hide feature, meaning that the texture wouldn't be purple all the time, if the toolbar remains there all the time. Cf. Toolbar forum thread where I talk about it + also found a user by accident having the same issue : https://forum.kerbalspaceprogram.com/what-did-you-do-in-ksp1-today/comment=4293508