mcdjfp

The biggest issue I see are the images labeled Beta Capture, implying that the game was in a certain state when it clearly was not.

And how, exactly, does angering customers so that they buy fewer (or none) of your products in the future help shareholders?

I might be mistaken, but I suspect that the heating "model" works just fine if you stick to the expected heat shield/capsule/parachute configuration. Once you start getting fancy ( start trying to copy Space X, or anything else not anticipated by the programmers), and start trying to use non-heat shield high heat tolerant parts to shield more vulnerable parts, the less complex heating model starts showing undesired behaviors.

KSP 2 would be a perfectly acceptable early access game, but that is not what it was advertised to be. In particular I am referring to the Beta Capture images. KSP 2 is nowhere near that state, and that misrepresentation is the problem. Plus, the bugs (and other issues such as the "vessel destroyed" pop-up) get in the way of the fun

If I am not mistaken, one of the selling points of X Plane, at least for past versions, was the ability to create your own aircraft. It is a much more complex process, but I played around with a few simple designs in version 5 (I think they are on version 12 now)

He may have been Jool diving, but I regularly consider the placement of parts (and more than just occlusion) when designing my Mun/Minmus shuttles and tankers. I use aerobraking to save fuel on the leg to Kerbin. The deeper I can go without breaking stuff, the fewer passes I will need. My issue is the removal of a design constraint. Now only occluding low temperature parts will be necessary. And now that I think about it more, that might not even be necessary. If it is a simple have more cooling than the craft is receiving heating, then why not mount that temperature sensitive part where it will be exposed to reentry? I just need enough cooling somewhere on the vessel that it won't heat up.

A bit more aggressive than my fuel saving aerobraking returning from the Mun/Minmus using my passenger shuttle. Edit: Even being less aggressive I still take care to not overheat the wrong parts.

I quite frequently ended up with uneven heat distribution (careful, often muti-pass aerobraking as one example, high speed planes for another) when playing KSP 1 and I was hoping for improvements in this area, not a removal. The ability to place low temperature parts directly on the hottest part of the craft with no consequences feels like a bad lesson to teach. I was also hoping that some of this stuff could be properly moved into their own threads to better make use of modern multi-core CPUs. Seeing only 1 core under any kind of strain makes me sad.

That is how I interpret the situation based on the Developer Insight. I am just hoping I am wrong because this behavior completely fails the authentic test for me.

I have a quick question about this thermal system that isn't dealt with in the 4 examples. I have 2 parts attached to each other. Part A: Large, has a 1000 K temperature tolerance and produces a positive heat flux. Part B: Small, has a 500K temperate tolerance and is essentially static with no heat flux. Which of these 2 parts will blow up first?

The screen itself (and the very useful log information) should still exist, but what is the point of improving the explosions if they are hidden behind a giant pop up? I would have a small (even the solar panels in shadow notification is too big in my opinion) notification when anything breaks giving you the chance to open the screen if you want it. KSP 1 seemed to handle it fairly well. It only popped up (for me) following complete loss of vessel, and only after I attempted to give further commands to the non-existent craft. And it should be a "Vessel Status" screen not a "Mission Failure" screen because I might want to check it at other times. (What did that SRB knock off during staging?) Things would be far better if the game paused when the screen came up. Then we would have a chance to do something after closing the window, or at least the ability to watch the fireworks at not a 1/2 screen, view obscuring, dialog box.

I do want to add, that I feel that the potential is there in KSP 2 so long as it is given enough time to get there. Please, give it the time. Given the state of the game, I feel that the "Beta" screenshots were a bit misleading at best. That said, if I had known the true state, I still would have purchased KSP 2 for the potential that it has. In some ways I am glad it is in such an early state because it feels like the developers are going to have to relearn some of the lessons that the KSP 1 developers learned over the years. The sooner we, the players, get a chance to start demonstrating the some of the design/UI issues, the easier they will be to fix since they will not be as entrenched. I am worried about the poor multithreading performance I am seeing. I am not sure how many new features (over KSP 1) can be added without major gains in this area.

