krbvax

Reported Version: v0.2.0 (latest) | Mods: none | Can replicate without mods? Yes OS: Wine 9.0-rc3 on Linux | CPU: AMD Ryzen 7 | GPU: NVIDIA 3060 Ti | RAM: 32GB (*) Note: this is a duplicate of the bug below - I'm filing a separate report to provide a reduced test case and hopefully useful observations, since I don't see a way to attach a save file directly to a post. Problem: Under specific circumstances, engines under thrust produce no acceleration during on-rails time warp. This appears to be possibly due to a loss of floating-point precision, causing extremely small acceleration values to be rounded to zero. In the attached test case, containing a simple craft with a xenon engine in a 2500km circular Kerbin orbit, acceleration on rails works only when the xenon tank has 0.219876t or less fuel. I can't find a way to display the current vehicle mass, but from calculations based on part mass shown in the VAB, this would be a total vehicle mass of 1695.876 kg. (In the file, the fuel level is set to 0.2199t, so it will cross the threshold after about 5 seconds of full throttle acceleration.) Severity: Medium Steps to reproduce: Load the attached save file. Press Z to set the engine throttle to 100%, and observe (in the orbital info window, or by switching to map view and pinning the Kerbin PE node) that the periapsis altitude begins to decrease. Within 3 seconds, set time warp to 2x. For 3 seconds (6 simulated seconds), observe the behavior of the periapsis altitude. Set time warp to 1x. Observe the behavior of the periapsis altitude. Set time warp to 2x again. Observe the behavior of the periapsis altitude. Expected behavior: The periapsis altitude continues to decrease throughout all steps after throttling up. Observed behavior: The periapsis remains constant during step 4, but decreases as expected during steps 6 and 8. Included Attachments: rails-accel-bug.json .ipsImage { width: 900px !important; }

The icon background does in fact change to grey when disabled - the bug is that the background isn't updated when you click to turn the switch off. Once the mouse cursor leaves the switch's hitbox, the background becomes grey as expected. (Interestingly, when switching from off to on, the background does update immediately.)

It looks like this may actually be a duplicate of this bug: I observed this on SOI changes only because those tended to be large burns, and looking closely at my video, the burn timer behavior changes exactly at the point the craft's remaining dV becomes less than the required dV of the maneuver plan.

This worked, thanks. For the record, what I tried before was to: go the search bar in the site header, click the dropdown in that search bar and change it to "Bug Reports", type "Going Green" into the search bar, and press Enter. That returned 0 results, and continued doing so even after editing the search string on that page to add quotes around "Going Green" and searching again.

Not entirely sure where to ask this, but is it known whether there are any issues with the forum's search feature? Several bugs I filed yesterday ended up being duplicates, but the searches I ran didn't turn up any results (and I guess there were a few too many bugs for me to reliably spot them manually). For example, searching in the Bug Reports category for "Going Green" (with or without quotes) turned up nothing, and specifically not this report: Apologies to the bug reviewers for the extra work I caused.

Reported Version: v0.2.0 (latest) | Mods: none | Can replicate without mods? Yes OS: Wine 9.0-rc3 on Linux | CPU: AMD Ryzen 7 | GPU: NVIDIA 3060 Ti | RAM: 32GB When the camera is sufficiently close to a planet with atmosphere, looking outward from the planet causes the planet's atmosphere effects (sky, etc.) to overlay the view of space. Severity: Low Steps to reproduce: Launch a vehicle into an orbit around 100km above Kerbin. Wait until the vehicle is on Kerbin's day side. Enter map view. Zoom the camera in as far as possible. Rotate the camera so it is between the ship and Kerbin (thus looking away from Kerbin). Slowly zoom the camera out, and observe the behavior of the map view. Expected behavior: Either the camera stops above Kerbin's atmosphere, or Kerbin is not displayed until the camera exits its far side. Observed behavior: Various layers of the atmosphere effects overlay the map view as the camera approaches Kerbin's surface. Included Attachments: .ipsImage { width: 900px !important; }

