Snark

Good thing that Intercept established today that they're emphasizing moddability right from the start, then, yes? <see immediately preceding post here>

More to the point: in today's announcement about the KSP2 early access release date, they come right out and acknowledge how important modding is to the game, and explicitly say that it will be "moddable from day 1". (Which is basically the same thing as they told us back at the original KSP2 announcement in 2019.) So I think we're good here, folks.

Great, glad you like it! That's not a bad idea. No promises, but I'll have a look-- thanks for the suggestions! Hm. That one's a bit niche (would involve a fair amount of special-casing of how things are displayed). I'll give some thought as to whether there's some reasonable way to support it via config or something. There's already a config setting that decides how much precision is displayed (e.g. "years / days / hours" versus just "years / days" or what-have-you), so there's that. But having it show "just days" instead of "years and days" is a bit different. Need to think on this one a bit.

Thanks, glad you're liking it I have no idea what's going on here-- there are several possibilities. One question: This discrepancy you're observing (where the stock/unmodified numbers are displayed): Is this something that affects BetterBurnTime only, or does it affect the stock burn time as well? To be clear: The stock burn time is what's displayed for maneuver nodes. The BetterBurnTime display is there for target intercept, time to impact. There may or may not be something that Kerbal R&D would need to address... and there may or may not be something that BetterBurnTime needs to address. Hard to say for sure, yet. The above question should hopefully narrow that down a bit. The BetterBurnTime code that does these calculations is located here. It relies on ModuleEngines.ThrustLimit() and ModuleEngines.realIsp for calculating the numbers. If Kerbal R&D is doing something to the engine that changes the thrust and/or Isp, but is somehow not updating the above two quantities, then that would explain this discrepancy. Whether fixing the discrepancy would require an update on KR&D or BBT remains to be seen.

Thread locked at OP's request.

Looks great! Thank you for the prompt attention. (And thanks for sharing this cool mod with the community!)

Define "needed". Needed this to accomplish ... what, exactly? Also, note that the new stock indicator's percentage is based on dV and not time. If you leave it set to the default "50%", that means "50% of dV before the node, and 50% afterwards". If it's a 1000 m/s burn that will take 1 minute total, the stock indicator (set to 50%) will give you a burn start time that will burn 500 m/s (and not 30 seconds) before the node time. Which sounds to me like what you want?

That's... not really a thing. What do you mean, "more accurate"? It's exactly accurate no matter when you start it: it starts exactly when you tell it to. The only thing that an aid can tell you is "how long the burn will take", and that can be more or less accurate. The old stock burn-time indicator was very inaccurate, which is why I wrote BetterBurnTime. Then they came out with a new stock indicator that is accurate, so I removed that feature of BBT. "Should I split the difference 50/50? When should I start?" That's your call, nobody else's. BetterBurnTime has never done that. The stock navball has never done that. The old stock indicator had a hard-coded assumption of a 50/50 split. BetterBurnTime was the same way. The new-and-improved stock indicator assumes a 50/50 split by default, but has a setting that allows you to change that to whatever other percentage split you want-- but it doesn't tell you what percentage to use, that's backwards. You tell it. So, the short answer to your question is: No, BetterBurnTime has never done this Nor has the stock indicator There's no math for deciding this because "more accurate" isn't really a defined thing, here Basically everyone just does a 50/50 split, because that's simplest and it doesn't actually matter much anyway , as long as the burn isn't really long If the burn is really long, that's going to be inaccurate no matter what you do-- better to split into multiple burns, e.g. periapsis kicking If you want to look at code for making automated decisions about burns, I'd suggest having a look at whatever MechJeb does, but since I've never used it myself, I'm in no position to vouch for how sophisticated it is (or isn't) about this sort of thing.

Various content has been removed due to a lengthy off-topic derailment that had nothing to do with this company's rocket launches. Folks, please try to keep things on-topic. (Also, please bear in mind forum rule 2.2.b about politics, ideology, etc. and try to steer clear of the sort of topics that tend to generate strong feelings and thereby derail threads. There are plenty of perfectly legitimate discussions to be had about such things, but the KSP forum is not the place for them-- plenty of other places on the internet to discuss that sort of stuff, okay?) Thank you for your understanding.

