Snark

Alas, no. It's a totally reasonable request, and you're totally justified in asking, it's just that I have a very low tolerance for administrivia. Doing backward compatibility patches is something I've never done because, straightforward as it is, it would push me past my "hassle limit" of keeping track of things. Thank you very much for your courteous approach, by the way; I really appreciate it, and I'm sorry I can't oblige. It's worth noting that BBT's license, unlike Kopernicus, actually deliberately prohibits people from publishing forks, for the reasons you mention (I used to use a more permissive license but got burned). Even though publishing a fork is off the table, though, you can totally build a patch for yourself if it's not published. I believe (though have not tested) that you should be able to just take the most recent code for current KSP, and then swap out the .csproj file and MM version from an older BBT that's compatible with your current KSP version. I think that'll work.

They also handle significantly higher temperatures. RGUs can take 2000 K. Most of the smaller cores top out at 1200 K. Can be an issue for reentry scenarios.

We're sorry, but we've had to remove the link because it violates several of the add-on posting rules. For full details, see recent discussion here: Executive summary is that it is not okay to just post a link to a DLL. If you want to share a recompile, there are several rules you have to follow, and just posting a DLL violates several of them. Your best course of action is just to wait for the updated official Kopernicus. Thank you for your understanding.

Some content has been removed. Folks, please play nice, and don't try to make things personal by dragging a disagreement from one thread into another. Thank you for your understanding.

Some off-topic content and interpersonal bickering has been removed. Please behave like civil adults, folks. It's never okay to level accusations against fellow forum members, and it's poor form to hijack another modder's thread to advertise your own. If you'd like to discuss your own mod, then your own thread is, of course, the best place to do that. Thank you for your understanding.

Moving to Add-on Discussions. Note that release threads must specify the mod's license (and, if the mod contains any DLLs, a link to the source code), per the add-on posting rules.

Moving to Mission Reports.

