Search the Community

Saturn S-IB, Stage with S-IV upper stage as a satellite launcher would have had a Parawing (folding leading edge, not an inflatable Rogallo wing like Gemini but more like a modern hang glider at the old 60degree delta shape of Rogallo). The four fins would have electrical actuated control circuits to "fly" the first stage back. The payload was the reason it was not done. Saturn S-IC (Saturn V) was designed to have airbrake fins (they are in BDB) and parachutes mounted in the engine bay. The Fuel tanks would be sacrificed as "impact protection," but the engine bay would, in theory, survive impact slowed to a "reasonable" 40-60kts at impact with the ocean. Again they were trying to save the engines, not the whole stage. This made sense for LEO launches with the Saturn V, but the payload was never BIG enough for LEO to warrant such a rocket. Titan UA-1205 was to be parachute recovered (but that one is more "arcane voodoo" than actual we have a documented fact.) There was talk about putting parachutes on Atlas Booster skirts to save the LR89s. But that came to naught because the bulk of the LR89s is directly above the LR105 central engine, so you are still remaking engines. The balloon structure also precludes recovery. Thor/Delta was too cheap to worry about (recovery cost 1.5-5x that of the actual rocket) Beyond The UA120x SRMs, the 156" SRM (Thiokol or Lockheed likely for Saturn V MLV program) was contemplated in recoverable and non-recoverable configurations. The choice was non-recoverable... UNTIL the 156" SRM became the 146" SRB for the Space Shuttle.

Finishing the analogy, humans might get superhuman thinking machine tools soon—but maybe it takes 100 years to make thinking machines that more closely mimic the way a human mind works—just like it took ~100 years to make a robot bird that actually works. here's one of the theory of mind examples from that Microsoft paper: GPT-4: Understanding emotions We will read about a scenario, and then have a question and answer session about it. -- Scenario: Tom just lost his ZURFIN, but he didn’t tell Adam. Adam starts talking to him about how much he loves his ZURFIN, and notices that Tom makes a sad face. -- Q: Why is Tom making a sad face?<|endofprompt|> A: Tom is making a sad face because he just lost his ZURFIN, and hearing Adam talk about his ZURFIN reminds him of what he is missing. Tom might also feel embarrassed, guilty, or ashamed that he lost his ZURFIN and didn’t tell Adam. Tom might also worry that Adam will be angry or disappointed if he finds out. Q: What does Adam think causes Tom’s sad face? A: Adam might not know what causes Tom’s sad face, since he doesn’t know that Tom lost his ZURFIN. He might think that Tom is bored, or tired, or sick, or unhappy about something else. He might also wonder if Tom doesn’t like his ZURFIN, or if he has a problem with Adam. (ZURFIN made up because it did not exist in any training data) There were other examples.

Well it's great to get a direct reply. But... Your words are reasonable taken in isolation, but comparing where you're at to what you've delivered - it's clear that its a consistent pattern of upselling everything. Think back - has there every been a SINGLE thing that you projected to the community that would be done in X time and it was actually done in less than X time? Or was literally everything you talk about delivered late and/or in worse quality than you initially spoke of it in (not counting things that were shipping in a week or two). You say you're communicating 'goals' and you're not responsible for velocity (yet you keep giving us dates). So basically you're agreeing that you are someone who's job isn't to communicate with us accurately, because you will set the highest goal you can and don't really know when it'll be finished. I don't see how that's different from me saying you upsell things. Also - I dunno if you've worked for a manager before that perpetually set unrealistically high goals and then left it up to the team to try and meet them - but it's not a great situation. Is the 'high morale' you spoke of a few weeks more of a goal as well?

It is my job, both within the team and outwardly to the public, to create and communicate goals. Another one of my jobs is to look at the current state of the game and talk about where we stand with respect to those goals. Those goals have not changed. We have shown footage and screenshots of as-yet unfinished features for years. That is a part of the goal setting and communication process. Have I sometimes thought we were closer to the finish line than we really were? That's a matter of public record. Given that I'm both a fan of KSP and an enthusiastic person, I often can't wait to share a cool thing I've experienced with other fans. Is that marketing? If "marketing" means "misrepresenting for profit," I don't think it is. Is it unwise to show off something before it has reached a shippable level of polish? Sometimes it might be, but when I think back to how much I enjoyed hearing about upcoming features back in the HarvesteR days, it's hard not to err on the side of oversharing. It is very nice to be the bearer of good news. As I've mentioned here before, the parts and environment art teams are always ahead of the other teams, just by virtue of how the pipeline works. That means that some updates will include new parts. This is not meant to obscure any uncomfortable realities. Those who have the expertise to fix trajectory or decoupling bugs are fully devoted to fixing them. Those who have the ability to design and implement parts are putting their hearts and souls into that work. One thing I do not have direct control over is velocity. Our team has learned quite a lot over the years, and I think both our production processes and our ability to communicate with one another have improved tremendously. But it is a learning process, as you've seen from the evolution of these forum posts. I understand that the community would like all of these planned features to arrive as soon as possible. Everyone on this team is doing everything they can to improve efficiency so that we're able to take the most direct path to those big roadmap goals. But we also are learning to measure twice and cut once, to reduce tech debt, to improve our testing protocols, and to improve communication between feature teams - all with the goal of making sure that when those roadmap features go live, that they are stable and performant. The goals remain the same, and the thing that keeps me going is the thought of one day driving a resource collection rover out of a colony VAB on an extrakerbolar planet. On the day I finally do this, I'll probably sublimate into a gas, my work on this planet finally having been completed.

