ShadowZone

I apologize if this is already written somewhere and I have glossed over it, but: transfer from moon to moon (e.g. Vall to Bop) is not yet implemented or is that one of the bugs that are currently open?

Just out of curiosity (and sorry if you already said that previously): do you stage parachutes while in atmosphere? Since 0.2.0 I had severe problems with chutes when staging them while in atmo, but when I stage them while still above 70km (at Kerbin), they usually work fine. I had various combinations of that but: total failure, only drogues failing, half of my chutes failing, chutes opening way too late (past 1000m) etc. I agree, it's pretty infuriating, but the "stage while still out of atmo" thing has helped me.

Nice, about 6 weeks after "For Science" came out, we have the first patch quite a few issues I encountered myself are (nominally) fixed. Haven't been able to launch the game yet, but that will change soon As per usual, here's the bugfix stats: Version Total items Community % of total 0.1.1 281 42 15% 0.1.2 173 36 21% 0.1.3 165 17 10% 0.1.4 81 9 11% 0.1.5 86 11 13% 0.2.0 156 0 0% 0.2.1 68 14 21% While the patch with the least number of changes, we have to consider that the Christmas holidays and New Year's was in between. Also a lot of issues that were found and fixed thanks to the community. Some more numbers: Including the initial 0.1.0 release, we had 8 releases since February 24th 2023. On average, that's almost 7 weeks between releases. Soooooo, mid March for 0.2.2?

Great update all around! The game still needs work, but I like to see the progress made. Here are some stats in regards to bugfixing: Total items Community % of total 0.1.1 281 42 15% 0.1.2 173 36 21% 0.1.3 165 17 10% 0.1.4 81 9 11% 0.1.5 86 11 13% 0.2.0 156 0 0% I'm curious: the rocket icon signifying fixes that were aided by the community is missing in the current release notes. Is this deliberate or an omission?

Thanks for the update! Question about process: I know the "floor hugger" regression we discovered does not have as many votes (yet?) as some of the other bugs listed here, but is it still treated with higher priority internally since it is a regression (at least the effect of the bug, maybe not the source of it)? @The Space Peacock said in a comment that there has already been internal analysis, so that's a relief! Just trying to find out if we can expect this to be fixed in 0.2.0 at the latest. I can make #1 happen with a specific vehicle all the time and have attached save game, logs, workspace etc here:

@Anth / @The Space Peacock I can trigger the orbit trajectory lines disappearing every time by launching my current Buran/Energia iteration. Load up the save in the bug package attached below, try it with a simple rocket (see video) --> orbits look normal. Then revert, launch "Buran Energia v2" and you will see that the trajectories are gone. Happens every time with this vehicle. See also video below. Bug Package with save game that was created fresh for 0.1.5, logs and workspace: https://drive.google.com/file/d/1sL7KWPWteFqxIPzaG4CXEJEK46IEW1KQ/view?usp=sharing Reported Version: 0.1.5.0 | Mods: none | Reproducible without mods? Yes | CPU: AMD Ryzen 9 3900X 12-Core Processor (24) | GPU: NVIDIA GeForce RTX 3090 (24340MB) | RAM: 65459 | OS: Microsoft Windows 11 Pro 10.0.22621 64-Bit

I got a few minutes, and yes, the workspace added to the crash bug immediately triggers the "floor hugger" when removing a part and pressing CTRL+Z

I honestly don't know. I haven't touched that one at all so the crash stays reproducible. Might copy/paste it or something to experiment when I get the time (not within the next 16 hours).

The craft attached loads into the floor. I have created another bug report with a previous version of this vehicle which results in a crash when trying to launch. I see this as two separate issues that's why I created two reports. But with the craft attached there you can try to experiment and see if adding/removing parts would provoke the "floor hugger" bug by pressing undo. The only parts I added after the state that's in the other bug were linear RCS parts.

Reported Version: v0.1.5 (latest) | Mods: none | Can replicate without mods? Yes OS: Microsoft Windows 11 Pro 10.0.22631 64-Bit | CPU: AMD Ryzen 9 3900X 12-Core Processor (24) | GPU: NVIDIA GeForce RTX 3090 (24340MB) | RAM: 65459 In the attached .zip file, there is a workspace (autosaved file) that causes my KSP2 to immediately crash when I try to launch it. I created a completely fresh campaign for 0.1.5, then created a fresh workspace for a Buran build. That resulted in the vehicle disappearing into the floor like in previous versions of the game (see this report). But when I load up the last working autosave of this, the craft appears to be fine. But when I press "launch", the game will crash every time. This really needs to be looked at. Attachment info: Video showing what I did. First I had the broken craft with parts hugging the floor. Then I loaded the last known working autosave version. Then the game crashed. The Bug package contains two sets of log files. First the logs from what is shown of the video. The second one is in the "Files" subfolder and was from a crash I experienced before I decided to record myself playing. Included Attachments: BUG137-Vehiclelaunchcasesgamecrash_logs.zip