We're sorry, but sharing mods requires complying with the requisite licenses. The content included here is licensed All Rights Reserved by the original author, meaning that nobody else can distribute it. Therefore, this sort of sharing is not allowed. We apologize for the inconvenience. Thank you for your understanding.

Nope. And not only don't we get extra KSP 2 info, we really don't get any "extra info" at all, about anything the company does. For example, back when original KSP was under active development, we found out about new version releases, or new DLCs, at the same time as everyone else-- we don't get advanced notice. In general, we never get any info about the internal development of KSP (or KSP2) other than what the public forum gets. This is because we're not employees, so (among other things) it means we're not subject to the same NDAs that an employee would be. (We do have NDAs, but they're different ones, relating to moderating rather than development.) Companies need to play their cards close to the chest. The only "secret stuff" that we can see (that you can't) is stuff directly relating to the forum users (e.g. things like a user's history of warnings and the like)-- basically, just the stuff that we need to be able to do our job as moderators. Beyond that... we never know anything beyond what you do, and we generally find stuff out in the same way that you do.

Some content has been removed. Please refrain from personal comments, folks. We understand that people care about the game, a lot, so it's very easy for tempers to flare when one sees someone suggesting a course of action for the game that one disagrees with. But let's please remember that we're all friends here (right?) and keep things civil. There has been a certain flaring of tempers in the thread, in general-- let's please take it down a notch, okay? And remember that everyone is entitled to their opinion. Which means that, 1. just because their opinion is different from yours, it's still just as valid as yours; and, 2. it's never worth getting angry or confrontational with someone about their opinion. If you can't keep your cool when posting, best to just stroll on by. (Or, at least, go do something else until you can post without temper flaring.) Thank you for your understanding.

Some content has been redacted and/or removed. Please avoid posting politics to the KSP forum, folks. It's against the rules, and never ends well. Furthermore, if you see someone else posting politics... please just report it, and do not respond. Responding just adds more to the mess that needs cleaning up. Thank you for your understanding.

Some content has been redacted and/or removed. Folks, let's please try to keep politics out of the forum. It's against the rules (2.2.b), and never ends well. Thank you for your understanding.

It's also worth noting that if you did accidentally permaprune important stock parts and wanted to get them back, then there's a good chance that you can repair your installation, depending on how you purchased KSP. For example, if you bought it through Steam, you can go into the KSP page of your Steam library and there's an option to "validate local files"-- doing that will cause it to scan your local installation, compare that with the "fingerprint" of what a fresh install looks like, and then if it finds any files that are missing or modified, it'll download them from the Steam servers and fix it up. I'm only familiar with Steam, myself, but I have the impression that other game purchase platforms tend to have something like that, too.

Locked per OP request.

Some content has been redacted. Folks, a gentle reminder that profanity's not allowed in the forum... and that means no linking or embedding to content (such as tweets) that contain profanity. Thank you for your understanding.

Hi @tilliepops, Just a side note to let you know that we've snipped the large log file contents from your post. We understand that you mean well, and it's good to share log files. Please try to avoid pasting really big ones into the forum itself, though, because it causes problems for people. Even if it's supposedly "hidden" in a spoiler, it forces the web browser to download the entire contents even if the person doesn't open the spoiler. This can cause problems for folks, especially on mobile devices. There's nothing wrong with pasting a page or two into a spoiler. However, if the content is thousands of lines long, best to post it to some third-party file sharing site instead, and then post a link to it here in the forum. That way, everyone wins. We're sorry for the inconvenience, and thank you for your understanding!

If you're running ReStock, then whatever issue you're having is almost certainly a mod interaction there; and it would be IndicatorLights Community Extensions that's the issue in that case, not IndicatorLights itself. Therefore, this would be a better question to ask over there: As @AmanitaVerna points out, that's not what those comments mean. They're not saying that you should do anything; they're explaining what this patch is doing. When it says "Fix duplicate models where...", what it's really saying is "The following lines are where I'm fixing duplicate models where..." So, in summary: There are no actions you're supposed to take. The mod is supposed to "just work". It's possible that there's some issue with ReStock and/or this patch (for example, if ReStock got updated in a way that makes this patch obsolete, so it needs updating or something). Best place to ask about it is over in the IndicatorLights Community Extensions thread.