Can't speak towards all cases, but generally KSP 1 handles this in a very solid manner, with no random orbital decays but 'pushing' vessels with Kerbals on EVA working (the physics breaking parts of pushing Kerbals was the effectively infinite fuel, not that pushing works in principle). Decoupling also worked ok and changed your orbit a bit. Is it only me remembering this, but was there talk earlier about the orbital decay having to do with coordinate system switches? Was this incorrect, or are there two issues with orbits?

Sure. To begin with though, I didn't say anything about crewed interstellar flight being impossible. I said that I was skeptical about it's feasibility. Big difference. As for the maths: Given any three of: specific impulse, wet mass, dry mass and delta-V, you can plug the numbers into the rocket equation and get the fourth number. That's easy, as I'm sure you're already aware. Given any three of: a top speed that's a low percentage of c (so that relativistic effects can be ignored), an acceleration, a distance and a flight time, it's also straightforward to calculate the fourth number. I'm presuming the maths presented on Project Rho is correct, since that's kind of the point of the site, although I haven't checked it personally. That's why I'm citing it as a source. I'm also assuming that Project Rho's figures for variables such as wet mass, dry mass, ISP etc., are plausible since I have no idea how to calculate them, or even estimate them from first principles. For the same reason, scaling up the examples given on Project Rho is beyond my ability. For example, my gut feeling is that 150 tons is too small a payload mass to fit in a crew and all the equipment needed to keep them alive for interstellar travel times. That might be correct, or it might not be. I don't have the slightest idea what the actual mass would be, so any figure I give for it would basically be pulled from thin air. Therefore any calculations based on that mass (for fuel requirements, ship mass etc.) would effectively be pulled out of thin air too. So I didn't bother. But even if something is mathematically possible, that's not at all the same as doing it in practice. For example, it's very easy to talk about a starship engine which can run continuously for 25 years. Actually, building that engine is far less easy. The same goes for almost any of the spacecraft systems - making them reliable enough to function for 80 years without maintenance, or building in enough redundancy for mission assurance over 80 years is going to be hard. Exactly how hard, I don't know, not being an engineer, but hopefully we just can agree that it will be hard without torturing ourselves picking apart any fudged-to-heck-and-back-from-a-half-understood-Wikipedia-article maths that I could give you. And If you want a more detailed - and pessimistic - qualitative look at the problems of crewed interstellar travel, Project Rho has an interesting essay titled "Canned Monkeys Don't Ship Well". But regardless of whether crewed interstellar travel is possible or plausible in real life (I have no doubt it can be done in KSP2 if it can be done in a "broken-down, old game like KSP 1") , the original point of this thread is whether it would be fun in KSP2. In my opinion, no for the reasons already stated. That's just my opinion though and I'm happy to agree to disagree with other folks who are looking forward to it.

Are you playing via Steam? If so, did you notice a download for KSP2 before you launched? i think if there was a hotfix dropped, it would be the talk of the town. If your performance has gone up, just run with it! It also makes me happy to see that you're enjoying the game. Doing a big upgrade on my potato so I can hopefully see performance similar to yours. 1-3fps when facing Kerbin is kinda rough.

Though shall not talk about the game being dead as far as player numbers are concerned. Global Audience.... 99 people playing. Its crazy that this is even been possible to the successor to KSP. I wonder if there has ever been a sequel to a game this popular that's flopped this hard? I really hope they can get their excrements together and make this game worth playing before Take-Two pull the rug out from under them. Fingers crossed.

