Search the Community

Although I think this is a common problem, I can't find an existing thread for it so here goes: My missions are frequently ruined by parts falling off my craft for seemingly no reason. It seems to happen more often with spaceplanes, and mainly when they are in space, just coasting along. Loading a save, even a previous save, often doesn't get the parts back. The crafts behave normally in space after losing these parts, aside from losing the functionality of these parts, but after losing some canards to this bug, the craft became less aerodynamically stable instead of more stable/too stable, even with all the remaining fuels pumped forward. my pc specs: OS: Windows 10 Home, version 22H2 CPU: 12th Gen Intel(R) Core(TM) i5-12400F 2.50 GHz GPU: AMD Radeon RX 6600 RAM: 16GB Some pics of the problems: https://imgur.com/gallery/M8aMNeO https://imgur.com/gallery/6AUk85o

Hello, System Info per Rules: Version is KSP2 0.1.1.0.21572 (vanilla), I am on Windows 10 using a RTX 2080 and Ryzen 9 5900X. I just encountered multiple bugs while flying a jet with afterburning Panther Engines, they are: One of the two engines has its Nozzle expand again after switching modes (as expected), the other one does not. Both Engines are locked at exactly one power setting of 77.49kN, despite the Change in Altitude and Speed which normaly would mean decreasing thrust with more altitude and increasing thrust with more speed. After passing 20.000m in Altitude, both Engines suddenly cut out (without the thrust decreasing before) only to enter a very quick cycle of activating and de-activating again (although they of course should not work at all at this high altitude). When the craft glides back below 20.000m, the Cycle of stopping and starting stops, only for the Engines to be "Methane-Air Deprived" (with plenty of fuel on bord and while low in the atmosphere) while in afterburner or "Nominal at 0.00kN" after trying to switch back to Cruise-Mode Saving and Re-loading also does not help (although it detatched the wings ion this particular case). To better follow these points, I have recorded the flight. The Problems start after engaging the Afterburners via Action Group at 0:37 in the Video Link: Feel free to ask if you have any Questions.

