Search the Community

The following steps made the problem occur: Start Flight Open Aero-GUI Finish Flight by Recovering Vessel Click away the events menu thing (the one that shows stats like max G, max speed, max altitude etc.) Click on "VAB" after the Flight has been recovered Voila, there's aerodynamics statistics in the Vehicle Assembly Building This is a very minor bug and I don't expect it to be high on the priority list. Cheers, hope the next update will be good

KSP Version: 0.1.0.0.20982 Operating System and version : Windows 10 CPU and GPU models: Intel i5 10400F / GTX 1080 8gb Description of the bug. On the VAB while the sun is rising if the orthographic camera is activated one side of the vehicle it's gonna shine really bright (i think it happens too while the sun is on the top). Steps to Replicate Wait until sunrise > Activate orthographic camera Other Notes / Screenshots / Log Files (if possible..) Video: https://imgur.com/HSuNWgL

Hey there, Zooming in to any celestial body (planet or moon) in map view with said body "focused", allows camera zoom to go all the way down to reference point (center) of said celestial body resulting in camera going into 3D model of the body and producing flipped normals visual effects. I believe, as in KSP1 zoom capability of a camera should be limited to CelestialBodyRadius + SomeDistanceAtWhichAtmosphericsStillLookOkay. So for instance if a body has radius of 50km, it can be == 50 + 10 == 60km Screenshots follow: 1. Inside Kerbin: 2. Inside Eve:

I had the this weird bug where the rocket phases into the ground of the vab and all the part's become disconnected this seems to happen with autosave. sd

Required to Recreate: At least 1 x Rapier Engine(+ 1 intake of your choice) attached to a craft containing at least 1x Full Methalox Fuel Tank (Liquid Fuel + Oxidizer). Steps to Recreate: Launch Craft, fly to a stable altitude within Kerbin Atmosphere, Engage Closed Cycle Mode on the Rapier Engine when your Liquid Fuel is close to running out, Wait for burnout, stay full throttle. Expected Result: Rapier Engine Burns out, Remaining oxidizer stays inside the fuel tank. Actual Result: Rapier Engine Burns Out (with half a tank of oxidizer remaining), Rapier (and everything attached to it) explodes, Fuel tanks empty. Craft destroyed. Summary: Rapier engine seems to vent all remaining oxidizer when liquid fuel is depleted, causing an explosion. Realistic? Maybe... Bug? Maybe... Annoying? Yes.

see. the last part of the video

KSP Version: 0.1.0.0.20892 Unmodded stock steam release Launched via stock launcher Subject: VAB - Orientation change, causes parts mounted on radial attachment points to pivot upon snapping to unrotated parts in other construct built in other orientation. Expected teams required: Gameplay Features: VAB // Orientations Behaviour Expected: When constructing something in horizonal alignment, then attaching a radial attachment point with a Docking port on it, and then rotating that construct into a vertical alignment, before trying to attach it to a vertically aligned secondary ship, with a side mounted docking ring, should connect the two docking rings as expected. Observed: The docking node on the selected (and earlier rotated ship) will pivot 90 degrees out of alignment with the selected ship and prevent the nodes from connecting. Reproduction Recreated in fresh empty campaign, but occurs in all instances. Probability: 100% (10/10 repro's) Steps: Start with a horizontal cockpit (Ref: shipA) and ensure the workspace is in horizontal orientation mode Attach a fuel tank behind it Attach a radial attachment point (Ref: radialA) below the fuel tank Attach a docking port (Ref: dockA) to radialA. Select the cockpit, and rotate the entire construct 90 degrees into a vertical alignment. Change the workspace into vertical orientation mode Place a new fuel tank somewhere as a secondary construct. (Ref: shipB) Attach a radial attachment point (Ref: radialB) to the side of the fuel tank on ShipB. Attach a docking port (Ref: dockB) to radialB. Pick up shipA, and attempt to connect it to shipB by attaching dockA with dockB. ERROR: When dockA snaps to dockB, dockA will pivot 90 degrees into the wrong orientation. Workaround: After the part (dockA) has snapped into the wrong orientation, pick it up (dockA), rotate it into the correct orientation, and reattach it to radialA. Then attempt to connect the two constructs together again and they will snap together as expected. Image/Video: https://imgur.com/a/UnikOQ7 Logfile: https://pastebin.com/aBAz7wrn Probably irrelevant but attached OS details regardless: Operating System: Windows 10, i7-6700k, GTX1070, 32gb Ram