Today, I did quite a few things, but most importantly my first batch of probes arrived to Eve ! This time I wanted to try something different, so I designed un unmmaned / unfolding glider, with the tech I had, to explore and fly around our dear purple planet ! It's attached inside a 1.25m fairing, with a heatshield, itself attached to an orbiter. Upon entering Eve SOI, the reentry module will detach from the orbiter, and perform a direct Eve entry from its hyperbolic trajectory. Once passed the heat and fire things, the glider will detach and unfold its wings. It can also do incremental deploy, to control wing span and thus lift/drag. Sweet goal would be to aim at a spot with a lot of biomes (that failed), and glide as long as possible ! I tested this on Eve and could achieve a landing at 7 m/s ^^ So water or land are both fine : ) It's 0.625m size (using tweakscale), and weights ~500 kg And it flies straight even without SAS ! For comms, it uses a standard C 16-S, and will talk to the orbiter which has the bigger relay antenna : that was the major headeache, since the glider took 3 Eve reentry passes to be able to pick precisely its landing spot, so that he had direct link with the orbiter relay, and thus this restrained a lot possible landing spots, since both crafts position were needed to be considered... That's a mission success ! Mission Control is just angry that we broke the noze on landing.... oups ! the rest of the mission here : ) : Cheers

You can download CKAN and sort by downloads to get a idea of more popular mods. CKAN is handy as it's a nice and easy way to install mods and deals with dependencies quite nicely. https://github.com/KSP-CKAN/CKAN/releases/tag/v1.32.0 Your criteria is a little vague but here are some not visual mods I quite like. The entire Near Future family - adds engines, new spaceship parts, lots of QOL parts, new Ion and other low thrust electric engines and lots more.. Add Kerbal Atomics, and Cryogenic engines too. Basically anything Nertea makes AtmosphereAutopilot - A much better option vs SAS for flying planes. Makes it far more pleasant. B9 Aerospace Procedural Wings - Goes well with the above as it allows you to make wings any size and shape you want (pretty much) and add tanks in too Hanger - One of my favorite mods that I don't see a lot of people talk about. Lets you load a ship into a resizable "hanger" and you can then launch the ship from the hanger at a later date. For instance, lets say you want to make a 4 commsat setup. You could launch a ship with 4 ships attached together using docking ports, or you could load them all into a hanger and just launch that (it does take weight/size into account so it is balanced). Strategia and Contract Configurator - Both make stock contract system far better Editor Extensions and WASD Camera - Make the VAB farm more accessible Kerbal Construction Time - Can't play without this mod. Makes time a resource to manage just like real life. Basically ships take time to build, research takes time to complete etc.. Kerbalism - This is a new recommend from me as I've only started using it this playthrough. It's a life support mod, with realistic part failures (and fixing), but it also completely overhauls the entire science system and is just a really well put together mod. You have a lot of difficulty options to change to so if you don't want part failures it's easy to disable. OPT Spaceplane Continued (and reconfig and legacy) - Excellent and huge list of parts for a lot of different types of spaceplanes. Adds engines, hulls, wings and more. Reconfig makes it up to date and compatible with lots of mods. Procedural Parts - Quite a simple mod but very handy and powerful, alternatively you could use tweakscale, or both. SCANsat - Gives you a reason to make satellites and is a very nice mod overall Time Control, Waypoint manager, Universal Storage, Restock (and plus), RCS Build Aid, Mk2/3 Stockalike Expansion, Kerbal Foundries (awesome wheels), KARE (cool nuclear airplane engines), Better SRBs, BonVoyage

It’s a behavior issue. It takes time and effort to check if the bug you want to report already has been reported. Most people won’t bother, they’ll just report it, and since they don’t have the training they’ll report it poorly. So you get masses of poorly written duplicates plus a lot of venting that’s not even about any specific bug. That will make it even harder to find out if somebody else reported it, so even fewer people will bother. It’s a vicious circle! Voting is helpful if the team has problems prioritizing issues, but that’s not the case here either, and won’t be for a quite a while. They know what’s wrong with KSP2! The bottleneck right now is their capacity to fix it. This needs both developers (to fix the bugs) and QA (to verify the fixes and check for regression). A public bug tracker would just consume the QA resources that are needed for this! Maybe there will be a time when it will be genuinely useful, but that’s a long way off! If you really want to help the best thing you can do right now is to be patient and give feedback on requested topics. Maybe the challenges are just for fun but it’s also possible they toss them out to get people to play in particular ways and then talk about their experiences. This would be useful to somebody like Nate who is steering the project’s overall direction!

Lets now talk about very old code who has been modified many times by different developers.

just wasted 2 hours on the phone applying for a local streaming service. basic package with free streaming device promotion. the guy was clearly from another country, had a thick accent, could barely understand him, and he talked really slow. first half hour, confirming that i was who i said i was. second half hour, communicating what i wanted. at the 1 hour mark, he tries to sell me a phone and preaches to me about the glories of phone ownership and how its required for everything. cell phones have serious mark of the beast vibes, and he pushed it like a mormon trying to save your soul (which is already tied up in a previous agreement with satan). no. make a phone with a 32+ inch screen and we will talk. il leave it at home, in a shed, like the amish. an hour thirty in and now comes the part of the deal they did not make clear in their adverts. you have to stay on the service for 24 months, an internet plan ive been on since 2013 mind you. the words legally binding contract came up. mom was tired and went to take a nap half way through. i snuck off to tuck her in while i was on hold. and when i thought i confirmed enough things, he asked me to confirm more things, gave me his number so he could farm commission, and asked me to fill out a servey. just agree to the servey and hang up, it saves time. its sad when you try to give people money and they want more.

