Forrey

Reported Version: v0.2.0 (latest) | Mods: none | Can replicate without mods? Yes OS: Windows 10 Home | CPU: AMD Ryzen 5 2400G | GPU: AMD Radeon RX 6700 | RAM: 32GB Consider the scenario: you're playing KSP2 and in the middle of something, but it's time to prepare the dinner, or do something else that takes a bit of time. I could save my position and then shut the game down, but it's a lot more convenient to just leave it in paused mode. However, when I do that, the task manager tells me that KSP2 is still using nearly 100% GPU, and a fair chunk of CPU too, despite it showing a static image. Of course, if I use the mouse to pan the view around it's not static anymore, so _just_ showing a static image won't work in all situations. However, it would be really nice if the game could go into some low-power mode when there's literally nothing changing on screen, and no time passing to necessitate game state being updated. Not having any experience in 3D game development, I have no idea how hard that is to do, but I'm filing this bug just in case it's really easy - it could save a lot of power. Thanks

Reported Version: v0.2.0 (latest) | Mods: none | Can replicate without mods? Yes OS: Windows 10 Home | CPU: AMD Ryzen 5 2400G | GPU: AMD Radeon RX 6700 | RAM: 32GB I'm attaching a saved game. In it, Val is in her lander on the surface of Moho, ready to go find herself a snack. To reproduce the bug, click on the EVA button to move Val to the lander can's door ladder. After a very short moment, the entire lander jumps up (seemingly pushed by an upward force from Val herself). It will then spin around a bit, losing parts, and can end up with the thing accelerating along the ground with Val underneath. If you EVA Val and them immediately hit Space to get her to let go, the lander doesn't jump. If Val then jumps back on and grabs the lander can, she also doesn't exert any force on the lander. Included Attachments: BUGValexitingcausesflip.json .ipsImage { width: 900px !important; }

Reported Version: v0.2.0 (latest) | Mods: none | Can replicate without mods? Yes OS: Windows 10 Home | CPU: AMD Ryzen 5 2400G | GPU: AMD Radeon RX6700 | RAM: 32G In the Research and Development view, at level 2, under "Medium Payloads", there are two saddle truss parts listed: MST-S and MST-L. There is no MST-M. Despite this, the description of the MST-L part says: "The MST-L Saddle Truss is longer, stronger, and more tubular than the MST-M."

Reported Version: v0.2.0 (latest) | Mods: none | Can replicate without mods? Yes OS: Windows 10 Home | CPU: AMD Ryzen 5 2400G | GPU: AMD Radeon RX6700 | RAM: 32G Entering the R+D 'building' always opens with level 1 highlighted. I've already (dedicated researcher that I am) unlocked everything in level 1. It would make more sense, given this fact, for the tree to open at level 2. Just a 'nice to have' really, but thought I'd mention it all the same.

Reported Version: v0.2.0 (latest) | Mods: none | Can replicate without mods? Yes OS: Windows 10 Home | CPU: AMD Ryzen 5 2400G | GPU: AMD Radeon RX6700 | RAM: 32G The main mission description for the "Better Signal" mission (send probe core to Jool) says: "We're getting farther out into the <style="OBJ-Kerbol">Kerbollar System We're going to need to set up communications to keep getting signals." Included Attachments: .ipsImage { width: 900px !important; }

Reported Version: v0.2.0 (latest) | Mods: none | Can replicate without mods? Yes OS: Windows 10 Home | CPU: AMD Ryzen 5 2400G | GPU: AMD Radeon RX6700 | RAM: 32G Fairly early on there's an optional mission to launch something with 4 wheels. I tried it a few times with LY-10 landing gear, as I hadn't unlocked rover wheels yet. The mission doesn't accept this as a success condition. As far as I can tell, it only accepts rover wheels. While rover wheels are just listed as 'wheels' in the VAB, and this is probably what the mission refers to, landing gear are wheels too, at least from a human understanding perspective. Please either change the mission statement to specifically refer to rover wheels, or allow landing gear to be acceptable: the current wording is a bit confusing. Thanks :-) Included Attachments: .ipsImage { width: 900px !important; }

Reported Version: v0.2.0 (latest) | Mods: none | Can replicate without mods? Yes OS: Windows 10 Home | CPU: AMD Ryzen 5 2400G | GPU: AMD Radeon RX6700 | RAM: 32G Steps to reproduce: Activate the "Kerbwide Tour: Kapy Rock" side mission (take report at Kapy Rock with a lander can). Go to the tracking station. In the left-hand locations list, "Kerbwide Tour: Kapy Rock" appears as a new item below "Minmus". Click on "Mun" (or "Minmus") - the Information Panel shows sections "Synopsis", "Orbital Characteristics" and "Physical Characteristics". Click on the Kerbwide Tour: Kapy Rock entry: the total in the Information Panel changes accordingly, but the "Synopsis" and "Orbital Characteristics" sections from the moon are still shown. The "Physical Characteristics" section has gone. A similar error happens when switching to the "KSC" entry (which shows a section "Crew" in the information panel). Switching from KSC to the Kerbwide Tour entry leaves the "Crew" section visible.