I am disappointed to hear this. With the current state of the game, maneuver node issues, SAS instability, craft loading in broken*, ...,the list goes on. There are too many fundamental problems right now that need fixing (barring any that are in temporary systems that are to be completely replaced in a future update) before any shift in focus to new features can be considered. I doubt the game at present is stable enough to enjoy any new features that are added that require more than 1 launch and 30 minutes to reach. * Loaded a craft at the launchpad. (already launched successfully several times trying to optimize flight path). A decoupler was a bit late in loading, but I didn't think anything of it until staging. When I staged, the decoupler exploded and the two stages it separated got stuck in each other completely ruining the launch.

I am not so sure. Most of my performance issues seem to be CPU related (poor multithreading) so I haven't been watching FPS counters much. What I did notice with patch 2 is that when launching the same rocket was much jerkier than it had been on patch 1. The clock ran at about the same (slightly slow rate), but it was far more noticeable to me visually. 4k 3090 Ti

The issue is not no life support versus no life support in the short term. The question is, was he speaking about what they are doing currently, or if he was speaking about their current plans for version 1.0 (or perhaps longer including DLCs) I would love to read the message from the point of view of current activities. That would be great. They would fix the current problems with the game (many), and once stable, life support would, sorry, might be one of the features added later in the road map. Until I read the second part of this AMA response, I had assumed this was the case and that life support was part of one of the later phases (probably colonies). Even if you read the AMA response this way, it does not promise that there would be life support in the future. (No life support in the short term might also be no life support ever) Unfortunately, the second part of the AMA response appears to indicate a focus on long term plans. Why does he move on to talk about modding, and that future improved moddability being the method to support the players who enjoyed KSP 1 life support mods? The response implied that they knew that there were people that liked life support, but that in their opinion the average player would be as happy without it ("the addition of life support won't enhance gameplay all that much for most players"). The only way I can read the AMA response is that there are no current plans to include life support in the base game. Note the use of the word current. I do not see it as a permanent decision at this point. Using the phase at present signals to me that there is a chance they could re-evaluate the decision in the future. Personally, I am concerned that if life support is not included in the 1.0 plans, that the developers will not want to wade into the mess of several competing life support mods, each with its own separate player base. Especially when they are not convinced at present it would "enhance gameplay." Mods are not an official part of a game, as a result, future features/optimizations may be implemented that clash badly with the mods functions, either on the surface, or more likely behind the scenes in the structure of the game's code.

The first part can be interpreted multiple ways. (1) It could be taken to mean that life support is not currently a high enough priority to work on, or (2) it could be taken to mean that life support is not currently in the plans. (Probably other interpretations as well, but these are the two I see). Since the second part of the response speaks about moddability and this moddability supporting the life support desiring part of the player base, the second interpretation (2) is the only one that makes sense to me.

I get no indication at all from the AMA response that life stock life support is currently anywhere is the plans for KSP 2. To me is says the current plan seems to be that once they add the modding tools (moddability is easier), modders will be able to add life support for those players who want it. The only positive I see in the response (and this comes from how I interpret the in the short term) is that it does appear to leave the door open to re-evaluating stock life support after 1.0 and they can evaluate the state of the community then. (A number of useful mods/mod features like Kerbal Alarm Clock did make it into KSP 1 eventually so there is a little hope there)

Right now the game needs to be stable. Considering the state that the game is in right now, I don't think anyone really expects life support or any other advanced features (science, resources, etc.) to be a short term focus You seem to be accusing people of ignoring the first part of the response. The problem with the AMA response is the second part of that quote. It very strongly gives the impression that they expect that modders will take care of providing life support for the people who want it "Obviously a lot of people have a lot of fun with life support mods in KSP1, once again we're hoping that once moddability is easier, that segment of the player base can be served in that way." The issue isn't when life support will be added. The issue is how it will be added (stock vs. modded).

