whatsEJstandfor

I don't know if I've seen the same text before but, like Matt, I have had my dV readout disappear, as if the game thinks there's no longer a fuel tank is attached, and then been unable to create maneuver plans, because of said perceived lack of a fuel tank.

It's definitely cathartic watching someone else run into the same myriad bugs that I get in a simple Apollo-style mission. Not that I didn't think I was alone in them, but it's genuinely nice to just have all of these bugs documented in one single gameplay session. Little things, like not being able to select a target until quickloading, or dV readouts being inaccurate (again until quickloading), etc. Stuff that, in their own rights, would be annoying but not game-breaking but, when all combined, lead to a profoundly frustrating experience. When KSP2 gets to a point where every bug in this video is fixed, I think that's when I'll be able to stop fighting the game and get to finally just enjoy it.

Based on the bug reports, seems to just be 6700 and 6800 cards, is that right?

At the moment, I think this is my personal choice for single most important bug, and I feel for all of you in trying to squash it! When it finally gets there, this will definitely be the one I'm most interested in seeing a deep-dive on since it sounds like the troubleshooting process has been the most complex.

I love seeing the thought process behind design but, and I mean no disrespect, it's not like we have any shortage of "here's the stuff we're planning"-type posts. The issue that people on these forums tend to have is that they aren't seeing the results from all the design talk. I think what would be most cathartic at the moment is hearing from engineers, so we can see exactly how these designs are being implemented. I think that ties into why people are upset over not seeing gameplay footage and whatnot. Like, it's all well and good to see mock-ups explaining a design, but we've had so much of that since release while seeing the actual nuts and bolts has been very scarce. I hope you (though, more specifically, whoever the people are who decide what information is released) take this as some more constructive criticism. The game has been in development for, let's just say, a while. It's been released in some form for almost 5 months. So I just don't have a lot of interest in more posts about art or design. That stuff is all fun but I've also seen creative teams, startups, Kickstarters, etc, spend so much time on pre-pro and planning but, when it comes time for rubber to hit road, nobody knows what to do next. In this case, I guess that'd be the engineers, so that's what I've been craving lately.

Thirded. As it stands, doing asparagus staging is highly manual (needing to pause when fuel in one set of radial engines runs out, then finding the correct decouplers, then decoupling them, then unpausing).

Thank you for continuing to show that these bugs are high-priority! With the SOI trajectory bug fixed, the decaying orbit is definitely my biggest bane and I'm so glad that a fix is in progress; I'd love to see a dev update about that one.

I think @Dakota has warned to not take this to be a sign that they're going to start dropping hotfixes on the reg. As I understand it, these were only released because the bugs they addressed were egregious and game-breaking; not because IG has, in general, moved away from the large and infrequent patches.

This all sounds perfectly reasonable to me; seconded!

I would add incorrect dV calculations (and the knock-on effect it has on maneuver planning) to that list, but, def, this hotfix is big time massive good news

Also, to clarify, I think @Scarecrow71 means "engineers", as in, the people digging deep into the code to make the clockwork run; Dakota has previously said that everyone at IG are considered devs, so I wanted to preempt that one.

Good call; I didn't realize we weren't talking about the VAB. In-flight, idk of a way to focus the camera not on the center of mass

It might be in the control settings but, agreed, it isn't made obvious; I only know it from word-of-mouth, too.

I've heard rumors that rotation during time-warp is planned, but I've yet to see anything official. I was wondering if it's simply too difficult to implement but, absolutely agree; if it is possible, it's necessary for use-cases like this.

Obvs, I agree with every single thing in this post. You're a hero for laying it out so thoroughly and convincingly. The idea of being able to do a static analysis and show the user where the weak points are is simply chef's kiss. Are you sure that's how the calculation is done in KSP? That sounds backwards to my intuition; it seems like stress should be computed first, and strain then computed based on that.