Ah yes, the notorious "we put the sun in the completely wrong place to make the image look neat" shot, which at least they have the good grace to be a bit sheepish about.

Why would they be? Polar ice caps are at the poles, and for good reason (because the poles are coldest). Duna has zero axial tilt. Were you expecting the polar caps to be ... somewhere other than the poles, for some reason? Discussion of polar caps and axial tilt in spoiler, since this is a discussion that's more about IRL science stuff and would belong better in Science & Spaceflight, and is getting away from the topic of this thread (which is axial tilt in KSP2).

It's certainly a legitimate discussion to have, as to whether Duna should have axial tilt for gameplay reasons or not. And certainly, IRL, Mars has axial tilt. However... the polar caps have nothing to do with the fact that there's axial tilt there. They're polar caps because they're at the poles, which are on average colder because they get less insolation than more equatorial regions. And that would be true even if there were no tilt.

I think that in general, newer players will find it easier without the axial tilt involved, and that there can be plenty of axial-tilt challenges to be had in other star systems. That said: I don't think it's super critical. A few bodies here and there (like Pol, Bop, Gilly, as you mention)? I don't see that it would particularly harm anything to include tilt, there. Like I said, I don't feel especially strongly about it. Yep. The concept that it exists, is pretty easy to explain. I'm talking about flying missions, and making the game harder than it needs to be in the early stages. After all, Earth has a substantial axial tilt, and space launches happen from facilities that aren't on the equator, and the Moon's orbit is inclined with respect to Earth's equator. Yet KSP gives Kerbin zero tilt, and puts KSC right on the equator, and gives Mun a perfectly circular orbit with zero inclination. Why? Because it's easier to fly in KSP that way-- even though an elementary-school student can understand these concepts by looking at a globe. You're also mis-stating my position. I don't think it's unreasonable to have tilt in the game. On the contrary, I think it's very important to have tilt in the game, and the fact that KSP 1 didn't was a major hole; I've long been astonished that they didn't put it in. What I said was: I think it's reasonable to keep the axial tilt at zero for the home-system bodies. Absolutely for Kerbin / Mun. I lean towards it for the other home-system bodies, too, though as mentioned above, I don't feel as strongly about that. No, but I've never said that. What makes me (and an awful lot of the folks here on the forum) "not like other players" -- or, at least, not like most of them -- is that I can, in fact, land on the Mun and manage interplanetary travel. Most KSP players don't get that far. I would contend, from what I've seen, that a substantial majority of KSP players don't make it as far as a Mun landing. I realize that the above statement is a pretty strong one, and may sound rather hard to believe. Once upon a time, I would have had trouble believing it, myself. Here's a discussion from a few years back, however, that I found quite eye-opening at the time: Another data point: I was able to attend PAX West 2019, when KSP 2 was announced. There was a presentation session that the developers (Star Theory) did, at the time, that was pretty well-attended. Must have been well over a hundred people in the audience. The presenter asked "How many people here play KSP?", and basically everyone's hand went up. The next question was "How many of you have gotten to orbit?" and a lot of hands went down. By the time they got to asking "How many of you have successfully landed on the Mun?" ... it was only a tiny minority-- I don't have an exact count, but it was well under 20% of the crowd, and may have been under 10%. I realize that's not a particularly big statistical sample. But it was a lot fewer than I would have expected, and it's worth bearing this sort of thing in mind when considering "what should the developers do when designing the game." To be clear: I'm not primarily making an assertion that it would be a good idea for the home-system bodies to all (or nearly all) have zero axial tilt. My primary assertion is that the game needs to be accessible to a large percentage of the player base, and not have a learning curve that's steep enough that it may put people off before they can really sink their teeth into the game. I just happen to think that keeping players from having to worry about axial tilt until they've gotten well into the game-- including a fair amount of interplanetary exploration-- is a reasonable choice on the path towards that goal.

Some discussion of that here:

I agree that it would be possible to implement in a way that would be fun for some players. I disagree, fairly strongly, that it belongs in the stock game. But more to the point, this thread is about axial tilt, not about communication delays, so the whole matter is off-topic here. I certainly agree that the question of communication delays is an interesting one, and I think it would make a great thread under KSP2 Suggestions (if there isn't one already) where folks can debate the matter to their hearts' content. However... probably best to drop the matter in this particular thread.