KSP Version: 0.1.0.0.20892 Operating System and version: Windows 10 CPU and GPU models, Intel Core i7 10700K @ 3.8hz, 32 GB ram, 4095mb NVIDIA GeForce RTX 3070 MSI Description of the bug. When renaming a vessel in the tracking station the vehicle's name never changes and reverts to its vab name On duna kerbal attempted to board vessel after eva and vessel spun out of control clipping below surface. Are had a lot of elevation differences In orbit around Mun attempted to board vessel after eva and vessel exploded Vehicles docked together separated but then the craft it separated from loss speed and fell vertically to surface Vehicles docked together could not separate The new maneuver nodes are very wrong much of the time, particularly with celestial body encounters. When accelerating under time warp vessel often becomes detached from maneuver path Steps to Replicate Fixes / Workarounds (if known..) None A list of ALL mods. If the list is long, please consider using a spoiler window. None Other Notes / Screenshots / Log Files (if possible..) None

How I built the ship: I put 3 medium docking ports on the XL engine plate in symmetry so that they weren't touching. I then built 3 segments to a space station on them, one crew segment, one solar panel segment, and one structural segment for expansion. This then had an XL tank (the middle one) and L/XL orbital engine on it for the 2nd stage. The first stage was the XL long tank with a mammoth engine and 4 of the Medium Long SRBs (because this was heavy and I am horrible when it comes to fuel efficiency). The Problem: When in LKO (100km circular orbit), I attempted to undock the parts to reconfigure them in their less symmetrical form. All seems to work normally for a varying amount of seconds (3-10 seconds maybe), I have RCS controls and am moving the detached part away and starting to rotate. Then the segment will rubber band back to its original housing on the docking port, I will get a message saying the ship is out of fuel (each segment has a near full monoprop tank), the flight log will appear as if I just ended the flight, and everything still reports operational in the parts manager. Troubleshooting: I can keep trying this process over and over on the same flight to no avail Quick loading or restarting the game also didn't help. If I have the setting for requiring comms on, then the probes and their antennae will not have an option to connect them to KSC even when directly above it and a Kerbal is onboard the crew section. I turned off this setting and have control of the probe for testing after doing so. I've tried each of the sections and they all do the same thing. There is no part collision between the segments, I made sure they had sizeable gaps (as much as I could and still fit them in a fairing on the ride up). I have also tried setting the strength of the docking ports to 0% on all the docking ports to make sure it wasn't that I was just not moving away fast enough. Even when I tried undocking and then having the part speed away as fast as possible in the few seconds (I got a whole length of the ship away which was about 2 of the medium long trusses in length), it still snaps back. The snapping back is almost like quick loading, when far enough away it is teleporting back with no applied force. If I was close enough to it, the ship did seem to wobble slightly when it bounced back (though that might just have been my imagination).

KSP Version: 1.0.0.20892 Operating System: Windows 10 Pro 22H2 CPU: Intel Core i7-10700k @ 3.80GHz 3.79 GPU: Nvidia GeForce RTX 3070 Ti RAM: 32 GB DDR4 Description, expectation, observed and replication: The lower part of the shroud of an engine mount shrinks after undoing any edit in the VAB. The expected behavior is for the shroud to stay in the same shape as before the undo. The observed behavior is that it shrinks This can be replicated like the following images explain link to full imgur album: Fixes / workaround: Simply re-attach the lower part Other notes: DxDiag for devs: https://pastebin.com/iEgr95TT

