Snark

You want the "Build" menu, from the main menu bar. Hotkey for rebuilding your solution is F6.

Hello all, Apologies for the very long delay, but I've finally released IndicatorLights Community Extensions v1.6.1. This incorporates several fixes from the community (mainly around ReStock+) that have been languishing for a long time. Thanks to the following folks for their contributions: @Poodmund, for addressing the science box @Tonka Crash for addressing antennas and docking ports @linuxgurugamer for pulling together the above, and testing it out Enjoy!

Hi all, Just a note that I've released MissingHistory v1.8.2. No new features, just a compatibility update for KSP 1.10. Changes include: Fix 1.875m reaction wheel and battery, whose IndicatorLights compatibility got broken. Update ReStock+ compatibility. Update to ModuleManager 4.1.4. Many thanks to @Tonka Crash for tracking down how to fix the scaling problem, and for supplying the fix for the reaction wheel and ReStock+ compatibility. Thanks also to @fragtzack, for pointing out the problem with the Z2K battery as well. Enjoy!

Now there, I'm sure, is an unpopular opinion. On point.

Argh. Yep, I've observed the same thing myself, now. Sigh... one more thing to track down. I suspect it has something to do with the relative order of patches between this mod and IndicatorLights. Technobabble about what I suspect is causing this, in spoiler. I just now spent a few minutes futzing around trying to figure out how to cajole it back into working again, but no dice so far. I expect the answer will be some combination of ModuleManager flags, but haven't yet hit on the magic combo. Unless some kind soul out there can figure it out for me, solving this will have to wait at least a few days until I have more time to put into it. Sorry for the inconvenience.

Yes, that particular issue has been there since forever, and will be there forever until and unless some kind soul debugs it and figures out how to fix it and hands me the solution on a silver platter. I poked around on that for a while, way back when, and couldn't figure out how to fix it-- it gets into Unity UI ledgerdemain, which is an area I'm highly ignorant of. I'm sure there's a solution, but figuring it out would require more time and energy than I'm willing to invest. So I won't be pursuing that fix, myself. If someone else figures out the solution and lets me know, then I'm happy to fix it.

Some content has been removed due to personal remarks. Folks, it's perfectly fine to have debate and disagreement, as long as it's civil. However, just a friendly reminder that it's never okay to make personal remarks. Address the post, not the poster, please. If someone is behaving in a way that you think is so egregious that it's actually breaking the forum rules, then by all means report it and the moderators will have a look. However, if you merely find their style or attitude personally reprehensible (but not actually rule-breaking), then it's nobody's place to criticize anyone else. Just address the content of what they said, and leave the person themselves (and your interpretation of their character) out of it. It never ends well and has a tendency to make threads melt down. Thank you.

Sorry, I forgot all about this little gem! @Rodger, feel free to contribute this over at IndicatorLights Community Extensions!

