Search the Community
Showing results for tags 'ksp2br-fixed'.
-
Reported Version: v0.1.3.2 (latest) | Mods: none | Can replicate without mods? Yes OS: Windows 10 | CPU: Intel i9 9900K | GPU: Nvidia 3070ti | RAM: 32GB Steps to Replicate: Load JoolDistortionTestSave.json Move between 10,000 timewarp and 100,000 timewarp to show its extremes. Screenshot: Video Evidence: JoolDistortion.mp4 Save File: JoolDistortionTestSave.json Additional Information: I haven't tested it for any of the other moons.
-
Reported Version: v0.1.3 (latest) | Mods: none | Can replicate without mods? Yes OS: Windows 11 | CPU: 11th Gen Intel(R) Core(TM) i7-11700F @ 2.5GHz | GPU: NVIDIA GeForce RTX 3060 | RAM: 31.68 GB Airbrakes sometimes deploy in the wrong direction. I found two different ways this can happen. If you launch a craft, return to VAB, and try to launch again some airbrakes will deploy the wrong way. Two workarounds to this are to 1) take the airbrakes off and put them back on, or 2) when in the VAB save and reload the craft. Another time the airbrakes deploy the wrong is when they are in a place where they act as control surfaces. If you take the attached craft and roll, one of the airbrakes will deploy the wrong way going through the craft. Included Attachments: whyworkspacesexist_____.json
-
Reported Version: v0.1.3 (latest) | Mods: none | Can replicate without mods? Yes OS: Windows 10 | CPU: i9-10850k | GPU: RTX 2060 Super | RAM: 24GB 3200MHz System Specs: Severity: Low Frequency: High, consistently reproducable The nozzle was extended and firing. After reloading, the nozzle is retracted and the plume appears where it normally would. The screenshot was taken after reloading a different save than the attached one because I overwrote it on accident, but the bug persists in both of them. Included Attachments: quicksave_1.meta
-
Reported Version: v0.1.4 (latest) | Mods: none | Can replicate without mods? Yes OS: Linux Ubuntu 20.04.6 | CPU: AMD Ryzen 5 3400G | GPU: NVIDIA GeForce GTX 1080 Ti | RAM: 16GB System Specs: Description: The extra info provided for parts seems to be displaying incorrectly. The size of the text seems extremely large causing nearly all of the text to be rendered off screen. Often the text area where the text would get displayed is blank as well. Included Attachments:
-
Reported Version: v0.1.4 (latest) | Mods: SW, BepInEx, Fancy Fuel Tanks, Toggle Notifications, Flight Plan, MNC, Custom Flags, Kesa Solar, UITK for KSP 2, Micro Engineer, Lazy Orbit Boosted, Node Manager, Resonant Orbit Calculator, Community | Can replicate without mods? Yes OS: WIN11 | CPU: i9-13900k | GPU: MSI Suprim RTX 4090 | RAM: 64 GB DDR5 @ 5200 mhz During flight, if you're using a separator when you activate it, it will successfully separate the two stages. However, the separator debris becomes the active vessel. The only fix I've found is to go into the flight tracker, delete the debris, then select the vessel you want to control. This occurs with and without mods installed. How to replicate: 1. Attach a separator to your rocket (any size) 2. Launch 3. Separate the stages by activating with spacebar 4. You're now controlling the separator debris. It is only separators that are bugging out. The decouplers are working as intended.
-
Reported Version: v0.1.4.1 (latest) | Mods: none | Can replicate without mods? Yes OS: 19045.3448 | CPU: 10900X | GPU: 2070 | RAM: 128 Any input of force while on EVA or in craft of Dres, upon finishing the input manifests a phantom force that doesn't seem to be related to the input of the force. When the player applies force the phantom force is removed. As in the video, jumping reproduces it, upon finishing any RCS input reproduces, walking doesn't seem to be affected. Craft also manifests the same behaviour. Fully stock game. Included Attachments: KerbalSpaceProgram22023-10-0719-49-36.mp4
-
Reported Version: v0.1.4.1 (latest) | Mods: none | Can replicate without mods? Yes OS: Edition Windows 10 Home Version 22H2 Installed on 29/06/2022 OS build 19045.3448 Experience Windows Feature Experience Pack 1000.19044.1000.0 | CPU: CPU Intel(R) Core(TM) i7-3770 CPU @ 3.40GHz Base speed: 3.40 GHz Sockets: 1 Cores: 4 Logical | GPU: GPU 0 NVIDIA GeForce RTX 3060 Ti Driver version: 31.0.15.3713 Driver date: 14/08/2023 DirectX | RAM: Memory 32.0 GB DDR3 Speed: 1600 MHz Slots used: 4 of 4 Form factor: DIMM Hardware reserved: 4 What happened: If you are in orbit, go EVA with a Kerbal then move up and down the ladder of the pod (I used the 3 seats Pod), the Kerbal will drift away from the craft. Then, moving again, a few seconds later, will teleport back to its supposed position: on the capsule's ladder. Expected behaviour: The Kerbals should be able to go up and down a ladder on a craft, without drifting away in space. What I suspect happened: The new fix that (successfully) reduces orbital decay may have created a new bug related to other bodies (crafts or kerbals) that are supposed to stick to another craft. It seems that this fix forces objects (crafts or kerbals) that are in orbit to forcibly freeze on their position, based on their motion (a kerbal moving up a ladder would create a "new orbit" since he created a force upward to go up the ladder, and maybe the game thinks that the kerbal is not attached to the ladder of the craft and therefore should not be sticking to it, ergo, should drift away). Might want to replicate this bug with DOCKING other vessels to one another. Video recording of my test: timestamp: 28 minutes 39 seconds Included Attachments: bugtest1.json Anth12 Edit: Adding Video of it working Correctly in 0.1.4.0 confirming issue is caused by 0.1.4.1
-
Reported Version: v0.1.3 (latest) | Mods: none | Can replicate without mods? Yes OS: Windows 10 | CPU: Ryzen 5800X | GPU: GTX 1060 6GB | RAM: 16GB Despite using 2x symmetry, only one engine appears in the situation below: Included Attachments:
-
Reported Version: v0.1.3 (latest) | Mods: none | Can replicate without mods? Yes OS: Windows 10 | CPU: Intel(R) Core(TM) i7-10700 CPU @ 2.90GHz | GPU: NVIDIA GeForce RTX 2070 | RAM: 16GB Severity: Very low, just a text change Frequency: High, always happening but still very minor Description: There is a confirmation box when you destroy a craft now (very nice change). But, it's missing a question mark, because it's a question, see below: Included Attachments:
-
Reported Version: v0.1.3 (latest) | Mods: none | Can replicate without mods? Yes OS: Windows 11 Home | CPU: Intel(R) Core(TM) i7-9750H CPU @ 2.60GHz 2.59 GHz | GPU: NVIDIA GeForce GTX 1660 TI | RAM: 16 gb So... I found out that if I undock vehicles while on pause, when you unpause the vehicle disintegrate. Video for reference. Sorry the quality is a bit bad.
- 26 replies
-
- 1
-
-
- v0.1.3
- Regression
-
(and 2 more)
Tagged with:
-
Reported Version: v0.1.3 (latest) | Mods: none | Can replicate without mods? Yes OS: windows | CPU: ryzen 7 | GPU: Nvidia Geforce GTX 1660 | RAM: idk This has happened to me sporadically but seemingly randomly, unfortunately I can't tell what causes this glitch. When going for a spacewalk, my kerbal will sometimes be flung away from the craft at high speeds as soon as they exit the vehicle.
-
Reported Version: v0.1.3 (latest) | Mods: none | Can replicate without mods? Yes OS: Win 10 | CPU: Intel Core i7-6700K | GPU: 2 x NVIDIA 1080 | RAM: 32 GB Scenario: Having no engine on a craft but consumers of EC will have no effect on EC level. The level of EC remains at max no matter how long you use anything that is supposed to consume EC. Test vehicle: MK1-3 pod with 150 EC internal storage capacity, 2 medium sized reaction wheels right underneath it, a medium decoupler underneath them, a tank and an engine (mainsail, but that does not matter at all). Test: Launch vehicle to some point where it can fly for a bit, decouple the engine and tank bit so that only the command pod and the 2 reaction wheels remain. While flying keep pressed any key that performs an action that requires the reaction wheels, e.g. keep q depressed to roll faster and faster. The wheels are supposed to consume 2.xx EC per second (according to tooltip in VAB) so it should drain the 150 EC from the command pod fairly quickly. Result: The EC level remains at 150 EC without any change at all no matter how long I use the EC consumers. Either the EC consumption is 0 or the EC production is constantly at a very high level without any engine or solar panel. Both of these conditions are wrong and should be classed as a bug.
-
Reported Version: v0.1.3 (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 Attach an AIRBRAKE to any part. Launch the vehicle. Press Q/E for rolling. Result: AIRBRAKES will deploy with the roll input and even exceed their angle limit doing so. See video and bug package file for more details. Included Attachments: BUG124.mp4 BUG124_logs.zip
-
Reported Version: v0.1.3 (latest) | Mods: none | Can replicate without mods? Yes OS: Windows 10 | CPU: Ryzen 5 3600 | GPU: Radeon RX 5600 XT | RAM: 32GB After picking up a strut from the parts menu, the symmetry icon appears greyed out and cannot be changed until I put the strut down. This is not an issue with other radially attached parts. The workaround is to change symmetry before picking up the strut. Severity: Low Frequency: High
-
It's impossible to rename a ship in the Tracking station. When you edit a name the line for KSP change, not the line of the ship you were editing. When you exit the tracking station and come back the KSP line is now back to KSP but the name of the ship still has the old name. Also the name is barely visible when editing.
-
Reported Version: v0.1.3 (latest) | Mods: none | Can replicate without mods? Yes OS: Windows 10 | CPU: Ryzen 5 3600 | GPU: MSI 3080 | RAM: 32 gig Specs: Severity: Medium- The workaround that was available has regressed. See the follow-up for more details. Frequency: High- following this build process results in the bug every time. Description: Make a plane using an Oscar-B tank, copy and paste. Wings flip. Included Attachments: NewBugs0001-11861.mp4
-
Apologies if this has been posted before. Not a major bug by any means, but I thought I'd report it anyway. KSP Version patch 2 Operating System and version windows 11 pro CPU and GPU models, any other system information which could be relevant Intel(R) Core(TM) i7-10750H CPU @ 2.60GHz, NVIDIA Quadro P620 Description of the bug. The centre of mass, thrust, and pressure vectors automatically spawn in the middle of the VAB floor. They don't change as I modify my craft. When I toggle them on, they disappear from the VAB floor and appear in their correct positions (i.e. somewhere on the craft itself). Expected Behavior The vectors should not be visible if they are toggled off. Observed Behavior As above A list of ALL mods. If the list is long, please consider using a spoiler window. No mods Other Notes / Screenshots / Log Files (if possible..) (you may need to squint to see them in the image below)
-
It's a major bug for me and really annoying, the maneuver doesn't behave correctly: KSP Version: v0.1.2.0 Operating System and version (Windows 10, Windows 11): Windows 10 CPU and GPU models, any other system information which could be relevant: i7-10700 / RTX 2070 / 16GB RAM Steps to Replicate On an orbit, place a maneuver and use the normal arrow. Execute the burn and you will see that the path doesn't match with the maneuver path. Description of the bug. Expected Behavior In ksp 1, when we use the normal arrow and execute the burn, the maneuver icon move on the navball. Thus, it results in a path which is not just normal (a orbit with a different angle) but also prograde (a orbit with a different angle AND a different apogee). Observed Behavior Here in ksp 2 the maneuver icon on the navball stay on the normal icon, it doesn't move, so when following this icon we obtain the path of a normal maneuver (just change the angle) In ksp 2. Either the maneuver should move when executing the burn like in ksp 1, or the maneuver path should show the path of just the normal maneuver (so not like in ksp 1). Fixes / Workarounds (if known..): Not a fix but => not using the maneuver, which is a shame A list of ALL mods. If the list is long, please consider using a spoiler window: No mods Other Notes / Screenshots / Log Files (if possible..) Here a video to better understand the problem (I only burn Normal because the maneuver icon is not moving): https://i.imgur.com/2MviOiD.mp4 I don't know if it's just the normal and anti-normal, but I think the problem is the maneuver icon not auto correcting. I think I have this bug since release.
-
Reported Version: v0.1.3 (latest) | Mods: none | Can replicate without mods? Yes OS: Win 11 | CPU: Ryzen 9 5900HX | GPU: 6800M | RAM: 32GB DDR4 3200MHz All of the UI elements with an amount of transparency, including the hamburger, Kerbal viewpoint, Staging window, the text map telling you which celestial body you are in their sphere of influence etc. have artifacting constantly, in both VAB and in-flight views. The artifacting is less prominent when in space, but that may just be different things that are less visible artifacting. Included Attachments: 2023-06-2218-07-20.mkv
- 23 replies
-
- 1
-
-
- v0.1.3
- Regression
-
(and 1 more)
Tagged with:
-
Reported Version: v0.1.4 (latest) | Mods: none | Can replicate without mods? Yes OS: Linux Ubuntu 20.04.6 | CPU: AMD Ryzen 5 3400G | GPU: NVIDIA GeForce GTX 1080 Ti | RAM: 16GB System Specs: Frequency: High (seems to happen every time) Description: Hitting "Revert to Launch" from the escape menu while the simulation is paused seems to always result in some pretty serious problems. When I first encountered this it left me at a frozen loading screen, but the audio you'd expect to hear comes in, and you can even hit some buttons on the keyboard and hear the game react via audio only like you'd expect. Hitting space for example caused the rocket engine sound to start. Another time It left me with a highly corrupt view and the GUI overlayed on top of it. This time I was able to rotate the view, but was so corrupt I could hardly tell what I was looking at. Included Attachments: I have a possible workaround. Once you're in the problematic state, it seems that you can hit pause"<" and then unpause">" on the keyboard, then you might be able to go into the escape menu as normal and revert while the game is not paused to get to a correctly reverted state.
-
playing on version 0.1.2.0 using windows 11 when opening the map screen while burning (orbital maneuvers, insertion, etc.), the craft actively flying begins to spin. looks kinda similar to a craft not having any gimbal, and not having enough RCS or enough torque power. (reaction wheels) steps to replicate: build spacecraft with engine that has gimbal (swivel, poodle, vector engines) open map screen mid flight/burn see craft spin out via navball fix/workarounds just, dont have the map screen open while burning / performing maneuvers. no mods used i'm not sure a screenshot can really be helpful here, but feel free to yell at me for not attaching one.
-
KSP Version v0.1.1.0 Operating System and version (Windows 10, Windows 11) Windows 11 CPU and GPU models, any other system information which could be relevant i7 12700F with RTX 3060 Ti Description of the bug. Expected Behavior SAS should not lose control of the ship when engine is burning fuel in any view. Observed Behavior Changing to MAP view while using any SAS option and the engine is burning fuel causes ship to lose control Steps to Replicate 1- Set any option on the SAS control; 2- Start the engine of the craft at any amount above zero; 3- Change the view to Map Fixes / Workarounds (if known..) - Unknown A list of ALL mods. If the list is long, please consider using a spoiler window. - NO MODS Other Notes / Screenshots / Log Files (if possible..) You can see the ship losing control as soon I change to MAP view at 0:14 and 1:07 of the video.