Reported Version: v0.2.0 (latest) | Mods: none | Can replicate without mods? Yes OS: Wine 9.0-rc3 on Linux | CPU: AMD Ryzen 7 | GPU: NVIDIA 3060 Ti | RAM: 32GB When the altitude of a vehicle is right at the boundary where the altitude display changes units (such as 99999m -> 100km), the program seems to either round inconsistently or choose the wrong transition point, such that the altitude may be displayed as 99 of the larger unit (99km instead of 99999m, for example). Severity: Low Steps to reproduce: Go to the VAB, create a simple vehicle with pod, tank, and engine, and send it to the launchpad. Launch the vehicle, giving it enough thrust to make time to use the cheats menu. Press Alt+F8 to open the cheats menu, and set the craft to a circular orbit of 100km above Kerbin. Ensure that the altitude display on the right side of the navball is set to Ground mode. Wait for the vehicle to move over the ocean. Observe the altitude display. Expected behavior: The altitude display shows either "99999m" or "100km". Observed behavior: The altitude display shows "99km". Included Attachments: .ipsImage { width: 900px !important; }

Reported Version: v0.2.0 (latest) | Mods: none | Can replicate without mods? Yes OS: Wine 9.0-rc3 on Linux | CPU: AMD Ryzen 7 | GPU: NVIDIA 3060 Ti | RAM: 32GB In some circumstances, the flight report displayed after recovering a landed vehicle shows what seem to be unrealistic G-force statistics for the flight, such as "highest G: 137.6g" for a simple flight around Kerbin and back down. I haven't found a consistent reproducer for this, but I have noticed that the G meter next to the crew display sometimes jumps to off-scale high for a single frame while orbiting a celestial body, which is clearly wrong (nothing colliding with the vehicle, naturally). Severity: Low .ipsImage { width: 900px !important; }

Thanks for the prompt check. I do recall that KSP1 (in that case, the native Linux version) had the same problem with R&D as well as similar 2D menu scenes (mission control, astronaut complex etc). Perhaps there was some Linux-incompatible v-sync method used in the code for those scenes which got carried over into KSP2? V-sync definitely has an effect in regular 3D scenes on my system (as with the title screen in my reproduction steps).

Reported Version: v0.2.0 (latest) | Mods: none | Can replicate without mods? Yes OS: Wine 9.0-rc3 on Linux | CPU: AMD Ryzen 7 | GPU: NVIDIA 3060 Ti | RAM: 32GB The "Cadet Orientation" setting in the Create New Campaign menu always resets to the "on" state when creating a new campaign, even if it was previously turned off. It might make sense to force this back on when a new mode has been released or to track the state of the switch separately for each game mode, but by turning the switch off, the user is essentially declaring familiarity with game behavior, so I don't see much sense in turning it back on every time. (Admittedly, this is probably not as much of an issue if one is not constantly creating new campaigns to document bug reproducers.) Severity: Low Steps to reproduce: From the title menu, select "Singleplayer" and click "Start a New Campaign". Confirm that the "Cadet Orientation" switch is in the "on" state. Click the "Cadet Orientation" switch to turn it off. Click "Start Campaign", and confirm that the "orientation" video is not displayed. Press the ESC key and select "Quit To Main Menu" from the ESC menu. In the "Save before exiting!" dialog box, click "Save and Exit". From the title menu, select "Singleplayer" and click "Start a New Campaign". Observe the state of the "Cadet Orientation" switch. Expected behavior: The Cadet Orientation switch is in the "off" position. Observed behavior: The Cadet Orientation switch is in the "on" position. .ipsImage { width: 900px !important; }

Reported Version: v0.2.0 (latest) | Mods: none | Can replicate without mods? Yes OS: Tatakae! Ouendan | CPU: Brain | GPU: Eyes | RAM: Not enough In the bug report form on the KSP forum (this very form!), the "Category" field defaults to "Crash", meaning that a user can unintentionally submit a non-crash bug as a "Crash" by forgetting to select an appropriate category. It might be better to have an empty or "(Select one)" default value and reject the submission if the category has not been changed from that default. Severity: Depends on how annoyed the bug reviewers get by improperly classified "Crash" bugs. Apologies: if any of the bugs I've submitted today got filed under "Crash" for this reason. .ipsImage { width: 900px !important; }