Reported Version: v0.2.0 (latest) | Mods: none | Can replicate without mods? Yes OS: Windows 10 Home | CPU: AMD Ryzen 5 2400G | GPU: AMD Radeon RX6700 | RAM: 32G For science(!) is lovely - having lots of fun. Reading through the mission brief for "Mun or Bust", the penultimate message from Keri is: "Set up a vessel with a probe core and an antenna with a minimum range of 86Gm around Jool" I suspect this is misplaced. .ipsImage { width: 900px !important; }

Reported Version: v0.1.3.2 (latest) | Mods: none | Can replicate without mods? Yes OS: Windows 10 Home | CPU: AMD Ryzen 5 2400G | GPU: AMD Radeon RX 6700 | RAM: 32GB I'm going to try to attach a craft file which reproduces this, and also a screenshot. Basically, attaching a fuel tank to a craft via two docked docking ports, it seems not to be possible to prevent fuel (and oxidiser) from draining from said fuel tank, despite both docking ports having fuel cross-feed disabled. I discovered this while trying to develop a spaceplane capable of dragging a full fuel tank into LKO. The craft I created shows fuel draining across 4 of the different kinds of docking port. Included Attachments: BugBuster.zip

Reported Version: v0.1.3.2 (latest) | Mods: none | Can replicate without mods? Yes OS: Windows 10 Home | CPU: AMD Ryzen 5 2400G | GPU: AMD Radeon RX 6700 | RAM: 32GB Summary: when a craft is on an encounter with a body that will only slightly perturb its orbit, two trajectories are shown very close to each other before the encounter. When clicking on the double-line, the one selected is that from after the encounter, rather than that from before. As such, attempting to "warp here" results in a missed encounter. More detail: I've attached a zip file with two screenshots. My craft is on a very slight intercept course with the Mun. This will perturb my orbit of Kerbin by some small amount, and thus results in my trajectory being shown as two blue lines (from where I am to Mun encounter, followed by the whole of the next orbit of Kerbin after the minor deviation). A natural thing to want to do is to warp closer to the encounter, possibly to adjust ones approach. However, when I click on the trajectory line before the Mun encounter, it shows I'll reach that point in 5d, 1h, 43m (one screenshot), while if I select a point just after the Mun encounter, it shows only 4h 33m. Indeed, if I try to warp to before the encounter, it sends me through the Mun encounter, then all the way around Kerbin, and back to the selected point on the post-perturbation trajectory. I think it would make more sense if, when I click on a place where there are two trajectories (pre and post perturbation), the game should default to selecting the earlier-occurring of the two. In the case of the Mun encounter one only loses a few days; I've had this happen to me with a Dres encounter though, which cost me a few years, and by the time the thing stopped timewarping Dres was entirely on the other side of the solar system. Thanks. Included Attachments: Screenshots.zip

Reported Version: v0.1.3.2 (latest) | Mods: none | Can replicate without mods? Yes OS: Windows 10 Home | CPU: AMD Ryzen 5 2400G | GPU: AMD Radeon RX 6700 | RAM: 32GB See attached screenshot. I'm in orbit around Kerbin, and have set up a manouver node to the Mun. The blue line still shows my current trajectory, with the orange one showing where I'll be going post burn. If I click on the orange projected line, I'm offered the ability to "Time Warp to Point", despite the fact that (unless I execute the burn) I'm never going to get to that point. Clicking on that item seems to warp me to an equivalent time in the future such that I would have got to that point in the orbit had I executed the burn as projected. I don't think "Time Warp to Point" should be shown on projected post-burn lines. Included Attachments:

Consider this situation: I've just docked my rather complex spaceplane (with 12 small fuel tanks) to my space station. I want to refuel. To do this using the current resource manager, I need to identify the reserve fuel tank(s) of the station, and the tanks of my spaceplane (and it may be just one of many craft currently docked). It would be helpful if I could group and name tanks. For example, I could have one group called "Station Fuel Reserve", and another group "Spaceplane XR Tanks": I can then just select these two and transfer, without having to individually select every tank on the craft I want to refuel). I'm not entirely sure of the correct approach to this: one might represent the tanks as a tree, having the root node contain the whole craft, with sub-nodes showing different sub-craft (currently held together via docking ports). This is going to work poorly if the station is build from multiple parts docked together, though. Possibly something 'simple', like being able to do a one-off manual grouping of parts, might be a good approach. Not sure. Being able to easily distinguish different craft in the Kerbal manager might also be helpful. Side note: the current system is already better than KSP1 - having to click on each fuel tank and pin its window open in order to refuel something was always a pain.

Note that it is not necessary to dock or decouple in order to provoke this behaviour. I've seen the same bug after merely rendezvousing two craft, and then de-orbiting one of them (using several timewarps).

