Spicat

Here you go: With the interesting bullet point: I hope this big UI update will be before or with colonies but at least they did hear all the stuff we had to say about the UI (I hope they also considered my UI post)

Yes, after 1.0

September would be 8-9 months since For Science! Considering Nate Simpson said: "...we are looking at a significantly shorter turnaround time" (https://youtu.be/FXG3eOZbo4M?t=941) "I would expect that the turnaround for future roadmap updates will be significantly compressed relative to the amount of time it took between launch and the first roadmap update" (https://youtu.be/aHQXJuSBR4I?t=1132) Even if those quotes are surrounded with big caution that this might not be the case and with their past history of delays, it would still be disappointing if the colonies take the same amount of time or just a little bit less time (like 1 month short). In my opinion, they will still take quite some time and deliver the update in August, which would be 7-8 months since For Science!. That would mean they can squeeze 2 patch updates in the remaining 4-5 months. I hope that they can improve the performance for part counts significantly (same goes for background vessels) for the Colonies update, because it will be unplayable otherwise. Talking about the next patch, I think it should arrive in the coming weeks considering how long it's been and how the candidate branch on steam is getting updated. It might also be the longest time an update took (as seen below (without counting hotfixes)).

I just want to recite Nate answer about commnet even if it's very off topic because some people seems to place this feature above anything else, even new features: They never said commnet was not in the game (at least the more complex one) because they want to make the game "easier" or something like that. They just don't give this feature the highest priority and it's more at the bottom of their list. So @steveman0 is right there. And for those that really can't wait and find this feature really important, there is a mod:

Also, do not use discord link, they expire

Interesting topic! Always great to hear how stuff work. For the future, like The Aziz linked, it would be cool to see the eclipse being actually projected onto the surface of the body instead of dimming the whole body like it currently does. I don’t know how this could be integrated to the system you presented.

I suspect this bug is related to landing legs, so if the craft you're controlling is always the one without landing legs (or the one that is big enough to not be noticeable), it can explain why you don't see it for the current one.

@EvilDr.Porkchop, merged your bug report. @The Aziz, merged your bug report with your old one. If you think those are both different and can explain why, I will put it in another bug report again.

@Winterstein, can you confirm that your bug report is about the german translation missing from the science report? For the number of science point it's another problem: https://forum.kerbalspaceprogram.com/topic/223498-science-multiplier-not-working-dres-eve-vall-very-low-science-rewards-for-some-region-on-other-celestial-bodies/ Also, I will probably make that bug report a respository for all missing translation in the game if there are other bug reports like this coming, to make things more organized. (Not just for German)

You can also do the same. Like I said I'm not the only one doing that. Ultimately, we try our best that the bug reports that people complain about are being properly represented (but I'm a simple user in this case so it's to people to upvote). But letting bug reports unarchived is not a solution to people not finding the bug report they want to upvote, quite the opposite even.

Yes, don't check that filter, it searches in the wrong category. Go to https://forum.kerbalspaceprogram.com/forum/144-ksp2-bug-reports/ Search in the box here (check that "These Forums" is checked) For more info see the "How to search the forum for existing bug reports" in https://forum.kerbalspaceprogram.com/topic/222806-bug-reporting-guidelines/

Oh believe me I'm probably the best placed to agree to that lol. (You can try to look at how to search: https://forum.kerbalspaceprogram.com/topic/222806-bug-reporting-guidelines/, but even for us it's pretty clunky) That will probably stay like that unfortunately just because the forum is based on a software that is limiting them (https://en.wikipedia.org/wiki/Invision_Community 20 years old stuff). That's why we can't order by upvotes. And they won't completely change the forums software when the community has used it for years and it works. I know that Dakota tried to make a new version for the bug report list but I don't know how far he succeeded. For the upvotes, to compensate for all that, I try to "advertise" the ones that I find important (when I see some people complaining about it on reddit/youtube/twitch/discord/forum or other platform) on the discord where a lot of people are casually looking. Other people also do that so that help. We're also here to merge the bug reports (Starting to know them by heart) and thus do the search for you.

That's not the case. They just can't look at every single one of them, and the word "look" is an understatement of the amount of time needed to check a bug report. So the explanation to why they are archived is to have a list of bug report up to date like I said. That doesn't mean they don't look at any of them, but that's why the upvote system is important, to let them know what bug need to be looked at (and fixed) asap. It also doesn't mean that bug reports with single digit upvotes don't get looked at. For instance, Anth seems to look quite a lot to the list of bug reports, but obviously it takes time to report a bug internally (from what I understand, it needs to have a 100% reproduction by ideally creating the condition from scratch (so not from a user save/craft file) which is sometimes impossible when a bug report has not enough information even more when it's an anonymous bug report), so they can't manage the hundreds of bug report from the KERB. Their main work is managing their internal list (which is not only on this version of the game obviously).

@ShadowZone, merged your bug report. Simple eclipse. With a mix of that:

@ShadowZone, merged your bug report.

Bug reports under a certain amount of upvotes are archived each update (not counting hotfixes). It's to not have 70 pages of outdated bug reports and to assure that those bugs are still happening, they get dearchived as soon as there is a new bug report about it (even if it's just a small sentence saying the bug is still happening with the link of the old bug report). We can't just check that each bug report are still happening after each update (even if we try), this would take a riduculous amount of time, more so of being mostly impossible for bug reports that don't have enough information or that we just can't reproduce (like dependant on specs for instance).

No

Pretty sure that's planned:

@Stephensan, merged your bug report.

The author and I couldn't reproduce it after that day, so no idea what was going on. If anyone is experiencing this bug again, please give some other information, it could help.

@PilotWasHere, merged your bug report.

@Abelinoss and @mattihase, merged your bug report. I analysed this bug a little bit and I will try to explain my understanding (I hope I didn't get anything wrong). First of all, mirror symmetry in ksp is not a real mirror symmetry, it's just rotating the part for 180° (Both in ksp1 and ksp2). Each part as what I will call an "identifying feature" that is the thing that lets us know which side is the part. Thus, that explain why some parts are not rotated, because it would make an identifying feature on the "wrong side". Take the Mk1 "Tin Can" as an example. If we take the window as an identifying feature, the game as the right symmetry: But now if we take the ladder as the identifying feature (that's not the case in the game), we have to rotate the part: The symmetry will be correct for the door/ladder but not for the window anymore. So in the game, currently, the identifying feature would be the window for this part. If we decided that the identifying feature would be the door/ladder, the part would be rotated wrong. Thus, asking for some parts orientation to be changed could be considered feedback. (For the tin can, there is not a right or wrong direction, it's a choice) But, I tried to list the important ones that are objectively the "wrong" direction: RF-AD-SL 2500 ASCM-B "Little Sniffer" RGSCM-01 "Science Jr. Jr." RSCM-01 "Sample Grabber" OSCM-01 "Mini-Lab" Parenthesis are the identifying feature S3 KS-100 "Mammoth-II" (Preburner exhaust pipe) LV-2000 "Trumpet" (Little buttons and side pipe) LV-1000 "Cornet" (Ball) LV-N "Nerv" (Nuclear icon and side pipes) For the science parts, the bug is pretty obvious: And for the other parts, in my opinion, they are in an appropriate direction (at least if I didn't forgot some of them).

@Filed.Teeth, merged your bug report. Don't know how to fix this, but you could use the cheat menu (ALT+F8)

Not a lot of people seem aware of prelaunch info, The Aziz made a topic back then. It's very good to summarize all of this:

@Koddra, merged your bug report.