Snark

That, unfortunately, I don't remember. It's been a few years. I remember that I didn't have to deal with an atmosphere, but the wiki tells me that the sun got an atmosphere in KSP 1.0, and I'm pretty sure this was after 1.0. For one thing, I'm pretty sure I was running Scatterer, mainly because I remember being wowed by the stark "whiteout / black shadow" effect it gives under super-intense sunlight; and that means it would have been after 2016 when I did this. [UPDATE] Ah, nuts. Never mind. Turns out that my memory was conflating different things. I found this old post of mine, which dates my sun-skimming expedition to KSP 0.90, which is before the new heat management. ...and it was PlanetShine, not scatterer, that was giving the cool lighting effects. So, sorry for the false alarm, I was mis-remembering. It was in the "easy" days. (The thing I was conflating it with, in my memory, was playing with the New Horizons mod, which includes a planet that orbits at 1300 Mm, and the sun has about 2.4x the luminosity of stock, so heat management becomes pretty important.)

I've done a solar orbit whose Ap was under 1000 meters. As in, a circular orbit under 1 km from the surface of the sun. To be clear: I'm quite sure I'm not the only person who has done this, because the reason I did it was that I was using a mod that involved harvesting a resource that was only available in that very thin zone. If I did it, then I expect a lot of users of that mod would have done it, too. The mod in question was Karbonite+, and the resource was Karborundum (which is used to power sci-fi engines with unrealistically high Isp). There are two reasons why a really low solar orbit would be hard: needing monstrous amounts of dV solar heating I'll happily grant you that effectively I "cheated" on #1, since to get there, I did in fact use the overpowered modded engines. I didn't do that using stock engines and fuels. However regarding #2, that was totally legit. I didn't have any cheating or mods to deal with heat flow; I just spammed the heck out of deployable radiators and was fine. [EDIT] Never mind, upon further detective work I was able to deduce that I actually did this in KSP 0.90 before the new heat management, and that I was getting it mixed up in my memory with a different thing. Sorry, my bad.

Moving to Gameplay Questions.

Moving to Add-on Discussions, since this is about mods.

