PilotWasHere

Reported Version: v0.2.1 (latest) | Mods: none | Can replicate without mods? Yes OS: Windows 10 | CPU: AMD Ryzen 7 5700X 8-Core | GPU: AMD Radeon RX 6700 XT | RAM: 32Gb Bug is pretty much as simple as the title states, when building craft with payloadbays, parts placed inside them will cause drag on the craft preventing it from performing as expected, most noticeable on spaceplane type craft. To reproduce, construct a craft that is capable of achieving supersonic flight with a payload bay and nothing inside it, take note of drag forces using the cheat menu aero gui, or the craft's top speed, then place a part or parts inside the payloadbay and test again, drag forces increase and max speed decreases despite unaerodynamic parts being occluded by the craft's fuselage and payloadbay doors. I will provide a craft file that demonstrates this issue as well, the craft provided cannot exceed 360m/s easily as provided, but removing the payloadbay contents by disconnecting the monopropellant tank they're rooted to will have the craft reaching orbit with 1000m/s dv left in its fueltanks. Included Attachments: PilotPayloadBayTestCraft.json .ipsImage { width: 900px !important; }

Having built a number of SSTO Spaceplane style craft of various size categories, all designed to dock in orbit to other craft, my main gripe is that the Clamp-O-Tron Shielded cannot survive ascent heating, it explodes around ~750m/s @ ~6km altitude, given that there is no integrated docking port for the Mk3 Spaceplane parts, I would assume that this docking port is what fills that part's niche but given it's current temperature rating, or the game's current heat tuning it fails to fulfill the requirements for that. To me, lower atmosphere heating seems correctly tuned, and the upper atmosphere is what needs work, so my suggestion is to raise the Clamp-O-Tron Shielded's temperature rating from 1200K to 1500K to match the Mk3 "Condor" Spaceplane cockpit it seems this docking port was designed for.

I suppose I'll start this post similar to a bug report, so those reading it can understand what exactly I'm talking about, there is graphical bug in the VAB caused by an interaction with Hiding the HUD with F2 and Orthographic Mode(Blueprint Mode, BP Mode), the steps to reproduce are as follows: Enter VAB Load/Build Craft Enter Blueprint Mode View Hide HUD Drag Camera Following these steps will cause an unexpected behavior, originally posted here, allowing blueprint mode's background to exist outside of blueprint mode, and unloading the VAB until the HUD is reenabled and blueprint mode is activated and deactivated again. I use this behavior to take some pretty interesting screenshots of my craft, some will be attached at the bottom of this post. Rather than report this as a bug, which in fairness it is, I've come to the feedback forum to say that I like this behavior, and, rather than see it removed I would like it improved. Perhaps inside BP Mode there can be an additional UI button that makes the background persist, maybe "Screenshot Mode". In order for this to work, however, some elements of this behavior must be improved, as if you move the camera too far from the angle at which you initiated BP Mode the view you get is... less than desirable, as seen below. (Image Courtesy of Anth) I think if the Orthographic/Blueprint background followed the camera in this proposed "Screenshot Mode", or any other method to enable this behavior to act in a more desirable way, players would be able to take screenshots of their craft with this interesting backdrop without being locked into the 2D, face on view Orthographic Mode currently makes use of, without exploiting a bug. Some screenshots of craft utilizing this bug I find interesting, or aesthetically pleasing:

Reported Version: v0.1.5 (latest) | Mods: none | Can replicate without mods? Yes OS: Windows 10 | CPU: AMD Ryzen 7 5700X 8-Core | GPU: AMD Radeon RX 6700 XT | RAM: 32Gb Upon building a craft that deploys multiple other crafts or parts from a docking port, if the secondary craft is copied including the docking port only 1 craft will successfully deploy, the remaining 2 crafts will be understood by the game as still connected to the main craft, engines and other staging elements will remain in your craft staging, and your camera will be bugged for the remainder of the craft's life. This bug is not present if the secondary craft is copied without the docking port and placed onto a docking port not copied from the original placed docking port. I suspect this bug is connected to Included Attachments: dockingPortDisconnectFailureBug.rar

Reported Version: v0.1.5 (latest) | Mods: none | Can replicate without mods? Yes OS: Windows 10 | CPU: AMD Ryzen 7 5700X 8-Core | GPU: AMD Radeon RX 6700 XT | RAM: 32Gb Essentially the same bug as orbital lines disappearing, but after closing and relaunching the game they don't come back, which is supposed to fix this issue. DX Specs Txt File, Craft File and Game Save attached. Not sure how I'd reproduce this or what caused it, was doing a pretty standard, but poorly constructed apollo style Mun landing, trajectory lines on the Munar Ascent craft were never present and have not been restored on relaunch, which I attempted thrice. Included Attachments: NewWorkspace.json OrbitTest.rar specs.txt .ipsImage { width: 900px !important; }