OK, I am sure this has been reported before but I had to share this. KSP Center following KSP Center at KSP Center. When did KSP start using Marvel graphics engines? Version Info: 0.1.0.0.20892 OS: Windows 11 (10.0.22621) 64bit CPU: AMD Ryzen 9 5950X 16-Core Processor (32) RAM: 130992 GPU: NVIDIA GeForce RTX 3090 (24340MB) FPS: 60 SM: 50 (Direct3D 11.0 [level 11.1]) RT Formats: ARGB32, Depth, ARGBHalf, Shadowmap, RGB565, ARGB4444, ARGB1555, Default, ARGB2101010, DefaultHDR, ARGB64, ARGBFloat, RGFloat, RGHalf, RFloat, RHalf, R8, ARGBInt, RGInt, RInt, BGRA32, RGB111110Float, RG32, RGBAUShort, RG16, BGRA10101010_XR, BGR101010_XR, R16

On launch, my computer will freeze, emit a sound like a buzz saw, and then blue screen of death on launch, when I have graphics on custom settings, leaning towards low, and am at recommended with RAM and CPU and in between minimum and recommended with GPU. Is it my build of the game, or what is wrong?

Version Info: 0.1.0.0.20892 OS: Windows 11 (10.0.22621) 64bit CPU: AMD Ryzen 9 5950X 16-Core Processor (32) RAM: 130992 GPU: NVIDIA GeForce RTX 3090 (24340MB) FPS: 60 SM: 50 (Direct3D 11.0 [level 11.1]) RT Formats: ARGB32, Depth, ARGBHalf, Shadowmap, RGB565, ARGB4444, ARGB1555, Default, ARGB2101010, DefaultHDR, ARGB64, ARGBFloat, RGFloat, RGHalf, RFloat, RHalf, R8, ARGBInt, RGInt, RInt, BGRA32, RGB111110Float, RG32, RGBAUShort, RG16, BGRA10101010_XR, BGR101010_XR, R16 Any Orbital Maneuver Expected Behavior: The burn time progress bar under the burn time status window (bottom center of screen) should reach the end (far left) when the Burn Time Remaining get to T-0 countdown. Observed Behavior: While the burn is occurring, and the view is toggled between Vehicle View and Map View, the status progress bar gets reset to the full right, then no longer finished at the far left with the total burn time reaches 0. Steps to Recreate: Plan any orbital maneuver node with a burn time duration of more than 30 seconds. Start Burn in Vehicle View, while burn is occurring switch to Map View. It also happens when starting in Map View and changing to Vehicle View. Workaround: Don't change views while performing a burn. Mods: None Logfiles: None Notes: See photos below. In KSP1 there was a burn down progress bar by the NAV ball and a Total DeltaV numerical count down. These two match. I like the Stop Burn In countdown and the 'stoplights' for the last 4 seconds, however please add the Total DeltaV numerical count down back in from KSP1. Photo 1: Started in Vehicle Mode, Stop Burn In time is 1:03, and progress bar below is reducing to the left as normal. Photos 2: Switch to Map View, Stop Burn Time has reduced nominally, however the progress bar is now full again at the start (far right). https://imgur.com/QkLEn9z Photo 3: Again switched between Vehicle View and map View. At Stop Burn In 10 seconds, the progress bar is full again (far right). Now in 10 seconds it should be all the way to the left. Photo 4: 10 seconds later at T-0, its not.

