Navoan

Reported Version: v0.2.1 (latest) | Mods: none | Can replicate without mods? Yes OS: Windows 11 | CPU: i7-14700KF | GPU: 2070 SUPER | RAM: 32GB When in orbit around a body that isn't strictly spherical the low orbit trajectory lines show the vessel as crashing. I expect that the trajectory in fact checks if my craft will interersect terrain in an exact manner, and show this exact impact site. As it is, there was an impact, but not where it was shown on the trajectory (even though there was a ~1600m close flyby) at that point. After going to KSC, time warping, and coming back to the craft after that 'impact' point, the trajectory updated, like to how I would have originally expected, like this: Whilst close the lowest altitude here was 1160m. Which is far from an impact. Included Attachments: Save2024-03-23BopCrash.json .ipsImage { width: 900px !important; }

Thanks for the replys!

Orbiting Bop atm and yeah, wow, this being changed would be lovely. Workaround is go to to KSC, then to Tracking Station, Focus on the body your craft is on/around and then time warp. But still, irritating.

Also having this issue. Affects all craft and Tracking Station. I had taken some screenshots landed on Pol (F2 usage), biome hopped a few times, and now poof no trajectory lines.

Checking the Wiki for KSP1 it lists the Poles as a biome on Pol. I have been trying now for the past while to get to the poles on Pol, without success. Are they not at the 'magnetic' poles? I've flown North, and south, until the nav ball spins and I'm heading in the other direction, meaning I've flown over the actual pole of the moon, without the biome switching. I've looked for any noticable areas on the map/visually and there's nothing really, apart from the Southern pole having 'swirly'/pinched graphics on the map, which could indicate the pole. Am I missing something, or are there no poles anymore on Pol?

Experiencing this too when doing a quick load on Lathe. At first I thought when re-loading there was a bug and the parachutes simply weren't there! But then I noticed the speed and figured they just aren't rendering.

Yup, this is a frustrating one. After staging the game is saying my ship has 0dV, when in fact I have two full tanks. I can USE the engine, there is fuel... yet saying 0dV. This wouldn't be the end of the world, ok I can't tell how much dV I have, however, on top of it all, I can't make a maneuver node due to having 0dV! So now I'm stuck with a stage full of fuel, that I can't plan for. That is an issue.

My two cents here are: It is really quite difficult to search the forum for anything to check if an issue has been reported before. And the effort to make a bug report is non-trivial. I completely understand the forum is old and has technical debt, thus it isn't worth 'fixing'. Right now people don't know if their bug reports and/or requests etc, which get archived, are simply now in the void, or if they got recorded/discussed before that action was taken. So they may feel disheartened due to the feeling that their effort was mostly pointless. Potential fix? How about a simple google sheets (or equivalent) with all the currently tracked bugs. Imo this list wouldn't even need to have statuses for all bugs/requests/features/whatever, it could simply be a repository for the community to know what information has been gathered before. A simple note in the docs saying 'need more info' with a link to the forum bug post would even allow the community to give help where it's beneficial. And there would be one common, and searchable, place for us to go to find these things. Right now, if something is reported as a bug, and the devs feel it's working as intended, it simply gets archived and poof the community have no way to know. If archived posts were still contained in this list (which granted would get large) at least we could still see X had been posted before and the resolution of said thing. Can't be fun for you Bug Hunters to constantly need to merge reports because people searched but were still unable to find any matching issue.

Plenty of replies here, but also experiencing this and is pretty game-breaking I feel.

Well articulated response with some great examples. Couldn't agree more.

@Spicat Just fyi, I think perhaps you changed this to incorrectly show v0.1.5 (as in the your quoted bug report), but my bug report is for v0.2.1

I saw this actually, and was unsure. I feel it maybe has the same root cause, but this referred to it happening under acceleration yeah. Time warping when not thrust is being applied also causes this same behaviour. Feel free to merge though!

I saw this was flagged as working as intended. I don't quite understand that decision. As of right now you need to always time warp to just outside the SOI and manually TW to get into the SOI to then plan a retrograde burn. You can't even select the line to time warp to inside the SOI. This creates a real moment of irritation every time it needs done.