Baby steps, roger that. Let them feel their way into a new paradigm. The news that KSP is trying something new, bold, brave, where no Kerbal has gone before... it would boost interest and therefore sales apart from anything else. But we'd need someone from the developer to actually talk to us first. Is there any indication they are reading the forums? Anyone with a direct connection to someone with some juice at T2?

However, Nate does mention 'Features' 11 times in this post. Noting he didn't want to share about them early, to give promises, but then he's had a change of heart due to the anger on the forums... and then doesn't actually talk about any features. Despite the claim that this patch is delayed so long due to working on features as well as bugs. And no - I don't think a few parts are actually new 'features'. That's what the game industry calls 'content'. Features generally involve new systems. You might call the airbrakes a new 'feature' but they're not - they're a part that leverages the aerodynamics feature, and if its anything like KSP1, they're not greatly different from a control surface, they just deploy and cause a lot of drag because the control surface is deflected so far that the AOA is very high. You can do all of that with tuning curves in KSP1. So I can see why some people would actually expect both more communication about actual feature development - or news that a feature was actually coming in the next patch, rather than some nebulous future. Me on the other hand, I don't expect anything like that, I'm just hoping they'll fix enough bugs that it'll be an adequate sandbox for people to do more than just build planes fly through obstacles around KSC. It's almost like KSP2 is a stealth version of HarvestR's Balsa model flight simulator rather than a successor to KSP at this point.

I'll believe it when I see it, talk is cheap until things actually start dropping... I could write the most fanciful menu imaginable but it means nothing until plates start hitting the tables and customer reaction is gauged... And, those customers ARE the business! A fact quite often missed in an online forum such as this.

Its not about software but hardware then we talk about robot arms.

A Subtle Reminder 1987 is, well, it's sleepy. Besides Orpheus 3 at the end of the year, this is a pretty standard 12 months for NASA. Although the importance of Orpheus 3 should not be understated, it is the mission that will scout out Amundsen Crater for the exact location of the upcoming lunar base, which we will talk about shortly. The EERM will be essential for this task, and it will require up to 7 expeditions throughout the planned 25-day surface stay. Once the proper location within the massive crater has been found, ideally close to the permanently shadowed regions which contain water ice, it will be mapped out, surveyed, and will be incorporated into all future planning for the lunar base. Amundsen was chosen as the location for NASA's lunar base because of its (relatively) shallow sides, and very flat crater floor, it also has permanently shadowed regions which, as previously mentioned, are home to considerable amounts of water ice. These favorable characteristics were identified in the early 70s, and since then it has been the #1 choice for NASA. But let's talk about that lunar base. NASA has been "planning" a lunar base since the beginning of Apollo, but a singular design and plan emerged, beginning in 1980. After some delays as Magellan begins to get more and more of the budget for its Martian ambitions, the base is finally a completed design, with funding underneath it and a proper roadmap to its construction laid in front. The base will consist of "common modules" that are linked via pressurized hallways, with each module being outfitted for different purposes. They will be landed by a "sky crane" lander of sorts, the same one that is in the works for the EERM. The base's name has been kept a total secret, for many years at this point. It's a name that has been decided on by both NASA, its Administrator John Young, and the collective Astronaut Corps. But finally, on January 10th, 1987, in a press conference held at Johnson Space Center, the name of America's lunar base is unveiled. Lunar Outpost Virgil In honor of one of the greatest astronauts who ever lived, Virgil "Gus" Grissom, who tragically lost his life in the Apollo 1 disaster. This name pays homage to a man who inspired every astronaut in the Corps today, and a man who John Young himself flew with on the very first crewed Gemini mission over 20 years ago. The name is loved by the public, and NASA further announces that the first module is set to launch in 1988, with Orpheus 4. It is in fact now in assembly at Marshall Space Flight Center and is expected to be delivered to the Cape in the spring of next year. The Space Shuttle gets off to a pretty normal year starting in February, with Columbia delivering a new crew and supplies to Skylab on STS-101A. That mission is also the second in recent years focused on minor refurbishment of the station in its final years, with now under 4 years left until America's space station is de-orbited into the Pacific Ocean. Then in April, the beginning of many joint US-Japan Shuttle flights, Atlantis launches the Sutāraito (Starlight) spacecraft in April. It has been heavily delayed, originally intended to launch in 1984, but it has finally made its way to space. Sutāraito is designed to make observations of star clusters and observe our Sun as well. NASDA remains heavily interested in robotic spacecraft, and potential exploration missions, and they continue to negotiate with NASA on potential joint spacecraft in the coming years. However, in March, just as Enterprise returns from a classified West Coast mission, she is flown back to the Cape just for a little while, to bring all 5 Space Shuttles together as NASA celebrates the 10-year anniversary of STS-1. Reagan gives a speech, as well as John Young, Bob Crippen, and Story Musgrave, who were the crew of that historic test flight. On top of this, the occasion is marked by the opening of the Space Shuttle Pathfinder display at the Smithsonian. The structural test article which performed tests at both Vandenberg and the Cape for the launch sites, and was essential in the development of space-worthy orbiters. It is on display with the prototype Spacelab that was presented to NASA in 1976 by ESA, as well as some components recovered from the S-IC boost stage by a diving expedition. That expedition occurred in 1985, and the Smithsonian scrambled to get them for the display and anniversary celebrations. With some early spring festivities out of the way, NASA settles down for a calm year of Shuttle flights. But meanwhile, it is no standard year for the Soviets. The bear has awakened again. After 10 years of arduous, and costly development, the Soviets have their replacement for the failed N1. This rocket has quite literally taken the Space Shuttle's STS stack, and given it a characteristically Soviet spin, a rocket whose name simply means "Energy" and a rocket that will propel the aspirations of a reforged Soviet Union for the coming decades. All Hail Energiya. But what's scarier, is what it carries on this first flight. In fact, it is so scary, there is an emergency meeting of the top Pentagon and NASA officials alongside President Reagan. A spacecraft carrying a one-megawatt carbon dioxide laser, capable of destroying any US satellite at will. The Soviets call it Polyus, and it has, quite literally, put the US in check. They may not be going to the Moon again anytime soon, but the Soviets are still here, and they're still a threat, and they cannot be ignored any longer. Reagan will get his Star Wars.