Reported Version: v0.2.0 (latest) | Mods: none | Can replicate without mods? Yes OS: Wine 9.0-rc3 on Linux | CPU: AMD Ryzen 7 | GPU: NVIDIA 3060 Ti | RAM: 32GB In the flight report displayed after recovering a landed vehicle, the "Research" list is empty even if experiments were done on the vehicle. (This might be because the experiments are removed and converted to science before the report is generated?) Severity: Low Steps to reproduce: Start a new Exploration campaign. In the VAB, create a vehicle consisting of a single command pod with a Kerbal aboard, and launch it. Click the "Experiment" button in the Vessel Actions box. Press ESC, and select the Recover Vessel option from the Vehicle menu. In the "Confirm Recovery" dialog box, click "Confirm". In the Flight Report which pops up, click the Research header, and observe what is displayed beneath it. Expected behavior: The crew report collected by clicking the Experiment button is listed. Observed behavior: Nothing is listed. .ipsImage { width: 900px !important; }

Reported Version: v0.2.0 (latest) | Mods: none | Can replicate without mods? Yes OS: Wine 9.0-rc3 on Linux | CPU: AMD Ryzen 7 | GPU: NVIDIA 3060 Ti | RAM: 32GB If a Kerbal on EVA is not considered "landed", such as when jumping or when landed on Mun/Minmus, switching from that Kerbal to a nearby vehicle triggers a spurious warning that the Kerbal is "on a crashing course". Severity: Low Steps to reproduce: Go to the VAB, create a vehicle consisting of a single command pod with a Kerbal onboard, and launch it. EVA the Kerbal. Controlling the Kerbal, let go of the vehicle and drop to the ground. Press the spacebar to jump. While the Kerbal is in the air, press the [ or ] key to change vessels to the command pod, and observe whether any warning is shown. Expected behavior: No warning is shown. Observed behavior: A warning that the Kerbal is "on a crashing course" is shown. .ipsImage { width: 900px !important; }