As seen in provided screenshots, I have an intersect with the mun, which then ejects me back around kerbin, for another intersect with the mun. Current Trajectory (Intersect #1): I am unable to create a maneuver plan. Future Trajectory (Intersect #2): I am able to create a trajectory (for some reason?) This simply seems like a mix up in the code between which trajectory the buttons are available. so hopefully an east fix? Note: this is directly after updating to the first patch. PC specs are in a previous post of mine if required. Steps to recreate: get an intersect with the mun, which then gives you a gravity assist for another intersect with the mun, this will show you your current intersect in BLUE orbital lines, and future intersect in ORANGE orbital lines. Images: https://ibb.co/QJ0b8Hy https://ibb.co/y48RjF1 https://ibb.co/QM2NLnr

Hello, KSP Version 0.1.1.0.21572 Windows 11 Laptop with an i7 1280P and a desktop GTX 1080 Ti as eGPU When orbiting at fairly low altitudes the camera begins to spam messages because it can't decide which setting it should use. It's at potentially not safe altitudes, so I can't really blame it for panicking. Expected Behavior: Decide for one setting camera, you are trained for spaceflight, so behave like that Observed Behavior: See the screenshot below Steps to Replicate: Go to a very low orbit around a celestial body (I just tried it on Moho so far) Fixes / Workarounds (if known..) No mods Screenshots: Also the probe just crashed into the surface because it altered the orbit while writing this post (is there a secret atmosphere on Moho?)..

Description of Bug: Clicking on the area next to an item after using the stage Delta v pop out in the VAB will result in the staging item disappearing. Steps to Replicate: Click the Delta V pop out While in VAB, then click on either the fuel lines or the empty space. This will cause the stage item image to disappear Fixes / Workarounds: Pull off then reattach the affected part to bring back the image in the staging list. Images: Before/after The mouse is hovering over the decoupler, however since it has been clicked it does not appear in the list. KSP Version: 0.1.1.0 OS: Windows 10 Home edition CPU: Intel i7-9700 GPU: NVIDIA GeForce GTX 1660 Ti RAM: 16 GB Mods: none

To possibly re-crate this bug/glitch: Land a vessel on the Mun or Minmus then launch off While in a sub-orbital or orbital trajectory: create a maneuver and try to change it (even slightly) - observe that the maneuver node doesn't move no matter the change, but the "Required Delta-V" is displaying tiny requirements on Dela-V with decimals (an extremely small Delta-V required) The vessel's "Situation" in JSON save file now changes from 'Orbital' to 'Landed' Write a topic about the bug on the forums This bug can somehow affect the previous save files of the same quick saved lander vessel but doesn't change their "Situation" but somehow "infects" or "inherits" this bug. A way to fix this bug for the player: Re-load the save when you were still landed Do not leave the game until you are done from that forsaken vessel. You are a prisoner of the Kraken until you leave this to it.

This in turn glitches out the main vessel that was attached on even though the decoupled part has already detached, but feels like the part is still attached to the vessel and its still pulling and acting with drag and weight, therefore slowing down and misguides the rocket even though decoupled part is now registered as a debris and is kilometers away.

Image: Screenshot of the staging

Landed space craft also jumps or spawns several meters above the ground after time warp.

Parts in flight stay highlighted even after reloading a quick save, but disappears after reloading the quick save when loaded from the main menu or after restarting a the game.

Things likes pressing 'M' opens the man, pressing ',' (comma) and '.' (period) changes warp time. Also, numbers can not be inputted even when pressing on the numpad.

Even after several tries, after restarting from main menu and game, it detaches as a separate craft and becomes a debris. I had my engines and landing gears directly under the wings too.

In my latest video for the week 3 challenge, I suddenly had my WASD controls locked out and I couldn't move after planting a flag. This wasn't the first time this happened. As someone pointed out in the YouTube comments, I was in time warp but didn't realize it. Watching the video more closely (at 15:30) it appears as soon as I used a period in the text description, that key also triggered the time warp change. https://youtu.be/MF4UDDlaljg?t=930 Version: 0.1.0.0.20892 Date discovered: 3/12/2023 OS: Windows Input: Keyboard and Mouse Expected result: Text editing in flag descriptions and other similar UX/UI should not pass forward to game controls.

I’ve been messing around with trying to piggy back satellites to orbit with a mk2 SSTO. (Think how the SR-71 carried the drone, except the plane gets to orbit before launching the payload) But it seems putting even a small mk1 size space craft on the back causes some ridiculous drag. I built the launcher plane first and it blasts through 440 m/s without breaking a sweat. But with the mk1 craft piggy backed on, it struggles to hit 300 m/s. I know cargo bays have been thought to be an issue but I have none on either craft.

I was playing the game as normal and i crashed my plane, following the crash i wanted to go into the VAB and improve my design. I improved it, but the game didn't allow to launch it using the launch button which also red out that i had 0 delta-V. I went to the KSC to select the runway and launch it from there but the vehicle i had saved using the save button in the VAB didn't show up. I returned to the VAB and found that the "Revert to VAB", "Recover vehicle", and the "Revert to launch" buttons were there, I clicked "Revert to launch" and the game froze with the screen as seen on the screenshot below.

So there is bugs, yea we expected some. but looking at the most common bugs raises concerns that they need to go "back to formula" see what outers think is simply a annoyance bug points to much larger issues. and there are a few "gotcha's" First off is simply user interface, how key and button input is handled. but also how it is processed. an example is when writing a ship's name, M key takes you to a map view. this shows inputs are global instead of mode specific and/or the mode swapping is not handled properly. then there is the lack of response from interface when crafts of extreme loads are being launched, lets say you get time to pass once every 10 seconds, pressing esc you wait up to 10 seconds to see map. this is first a ticking issue, shows the menu is not calculated independently and have to wait for the world render cycle to complete before it is acted upon. the menu us a slave function to rendering. this should not be so. next there is time itself. time should pass once every second, no lag or load should reduce that. any function should be a slave of time and use "time passed since last action" as part of its calculations. instead of relying on each action's output to calculate the next, formula's should allow passing of any amount of time and be able to adapt to those. an example is rotating to a position over time, instead of needing to take action at every passing unit of time, a simple formula can be used to see how far it would be towards its goal giving this amount of time passed. so if a craft would need 8 seconds to rotate from prograde to retro, and you are on 10x speed, then simply assume that in the passing of 10 seconds it made the rotation and set it as such, and deduct the propellant it would have used for that. simple this will fix rotation and acceleration not functioning over time warp of any kind. then as for physics, this should be simplified where you can pre-calculate it take the assembled craft in its current state, then do a linetrace from it from every direction, get the relevant angle of the hit and assign a value to it. do an additive overlay for control surfaces and other moving parts. now simplify it into center of drag, and center of mass use this along with speed to calculate everything else needed, bit you now get to treat it as a single part and not 100's of parts, and only needs to recalculate if the assembly changes. you can further pre-calculate each part and in the final calculation use those as an is visible basis. you're welcome. the current setup looks to prioritize visual priority of execution should be: 1 - time 2 - interface input and response 3 - control input and response 4 - vehicle movement 5 - actual rendering, here going LOD or even complete basic Low poly will be acceptable as long as time keeps passing, input responding and actions happening reliably. next assembly again looks like rendering is prioritized. it looks like everything is as movable and lighting is dynamic, this is wrong and even bad for performance. treat every placed object as static, use directional light and pre-bake light as much as possible, then calculate dynamic shadows for the single combined model. also VAB should have better uniform lighting with less shadows, it's a rocket factory after all so can assume its getting at least 4x light from each side and from on top, this makes baking light easier. as for placement sockets, sure snapping to anything is a function now, but how about if we mid-mouse-button select something to then prioritize snapping to the object that we are focusing our view on? also you dont have to make an entire assembly as moveable to attach it, simply rendering a 2d version of it for the current view and using a depth offset, use that as a card for the moveable part, and hide the static once you render the card, then you dont even need movables. there is also collision issues with many parts, the simple solution is to do a visual interrace and get tangent at location, use that instead of collision, so a surface mount item will mount to the visual outer surface. these are just a few bug fixes and performance booster i would have looked at. again this is speculative and only the opinion of a play test, and I have no actual knowledge of how the code actually functions

Version: 1.12.4 Windows Problem: When attempting to load any active vessel for the first time after starting the game, the craft violently shakes with an "approaching G-Limits" warning and explodes. Reloading the last quicksave returns the vessel to normal, at the cost of any progress since then. However, for some craft, the game just crashes upon attempting to load (again, only after first starting up the game). Mods installed: Reproduction steps: Start up game, Enter tracking station, Switch to any active vessel Crash Logs:

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:

Im not sure if its the 4 engine plums that are causing it or something else and the fuel lines are not currently working for me. not sure if anyone else has come across this problem plus after the R.A.P.I.E.R. test there another bug about the engine working, but not working during time warp (using fuel but going know where) and the camera separating from the ship but i would stick to the fuel lines, camera, and R.A.P.I.E.R. if these are going to be fixed \/ video demo

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.

The attachment nodes on the Mk2 "Tuna Can" are not aligned with the center of the part:

see. the last part of the video