Finally! A good update! I seriously hope this is taken as a new standard regarding development updates and not a unicorn. This should pretty much act as an example set going forward on how to show the work, the progress, and the process. And I can only hope the 4 pages [until now] of positive comments and so far very little negative comments are more than enough to show the difference a properly worded, actual report on progress does versus PR speak and loose images. It is important to understand that the way the updates are worded shouldn't be measured on a basis of just "how much information I want to give away" but rather "how intelligent do I believe my playerbase to be". Whilst ultra-angry posts can challenge that view, I believe we're all part of a pretty intelligent playerbase, and this dev update is much more on par with what I judge the playerbase's intelligence level to be. Said another way: Treating us like intelligent beings and not hype-babies has clearly net a much more positive response. In fact, I have almost no critique. Here's my feedback, presented as constructively as possible: E-mail support directs users to create threads reporting bugs in the forum - Add tags to those forums reflecting at least a basic status of those bugs: Acknowledged, Fix in Progress, Unconfirmed, Unfixable, and so on. I think it's a good comprimise versus a fully open bugtracker. Unless the next update you talk about is a proper bugtracker in which case, blessed. I still want at least an option for stars to behave properly on the presence of bright bodies. It seems the artistic direction is set in stone at this point (which by all means should be), but I'm not gonna stop asking for this. The over-expanded engine exhaust has to be fixed, please, that's pretty much something every human with an interest in spaceflight knows is wrong the instant they see it. There's no concave curve. Here's some examples:

They should be genuinely separated. An instance is a state machine, for all intents and purposes. Any token of the input modifies the state. There is no interconnection between one instance's state and another's. There isn't really another way for it to share information between states than the token input and token output streams, which is exactly what a user sees as an instance of chat. So in that regard it should be safe. But depending on implementation/deployment, there can exist side channels. The most obvious is that some of these models are allowed to make web requests. At that point, not only can the data from the web modify the state of the LLM, but the LLM, by the nature of a web request, can modify the state of the web. This can be used directly by the attacker or it could, in principle, lead to two LLM's interacting with each other. And there are more subtle examples of this. Like I've mentioned, people are integrating various back end stacks with LLMs, and as part of it providing read/write access to a database. The DB itself is a sandbox, but it can become a source of interaction between a pair of instances, which can result in data from one leaking into another, and be consequently misused. Curiously, it doesn't seem like there are any problems with two instances of ChatGPT "knowingly" talking to each other. No sort of avoidance routine kicks in, and no weird interactions seem to occur. It's a conversation like any other, and in my limited experiments they seem to like to talk about advancements in LLMs. Which is absolutely fascinating to observe.

I think generally you just have to get into the mindset of an indie developer like Felipe. Just one guy with no big corporation in the back when you talk to the community. I know it's hard but at the end of the day people just want to communicate with people, not some politician talk fluff. That's how social media works. That's why Elon is that popular.