The first thing that comes to mind is planning around time. Until you got late in the tech tree you would always have to be aware of how long a crewed mission would take. Currently we have dV for the payload, and for probes can a link be tracked back to Kerbin. Also, for longer missions one would probably want to send additional supplies (perhaps even pre-staged) in case something goes wrong and the crew needs to wait for a rescue/refueling craft to get home. And of course for the first crewed missions to other systems there would be the question of how to get a supply chain for life support working with what you took along (or sent ahead uncrewed).

I am really disappointed to here this. Life support was one of the three things I was really hoping for out of KSP 2. (the others being clouds, and built in support for multiple star systems). I assume that there must be complaints about CommNet being back too. How it is a part tax for unmanned probes. Too much of a complication for new players (even though it can be turned off). Life support is the tradeoff for crewed missions just like maintaining communications is the tradeoff for probes. While hoping for more, I expected something along the lines of power (to run the equipment) and supplies (whatever they chose to call them). And that short flights (under a day) probably wouldn't need anything beyond the capsule. I was looking forward to the challenge of preparing for the longer duration missions where the high-end life support parts unlocked through the tech tree would be needed (Along with a ship massive enough to support them). I don't want to send a Kerbel to the next solar system by simply jamming him/her into the smallest pod I have and tossing them there without any concern. I bet the ion engine and large Xenon tank already available would be enough for that. I would have infinite time to get around to retrieving them. That is a big enough problem already without going past Duna and Eve. And I really don't understand why both sides can't be served. There are already difficulty settings in the game. Easy could default to off, while hard would kill them if they ran out. Normal could sit somewhere in between, perhaps some sort of hibernation until resupplied (that could trigger some interesting rescue missions, especially with higher difficulties)

With the Dev version 466 it is not reporting the dV of R.A.P.I.E.R engines properly. Started in air breathing mode and switched over once the air got too thin. After leaving atmosphere MechJeb claimed 37 dV left. It completed the 550+dV circularization and still had enough in the tanks to deorbit as well. All the while reporting 0 dV left. This was a SSTO space plane.

The case is typically one of the first parts to display heating issues on my craft. I have problems with the case still causing drag even when in fairings/cargo bays. I destroyed a space plane with an off center MechJeb case in a cargo bay. (at about 1000 m/s the drag from the case became to strong to fight and spun the plane with predictable results). If it is generating drag, then could it be also be subject to direct heating (making indirect even worse) even when in bays/fairings?

I don't know about others, but my biggest concern was the very moment the drag went away, it was suddenly increased a couple of days later. With enough time to experiment, it seems acceptable (at least for Kerbin). I am quite happy to hear that they are still working on things though, and I think I will want for several major patches/updates before worrying again.

I have watched MechJeb fly craft nose first into the ground enough times that the first thing I check is the control from here. The plane flies fine at first, then as the speed increases the craft begins trying to rotate toward where the MechJeb unit is placed. Eventually the drag force (at least that is what it looks like to me) becomes so great that it overcomes all available control input (anywhere from Mach 1 to when the flames begin to appear depending on placement and craft design. In one of my tests the unit was facing backwards, and another time it was upside down, so I really doubt it would have flown at all if the MechJeb case was the control point. To clarify by after gravity turn I mean at the point that MechJeb reports between Mach 0.95 and 1.05. Any rocket that survives that might fight, but it stays in control. I wish to add that many of my rockets have been pulling slightly towards the south, which is where the MechJeb case tends to live on my rockets. (Use to deorbit top stage along with SAS of some type).

I have been using MechJeb ever sense I started with KSP. I like both the numbers and the ability to automate things that while fun the first ten times, get tedious after a point. I especially liked the advanced transfer tab of the maneuver planner. I do have one thing that I would like to report that I didn't see in a thread search. It is not really a bug, and it might be desired behavior. Unless the MechJeb case is mounted very near the centerline its drag will cause the plane (I have not checked rockets yet) to eventually spin out of control. Even placing the case within a cargo bay did not help, it needed to be very near the centerline or the plane would eventually lose control. I normally mount it near the centerline near the cockpit, but I wonder if it is contributing to rockets tumbling after the gravity turn.