Reported Version: v0.1.5 (latest) | Mods: none | Can replicate without mods? Yes OS: Microsoft Windows 11 Pro 10.0.22621 64-Bit | CPU: AMD Ryzen 9 3900X 12-Core Processor (24) | GPU: NVIDIA GeForce RTX 3090 (24340MB) | RAM: 65459 I was building my Buran replica, then deleted a part by mistake, pressed CTRL+Z and suddenly the vehicle was in multiple parts below the floor of the VAB. Trying to do "Undo" a couple more times only made it worse (see video). Also, the craft renamed back to "Fly Safe" after it disappeared under the floor. This is something that I believe was already fixed in the past, so I added "Regression" to the title. Included Attachments: Spicat edit: Steps to reproduce: Load AutoSave ShadowZone 0.1.5 05.11.2023 16_15.json Hit the undo button Hit the redo button ShadowZone's Bug Package: BUG136-Floorcraftreturns_logs.zip It contains the craft that is already in the ground.

Yes, this is in KSP2 since version 0.1.0 It happens all the time.

As usual, I took the liberty to compile some statistics. And here they are: Total items Community % of total 0.1.1 281 42 15% 0.1.2 173 36 21% 0.1.3 165 17 10% 0.1.4 81 9 11% 0.1.5 86 11 13% Community column is calculated based on how many items in the list have a rocket icon. Thanks to the devs for the release! Let's see how many fly swatter creations we can see in the coming days thanks to those grid fins

Here's the full presentation with crowd reactions and gameplay footage in full 4K:

Hey guys, back from Space Creator Day. I was in the crowd when the announcement happened, just wanted to give you guys some impressions from how the reactions were and what people thought who talked to me afterwards. First off, the KSP2 stand was SWARMED basically the entire time. There even was a father and son that came all the way from Seattle to attend the event, not exclusively for KSP2 but it was a big part (I chatted with them a bit). Pretty much until the presentation, Nate and Dakota were non stop interacting with fans. What does that tell us? It appears that interest in KSP2 is still high despite the problems it is currently facing. During the presentation, the crowd was very positive regarding the information provided. I talked to a few audience members afterwards and they pretty much share my own take: Nate sold "FOR SCIENCE!" (I am contractually obligated to use all caps and exclamation mark every time1) pretty well. But now the team has to deliver the quality matching the promises made on Saturday. Personally, I am pretty excited about the prospect of the update. Btw, I will upload my recording of Nate's presentation later today (October 23 CEST) including high res trailer footage. You'll be able to check out all the details a lot better than with the SCD official stream footage. This was my POV: 1 - Just in case, I am joking. There is no contract between myself and Intercept Games, Private Division or Take Two Interactive.

Congrats, Anth! You've been already doing great work here on the forums. Who will now mainly check the incoming bugs here for duplicates or is that still something you are going to do?

Reported Version: v0.1.4.1 (latest) | Mods: none | Can replicate without mods? Yes OS: Microsoft Windows 11 Pro 10.0.22621 64-Bit | CPU: AMD Ryzen 9 3900X 12-Core Processor (24) | GPU: NVIDIA GeForce RTX 3090 (24340MB) | RAM: 65459 Tried to refuel a vehicle in orbit. Target vehicle was combined of 3 main vehicles: Mothership, lander and spaceplane. all sent up together in one launch (which was PAINFUL btw). When the refueler arrived at the target vehicle, the spaceplane was suddenly undocked, but it still reacted to control inputs given to the mothership and parts were also controllable via PAM. There was no "undock" option for the docking ports in question but the two vehicles were still treated as if they were one (except for position in space). This is infuriating on so many levels I cannot begin to describe. But I made a video for everyone to share the pain. Logs, relevant save game and workspace in bug package. Included Attachments: BUG135.mp4 BUG135Vesselundockedbutstillcontrollable_logs.zip