Reported Version: v0.2.1 (latest) | Mods: none | Can replicate without mods? Yes OS: Windows 11 | CPU: i7-14700KF | GPU: 2070 SUPER | RAM: 32GB If you have a kerbal on a ladder in Orbit and then timewarp, they start to float away from the craft. When you stop timewarping they snap back to where they should be. Included Attachments: .ipsImage { width: 900px !important; }

Proceedural ladder lengths? Well well... Would be too OP if it extended beyond the ship, need a reason to have extendable ladders, but not the worst idea imo!

Reported Version: v0.2.1 (latest) | Mods: none | Can replicate without mods? Yes OS: Windows 11 | CPU: i7-14700KF | GPU: 2070 SUPER | RAM: 32GB Severity: Medium. Frequency: Unsure. Issue: In orbit around Duna I expect that when my crafts trajectory enters Ike's SoI the affect on my crafts trajectory will be shown correctly, i.e. that Ike's gravity will change my trajectory. What is happening is that after a standard launch from Kerbin into Duna orbit, intersecting Ike's SoI doesn't show to have any impact on my orbit trajectory. But when passing into the SoI the trajectory is then updated. With a manuever node it seems like when the Periapsis is higher than ~393k (hard to get exact number) above Ike the game simply stops showing that the craft will enter the SoI. Included Attachments: KerbalSpaceProgram22024-03-0921-46-08.mp4 AutoSaveRevolution03_04_202423_39.json

Had this issue recently, parachute was just barely covering the door and was not obvious at all that it would be an issue. I feel a warning before being able to launch, or at least a mention in the Engineers report, could help with this. Should we test every entry/exit possiblity on each craft, yes, do we... well this is KSP afterall!

Upvoted as this is something that would be lovely to have.

Since this was birthed again from the Archive, just posting that I agree with the comments made here that this feels unintuitive. Embeded video in my post showing the confusion it causes and leaves the player shouting WHY at the screen.

Appreciate that, judging by the comments this really is an 'issue', either to be changed to continuous traveral by default, and/or add a settings toggle to enable this, or make a UI change to help the player intuitively understand that each ladder needs needs to be grabbed. Because as it is now, it just isn't intuitive.

I honestly searched the forum using key words, and didn't find anything, and hadn't thought to check the bug list (unsure this classifies as a bug per say?) but I appreciate being informed about this! Nice to see that the team feel it is an issue that can be fixed.

I have an issue, when I have craft orbiting a body, say Duna, it is near impossible to easily target said body, Duna, from another body such as Kerbin. The game constantly wishes to select the craft that are orbiting, instead of the actual planet. Would it not make more sense to prioritize the selection of the body when viewing from far away in the map view, rather than any of the craft currently already in orbit? In the image below, from Kerbin, it's simply impossible to do without double clicking one of the craft to go into Duna's SOI and selecting Duna, only to do the same thing to get back to the craft in Kerbin Orbit.

I see a design decision has been made to handle ladders differently, essentially you need to grab each section of ladder to continue climbing. I'm not against this, and I see in the UI the Grab (F) UI action pops up when reaching a new ladder piece. But my honest feedback was that this was not attention grabbing (no pun intended) at all, and I had zero idea this was how it was now functioning. I would have loved the Grab button to start flashing at me or... something. Anything. Understandably I missed the F button showing up on the UI, and taking a step back from what I was doing, I can see it popuping up, I get that, but in the end as someone who has played a fair bit of KSP I flet stumped, I resulted in google, and found a reddit thread which instantly had the answer for me. But still, was a frustration for a while as to why I couldn't get it to work. The camera shake in the reddit vid is perfect to show the frustration you feel when something seemingly 'should' work, but doesn't. Why is it that a series of ladders in a 'row' as in the vid, should stop you continuing down the ladder?

New install of KSP2, returning from Kerbin orbit and experiencing this bug, MK16 parachute just will not deploy with staging, or manually trying to deploy. Tried reloading, same result. Reloaded again, staging wouldn't work, but was finally able to manually deploy the chute. Same entry profile etc.

In KSP1 I sent a probe to the Mun, only to loose signal. It was a what moment for me. But that triggered me to set up a comms network and I enioyed that! It was fun, it made the mission possible. Add a tutorial about good orbits for relay satalites etc and its gg. Plus a toggle so people can opt out/in, I get newer players may not want to/care about this, but it is a step too far away from realism imo.