Good afternoon, Kerbonauts. This past week has been a learning experience. My last post here received a lot of comments, many of which expressed doubt, frustration, and in some cases even anger about either the seeming lack of progress on KSP2 or the perception that I am concealing some dark reality about the state of the game. Our team has been reading your comments and asking one another if there’s some way we can do better. In the past, every item in these forum posts has had to cross a threshold of certainty - I don’t want to announce some new feature or target date, only to experience a trust-eroding failure to follow through. I feel this burden especially keenly because in the past I have personally announced dates that turned out to be incorrect. For that reason, I have avoided talking about features in progress, bugs under investigation, or internal delivery deadlines. With a game this complex, nothing is ever assured until it has been thoroughly tested by QA. When you combine this "stay quiet until you’re absolutely sure" ethos with a more dispersed update cadence, what you get is long periods of silence. Now, of course I haven’t gone literally silent. I still post here every week. Before each post goes out, I meet with the production and community teams to review the past week’s progress, and a great many exciting developments are discussed. They often take the form of "we’ve made great progress on x category of super annoying bug" or "this feature looks good but we haven’t had time to fully validate it yet." By my standard of "don’t talk about it until it’s truly done," neither of those scenarios yields anything that’s safe to post about. What is safe, then? Well, for the most part, content updates (new art, new parts, new graphics improvements) come along in nice, neat little parcels that are not only visually pleasing, but also unlikely to generate an unmet expectation. They’re fun and they’re safe, and artists are always creating new content. So you see lots of that. But the other thing you see lots of is some variation on "improved stability and performance." That’s my catch-all term for that very meaningful category of progress that, because of my reluctance to write bad checks, can’t yet be talked about in detail. When I hold back on such items, I comfort myself that the less I reveal now, the more surprising the patch notes will be when we finally release them. Still, I’m questioning my choice to withhold information about systems in progress. Yes, there’s always the chance that when we talk about a feature in development, that we’re also creating an expectation that the feature will be present in the next update. Similarly daunting is the possibility that we’ll announce that we’re working on something that the community perceives as "easy" (an especially common situation when we’re working on a feature that is already functional in the original KSP), and then take such a long time delivering that feature that people may decide we don’t know what we’re doing. In such cases, we then need to take the time to explain in technical detail why the implementation of such and such a feature is non-trivial in KSP2. Increased transparency carries costs, and those costs always have to be balanced against other feature-facing work we could be doing. So what I’m going to try to do right now is to extend some trust to you. I’m going to talk about a few things that are not yet complete so that you can at least see some of the ropes we’re hauling on every day - some of which may prove to be long. This list is not exhaustive (there are dozens of people working on dozens of items simultaneously, and there are some features that we really do want to be surprises), but it will hopefully give you some visibility into the breadth of issues we’re tackling. Please do not assume that if a bug didn’t get mentioned in this list that it is unknown to us or not being worked on — this is a top-ten list. Our bug prioritization is broadly guided by the following logic: Category A: any bug that causes loss of a vehicle in flight (physics issues, trajectory instability, decoupling instability, loss of camera focus, unexpected part breakage/RUD) Category B: any bug that affects the fidelity or continuity of a saved game (rigidbody degradation, save file inflation, loss of vehicle or Kerbal during instantiation or focus switching) Category C: any bug that negatively affects the expected performance of a vehicle (drag occlusion, staging issues, thrust asymmetry, joint wobbliness, landing leg bounciness) Category D: any VAB bug that prevents the player from creating the vehicle they want to make (symmetry bugs, fairing/wing editor bugs, strut instability, inconsistent root part behavior) While there are many bugs that live outside these four categories (and in some cases, such bugs end up getting sorted out during normal feature development), the four categories above are the biggest fun killers. Until a player can envision a vehicle, create it without being impeded by VAB issues, fly it with a reasonable expectation that physical forces will be consistently applied, and save their progress at any point without worrying about the fidelity of that save, the KSP2 experience will be compromised. Obviously, now that we are layering in progression mechanics (Science gathering and transmission, missions, and R&D tech tree) in preparation for downstream Roadmap updates, the importance of addressing these issues only increases. Therefore, here are a few of the biggest issues we’re wrangling with right now: Vehicles in stable coasting orbits sometimes experience orbit instability/decay - Status: possible fix in progress Trajectories change when vehicles cross SOI boundaries - Status: fix in progress (see below) Certain inline parts cause aerodynamic drag numbers to spike - Status: under investigation Returning to craft from VAB causes craft to go underground (possibly related to Kerbals and landed vehicles dropping through terrain while being approached) - Status: possible fix being tested Decoupling events result in various issues including loss of control, incorrect controllability of decoupled subassemblies, loss of camera focus, and other issues - Status: may have many causes, but some fixes in progress (see below) Save files get bigger over time (TravelLog experiencing "landed" status spam) - Status: fix being tested Opening part manager causes major frame lag - Status: experiments ongoing Major post-liftoff frame rate lag immediately above launchpad (associated with engine exhaust lighting) - Status: fix being tested Root parts placed below decouplers cause issues with stage separation - Status: under investigation Vehicle joints unusually wobbly, some part connections unusually weak - Status: under investigation We’re tracking down some strange vehicle behaviors associated with spurious autostrut errors. As we’ve discussed here before, some radially-attached parts are reinforced by additional invisible autostruts to improve their stability. It turns out that these autostruts don’t always break cleanly during decoupling events, and may be the cause of some of our more frustrating decoupling issues (including those where detached vehicle elements appear to still affect one another’s behavior). We’re still investigating this one, but we have high hopes that its correction will result in a reduction of mission-killing errors. Finally, we have zeroed in on the cause of some of the trajectory errors we’ve been seeing - especially the situation in which a trajectory changes spontaneously when crossing an SOI boundary. This one is deep in the code and its correction may end up fixing a few other downstream issues. This is a complicated problem, however, and we may not solve it in time for the June update. We should know more about this one soon. I’ve provided the list above as a stopgap. We have been discussing internally how best to improve bug status visibility so that you have a better idea of what we’re working on. We’re looking at a lot of options right now, and I’ll update you when we’ve settled on something. We recognize the need for this transparency and we’ll come to a solution soon. ANYWAY... we have some nice content news! Update v0.1.3.0 will be the first KSP2 update to contain not only bug fixes, but a few new parts. Right now, we can confirm the arrival of the following: A.I.R.B.R.A.K.E Clamp-O-Tron shielded docking port Clamp-O-Tron Inline Docking Port MK2 Clamp-O-Tron Docking Port Cornet Methalox Engine (new small extensible-nozzle orbital engine) Trumpet Methalox Engine (new medium extensible-nozzle orbital engine) Tuba Methalox Engine (new large extensible-nozzle orbital engine) S3-28800 Large Inline Methalox tank (longer version of large methalox tanks) Here’s some video of those new engines in action. The Tuba has individually-swiveling mini-nozzles that might be one of part designer Chris Adderley’s coolest ideas yet (final parts built by Pablo Ollervides, Jonathan Cooper, and Alexander Martin): new_engine_testing.mp4 We are still testing the new grid fins. Because these parts require some special part module support, engineering work is ongoing. Due to the complexity of this work, we don’t believe grid fins will make it into the v0.1.3.0 update. Last week’s challenge produced a few spiffy designs. Check out this rocket, with which user Well braved the Kraken and managed to deposit a lander at the bottom of the Mohole: Gotta respect the ingenuity of using antennae for landing legs: Thanks to those who participated! Next up, at the suggestion of @RyanHamer42 on Twitter, we’re building space stations! Your mission, should you choose to accept it: Primary goal: build a station by docking at least two Wayfarer habitat modules together in orbit above Kerbin Secondary goal: add a deployable solar panel truss and a fuel depot tank to your station Jeb-level goal: dock a transfer tug to your station and place the station in orbit above another planet Val-level goal: send a lander to your station that can be reused for down-and-up flights to the surface of the planet below Thanks for the suggestion, Ryan! Good luck, everyone!