Drat. Good to know, thanks. It seems only the last image (showing the broken space station orbit) has been preserved. I probably didn't really need all those screenshots anyway - it's the instructions that are important, and those should be easy to reproduce. However, including the saved game would help. I have it (at a position where you can jump straight into step [2] above), but I don't see how to attach it, now that the bug has been posted. Please let me know if there's some way to share it.

Reported Version: v0.1.3.1 (latest) | Mods: none | Can replicate without mods? Yes OS: Windows 10 Home | CPU: AMD Ryzen 5 2400G | GPU: AMD Radeon RX 6700 | RAM: 32GB Steps to reproduce (using the attached craft file): 1: Launch into orbit, about 100km and roughly circular. Once you're in orbit, you should have the core of the station, with the last bit of the launch vehicle (with the 8 parachutes on it). Screenshot #1 shows this from the map. 2: Stage, and then use '['to flip to the launch vehicle. Hit 'T' to enable SAS, and rotate to point retrograde. Screenshot #2 shows this in progress. 3: In screenshot #3 (post-separation), both craft are still in a 100km circular orbit. All fine. 4: Hit the gas for a bit to put the launch vehicle into a collision course with the atmosphere (screenshot #4). Getting PE down to 20km is enough. 5: Screenshot #5: the map view shows that the orbits are fine - launcher is going down, but the station is still in orbit (screenshot shows a collision with the planet instead of 20km PE, but that doesn't seem to matter). 6: Once the station is 500m away, hit the timewarp button a few times (2 or 3). Keep timewarping until the station is 5km away, then cancel timewarp. 7: If you check the map view at this point, the station is _still_ on a circular orbit. 8: Timewarp again. The station will start riding up in the sky, as it gets further way. Once it gets towards about 10km away, stop timewarp. By this time, you should have seen a "station is on collision course" warning. 9: Screenshot #7: Checking the map view, our launch vehicle is still on its way to the surface, but also the space station core has left its 100km circular orbit, and is now on a highly eccentric... deorbit. I've reproduced this (with similar craft) many times. The corruption of the station's orbit seems to be caused by a transition into timewarp, then out, and then in again. A single timewarp does not seem to trigger the bug. The screenshots attached are from a different time I reproduced the bug. On this last run (without screenshots) I tried to be as specific as possible with the timings. Included Attachments: Kerbstationpart1.json

Hi. Ryzen 5 2400G; Radeon RX6700; 32G RAM; Windows 10. It consistently takes about 25s from me clicking on "revert to VAB" to actually getting to the VAB. On the other hand, going the other way (from VAB to runway) takes just a few seconds. Please consider optimising the VAB loading. I was recently trying to diagnose a bug in how wing pitch works, switching back and forth between runway and VAB, and the 25s delay each time makes this frustrating. Thanks.

I've encountered the same effect, and spent some time trying to diagnose why. I tried making a long plane with pairs of wings at the front and back. Initially the ailerons would always be inverted while trying to climb/descend, but worked correctly for roll. Inverting the control direction of the wings would thus not work well, as rolling would be reversed. After many attempts at trying different sizes of wings, eventually the game got to a state where the problem was no longer occurring. I've not managed to figure out the trigger that causes the inverted behaviour. I've tried: Adding the wings on either side (on the left, with symmetry adding the right one, or on the right, symmetry adding the left one). Adding the wing on one side, then moving it to the other side. All 3 different wing sizes. With manual edits and without. Rotating the wing a little, or adding it at an angled location (ie not sticking out directly left/right. None of these made a difference to whether the bug occurred or not. When a plan has a pair of wings at the front and one at the back, (on either side of the centre of mass, I presume), their ailerons will move in opposite directions to each other when trying to climb or descend. I'm not sure this is right, but I'm also not a fluid dynamics expert. When the bug hit, trying to climb would make the rear aileron turn downwards, and the front one turn upwards.

I was about to file a duplicate of this, but here's what I found, running the 2023-03-16 patch: Go to VAB, and start building a plane. Add a pair of wings with aeroplane (mirror) symmetry. They look normal. Click on the little spanner (aka wrench) icon to open the wing shape edit dialog. While the wing shape edit dialog is open, one of the wings is displayed as being upside down, as if it was attached with radial symmetry. Closing the shape edit dialog causes the wing to flip back to mirror symmetry.

Version: KSP2, patch 1 (2023-03-16); Windows 10. Steps to reproduce: Start campaign. Go to VAB. Click 'Open' button in top-right corner of screen. Of the 8 pre-built vehicles shown, select the "Stock Aeris-K2". The plane opens in the VAB, but the proposed launch site is "Launchpad 1". Clicking on "Launch" does indeed put the plane on launchpad 1, and due to the railings and lack of on-ramp, it's not possible to launch from there. Expected behaviour: the default launch site should be "Runway 1" (or 2). The "Stock RC Sparrow" uncrewed drone, by constrast, defaults to Runway 1.