Fair 'nuff. I think it's one of those things that really has to be judged on a case-by-case basis. There are certainly situations where the devs shouldn't implement a feature, and it should be left up to modders. The most common example of that would be if the feature is specialized enough that only a very tiny fraction of players would actually use it. Software development is a zero-sum game, and spending more time on one thing means spending less time on another. If less than 1% of the player base would use the feature... it would be better to just skip it, and spend that time instead on some feature that, say, 10% or more would use. Leave the "under 1%" features to the modders. So, trying to answer the question "should it be stock or should it be left to modders" requires having some idea of what percentage of users would use it... and as players, you and I don't necessarily have a good view on that, since we don't have access to any sort of statistics or focus groups or whatever. So for any given feature, we can guess... but since it's just a guess, we could be wildly wrong. And different people could come to different conclusions about how popular any given feature might be. My impression has been that an awful lot of folks here on the forum vastly overestimate what the average KSP player does (in terms of how far past Kerbin's surface they get), and I think this can often lead them to propose features that "should be stock" that, IMO, really shouldn't be. Speaking for myself: I've seen quite a few discussions / arguments that fall into "they should make this stock!" / "no they shouldn't!" category... and I gotta say, in most such cases I've come across, I usually find myself agreeing with the "no they shouldn't" side. Reasonable people can differ, obviously. Having these things as difficulty settings potentially makes sense to me (depending on how many people would use them): non-random part wear and failure wind Lightspeed communication limit is... potentially problematic, depending on how it meshes with the rest of the game design. It's not at all clear to me that there's one "right" way to design it, and I fear it would add too much code and UI complexity, relative to the amount of challenge it adds. (My impressions on this are based on playing with lightspeed delay turned on with RemoteTech, back in the pre-CommNet days. It was fun to play with for a little while, but I ultimately concluded that it wasn't a feature I'd like to see in stock.) I happen to think that axial tilt shouldn't be a difficulty setting, mainly because it involves the actual geography of the game and would fracture the community experience. (For me, "turning various physical simulation types on and off" makes sense for difficulty, but "changing the actual physical behavior of things" shouldn't.) The preceding couple of sentences are a very brief, over-simplified summary of a topic that I've thought a lot about, mainly because I figure I should spare you the multi-page rant. But it boils down to this: I am with you on the subject of difficulty settings in general-- I think they're a powerful mechanism that allows a wide variety of skill levels of players to enjoy the game in their own way. But for various verbose reasons, I don't think planetary configuration should be one of them. I don't think that specific thing should be a difficulty setting. I think that should be basically fixed, and that the way to accommodate players of differing abilities is in the universe design. (i.e. "Kerbin is easiest, then Mun; then the solar system is harder; then the other solar systems are harder still.") (I do think it would have been a good idea if they'd added one more planet to the stock system-- say, a Saturn analog like OPM's Sarnus, out past Jool-- which could have axial tilt and so forth. This would provide useful and interesting gameplay, including axial-tilt features, without requiring the player to go interstellar. It would also be a nice way to jazz up the home system, for those of us who have been staring at the same seven planets for the last decade...) I acknowledge that this is a matter of taste.

To be clear, when I say "I don't feel strongly one way or the other, about it, as long as it's easily moddable": what I mean by that is, I believe that as a matter of game design, they should design the game to appeal to a broad audience and should give a lot of weight to making it fun and accessible to the majority of KSP players. It's the right call. It will make the player base the happiest (in the aggregate), which in turn will help sales, which will help encourage further development, which will benefit all the players, so everyone wins. You'll note that I didn't say that they should design the game to appeal to me, personally. That's because I am not a typical KSP player. The typical KSP player finds it a challenge just to make it to the Mun, and going interplanetary at all, even when everything is zero axial tilt, is a major leap. (I'm not being judgmental about that at all, merely commenting on what I perceive the statistics to be.) I mean, sure, if they designed the whole game to appeal perfectly to my personal tastes, to the point I wouldn't want or need any mods at all, then that would be great, as far as my own play experience is concerned... but it would be pretty short-sighted of me to want them to do that. Because my own idiosyncratic tastes are a tiny minority of what the overall player base wants. If they designed the game to appeal specifically to me... they would render it less attractive to the large majority of their prospective customer base. Which would tank the game's sales. Which would pull the plug on any further funding, which means I would lose, in the long term. Therefore, as a self-interested, selfish player ... what I want is not a game that caters to my personal tastes. I want a game I enjoy, sure, but what is really important is that lots of people need to find it fun. That's what will get me the largest amount of sustained kerbal goodness into the future, so it's what I want. Which means, I have to be okay with options that are less than what I, personally, would prefer to play with. Personally, I think it's the right call for them to keep the home solar system's bodies at zero tilt, mainly because I think that will make the solar system more accessible to a lot of players-- without killing the enjoyment for me (after all, I've been happy to plow thousands of hours into KSP1, which doesn't have tilt at all). I can get my jollies from having interesting planet designs in other systems (including tilt). And in that context, when I say "I don't care much, as long as it's easily moddable", what I mean is: that lets me, personally, tweak the home system as I like. Which mitigates any angst I might feel about their correctly (in my opinion) deciding to leave the home bodies with no tilt. Well, sure, so do lots of people. Heck, I was playing the game for a year-- I mean, a lot, more time than I'd ever plowed into most games-- before I ever installed my first mod. Suppose the game had been built in a way that it was completely unmoddable. I still would have enjoyed the heck out of it, I still would have plowed hundreds of hours into it, I still would have been utterly happy with my purchase and convinced that I got my money's worth dozens of times over. (But I probably would have eventually have gotten bored and wandered away from it after a year or two.) I'm a little confused by your raising this point, though-- do you have some reason to believe that KSP2 won't be a good stock game? Or that it won't have any difficulty options? I haven't seen anything to indicate either of those two things to me, and was curious whether you've been reading something I haven't. I agree that mods shouldn't be a crutch to fix the game. I disagree that they are one in KSP1. I'm sure it's possible to have a lengthy and spirited debate on that question ... but I won't go into it here, because it would be off-topic for this thread, which is specifically about axial tilts in KSP2. Same here. My guess is that probably most players are in that boat, too. (Even with a "great mainstream, balanced experience" that I can enjoy with 0 mods, though, I'd still eventually end up playing with mods, anyway, if only because they open the door to variety and help extend how long I'm likely to play it.)

My understanding is that, Unlike KSP1, yes, there will be axial tilt in KSP2. They don't intend to change any of the orbital characteristics of the original bodies of the home solar system, so we shouldn't expect to see any axial tilt there. That's my understanding of what they will do. What one thinks they should do is another matter, of course. Personally, I would say that absolutely it's the right thing to keep Kerbin and Mun at zero tilt, at the very least, mainly due to how hard a lot of players find it to master the early elements of the game. A training ground, as has been remarked. If they keep the rest of the home system at zero tilt, I'm fine with that, too, though I don't feel strongly one way or the other about it, as long as it's easily moddable (which I expect it will be). I do really look forward to exploring new planets which have some tilt.

Hi all, I've released PlanetInfoPlus 1.4.2, which includes the following bug fixes: Now correctly says "meters" instead of "kilometers" for near space height. (Thanks to @alartor for the bug report.) No longer gets NullReferenceException when used in a new game. (Thanks to @linuxgurugamer for the bug report.) (For the curious: The reason LGG was seeing this bug and I wasn't, was that it's a thing that happens when you've started a new game and haven't explored much, yet. There are some data structures that aren't actually initialized yet and are null. I never noticed it because even though I was running the same solar system mod as LGG, I had already been playing for a bit when I wrote & installed PlanetInfoPlus, so I never experienced "run the mod from the very start of a new game". Live and learn, I suppose!)

That's... really odd. I wrote PIP and then used it for a couple of months while playing a New Horizons career game, with nary a problem. I'll need to dig into this.

Thanks for the report! I'll have a look as soon as I get a chance. It's kind of interesting that you're hitting the error with New Horizons... because it was starting a New Horizons KSP game that prompted me to write PlanetInfoPlus in the first place. So clearly it basically works with New Horizons itself-- at least, when I was playing, I didn't run into any such error. I wonder if it has to do with your playing a sandbox game (which I didn't test as much, since my own gameplay is generally all career mode). I'll see if I can reproduce this.

Thank you for the suggestion, but I'd say I'm unlikely to make such a change. I tend to be very "strongly minimalist" when modding-- I deliberately write my mods to do the bare minimum of what's needed to accomplish some particular task, and tend to be strongly averse to adding in functionality for which the game provides some other mechanism. For example, my own answer to the problem that you describe is at construction time (i.e. making sure docking ports are the right way up). To be clear, I'm not saying it's a bad suggestion-- it's a pretty good one. It's just not my cup of tea for how I put my mods together.

Well, probably not anytime soon, to be honest. I mean, it's not like I've decided definitively "no" or anything. It's just that, when I'm modding, my proclivity can probably best be described as Frustration Driven Development™, and I've basically got my frustration cleaned up at this point. I'm a problem solver, not a creator. I mod the game because I find something in the gameplay to be personally inconvenient, so I set out to fix that... and for me, once the problem is solved, it's solved, and I tend not to be strongly motivated to tinker with it further unless something new comes up. In the case of this mod, it's been seven years since I first released it, and I've got thousands of hours of KSP under my belt since then, so at this point the rough edges have all pretty much been sanded off, as far as my own gameplay is concerned. If there were some important "missing feature" that I really cared about, I probably would have already added it by now. And since KSP development itself is pretty much done at this point, it's not as though I've got any new changes in the game for which the mod needs updating. That's not to say that there aren't some nifty features that could be added, and I've had a few possibilities in mind for a long time. Atmospheric suicide burn times (as @dtondo mentioned) would be one such example. Having more accurate vacuum suicide burn times-- which actually project trajectory and the terrain ahead of the ship, so as to be substantially more accurate, would be another. The problem is, any idea that's really cool and wouldn't be a massive undertaking to implement (and/or risky as to how well it would work), I've pretty much already done. Those remaining items tend to be complicated, risky, and (in my own gameplay) not all that necessary for me. (Plus, with KSP2 looming closer on the horizon, my motivation to spend more time developing KSP mods has been waning; I expect that once KSP2 arrives, I'll probably jump into that without a backward glance, and my original KSP will just gather dust. So I have this sense that any modding I do now will become obsolete and unused-- by me, anyway-- within a few months, so I'm less motivated.) Anyway, I'm sorry I couldn't be more helpful.

Agreed that that would be nice, but it's actually a Very Hard Problem™. I looked at it once, but the thing is, air resistance is critically important in determining this sort of thing, and when I poked at it a little bit, I found that it fluctuates in ways that would require a fair amount of code to smooth out. (There are other complexities, too, such as predicting the varying engine thrust due to Isp decreasing as the atmosphere gets denser on descent, that sort of thing.) Trying to address this would involve adding a fair bit of code complexity, plus I'd be almost guaranteed to get it wrong to some degree... and "getting it wrong" on a suicide burn can mean "player's craft goes splat". So I'd rather emit no signal at all than a likely wrong signal, which is why I ended up not adding the feature.

Hello, and welcome to the forums! Moving to Science & Spaceflight.

A friendly PSA for anyone who's relatively new to the forums and isn't aware of the context of the Elcano challenge, the above quote perhaps qualifies for "understatement of the year". By which I mean: I would advise listening to this person, they know what they're talking about. Completing that challenge is basically the definition of "have done all the roving that there is to be done", and involves several orders of magnitude more roving than most KSP players ever do.

Hello, and welcome to the forums! Moving this to Gameplay Questions, since "Science and Spaceflight" is about real-world stuff. Hmm. You absolutely should get science points for that, assuming that the probe had science on board at the time. A possibly silly question, but are you sure that you did have science on board? (for example, you took a science report and kept it on board rather than transmitting it? Because if you transmitted it, it wouldn't be on board any more and wouldn't be worth points to recover.) Can you load the save when your probe is approaching Kerbin, and check to make sure that the instruments still contain science in them?

Well, as high a speed as I can make it go in a really low-g environment like Minmus (which is what we're talking about here)-- traction's somewhat limited. With a good strong reaction wheel set to hold orientation, tumbling basically isn't a thing, at all; doesn't matter how hard you hit it, the rotation stops almost instantly as soon as the rover is out of physical contact with the obstacle. This can leave the rover in a somewhat off-kilter attitude (for example, leading back on the rear wheels, or leaning left and driving just on the left wheels)... but that doesn't hurt it right away, as it can drive along just fine indefinitely at that attitude. So at my leisure I just pitch or roll it back to flat again. (Plus, any high-speed jolt that's strong enough to push it seriously out of true will launch it off the surface with some serious hang-time, on Minmus, which gives plenty of time to reorient it a bit if I need to.) Here's another example of using strong reaction wheels for a rover. This unicycle works fine in Dres gravity (substantially stronger than Minmus) at pretty high speed (as high as that motorized wheel will go, anyway). https://imgur.com/a/cptXT (The ion drive is just there for purposes of interplanetary flight, capture, and landing. Once landed, the vehicle gets along fine on the surface without it.) Another option, I suppose, for someone who wanted true "keep it right-side up" stability, would be to mount a probe core on the rover that's pointing up, set "control from here" to that, and then set SAS to hold . With the navball in surface mode, this means pointing straight towards the zenith, regardless of the rover's motion. That would auto-correct for both roll and pitch. (It would also have the side effect of making the navball basically useless for navigation, which is why I generally don't use this mechanism myself, but tastes vary and I mention it just in case someone else might find it more appealing than I do.)

No, I leave them on standard mode, otherwise I can't use them to help with things like yaw-steering and it makes the rover difficult to steer. No no, don't set SAS to hold , just set it to hold orientation (i.e. the default mode). That way it basically can't roll. Even the hardest bump will only knock it slightly off-kilter, which you can easily correct by hitting the roll key a bit. Well, yes, but leaving those as the default commands makes steering rovers practically impossible by having the reaction wheels do counterintuitive and unhelpful things every time you need to steer. Absolutely remap the rover controls to something else, otherwise all is confusion and madness. I like to use the numpad keys, myself, since they're not otherwise used for anything else.

Yup, as @The Aziz said, what you need here is layers. The thing that's causing that outline is anti-aliasing. Here's what that means: Take a look at the following image. Note that the text on the bottom seems smoother and "nicer" than the text on the top, which has "jaggies" at the contrast between black and white pixels. That's because the bottom text uses anti-aliasing to "smooth" it. What that means is that the drawing program I used to make that text will generate various gray-scale pixels around the boundary, to create the visual impression of smooth round edges even though the image is made out of hard, sharp, square pixels. The top one looks "jaggy" to you because you can see the shapes of the pixels at the word boundaries; those "jaggies" are the sharp, square pixel edges. In general, people tend to find the look of smoothed images more pleasant, so it's pretty common to see anti-aliasing used a lot. Here's a blown-up version of the image so you can see a bit more clearly what's going on: So... anti-aliasing makes things smoother and nicer, so it's a good thing, right? Well, yes... except when it isn't. In particular, anti-aliasing makes image compositing a problem. Suppose I gave you that original image up above, and you thought: "Yay! This is just what I need! ...Except I need the background to be blue, not white. Well, no problem. I'll just take the paint-bucket tool in my drawing program, and use it so that every white pixel in the image will be made blue instead." In which case, here's what you'd get: See that awkward "white" boundary around it? And notice how it's only a problem on the anti-aliased version? That's the problem with anti-aliasing in a single-layered image. It's very compositing-unfriendly. Because on the anti-aliased version, there are a bunch of pixels around the rim of the letters that aren't either black, or white-- they're shades of gray in between the two. So your paint-bucket tool in your drawing program kinda throws up its hands and doesn't know what to do. (There are some fidgety bits with the tool settings that a good drawing program can use to try to work around the problem and make it not quite so glaringly obvious, but it's still not perfect.) The fundamental problem, here, is that conceptually this image has a foreground (black letters) and a background (white field). At the time the anti-aliased letters were rendered, the drawing program had first-hand knowledge of the foreground and background colors and was able to calculate the in-between colors itself. However... as soon as that was then collapsed down to a single-layer image, all knowledge of "foreground" and "background" is lost. So when you come along, after the fact, and try to work with a thing that has already been anti-aliased, then your drawing program is missing the context it needs to be able to change the background out from under the foreground part of the image. To composite an image together the way you want, and have smooth edges without jaggies, and have differing colors the way you do, is certainly doable. But it will involve getting a little fancy with layers, and describing a blow-by-blow "how to" for that is probably a longer discussion than folks here would want to read. (In addition to which, how I would do it is not necessarily the ideal way, since I am by no stretch of the imagination a graphic designer, and someone who actually knows what they're doing could probably do it considerably more efficiently than I could.) So, I won't specify an exact solution, here-- but thought you might like a discussion of what the actual issue is.

Moving to Gameplay Questions.

Moving to Gameplay Questions. Sure, they work just fine. It's just a different experience from driving on a body with higher gravity, is all. Launching from bumps, absolutely, yes... but how is that a problem? It'll come back down soon enough, it's not as though you're going at orbital speeds. In the meantime, wheeeee! Slipping and sliding can be an issue, sure, but that just means you need to be patient for it to get going. (Minmus has some pretty steep slopes, so those can be an issue if you don't have enough traction to stop from sliding downhill faster-and-faster. When I'm roving on Minmus, I generally avoid the steeper slopes, or else put some RCS thrusters on for assistance in case of need.) Stability's not much of an issue-- just make sure you've got a reaction wheel on there (which I see that you do). Reaction wheels are super effective on Minmus, precisely because the gravity is so low-- they can muscle the rover around to any orientation you want, and with SAS activated, they absolutely prevent any flipping over. (And even if you did somehow flip over, they could flip you right back again.) Just put a reaction wheel on the rover and flipping's not a thing. Rock solid stable. Hm? I would say precisely the opposite: always keep them running, so that you cannot possibly capsize. If they're off, then you'll rapidly flip if you hit the smallest bump, which requires quick reaction to turn them on before you clobber yourself upside-down on terrain. Just leave them on all the time so you're always stable.

An example usage: Note that it's a 1.25m stack, but the upper stage has 0.625m engines on it. The engine plate allows you to use a smaller-diameter engine in the middle of your stack, while keeping your craft as a smooth cylinder for aerodynamics (and keeping the wide-diameter attachment node size, so that your rocket stays nice and rigid) . So it greatly improves your choice of engines, since you can use any (smaller) size you want, and don't have to be constrained to the size of your stack. You can also select how many engine attachment nodes you want to have, which allows you to use multiple smaller engines if you like. The above example, for instance, has two ion engines. As icing on the cake, the engine plate also functions as a decoupler, so you don't need to add a decoupler below it.

Folks, a little joking around is fine, but let's please try to keep things on topic. Some content has been removed.

This thread has been locked. Since the original mod release thread has removed its download links and is, itself, locked, there's no useful purpose to be served by leaving this thread open. We're always sorry to see a KSP mod go away, since mods provide such value to the community. As everyone here knows (right?), this is of course entirely up to the mod author; it's their work, and therefore their decision. I'm sure we're all especially sorry to see a mod go away due to an author having a poor experience in the community, and hope that folks can learn from the experience so that future occurrences can be avoided.

Moving to Add-on Discussions, as this is not an add-on release.