Not as often as you might think, mainly due to the hassles one has to put up with in order to post a recompile while following the add-on posting rules. It's actually a pretty big deal. That's because posting a recompiled mod counts as publishing your own mod, which means you have to jump through all the same hoops you'd need to if you were making a new mod from scratch. You can't just share a zip file or DLL and post a link. (Of course, a fair number of well-meaning people don't realize this, and post rule-violating recompiles anyway-- which we moderators must then, regretfully, remove when they come to light.) For example, here's what the process would look like to legitimately publish a recompile : 1. Establish that the mod has a license that even allows publishing derived works in the first place. 2. Do the recompile. 3. Create your repackaged mod, including an updated license (since you're the author of the recompile), while giving credit to the original author as required. 4. Set up a public repository of your forked code, for example on github. 5. Create your own thread in Add-on Releases with a link to your download. Ensure that it has both a link to your updated source repository and your updated license information. That's... rather a lot of hassle, for just a simple recompile, which is why most people don't do it. (Unless they're going whole hog and assuming full ownership of maintaining their own published fork on an ongoing basis, in which case there's so much labor invested that the hassle of publishing is worth it.) So please understand that if you ask a forum member to "share a recompile", that's not a small thing. Either you're asking them to take on the massive hassle described above, or else you're asking them to break rules for you. In other words... it's a much bigger ask than you probably realize. So, please be mindful of that, and best not to be forward asking for such a thing unless they've already volunteered to shoulder the significant burden of publishing. A final note: I've explained all this here due to the ongoing interest in Kopernicus, but further discussions of the intricacies and pecadilloes of mod forking and publishing, and the forum rules pertaining thereto, would be off-topic for this thread. So if anyone wants to discuss that, please take it to a separate thread over in Add-on Discussions, rather than here. Thanks!

Some content has been removed and/or redacted. Folks, just a friendly reminder that reports are a private matter between the moderators and whomever filed the report. As such, it's never appropriate to tell anyone (other than moderators) that you have filed or plan to file a report. Doing so constitutes "backseat moderation" and is, itself, not allowed (per forum rule 3.2). If you believe someone has violated a forum rule, simply file a report and leave it at that; then the moderators will review and decide whether they think any action is necessary. Thank you for your understanding.

Folks, just a friendly reminder to stay away from political topics. Given the topic of this thread, the temptation to delve into political comparisons and discussion may be irresistible to some, and perhaps it's a forlorn hope that people can control themselves and the thread can be left open and unlocked. However, please try, and steer away from the political stuff, okay? Thanks.

I also note that your ailerons are really close in to the central roll axis of the plane, due to the stubby wings. That means it's going to have very little roll authority. If it's solved, great, but in general: if you have an issue with insufficient roll authority, it's good to move the ailerons (i.e. roll control surfaces) as far out from the axis as possible to give them a better lever arm to work with.

Yep, even that. Note that when Geonovast says "adapter parts", we're talking about conical parts so that there's a smooth, "slanted" transition from one diameter to another. This includes a reasonable selection of fuel tanks. For example, if you want to mount a Science Jr. behind the Mk2 command pod, there's a short conical fuel tank that's 1.25m on top and 1.875m on the bottom. So, you could put one of those upside-down under the command pod, then the Science Jr, then either you could have a 1.25m stack from that point, or you could use another conical fuel tank to go up to 1.875m or even 2.5m if you like. Here's what the 1.25m-to-2.5m adapter fuel tank looks like: ...there are lots of others in various sizes and shapes.

There's a sub-forum, The Spacecraft Exchange, where lots of folks share their craft for all sorts of missions. Suggestion: search for "Eve" in that forum, I expect you'll get a fair number of results to look at.

Those are not uncommon problems. The devil's always in the details, though. For example, "craft get tossed around" is a very different problem from "fuel runs out mid-mission". There's not going to be one "general help", really-- KSP is a bunch of very specific, very focused individual problems, and each one of those has different potential causes and different solutions, and is best addressed separately. In general, the best way to get help for this sort of thing is to post a question to Gameplay Questions-- and for best results, make it as focused as possible. For example, let's say you wanted to address the "craft get tossed around" thing-- I have no idea exactly what you mean by that, "get tossed around" is pretty vague. So, for example, you could post a topic to Gameplay Questions, asking "Why do my craft get tossed around on launch?" for the title. Then describe, as specifically as possible, what happens, something along these general lines: ...Or something like that. Don't worry if you don't get the wording perfect, or aren't sure how to describe it-- that's a common problem. If what you've said isn't specific enough, people will post clarifying questions so they can zero in on the issue. In general, always include a screenshot of the problem, if you can-- a picture's worth a thousand words, and lots of KSP problems can be identified at a glance by someone who's experienced. Anyway, that's my suggestion. Post a Gameplay Question thread for your get-tossed-around problem, and another one for your run-out-of-fuel problem. For the former, be sure to describe just what you mean by "tossed around" and under what circumstances it happens, if possible. For the latter, a description of the intended mission is helpful. In both cases, include a screenshot. Good luck!

Moving to Technical Support.

Ah, okay. You may want to re-title your thread, since this is causing a lot of confusion. "The landing gear is messing me up" makes it sound like you have a problem with the landing gear, whereas what you actually have is a problem with the structural integrity of the craft, which is nothing to do with landing gear at all. Anyway. If you've got big flimsy wings made of multiple parts, and the landing gear are located way out on the wingtips, that puts a lot of mechanical strain on the wings and involves a lot of potential joints to break. How's the craft put together? Do you use any autostruts on the wings? (If not, you should). Have you turned on "rigid attachment" anywhere in the wing assembly? (If you have... don't; it'll make 'em more brittle.) The closer to the center-line of the craft you can make the landing gear, the less bending torque they'll apply to the wings. The ideal case (from a mechanical-strength standpoint) would be to have the gear mounted directly to the fuselage, underneath it. Of course, that would give the craft a narrower "stance", and make it easy to tip over left or right when landing... but you could always put some "outrigger" gear farther out to prevent a tip-over, and mount it ever-so-slightly higher than the ones under the fuselage. That way, on landing, the brunt of the shock would be transmitted directly to the central fuselage of the plane, so less likely to snap apart. And if you accidentally start to tip, then the outrigger gear will have you covered. I'd suggest checking that, and if it's not the largest gear, make it the largest gear. 100-150 tons is a pretty heavy craft, and KSP landing gear can be pretty finicky about the amount of load they can handle. And the amount of load the handle on landing is generally considerably lower than they can handle just sitting on the runway, so it's possible to have a craft that launches and takes off just fine but blows up the gear upon landing. There's nothing wrong with posting a craft file-- if you can do that, great. But suppose some potentially helpful person is skimming through the Gameplay Questions forum, and they glance at your post. If all you give them is a craft file... that's a hassle. They gotta download it, and install it into their game, and start up KSP, and so forth. It's inconvenient... and it's also impossible unless they happen to be sitting at the computer where they play KSP. Whereas a well-taken screenshot is super helpful, reveals a lot of categories of problems at a glance, carries no "inconvenience" burden, and works on any device anywhere. In short, there's a bigger pool of available people inclined to help you if you provide a screenshot. So, when you run into problems, my advice would be: Always post a screenshot Also post a craft file, too, if you feel like it, but it's not absolutely necessary Just post 'em to some image-sharing site such as imgur (anywhere public will work, but imgur tends to be the most popular here since it doesn't require you to have an account in order to post stuff). Once you've posted it to imgur-or-wherever, just right-click on the image and choose "Copy image location", then paste that URL here. It'll get automagically converted into an in-line image.

Did you disable roll authority on the tail fin? Because if you didn't, the tail fin will try to "help" you roll, which is exactly precisely what you don't want. With roll authority turned off, you should never get any yaw result when rolling. (The reverse-- i.e. getting a bit of unwanted roll when you're trying to yaw-- is basically unavoidable with a lone tail fin, but that's generally not a problem assuming you've got some well-placed ailerons on the wings to compensate-- they're a lot farther from the roll axis than the tail fin is, and therefore have a lot more roll authority.) (Apologies if it's a silly question, but a lot of folks forget to do that.)

I see this screenshot on the page link, ...but could you post a larger screenshot? It's easier to work with, doesn't require starting up KSP and allows diagnosing a lot of problems. Some questions: What's the mass of your craft when you're trying to land? How many landing gear, of what type, are you using? What exactly do you mean when you say "the thing snaps apart"? The landing gear explodes? The wings snap off the fuselage? Something else?

Just a side note that this entire discussion is now well over six years old, and KSP has changed a lot in the meantime. The OP, and other folks involved in the original discussion, have presumably long since moved on. Accordingly, locking the thread to prevent further confusion. If anyone has any related concerns that they still want to ask about, feel free to spin up a new thread!

It's not a bug, it's by design: for docking the craft to "count", they must come from separate launches. I assume they deliberately did it that way so that the player has to be able to do an orbital rendezvous. Otherwise, a player could just launch one vessel with a couple of docking ports, get to orbit, separate and immediately re-dock, thus evading the challenge. Since it's by design and not a bug, I wouldn't expect them to ever change this. In any case, though, this thread is from years ago, so the folks involved have presumably long since moved on and further discussion here is likely moot. Accordingly, locking the thread to prevent further confusion. If by any chance you've found what seems to you to be an actual bug, i.e. something that's not intended behavior, then feel free to spin up a thread in the technical support forum to see if any info is available.

Got any specific examples? i.e. some specific "how do I figure out <thing> in <situation>" type of question that you're interested in or is especially vexing you?

Thread locked per OP request.

The main suggestions are: Liberally include code comments, like, a lot. How much is "enough" is subjective, of course, but just for comparison, here's a typical source file of mine to give an idea of the amount of comments I like to use, myself. Avoid really long blocks of code that go on for pages and pages-- if it's more than will fit on a screen or two, consider breaking it up into smaller functions. Rationale for the code-comment thing: It'll make your life easier. It means you're less likely to self-inflict bugs on yourself by getting confused about "what did I mean when I coded this". It's easy to write code that's meant to do one thing, and then come back weeks or months later and read it and think you meant something else and get caught up in your own assumptions. It means that other people can read your code much more easily too, which means that if you ever need to ask for help, it's a lot easier to get it. It also means that anyone inclined to debug your mod themselves, and/or look at your source code, will better be able to understand it and more likely to spot problems (e.g. stemming from mistaken assumptions or whatever). It means that when you do have a bug, and you're trying to track it down, you'll be able to follow the logic flow of your code faster and more reliably, and incorrect assumptions will tend to "stick out" more. Rationale for the break-it-up-into-smaller-functions thing is much the same. Pretty much the same benefits as the above.

...rummage rummage... Ah, quite so, as is Vector3d. Earlier comment cheerfully withdrawn. Thanks!

Fair 'nuff then. Interested in some friendly coding style advice/suggestions from a grizzled old coder, which may help make life a bit easier for you? (I ask first, because no desire to pontificate unless you're actually interested. Not everyone is.) Yes. .magnitude returns whatever units the Vector3d is in. Remember, Vector3d doesn't itself specify any units, any more than double does. It's just a trio of double values named x, y, and z. So, suppose you have a Vector3d where x = 3, and y = 4, and z = 0. The magnitude will be 5. Because 32 + 42 + 02 = 52. So... 5 what? Answer: 5 of whatever x, y, and z were specified in. So, for example, Vessel.GetWorldPos3D() happens to return a Vector3d whose units are meters. So if you have two vectors, and both of them happen to be in meters, then the magnitude of each one will be in meters, too. (And of course, if you're doing any math on the vectors, like finding v1 - v2 to get the delta between them... better make sure they're both in the same units, or you're trying to mix apples and oranges and hilarity will ensue.)