Version Info: 0.1.0.0.20892 OS: Windows 11 (10.0.22621) 64bit CPU: AMD Ryzen 9 5950X 16-Core Processor (32) RAM: 130992 GPU: NVIDIA GeForce RTX 3090 (24340MB) SM: 50 (Direct3D 11.0 [level 11.1]) RT Formats: ARGB32, Depth, ARGBHalf, Shadowmap, RGB565, ARGB4444, ARGB1555, Default, ARGB2101010, DefaultHDR, ARGB64, ARGBFloat, RGFloat, RGHalf, RFloat, RHalf, R8, ARGBInt, RGInt, RInt, BGRA32, RGB111110Float, RG32, RGBAUShort, RG16, BGRA10101010_XR, BGR101010_XR, R16 On a interplanetary flight to EVE: Expected Behavior: When planning a maneuver to intercept EVE, adjustment to the deltaV amount brings together the two intercept flags, when the two intercept flags are within the SOI of EVE, the SOI markers should be shown Observed Behavior: The SOI flags are not shown even though the intercept range is well within the SOI of EVE. (See first image below. The Intercept flag shows distance to target at 18km, well within Eve's SOI, but not SOI markers shown) Steps to Recreate: Create a EVE intercept orbit maneuver Workaround/Fix: When changing between vehicle view and Map View, it still did not show the SOI markers. Though when in Map view and rotated the view so that the intercept point were off the screen and brought back into view they got magically added. Possible and view refresh update issue? (See second image below) Mods: None Logfiles: None Notes: None

So, my RTX2060 maxes out at 30% on startup while I only get around 30 fps. There are also moments where fps drops to 15 and GPU usage drops to 10%. Similar things happen when I have a couple of vehicles next to me and I look at them, the usage drops along with the FPS. My Specs: Ryzen 5 3600 Rtx 2060 16GB RAM And my ksp is on SSD

Whenever I launch the game, random graphics settings will be selected, there's always more than setting selected for the same option. I set my PC setting to low but the next time I played both medium and high settings were selected with a random jumble of all the other settings.

What the title says. Am I doing something wrong? I activate the decoupling stage but both parts are still connected to each other even though the decoupler is gone. This never happened to me in KSP 1 so I don't think it is my problem. Is there any workaround? Has this happened to any of you?

Video:

I spent an hour today driving the Rover on Duna. The idea is to get to a crater. Buy I also wanted to see how it behaves on terrain. It's buggy. -wheels float above Dunas surface -Randomly hits invisible terrain object in relatively flat terrain and spins in 360 degrees -refuses to go in a straight line and constantly fighting with maintaining control of velocity Will post a video of this on 3.3.2023

The title says it all

KSP Version: 0.1.0.0.20892 Operating System and version: Windows 10 22H2 CPU and GPU models: Ryzen 5 3600X, RTX 3060 Ti, 32GB DDR4 RAM Description of the bug. Expected Behavior: When decoupling these simple structures, which are made up of 3 xs fuel tanks and 2 xs nose cones on either end, I would expect them to just fall to the ground and explode in amazing fashion. Observed Behavior: It seems they have some type of aerodynamic lift to them that causes them to shoot up and in random directions after dropping them from the craft. It is more exaggerated the faster and higher I go. Steps to Replicate: Make a plane and add little "bombs" to the wings. I think you have to have nose cones on either side of it. A list of ALL mods: I have SpaceWarp and the custom flags mod, that is all. I have numerous other bugs that all seem to have been reported. The most annoying of which is my campaigns seem to break and I no longer can save them, forcing me to delete them and start a new one. It's not a huge deal though because I am just testing stuff right now and messing around due to the WIP state of the game. But I haven't seen much reported about this issue with the aero behaving strangely. I am not sure if this is really a bug as much as it is the aero system still being worked on and tested. Here is a quick video below I recorded of the bug:

This happens with every ship I leave in orbit at 1x timewarp, it just spins (and accelerates the spinning) forever. SAS and RCS do nothing.

Version: 0.10 OS: Windows 10 CPU: AMD Ryzen 5 3600 GPU: NVIDIA GeForce RTX 3060 Expected Behaviour: Timewarp Observed Behaviour: Mission failed pop up Steps to replicate: Timewarp in atmosphere

I usually make planes and fly them in KSP, so I frequently have to deal with a big bug: if you attach landing gears to big wings, like the commercial airplanes wings or a sistem of wings, the plane immediately starts to bounce and never stops, and it makes taking off literally impossible (mainly if you have a big part of your wing going further to the fueselage than the gears), and the only solution is to attach the gear to the fueselage and move it, but I think this is a big bug and deserves some attention.