Hi gang, Well, at (very) long last, it's IndicatorLights v1.7, updated for KSP 1.10 compatibility! Here's what's new: Adds an indicator light to the shiny new magnetometer from KSP 1.10. Fixed a Unity startup bug. Thanks to @linuxgurugamer for raising the issue (and providing a fix!) Eliminate the CrewIndicatorDefaultStatus config option; it now just defaults to true. Change the default behavior of the crew indicator lights so that they're toggleable only in the editor, to eliminate UI clutter in flight. (Anyone who doesn't like this can change it back to the way it was via ModuleManager config.) Add a new controlLevel() parameterized syntax for toggles. See wiki for details. (Thanks to @Rodger for the feature suggestion!) Update all ModuleManager part patches to correctly use the :FOR[IndicatorLights] syntax. This should make IL play nicer with MM relative-order directives. Update to ModuleManager 4.1.3 (Note that this update does not include @Tonka Crash's cool which-way-is-up patch for the docking ports. Tonka, that's a neat idea, but I'd prefer to keep that more as an optional sort of thing-- could you please submit it over at IndicatorLights Community Extensions? I've been horribly remiss keeping that up to date, but expect to be updating it Soon™, and would be happy to include it over there.) Hope folks enjoy the update, and my apologies I've been so long-- IRL has been pretty busy of late. Have fun!

That's about petitioning stock KSP, which really deserves its own place.

Oh, I'd love to see Kopernicus rendered unnecessary by having the stock game support the same kinds of features. I'm sure lots of other people would, too. Such a discussion would be off-topic for this particular thread, though. The topic of this thread is about Thomas P.'s fork of Kopernicus that he's been maintaining for the last few years. The topic of this thread is not discussing Squad petitions and desires for changes to the stock game. Great idea for a topic ... but it belongs over in Suggestions & Development Discussion, not here. Perhaps spin up a thread over there? (Given the high level of interest in Kopernicus, I wouldn't be at all surprised to see such a thread get a lot of attention and discussion. Give it its own place to live.) As for this, ...I'd respectfully suggest that the jury's still out on just how fast the community can keep up with things. For example, now that Thomas has officially stepped back, there's already at least one new Kopernicus fork out that's 1.9.1 compatible, and there may be others to come (subject, of course, to questions of how long they'll be maintained and at what level of testing). So we'll see what develops.

And that is indeed true, for this fork of it, being maintained by this author & helpers. Nonsense-- that's the exact opposite of what he said. Quite clearly stated (and since reiterated, just 2 hours and a few posts above this one, so I'm honestly puzzled how this would be susceptible to misinterpretation at this point), he did in fact say, Kopernicus is-- and always has been-- licensed GNU Lesser General Public License. That's an open license that permits forking, and nobody-- including Vanamonde-- is saying anything otherwise. Anyone who wants to fork it, always has been able to. Of course, to do that, and to put in the work to keep it up to date with KSP and ensure that it's reliably tested and won't break the saves of the many tens of thousands of people who use it, is a colossal job. To do that would be a major, major time investment-- and largely thankless, which is why @Thomas P. and his helpers have been heroes of the community to keep it going, lo these many years. I would assume that the massive hassle of such an undertaking would be why nobody else has stepped up to do it, as long as Thomas P. & co. were doing so. Of course, nothing says that someone who wants to fork Kopernicus actually has to put in that level of effort. Someone could always fork it, do some minimal work to stick on a band-aid or two to keep it more or less running, and push it out the door with minimal testing, minimal upkeep, and maximal risk to the saves of anyone who uses it-- as long as they conform to the mod-posting rules, of course. Caveat emptor, and all that. I just hope that if someone does that, they (and their users) are prepared to deal with the potential fallout (e.g. if they break thousands of people's saves). So, to summarize, here are your (and everyone's) options: Stick with the last release of this Kopernicus fork, on an older KSP version that you don't update. Fork Kopernicus and update it yourself (or use a fork from someone who has done so). Note that if you want to do this and publish your fork here in the forums, you'll need to jump through the usual mod-posting hoops, including posting the license and your fork of the source code. Don't use Kopernicus. That's basically it. Take your pick, nobody's stopping you. You'll note that "pester the current authors of the current fork to try to tell them what to do" is not among those options, since this fork being maintained by these people is their lookout, and therefore of course nobody else is in any position to tell them how they should conduct themselves in any way. Because they've been giving everyone shiny toys for free, and therefore-- naturally-- they don't owe anybody anything.

We're sorry, but by "you have to link to the source code", that means an actual link to the source code itself that you used to produce the mod-- for example, a link to your github repository or the like. A link to the original modder's thread doesn't meet that requirement. Could you please provide this? Thanks!

Some content has been removed. Folks, please try to steer clear of politics, which are not allowed per forum rule 2.2.b. This includes bashing people who come from a particular place. Some of the content still remaining in this thread has been allowed to stand, but it's skating perilously close to the "politics" line-- take it down a notch, please. Example of problematic content in spoiler. We're sorry we have to do this, but political discussions never turn out well, thus why we have to have the rule. If anyone has any questions or concerns about this, please feel free to reach out privately to the moderator team (bearing in mind that rule 3.3 prohibits public discussion of moderator action). Thank you for your understanding.

Some content has been redacted and/or removed, due to personal remarks. Folks, let's please keep it civil and remember that we're all friends, here. There's no call to get personal. And if you think someone else is getting personal, please do not respond; trying to "retaliate" only makes it worse. Instead, just report the post and the moderators will have a look. We'll sort out anything that needs sorting out-- that's our job, not yours. Thank you for your understanding.

Hello, and welcome to the forums! Moving to Mission Reports. (And congratulations on the successful mission!)

Hi @Henri, and welcome to the forums! Moving your question to "Gameplay Questions" where it may get more answers.

Yup

You're really not. If you wait a bit it'll be better. Also, be aware that if your trajectory is crossing Kerbin's at a steep angle (as in this picture), as opposed to approaching it in a fairly parallel fashion... it means you'll be arriving at Kerbin with a very large velocity-- which potentially could be a problem, depending on how robust your ship is for resisting reentry heat. So, yeah, wait a bit!

Moving to Gameplay Questions. The colors are really just for decoration. There's no "good" or "bad". It's just an indicator of how hard you're accelerating, that's all.

Could you post a picture of your rocket? A picture's worth a thousand words, and all that-- if we could see your rocket, we'd probably be able to give more constructive suggestions.

Apologies if you already know about all this, but I haven't seen anyone mention this in the thread, yet. Are you turning on "fine control" mode while docking? (Caps lock, by default) Because as long as your RCS placement isn't hopelessly bad, turning on fine control mode will basically make your problems go away because it automagically does all the math for you to do variable thrust on your different thrusters to auto-balance it for you. Detailed explanation here. If you're already doing this and need further help with placement, then never mind. Just wanted to check that you're doing it, because if you haven't, then it's possible that something as simple as "just hit caps lock when you're about to dock" could solve all your problems with one keypress.

The problem is that your center of mass doesn't line up with your center of thrust. So there's two ways you could fix it: Move the center of mass Move the center of thrust The easiest way to move the center of mass is to pump fuel around... but the degree to which you can do that will be limited by things such as "where do you have available empty tanks that you could pump fuel to" and so forth. As to moving the center of thrust... you might actually be well set up for that, because of this: What you can do is to tinker with the thrust limiters. If the craft tends to curve left when you thrust, try lowering the thrust limiter of the engine on the right, and so forth. How effective that will be (and whether it will be enough) will depend on how far off-center your CoM is, and also how far apart your engines are. The way that @Vanamonde describes is basically the only way to do it in flight, unless you use a mod. Rotate the camera view, the CoM is the center of the camera rotation.

By "reach Eve", you mean you're in orbit around it? Congratulations! If you're in orbit around Eve, 5600 m/s is a lot more than you need to go home to Kerbin. Assuming that you're not planning to go down to the surface. The orbital calculation tools generally assume that you're orbiting in the same direction as the planet rotates. If you're orbiting retrograde, then that won't affect the size of the burn you need to make to go home. And it won't affect the timing of the launch window. It just affects what direction you want to go when you do your burn to eject from Eve at the desired angle. Basically, as long as you set it up so that you're pointing essentially relative to the sun when you eject from Eve's SoI (for an ideal launch window), you'll be fine. By "change the direction of rotation" you mean change it so it orbits Eve in the opposite direction? If that's what you mean, definitely no. It's not necessary, and it would use a huge amount of fuel to do so. If you're orbiting retrograde, it just means you'll do your burn when you're on the sunward side of Eve instead of on the night side of Eve. You want to eject from Eve going in the same direction that Eve is traveling around the sun. Assuming you're in an equatorial orbit... just stay equatorial. Kinda. You can do this: Drop a maneuver node in the right spot to eject from Eve to head homeward. If you're orbiting in the same direction Eve rotates, this will be just a little bit west of the "midnight longitude". If you're orbiting retrograde, then it will be just a little bit east of the "noon longitude". Drag the handle on the maneuver node until it's got enough dV to generate an escape trajectory from Eve. Zoom out until you can see both Eve and Kerbin in their orbits around the sun. Keep dragging the handle on the maneuver node. This will cause your projected Ap around the Sun to climb. Keep dragging until your Ap reaches and just barely touches Kerbin's orbit. When you get to that point... look at the "closest approach" markers (pale blue ones). When you're at Ap at Kerbin's orbit... where is Kerbin? If you see that Kerbin at that time will be N degrees ahead of where your ship will be... then you're that far early from the launch window. For example, if Keribin is 30 degrees ahead, it means you need to wait until Eve has caught up another 30 degrees before you launch. Note that the above strategy is only for the "perfect" launch window. You actually have a lot of extra dV. From low Eve orbit, you should only need around 1400 m/s of dV to go home to Kerbin with a good launch window. So if you've got 5600, that means you could have a launch window that's not all that great and still get home. There are various ways. Simplest way is to use something like ksp.olex.biz, get the angles, wait until Eve is in the right place, and do the burn. The more general description looks like: 1. fiddle with maneuver node until you can see in map view that you'll have a Kerbin intercept, and then 2. do the burn.

As a side note to your actual questions-- you might want to consider trying a career play-through, at least for a bit. There's nothing wrong with playing in sandbox, but it throws all the options at you, so it can be a bit bewildering for someone who's new to the game, sometimes. One of the things that can be handy about career mode is that it takes the confusion away by drastically limiting your options to just a tiny handful of parts to begin with. It can be a useful way to learn your way around. You don't have to do that, of course-- just mentioning it as something you might want to consider. Those are useful in certain ship designs where, for whatever reason, it's either not possible or impractical to have an engine mounted below a stage. There are a lot of potential reasons around that, I won't go into them here-- they boil down to "fancy design options". Typically, radial engines tend to be somewhat less "efficient" than equivalent stack-mounted ones (e.g. lower Isp or something), so you may want to stick with the stack-mounted ones for now, particularly if you're new to the game. Basically: if you come to a point where you're trying to build a rocket and something about the design is awkward when you try to fit the engine in there... then that's when you might want a radial engine. Pretty much what @mabdi36 said, above-- that's good advice. A good way of thinking about "what's the right TWR" in general is, you want the lowest TWR that you need for the job at hand. Why do you want low TWR? Because the biggest limiting factor for rocket designs, for the most part, is available dV. You want lots of dV, and designing for that is hard. So anything that gets you more dV is usually a good thing. And the enemy of dV is dead weight-- because the heavier the rocket is, the less dV you have. You don't want to "waste" mass. And engines are heavy. And bigger engines are heavier. So if you have "too much TWR", then that means you're carrying more engine power than you need, which in turn means that your engines are probably a lot heavier than they need to be, which means you're wasting dV. (Also, the really high-thrust engines tend to have lower Isp, and you really want higher Isp when you can.) "Okay then," I hear you cry, "why don't I just make it really really low for everything?" The answer is that you do need to have "enough"-- for example, if you're launching off the pad, then you need to have TWR significantly higher than 1 because you're fighting gravity. Gravity loss is a thing. It's a huge source of wasted dV for the first stage, so that's where a higher TWR helps you. It becomes a balancing act. First stage: You need high TWR. 1.5, as mabdi36 suggests, is a reasonable "happy medium". In practice, anything from 1.3 to 2.0 can work, though you need to design the rest of the rocket accordingly. Second stage: Around 1.0 is not bad, though it can be higher or lower depending on how much dV your first stage has. Here's how to think of it: At the time that your first stage is jettisoned, what angle are you flying at-- i.e. how far along your gravity curve have you gotten? If you're around 45 degrees, then you probably want a TWR of around 1.0. If you're steeper (more vertical) than 45 degrees, then you probably want something higher than 1.0. If you're shallower than 45 degrees (i.e. mostly horizontal), then you probably want something lower than 1.0; even 0.5 or so would probably be fine. Third stage: You want a low TWR. The lower it is, the less mass you've wasted lugging around engines you don't need. It should definitely be no higher than 0.5ish, but just how much less will depend on various things such as your mission profile and so forth. Play around with it for a bit and find out. (I'm assuming that this is the stage you're using to circularize orbit to LKO.) Fourth stage and beyond: Let's say you've gotten to LKO, but now you're going on somewhere further, such as the Mun or Minmus or other planets. You're already in orbit. In this case... you generally want your TWR to be really low, so that you're saving mass and getting good dV. Pick an engine that has the highest Isp you can get, and it's fine if it has low thrust.