(Copy/pasting this here from the Wobbly Rocket bug report thread at @Anth12's request due to it being better classified as feedback) My kingdom for a Beam.NG-style soft-body solver but, until then, let's get these rigid bodies to stay, ya know, rigid! So far the arguments I've seen FOR wobbly rockets are "players should get feedback on when they've designed something poorly". Agreed! However, I think having elastic joints are just the wrong kind of feedback. I think @Kavaeric's Discord post here is right on the money: Groaning/creaking and (imho, a purely cosmetic) rattling (like in the launch trailer) could tell the user that the joints are nearing their failure point, followed by catastrophic failure. I ran some tensor calculations on my Hello Kitty calculator and plotted this helpful chart:

My kingdom for a Beam.NG-style soft-body solver but, until then, let's get these rigid bodies to stay, ya know, rigid! So far the arguments I've seen FOR wobbly rockets are "players should get feedback on when they've designed something poorly". Agreed! However, I think having elastic joints are just the wrong kind of feedback. I think @Kavaeric's Discord post here is right on the money: Groaning/creaking and (imho, a purely cosmetic) rattling (like in the launch trailer) could tell the user that the joints are nearing their failure point, followed by catastrophic failure. I ran some tensor calculations on my Hello Kitty calculator and plotted this helpful chart:

As @Vanamonde said here, if you middle-mouse click on a part, it will focus the camera on that part, and the center of that part will become the camera's pivot point

In short, in KSP 1, you could press ALT+[time warp hotkey] to force a physical timewarp even when outside of an atmosphere. I used this for, for example, rotating a massive craft to a different attitude. In real-time, depending on the mass of the vehicle and how anemic the RCS was, it could take a minute to do a 180, whereas physical timewarp allows me to do it in seconds. Given that physical timewarp already exists, would it be simple to implement that same functionality and give the user the option to invoke it regardless of where they are? Also, let me do >4x physical timewarp; my CPU can handle it!

This is by far my biggest (and, ignoring some minor things, only) complaint about the graphics so far. Maybe I'm spoiled from something like Red Dead 2, but I also think getting atmospheric scattering working should be a major focus in a game about planets. How light scatters in the atmosphere tells a story about what kind of atmosphere the body has (or doesn't have).

I'll add to this by saying that it looks like all but a few standard resolutions are not available natively. I run a monitor at 5120x1440, but only by editing settings.json. Additionally, the artwork during load screens don't compensate for an ultrawide display; instead they're the normal 16:9 images stretched to fit a 32:9 aspect ratio. I haven't created a bug report about this because it's incredibly trivial and low-impact, but I figured I'd bring it up here.

I had this happen (with the same UI elements missing) after reverting to launch one time (a stock Crater-Crusher on Runway 1), but reverting to VAB and back fixed it, and I didn't encounter it again after that.

Reported Version: v0.1.3.1 (latest) | Mods: none | Can replicate without mods? Yes OS: Windows 11 Pro | CPU: AMD Ryzen 9 3900X | GPU: AMD Radeon 7900 XTX | RAM: 32GB DDR4 Severity: Low Frequency: High Description: When in the VAB, loading in the Stock Mk2 Crater-Crusher, it contains much less fuel in the RF-AD-B 400 methalox tank than it can hold. It loads with 0.176t of methane and 0.225t of oxidizer, while its capacity is 0.4t of methane and 1.6t of oxidizer. This is easily worked around by opening the part in the Part Mangler and increasing the amount of fuel and oxidizer in the tank. Note: My screenshot looks over-exposed because I'm playing in HDR Included Attachments:

A second hotfix, you say? LET'S GO, GAMERINOS! Even if it's high-risk, gimme it!

In the Early Access development video, when Nate's talking about how they're going to find that some assumptions they're making are incorrect[1], I'm thinking that the aversion to hotfixes might be one of those incorrect assumptions. I get not wanting to push out an update that inadvertently introduces new bugs, but I think it's kind of inevitable[2], and getting hundreds of eyes on it via the community has surely got to be better than relying just on the QA team who, presumably, is also working on QA for all of the roadmap features as well. Yeah, the hotfix yesterday introduced this DRM bug, but then today's hotfix fixed it. I dunno about everyone else, but I'm way more tolerant of new bugs assuming that frequent updates are being pushed out (like, once a week or more). [1] https://youtu.be/XAL3XaP-LyE?t=29 [2] Even with the much longer delay between patches 2 and 3, a massive, easily reproducable game-breaking bug made it through