Reported Version: v0.2.0 (latest) | Mods: none | Can replicate without mods? Yes OS: Wine 9.0-rc3 on Linux | CPU: AMD Ryzen 7 | GPU: NVIDIA 3060 Ti | RAM: 32GB When a maneuver node is in a different SOI than the currently controlled vessel, dragging the node adjustment handles adds incorrect vectors to the maneuver velocity. (The vectors appear to be based on the vehicle's current SOI instead of the node SOI.) This makes it impossible to plan a capture by adding a retrograde maneuver node at the periapsis in the target SOI, without first time-warping into that SOI. Severity: High Steps to reproduce: Launch a vehicle to Kerbin orbit. Enter map view,. Accelerate until the vehicle is on a Mun intercept course. Click at the Mun periapsis marker and select "Create a Maneuver Plan". Click the newly created maneuver node to open the adjustment handles. Drag the retrograde handle outward and observe the change in the projected trajectory. Expected behavior: The projected trajectory eventually becomes a Mun orbit. Observed behavior: The trajectory does not become a Mun orbit and instead changes direction to exit the Mun's SOI in a different direction. .ipsImage { width: 900px !important; }

Reported Version: v0.2.0 (latest) | Mods: none | Can replicate without mods? Yes OS: Wine 9.0-rc3 on Linux | CPU: AMD Ryzen 7 | GPU: NVIDIA 3060 Ti | RAM: 32GB When switching from one vehicle to another using the vehicle context menu's "Control" option in map view, the map remains focused on the first vehicle even after control switches to the second. Leaving and re-entering map view fixes the focus. Severity: Low Steps to reproduce: Launch one vehicle to Kerbin orbit and another to Mun orbit, and control the vehicle in Mun orbit. Enter map view, and confirm that the map focus is on the vehicle in Mun orbit. Right-click the vehicle in Kerbin orbit and select "Control". Observe the map focus. Expected behavior: The camera changes focus to the vehicle in Kerbin orbit. Observed behavior: The camera remains focused on the vehicle in Mun orbit. .ipsImage { width: 900px !important; }

Reported Version: v0.2.0 (latest) | Mods: none | Can replicate without mods? Yes OS: Wine 9.0-rc3 on Linux | CPU: AMD Ryzen 7 | GPU: NVIDIA 3060 Ti | RAM: 32GB When time-warping to a specific point on a vehicle's orbit or to the next maneuver node, the incorrect error message "time warp limited due to proximity to celestial body" is displayed at the end of the time warp. Severity: Low Steps to reproduce: Launch a vehicle to orbit. Enter map view. Click a point on the vehicle's orbit line and select "Time Warp to Point". Wait for the time warp to complete. Expected behavior: A success message such as "time warp complete", or no message at all, is displayed. Observed behavior: The error message "time warp limited due to proximity to celestial body" is displayed. Included Attachments: .ipsImage { width: 900px !important; }

Reported Version: v0.2.0 (latest) | Mods: none | Can replicate without mods? Yes OS: Wine 9.0-rc3 on Linux | CPU: AMD Ryzen 7 | GPU: NVIDIA 3060 Ti | RAM: 32GB When entering the Tracking Station, the list of celestial bodies, which normally has a Kerbol "folder" with the various planets underneath, displays only "Kerbol" with a closed-folder arrow next to it. I have not been able to reproduce this consistently; it happens perhaps once in 20 times or so. Severity: Low Included Attachments:

Reported Version: v0.2.0 (latest) | Mods: none | Can replicate without mods? Yes OS: Wine 9.0-rc3 on Linux | CPU: AMD Ryzen 7 | GPU: NVIDIA 3060 Ti | RAM: 32GB When a maneuver node is open (with either the adjustment handles or the control buttons), hovering over orbit markers (PE/AP, intercepts) does not cause their tooltips to show. The tooltips can still be pinned by right-clicking their markers. Severity: Low Steps to reproduce: Launch a vehicle to orbit. Enter map view. Create a maneuver node along the vehicle's orbit. Left-click the maneuver node to open the adjustment handles. Move the mouse pointer over the orbit's PE (periapsis) marker. Expected behavior: The PE marker's tooltip is displayed. Observed behavior: The tooltip is not displayed. Included Attachments:

Reported Version: v0.2.0 (latest) | Mods: none | Can replicate without mods? Yes OS: Wine 9.0-rc3 on Linux | CPU: AMD Ryzen 7 | GPU: NVIDIA 3060 Ti | RAM: 32GB When deleting a maneuver node, a stray "CE" marker (looking similar to the "+" marker indicating a staging point when a burn crosses multiple stages) can be left on the map. I'm afraid I don't have a reproducer for this because I don't know under what conditions the "CE" marker appears - I only saw it this one time and wasn't paying close attention when it appeared. Severity: Low Included Attachments: .ipsImage { width: 900px !important; }

Easy reproducer: launch a ship to Mun orbit, then go into map view and look at Kerbin - as you zoom out, the KSC icon increases in size until it covers Kerbin. Interestingly, as you zoom in (toward your ship), the icon shrinks to the point of being invisible while Kerbin grows in apparent size - so maybe this is just a case of an inverted scale factor?

Reported Version: v0.2.0 (latest) | Mods: none | Can replicate without mods? Yes OS: Wine 9.0-rc3 on Linux | CPU: AMD Ryzen 7 | GPU: NVIDIA 3060 Ti | RAM: 32GB When a ship's altitude is above 1000 km, the map displays the ships altitude using the incorrect spelling "k/m" instead of the correct "km". (Interestingly, orbit node tooltips use the correct spelling.) Severity: Low Steps to reproduce: Launch a vehicle into an orbit at least 1000 km above the surface of a celestial body. Enter map view, and mouse over the ship icon. Observe the unit displayed for altitude in the ship's tooltip. Expected behavior: The altitude is displayed using the unit "km". Observed behavior: The altitude is dispalyed using the nonexistent unit "k/m". Included Attachments:

Reported Version: v0.2.0 (latest) | Mods: none | Can replicate without mods? Yes OS: Wine 9.0-rc3 on Linux | CPU: AMD Ryzen 7 | GPU: NVIDIA 3060 Ti | RAM: 32GB When a Kerbal walks around in EVA, the compass on top of the navball bounces around very erratically. On Kerbin, it settles down after a short time of walking in a straight direction, but on the Mun, it flips around 180 degrees with every step the Kerbal takes. Severity: Low Steps to reproduce: Launch a vehicle with a Kerbal aboard and land on the Mun. EVA the Kerbal. Controlling the Kerbal, let go of the ship and go down to the ground, then face west (270 degrees). Hold the W key to move forward, and observe the behavior of the compass. Expected behavior: The compass consistently points west. Observed behavior: The compass repeatedly flips between west and east. Included Attachments: walk.mp4

Reported Version: v0.2.0 (latest) | Mods: none | Can replicate without mods? Yes OS: Wine 9.0-rc3 on Linux | CPU: AMD Ryzen 7 | GPU: NVIDIA 3060 Ti | RAM: 32GB There seems to be no limit to the number of quicksave files which are created when pressing F5, resulting in potential excessive disk usage. (My two-day-old Exploration campaign already has 52 quicksave files.) Severity: Medium Steps to reproduce: Start a new campaign. Open the campaign's save data folder in a file manager. Launch a vehicle. Repeatedly press the F5 (quicksave) key and observe the content of the save data folder. Expected behavior: The number of quicksave files in the campaign save directory reaches an upper bound, after which the game takes action (reusing filenames, deleting older quicksaves, etc.) on each quicksave to keep the number of quicksave files within that bound. Observed behavior: The number of quicksave files increases without apparent bound. .ipsImage { width: 900px !important; }

Reported Version: v0.2.0 (latest) | Mods: none | Can replicate without mods? Yes OS: Wine 9.0-rc3 on Linux | CPU: AMD Ryzen 7 | GPU: NVIDIA 3060 Ti | RAM: 32GB The game does not recognize the JP106 (Japanese) keyboard layout in the context of keyboard controls (movement, etc). Input in text boxes works correctly. Note that because I am using Wine on Linux, I can't say for sure whether this is a problem unique to my environment - but the only other programs I have seen which don't correctly recognize my keyboard are those which don't support non-US layouts in the first place. Severity: Medium Steps to reproduce: Configure a runtime environment with a JP106 keyboard. Start the game with default settings, go to the Create New Campaign screen, and click in the Campaign Name text box. Press the "]" key on right side of the third row between ":" and Enter, keycap: ]}む」 Observe that a "]" character is entered into the text box. Start the campaign (it may be necessary to delete the "]" character due to other reported bugs related to file I/O), launch two vehicles, and maneuver them to within switching distance. Press the "]" key and observe the result. Expected behavior: Control switches from one vehicle to the other. Observed behavior: Nothing happens. .ipsImage { width: 900px !important; }

Reported Version: v0.2.0 (latest) | Mods: none | Can replicate without mods? Yes OS: Wine 9.0-rc3 on Linux | CPU: AMD Ryzen 7 | GPU: NVIDIA 3060 Ti | RAM: 32GB When using the EVA jetpack on Mun or Minmus, thrusting up (away from the surface) adds a forward velocity component, and thrusting down adds a backward velocity component. This does not seem to happen while in orbit (at least not that I've been able to notice). The navball velocity mode (orbital vs. surface) does not seem to make a difference. Severity: Medium Steps to reproduce: Launch a vehicle with a Kerbal aboard and land it on the Mun. EVA the Kerbal. Controlling the Kerbal, go down to the ground, then move a short distance away from the landing vehicle and face it. Activate the Kerbal's EVA jetpack. Hold the left Shift key until the Kerbal rises above the height of the vehicle, then release the key. Observe the Kerbal's path. Expected behavior: The Kerbal lands in the same place it started from. Observed behavior: The Kerbal jumps over the landing vehicle. .ipsImage { width: 900px !important; }