Snark

Some content has been removed. Feel free to share your "unpopular" opinion about the game, folks. But dissing on how your fellow forum members prefer to enjoy the game, or implying that how they like to play is somehow inferior to your own, is seriously not cool. Being rude and disrespectful is certainly unpopular, but it's not appropriate here, so just don't go there, please. Thank you for your understanding.

Moving to Add-on Discussions, since this is not a mod release thread.

Thank you for reaching out! We're currently reviewing and will get back to you as soon as we can.

The first thing I wondered was what it's using as its boundary condition when parsing. For example, is it counting incidence of "KSP" only as a term of its own, or is it counting any word in which the sequence "k, s, p" occurs? For example, Shakespeare's name has been spelled in various ways over the years. "Shakspere" is one example. Would that be counted here, or not? (I don't know anything about how Google Books Ngram is implemented.) That said, though, I just went and did a Google Books search for "KSP" and constrained it to 1700-1750. Turns out that it appears a fair number of times, referring to other things of course. https://www.google.com/search?q=KSP&source=lnt&tbs=cdr%3A1%2Ccd_min%3A1700%2Ccd_max%3A1750&tbm=bks

Moving to Add-on Discussions, since this is not a release thread. Also, @dstymindz71, welcome to the forum!

So, everything is a tradeoff, and nothing is unalloyed good. The tricky part comes in balancing the tradeoffs. It may be instructive to review the history of open-versus-closed betas with KSP 1. Once upon a time, when KSP had a major release coming out, there used to be a thing called "Experimentals" where basically anyone who wanted to could sign up for it to get an advance peek at the upcoming release, with the opportunity to submit bugs, feedback, etc. An open beta, basically. It was that way for a while, and then eventually they shifted to doing a closed beta. Instead of having it open to the general public, they limited it to a relatively small number of people (regular players doing it as volunteers, not paid staff). Once they shifted to that pattern, they stayed that way for the remainder of KSP's lifecycle. The small, closed beta was entirely private, with members not allowed to share what they saw with the public. So, it's worth asking the question: why would the company do something like that? Obviously, they thought it would be "better" for some reason, but why might that be? (Especially why would they think that's better when they already had the experience of large open betas?) After all, with the open beta, they'd get far more users providing feedback and trying all sorts of things and finding bugs and so forth, so that must be better, right? Why would they prefer something much smaller? Well... it turns out that "more" does not necessarily equal "better". Here are a few of the benefits you can get with a closed beta rather than an open one: Much more actionable feedback: Pretty much every avid KSP player knows what they like and is ready to share opinions. Lots of them would be happy to report bugs, too. However... reporting in a way that is useful to the developers is a specialized skill, and lots of people don't have that. The only good way to report actionable feedback (either a bug report, or a suggestion) is to file a bug in a bug database. And the bug has to be couched in terms that are actually useful to the devs-- for example, if there's a bug in the program, then the report needs to state a clear and succinct repro case for how to reproduce the bug. Most people don't know how to do this. If you have a closed beta, you can pick and choose whom to let in, and so you have a population of reasonably-trained people giving you feedback, who can be counted on to be diligent about checking for duplicates before filing, and whose goodwill is assured. As a developer, it's much more useful to have 200 good, actionable bugs than to have 10,000 bug reports & miscellaneous feedback, of which 90%+ are either unactionable or duplicates of each other. Having the huge numbers of bugs not only doesn't help, it actually hurts because now you have to spend your time hunting for the needle in a haystack and triaging endless cruft rather than spending time actually, y'know, developing and fixing bugs. There are other considerations below, but I think this one's the biggie. Participants with the right motivation: What the devs need, from a beta participant, is someone who is motivated to do whatever is necessary to make the game better (even if it's un-fun and boring). What they do not need is someone whose primary motivation is just to have fun, and who wants to get their hands on it earlier rather than later. Really good beta work is a form of drudgery. "Game tester" may sound like an awesome job title ("Oh man! You mean I get to play games all day and get paid for it? Sign me up!"), but it's actually a lot less fun than it sounds like, even if you're getting paid, which beta participants aren't. Someone who makes a good beta tester needs to be patient and have a high tolerance for repetition and attention to niggling little details. This does not describe most people, and it does not describe the primary motivation of most people who sign up for an open beta. The devs need people who will do the drudgery, not play the play. Better engagement: If you only have a reasonably manageable number of people in your beta, and they're all people who have been vetted and approved, then you can have a group chat channel where people can talk back and forth, bounce ideas off each other, exchange thoughts with the devs, etc. This sort of engagement is invaluable. And you can't do that if you've got several thousand random members of the public in your beta. There would be just too many of them, it's not possible to have a coherent chat if there are thousands of people in the channel; plus not all of them would be of good will and on good behavior, so then you'd have to waste more time and resources moderating and so forth. It would be impractical-- the upshot is that with the open beta, it simply wouldn't be practical to have that sort of engagement. Confidentiality: With a closed beta, you can have all the participants sign NDAs so that they can't talk about it with anyone outside the beta. Knowing that they have confidentiality means that the devs can be much more open in talking about what's going on, what their problems are, their concerns about various matters, etc. They can be more free to experiment with ideas that might not pan out and end up needing to be axed or substantially modified. Whereas if it were all out in the open, this is just all sorts of PR disaster just waiting to happen, even if the devs do nothing "wrong". People are funny creatures-- if you show them something they tend to think "yes! that's mine! I'm gonna have that!" and if you then decide not to do it after all, they view this as if you "took it away from them" and can be vocally angry about it in ways that are unhelpful. With a closed beta, it's easier to manage the message, and the general public doesn't get their hands on it until it's relatively polished. It's also the case that with confidentiality, this gives the company various PR options, for example they can choose to do a big "ta dah!" unveiling when they actually release. Sometimes that can have value, and it's nice for the company to have the option. Flexibility & practicality: With a closed beta, the devs can set things up however is convenient for them (which is what they need), without needing to worry too much about "would this arrangement leave anybody out"-- because they can pick and choose who's in the beta. That can greatly simplify things. For example, back when KSP was still doing Experimentals (open beta), there was one release where they announced that they were going to have this open beta, but only people who had KSP via Steam would be able to participate. There were perfectly good, simple, technical reasons for this: at the time, Steam had good support to meet their technical needs (in terms of releasing builds, having the necessary infrastructure for distribution, etc.) The problem is... the general public viewed this as vile discrimination. Lots of people were super eager to get their hands on the early version... and then became absolutely enraged when they were told that they couldn't. (Especially people who bought the game through the KSP store, because they felt they were being "more loyal and helpful" by doing so.) Holy mackerel, the KSP forums were a firestorm for a while. It was pretty much a PR nightmare. There was basically no way to tell people "you haven't lost anything and this isn't personal". Point is: if you have something open to everyone, then the collective community is going to decide that you have to support and allow everyone to do everything, which isn't necessarily what the devs need or want to support when they're busy working their way through the development process. With a closed beta, the devs can simply do whatever is technically easiest and most efficient, and not have to worry about managing the social dynamics of it. ...Anyway. Those are a few of the reasons why a company might choose, for example, a closed beta over an open one. It's worth noting that the folks who made KSP actually tried the open beta for several releases, so they had a pretty good chance to see the advantages and disadvantages of it-- and then, they switched to closed beta and never switched back. I'm not a Squad employee and am therefore not privy to their internal deliberations, but I think those observable facts right there make a pretty strong case that having experienced both options in detail, they decided that on the whole, the closed beta worked better for them than the open one did. That's all ancient history at this point, of course. You weren't asking about original KSP; you were asking about KSP 2. Well... again, I have no idea what their plans are for KSP 2-- I don't know any more about it than you do. And of course, not every company (or even every game from the same company) is always going to do things the same way all the time; KSP 2 has a somewhat different context than KSP did, so the same factors wouldn't necessarily apply. But, that said: it totally makes sense to me that they wouldn't do an open beta. They tried an open beta with original KSP for several releases, and eventually gave up on it and never looked back. So, if it worked for KSP, it's at least plausible that it would work for KSP 2 as well.

I guess, technically, if one wanted to refer to the "dark" side of the moon, it would be the near side, since it has the lunar maria, which appear darker than the rest of the surface. (I mean, it's all fairly dark rock, but the maria appear somewhat darker from a distance.)

Hello, and welcome to the forums! I'm going to go out on a limb here and guess that you're saying "Hi, how are you doing?" in Finnish. FYI, the main part of the forums (such as here) is English-only. However, if you'd like to chat in another language, please see the International subforum. Perhaps you might enjoy this thread?

As @Gargamel explains above, you can report your post with the request to remove. (The reason we don't let people just delete posts themselves is because of the potential for abuse, e.g. from trolls and such.) We're happy to remove a user's post when they request it... on one condition: only if nobody has quoted it or responded to it. Because if someone has responded, then deleting the original would leave the responder looking like they're responding-to-nothing, which would be weird. So, for example, suppose you wanted to remove your post that I've just quoted above. Since people have already responded to it (for example, Gargamel's initial response), that means that that particular post of yours would not be subject to removal, even upon request.

Folks, nothing wrong with trying to work out how to use forum features, such as "how do I see signatures?", but this thread is not the place for it. Feel free to ask questions about the forum software over in the Kerbal Network subforum, if you like. Just a gentle nudge to stay on topic, please.

The icing on the cake is the bit where, right after he asserts that "one side of the moon-- the 'dark side'-- never gets struck by sunlight", he actually provides a phys.org link as a citation... and if you go look at that article, of course it says no such thing. So not only did he get the science hopelessly wrong, he's clearly not even reading his own citations. If the blithering ineptitude of this article causes you actual physical pain, as it did me, then I suggest you take a look at the comments on it. You won't be disappointed. (My personal favorite comment is "Who is Richard's editor, Pink Floyd?")

The short answer is: wait until you are at your closest approach to the Mun (where the "Pe" marker is) point your ship so that is centered on the navball crosshairs thrust until you're captured to orbit. That glosses over a lot of useful details, for which I'd suggest reading @Zhetaan's excellent, detailed post just above. But the simple version boils down to this.

(And not even on the desktop version, if the user has picked the option not to display them-- which a fair number of folks do, in order to conserve screen real estate.)

I'd be curious how they'll handle the gameplay aspect, in terms of player patience. Angular moment of inertia goes up with the square of the linear dimensions; rotating a megaship is going to be sloooooow. (This would apply to all maneuvering, not just docking.) This feels like it has the potential to tax the player's patience somewhat. About the only way I could see to mitigate this (other than just telling the player "well, be patient, then") would be to substantially increase the maximum allowed physics warp. Which, in turn, would require careful programming. KSP1 tops out at 4x, and even that tends to get really unstable and kraken-prone for larger vessels. It sounds as though megaships are intended as a pretty important part of KSP2 gameplay, so I assume they'll have some answer for all of this. I'm just curious to see what it will end up looking like.

A gentle reminder to try to stay approximately on topic, folks? Discussion of software release models, branching, etc. is an interesting topic well worthy of discussion, but unless you're tying directly to the topic here-- which is "KSP2 release date in early 2023"-- perhaps better to delve into the details elsewhere?

Some comments have been redacted and/or removed. A few reminders: Please avoid personal remarks. Please do not make accusations. Please do not tell other people what to do or not to do (you're not a moderator). Please do not "threaten to sic the moderators" on people. If you believe someone is behaving sufficiently inappropriately that they're violating forum rules, then by all means file a report and the moderators will have a look. However, beyond that, you are not allowed to discuss or threaten that publicly. Once you've filed the report, you're done-- we'll have a look, please don't respond further in the public thread or you'll just make our jobs harder. Thank you for your understanding.

Moving to Add-on Development. (Threads in Add-on Releases need to include a download link. If it's not downloadable yet, Development is where it needs to go. Once it's ready for download, we're happy to move the thread back to Releases if you like, just let us know.)

Some content has been redacted and/or removed. Please be mindful of forum rules, folks. Thank you.

No, why? People have been using the like button for years, everyone understands it, it's popular, it can't be used to abuse and discourage, there's basically no downside. Works great and serves a useful purpose for the community. Whereas removing it and forcing people to have to type stuff out would just create a bunch of fairly low-content posts saying things like "nice!" that would clutter the forum and get in everyone's way. Very often, there isn't a complex reason "why"; nothing wrong with simply expressing appreciation.

Thanks, the log is helpful! It is clear to me what is happening-- what's not clear is why. More specifically, it's not clear what's triggering it in your particular case, since I don't get this problem myself in my own gameplay. If I had to guess, it would be that there's something about one of your other mods you're running that's causing IndicatorLights to have indigestion. Without going into too many technobabble details, IndicatorLights relies on registering certain information when a part is being loaded, and I notice the following from your log: IndicatorLights is logging a "hey, I can't find the module that I need" warning, and there are a whole bunch of other mod-related log messages going on at that same time (in particular from FAR and something called S.A.V.E.) I don't know that one of those is the culprit, and maybe the log lines I'm seeing are red herrings and not directly related to the problem, but that's about the only guess I have, at the moment. Certainly, the fact that IndicatorLights is giving you log spam in this case is a miss on my part. I can see exactly where in my code the problem is-- I've got some code there that's making an assumption that it shouldn't. It would be straightforward for me to add a simple check at the appropriate spot in the code, so that if the necessary info isn't present, then the indicator light simply doesn't light up rather than spamming log messages. Such a "fix" would result in the indicator light on the M700 part not working, in your particular case... but at least it wouldn't be hosing you with log spam. Are you only seeing this with that one part, or are you getting this on other IndicatorLight-equipped stock parts as well? If it's just that one part, then you can eliminate this problem by just deleting the GameData\IndicatorLights\Parts\scanners\surveyScanner.cfg file from your IndicatorLights installation. That will cause the M700 scanner not to have an indicator light on it, but at least it would eliminate your spam.

More content has been redacted and/or removed. Folks, once again, please refrain from personal remarks. Please address the content of what people said. For example, if someone says something that you disagree with, then feel free to 1. quote them, and 2. explain what your disagreement is. But if you find yourself addressing the character, behavior, intentions, or attitude of the person... then you're over the line and you need to rein it in. It's understandable that emotions can run high on a topic that people really care about a lot, but that's not an excuse for trying to blow off steam by going ad hominem. This was already explained less than 24 hours ago, just a few posts up, but apparently some folks aren't quite clear on what "personal remarks" entail, so here are a few examples: Making comments on other people's behavior (e.g. accusing them of having a "tantrum"). Demeaning language directed at the person themselves (e.g. "I can't talk to someone like you"). Putting words in their mouth by speculating on what you think they would do in some hypothetical situation. No, sorry, you don't get to do this-- you only get to comment on what they said, not on what you think the person "would do". That's their concern, not yours. Those are just a few examples. Look, if you're passionate about a topic, great. If you like to argue, that's fine, too. But if you can't manage to do that without making personal jabs at people, that's a pretty good sign that you've hit the limits of your actual argument. It's also a pretty good sign that you're posting angry, which is almost never a good idea. Best to either step away from the conversation, or at least take a step back for a while until you've cooled off enough to post like a civil adult. (Also... kindly do not presume to tell anyone else what to do or what not to do. How they choose to post is their business, not yours. If you think that someone's behavior is sufficiently egregious that it's violating forum rules, please report the post and the moderator team will have a look as soon as we can. Short of that, though, it's not your place to make accusations or give people orders, so please don't do that.) We understand that people feel strongly on this subject, so we've been trying to be as accommodating as we can, here. This is the second time in a short period that this has been an issue, however, so please, everyone, try to take it down a notch? Further personal remarks will be dealt with more sternly. Thank you for your understanding.

Various content has been redacted and/or removed due to insults, personal remarks, and flamebaiting, all of which are forbidden by the forum rules. Folks, please play nice. It's fine to argue. It's fine to vehemently disagree. Please confine your responses to the merits of the argument, however, and do not comment on your fellow users themselves-- personal remarks and put-downs are never appropriate. If your argument is weak enough that you need to resort to name-calling and finger-pointing, you're not going to convince anyone. Insults and flamebaiting don't win arguments and just make the forum a less pleasant place for everyone, including innocent bystanders. So please don't do that. Thank you for your understanding.

I believe not. Weird buggy stuff would happen. The friend would need to have SimpleFuelSwitch installed. Any tanks that you haven't switched and are still in their default (stock) configuration should be fine, though.

Hi all, I've released SimpleFuelSwitch v1.4.2. No major new functionality; this update includes the following: Correctly handles resource cost when switching resource types. Now with German localization! Thank you to @Sqeep91 for generously providing. (A mea culpa on my part, there-- they actually provided it a couple of years ago, and I didn't notice until just recently. My apologies for being so slow on the uptake.) That's it, that's all there is. If you're not playing in German, and if you're only using it to work with the default switching between LFO-versus-LF, then this update does nothing for you and it's entirely optional to update. (I never noticed, before, that the mod wasn't handling resource cost at all, because the default behavior is just to switch between LFO-versus-LF, and those are the same cost as each other per unit and therefore it makes no difference. And in any case, most resources are pretty cheap per unit, so any errors would be not super noticeable. What finally prompted this update was that I was playing a career with Karbonite Plus, which includes a super expensive resource in it, and I tried to use it with SimpleFuelSwitch and the part costs were bananas. So now it works the way it ought to.)

+1 to this advice, in general (and absolutely, try this to see if it helps!) In the current case, though, the (probable) aerodynamic instability, and/or that materials bay (if that's what it is) exploding so that the heat shield is no longer attached to the pod, seems to me likely to spell doom.