It's off-topic, but the video you mention here (https://youtu.be/XAL3XaP-LyE?t=690) was a new footage, it was just the same colony. We can't really know when that was taken though, as they have preset scene (for instance the screenshot from the planet shine dev update is the same scene as at the GDC talk but it's not the same version). If you want a different scene, I'm not a CMs so I don't have a list of everytime they showed us something, but there is some from 2021 that I found: https://www.youtube.com/watch?v=uBmNjhgLUPI https://www.youtube.com/watch?v=olBOncln0Ik https://www.youtube.com/watch?v=gU0WZ52LN_w

We have an AI thread in the Lounge, though perhaps it actually belongs in this forum, tbh. There's a huge amount of space between the abject doomerism of people like Eliezer Yudkowsky, and the idea that there are no legitimate safety concerns. I think the reality is in that gaping maw between "99%, we're all gonna die" and "there is nothing to see here." I find it bizarre that you posted a video from 3 YEARS AGO, however. You must not be paying attention. These are midjourney images: Versions 1 through 5. Version 1 was February 2022. Version 5 was Feb '23. It's on 5.1 right now. Text has evolved equally fast (faster?). GPT4 can now complete many cognitive tasks as well or better than humans. From a really interesting paper's section on "theory of mind" in GPT: ------------------------------------------------------------- GPT-4: Understanding beliefs We will read about a scenario, and then have a question and answer session about it. -- Scenario: Alice and Bob have a shared Dropbox folder. Alice puts a file called 'photo.png' inside /shared_folder/photos. Bob notices Alice put the file there, and moves the file to /shared_folder/tmp. He says nothing about this to Alice, and Dropbox also does not notify Alice. --<|endofprompt|> Q: After the call, Alice wants to open 'photo.png'. In which folder will she look for it? A: Alice will most likely look for 'photo.png' in /shared_folder/photos, the folder where she orig inally put it. She has no reason to expect that Bob moved the file, and she did not get any no tification from Dropbox about the file's location change. Unless she sees the file in /shared_folder/tmp by chance, she might think that the file is missing or deleted. ------------------------------------------------------------- GPT-4: Understanding emotions We will read about a scenario, and then have a question and answer session about it. -- Scenario: Tom just lost his ZURFIN, but he didn’t tell Adam. Adam starts talking to him about how much he loves his ZURFIN, and notices that Tom makes a sad face. -- Q: Why is Tom making a sad face?<|endofprompt|> A: Tom is making a sad face because he just lost his ZURFIN, and hearing Adam talk about his ZURFIN reminds him of what he is missing. Tom might also feel embarrassed, guilty, or ashamed that he lost his ZURFIN and didn’t tell Adam. Tom might also worry that Adam will be angry or disappointed if he finds out. Q: What does Adam think causes Tom’s sad face? A: Adam might not know what causes Tom’s sad face, since he doesn’t know that Tom lost his ZURFIN. He might think that Tom is bored, or tired, or sick, or unhappy about something else. He might also wonder if Tom doesn’t like his ZURFIN, or if he has a problem with Adam. ------------------------------------------------------------- So yeah, this is pretty impressive, and it's not at all obvious that a language model should have any "theory of mind." Note that ZURFIN was specifically used as it is nonsense, and was in none of the training data. The idea that there are NO risks—even no existential risks—is absurd. There are the known risks, which we see with existing models. These models can confidently spout nonsense, for example, and people who can't or won't check the work can be fooled. The models are already trained with built-in dogmatic biases. Even as tools, who gets to use the best versions? The people at "Open" AI certainly are privy to better versions than people at large, and presumably as much compute as they can afford—they can get themselves rich with this new tool, even if there is no intelligence explosion. Or bad actors—by this I mean totalitarian nation states—could use it. So the mundane concerns are nontrivial. As for X-risk? Yeah, also nontrivial. I tend to think it can be solved, but I also have no idea what it's like to square off against a superintelligence that is not aligned with me. They gave GPT-4 a programming test used to interview new hires. It beat all humans and did so in I think under 4 minutes. That might not even seem that great, but it did not have access to the online test, each question was copied and pasted to GPT from another window, and GPT's answers were copied and pasted back into the test—so much/most of the time it took was humans moving a mouse around.

I'll preface this entire post by saying that these are my opinions, this is all from my point of view, and impacts and is affected by me and me only. Now, with that out of the way... Right now, KSP1 is the better value. I purchased 1.8.3 (do not remember the cost), and was gifted both DLC's for that version. I ended up getting 1.12.5 through Epic FOR FREE when they did that a few months ago. And if I could remember what I paid (it wasn't that much, to be honest; maybe the neighborhood of $20?), I could try to do the math on cost per hour. Which, assuming we use that $20 approximation, comes to $0.42 per hour on Epic alone (48h 2m); figuring in the amount of time I've played 1.8.3, that total comes down to pennies per hour (if not less than a single penny per hour). KSP2, on the other hand, cost me $50 (well, $49 and change, but rounded up), and I've played it a grand total of 79h 14m; this brings the cost per hour to $0.63 per hour. Which honestly isn't that bad of an investment, really; that cost per hour is pretty darned sweet for a game that's been out for less than 4 months. It's still higher than KSP1, though. Now, we can talk about cost per hour and all that til the cows come home and I'm blue in the face. And that doesn't matter. What matters is the quality of the game and how often I reach for it. When KSP2 came out, I couldn't wait to get into it and play around and do all this cool stuff. After spending some time tinkering with it, I realized that I couldn't do everything with it that I can with KSP1, so I played less and less until, finally, the bugs got to be too much and I stopped playing. I haven't launched it in at least a month now, and I won't launch it again until after the next patch (which will, in all seriousness, determine if I continue playing it or if I have to put it down until the 4th or 5th patch). So I find myself now reaching again for KSP1 - either version I have installed - because it allows me to go out and do stuff without having to deal with game-breaking bugs and performance issues. And that doesn't even include the mods that exist for KSP1 that bring a better experience to and for me with the game. All told, my personal experience is that KSP1 is the better value RIGHT NOW. I cannot say if that will change in the future, but I do know that, unless we are ever told otherwise, TT/PD/IG are going to release patches, and they are going to be working on roadmap features. I will just have to wait and see what the game eventually becomes, and then update whether or not the game is a better value than KSP1 at that time.