Reported Version: v0.1.4.1 (latest) | Mods: none | Can replicate without mods? Yes OS: Microsoft Windows 11 Pro 10.0.22621 64-Bit | CPU: AMD Ryzen 9 3900X 12-Core Processor (24) | GPU: NVIDIA GeForce RTX 3090 (24340MB) | RAM: 65459 When trying to rendezvous with another vessel, trying to match orbits by locking both active and target vessel's PE visible results in the UI elements overlaying each other. This might be a regression, because I believe in previous versions the game realized that these two would inhabit the same space and put them apart from each other. Please correct me or close this if that was not the case. Because then it's not a bug, just a badly implemented feature not providing any advantage over how it worked in KSP1. Included Attachments: BUG134.mp4

Can you switch back to the vessel you want to control by double clicking on it? Because I encountered something similar, but with decouplers not separators and I was able to switch to the second stage after separation with double click. I included a video, could you maybe comment on whether or not the behavior is the same? Then this might be something that is a larger issue not just limited to separators.

Reported Version: v0.1.4.1 (latest) | Mods: none | Can replicate without mods? Yes OS: Microsoft Windows 11 Pro 10.0.22621 64-Bit | CPU: AMD Ryzen 9 3900X 12-Core Processor (24) | GPU: NVIDIA GeForce RTX 3090 (24340MB) | RAM: 65459 When collapsed, right mouse button drag in the area where the expanded staging UI would be results in camera not reacting, as if a "hit box" for the expanded UI is still there and preventing the camera from performing as it should. See video for more detail. Included Attachments: BUG133.mp4 BUG133-StagingUIblockscamerarotation_logs.zip

Reported Version: v0.1.4.1 (latest) | Mods: none | Can replicate without mods? Yes OS: Microsoft Windows 11 Pro 10.0.22621 64-Bit | CPU: AMD Ryzen 9 3900X 12-Core Processor (24) | GPU: NVIDIA GeForce RTX 3090 (24340MB) | RAM: 65459 Launch the vessel attached in the bug package (called "dV liar"). After stage is spent, hit space bar to stage. Result: Game says "vehicle control lost due to None" and remains on the spent stage (or a part that was staged, multiple decouplers were used) You can still switch to the second stage by double clicking on it, but this just should not happen. Attached: Bug Package, video example Included Attachments: BUG132v2.mp4 BUG132stagecontrolloss_logs.zip

Reported Version: v0.1.4.1 (latest) | Mods: none | Can replicate without mods? Yes OS: Microsoft Windows 11 Pro 10.0.22621 64-Bit | CPU: AMD Ryzen 9 3900X 12-Core Processor (24) | GPU: NVIDIA GeForce RTX 3090 (24340MB) | RAM: 65459 When attaching radial tanks with engines to a center stack with engines, the game does not correctly calculate the dV available. In fact, it always shows more dV than is actually available. This prevents me from reliably building rockets that can reach orbit since the dV is usually displayed higher than is actually available. Video example attached. Also bug package including two workspaces that have the issue as well as log files. Included Attachments: BUG131.mp4 BUG131dVcalculationwrong_logs.zip

Yeah, it was the same for me. Nothing as big as parts of a vehicle disappearing like I have experienced since 0.1.0.0

Reported Version: v0.1.4 (latest) | Mods: none | Can replicate without mods? Yes OS: Microsoft Windows 11 Pro 10.0.22621 64-Bit | CPU: AMD Ryzen 9 3900X 12-Core Processor (24) | GPU: NVIDIA GeForce RTX 3090 (24340MB) | RAM: 65459 Built a small SSTO and included two SM size cargo bays. One has the deploy limit slider, the other doesn't. Unclear why. This could be a general issue for all parts that use this slider, not just the SM cargo bay. Included Attachments: BUG130_logs.zip

I use fairings as hull replacement for large ships or to make spherical objects. Like the 2001 moon landing shuttle at 0:52 in this video: https://www.youtube.com/watch?v=55btWQQVPLE Getting both halves to have the exact same diameter and curvature was a royal pain in the behind and even then I never quite nailed it. Or when I tried to recreate KSP2 vehicles in KSP1 and used fairings to replicate the spherical parts: https://www.youtube.com/watch?v=UNgTLF_JV5U Come to think of it: no, I don't necessarily need fairings. I need some procedural part that I can make custom shapes out of in a manner that is reproducible and precise. Like when I wanted to do a 1:1 Starship and used fairings to create a 9m diameter hull. Which was only possible with a lot of trickery instead of just showing me the diameter of how wide the fairing really is. Fairings are so far the only part that enables me to build something close to what I want to achieve. And no, I don't want mods. I want to do it stock.