Snark

Astonishingly enough-- and I realize that this is, apparently, complicated enough to be difficult to grasp, so stay with me-- the reason turns out to be that it is, in fact, a malicious site that we no longer use. There was once a website which was a predecessor to SpaceDock, which was running essentially the same software and worked the same way, which was (like SpaceDock) a major go-to site for hosting KSP mods. The site was decommissioned and abandoned several years ago, which is why SpaceDock popped up to replace it. Unfortunately, the abandoned website's DNS then came up for grabs, and it was taken over by malicious actors who now use it as a site for hosting malware, i.e. the kind of dangerous place that tries to put viruses and things onto unwitting visitors' machines. It's a bad place and people shouldn't go there. Alas, the KSP forum was strewn with many links to this site (from the "before times" when it was legit), which put the KSP community at risk. So we did our best to scrub the references and links, and as an added safety precaution, we added the name of the site to the "naughty words" list so that it will get auto-replaced with "malicious site we no longer use". This serves a dual purpose. First, it lets people know (who might otherwise not have gotten the memo) what's going on with that site; and, second, it helps prevent further spread of references to the site in the forum. It's not a perfect solution by any means, but it's easy for us to do, and it's reasonable because there's really no legitimate reason for anyone to be going there anymore. On a more serious note... in general, please don't try to get "clever" and bypass the filter, as you just did. There's a forum rule about this (2.2.g, "any technique that bypasses the language filter"). If you find that the forum is blocking you from typing something... well, that's there for a reason, even if it may not be immediately obvious what the reason is. It means that the forum is telling you "don't type that", and is not an invitation to find a way to work around it. So please don't do that, okay?

Thank you, looks great! You're all set. Just for your information: I see that you've included bin/Debug in your github repo. There's nothing wrong with that, but you don't actually need to include the "bin" directory in your repo. That's because it doesn't contain source; it contains the build result, and so users don't actually need to download that (since when they download the source code and press the "build" button in Visual Studio, the "bin" folder will be generated for them). I'm not sure how familiar you are with github, but if you'd like to exclude the "bin" directory from your repo so that the git client won't always be pestering you to upate it, you can include a .gitignore file with your repo. Totally optional, it's up to you. (Here's an example of a .gitignore from one of my own mods, as an example of something that works. My own .gitignore has "src/" on each line, because that's where I put my source files, so if you add your own .gitignore to your repo, you may need to adjust that.)

Hello @Leo0806-studios, and welcome to the forums! Thank you for contributing to the modding community. It's great to see you posting your mod here, but there are a few points to fix, per the add-on posting rules: Could you please edit your forum post, above, to say what the license is? (From looking at your github repository, it looks as though you're using Gnu GPL v2. So if you could just add a note to your post, above, saying "License: GNU GPLv2", then that would satisfy this requirement.) You also need to include the license file in your downloadable zip. When I download your zip file from SpaceDock, all it has is a DLL in it. It should include the LICENSE file from your repo, so that when a user installs it on their KSP machine, they'll have the license file there. Where is your source code? Maybe I'm missing something, but when I go to your github repository that you link, above, I don't see any actual code. All I see is a README and a license file. Where's the actual code? Your code link (i.e. your github repo) should include all the source files that you use to build your DLL-- i.e. the .sln file, .csproj file, all the .cs files, etc. It needs to be so that any user can clone your repo and build the DLL themselves. Thanks again for posting the mod! (And please don't worry about your English-- you're doing just fine, and lots of people here have English as a second language, nobody worries about that.) Cheers, Snark [EDIT] I see you've already fixedthe issues.

Looks as though you've got very little pitch authority-- i.e. pressing W and S won't make the plane pitch much, which is going to make it hard to control. As far as I can tell, you only have two sets of pitch control surfaces, and those aren't going to do much: The ailerons on the wings. But those are only barely behind the CoM and therefore have almost no lever arm to work with-- they're not going to be very effective for pitch control. Some tiny ailerons mounted to the fuselage, just behind the cabin door. But those are pretty small, and also not super far forward (so not a lot of lever arm). Suggestion: Take those ailerons that you've got mounted just behind the cabin door, and move them all the way forward, up so they're right close to the nose. That will give them about double the pitch authority, just from increasing their lever arm. (You'll probably want to disable roll authority on them-- it's not needed, you don't want them generating drag just to try to roll, and your wing-mounted ailerons should be ample for roll control). Add ailerons in the back. You've got that looooong tail code sticking out the back of the craft, so use it. Put some pitch control surfaces right back there at the very aft-most tip of the tail cone. That's way behind your CoM and will give you a lot of control authority. While you're at it: Take that vertical stabilizer and move it all the way back, too. It'll work way better. Also, make sure you've turned off roll authority for it; it should only have yaw activated.

Moving to Gameplay Questions.

Shrug. Silly autocorrect is silly. Typo corrected.

Hello @Kion, thank you for sharing your mod with the community! Moderator note: Some content has been removed. Folks, please remember that constructive feedback is always welcome, but it's not your place to tell a modder what decisions they should make about their own stuff. More words to that effect here.

A fair amount of content has been redacted and/or removed, due to being some combination of unconstructive, off-topic, and backseat moderating. Folks, modders are free to make what they want to. It's their stuff, so they can do what they like. If you like a mod, then you can use it. If you don't like it, then don't use it. If you have positive, constructive things to say, for example how you think the mod could be improved, then of course that's fine to say. What's not okay is to criticize a modder's decision about their own stuff. "I think it would be nicer if you did X" is fine, but "you shouldn't be doing what you're doing" is not-- it's not your place to tell someone what they should or shouldn't be doing with their own stuff. You're not an arbiter of the forum, it's not your place to decide what people should or shouldn't be posting. You're not the gatekeeper. Trying to "gatekeep" is unhelpful, inappropriate, and makes the forum a less friendly and less welcoming place for everyone. So, please don't do that. Remember that every modder who posts something here-- regardless of whether you happen to like it or not-- is someone who put work into doing something that was likely challenging for them, and then had the courage to post it publicly. So, criticizing them for that seems like a pretty poor way to show appreciation. If you have positive words of encouragement, or suggestions for improvement, great. If you don't care for it, then nobody's putting a gun to your head, just stroll on by and find some other mod that's more to your taste. Thank you for your understanding.

Thread locked per OP request.

The larger hinges are considerably stiffer than the smaller ones. If your problem is that it's too floppy when you want it to be stationary, you can address that with autostruts. Have a part on the distal side of the hinge autostrut to the root part or heaviest part-- i.e. something that's on the proximal side. When you lock the joint, then the autostrut will activate and hold it rigid. (When the joint isn't locked, then that breaks the autostrut and it will have that floppiness, so this solution won't help you if your issue is that it's too floppy while you're moving the hinge.)

Moving to Gameplay Questions.

Very nice walk-through with pictures, thank you! I tried a manual gravity ascent myself, with a craft pretty similar to yours. Managed a slightly-over-5km circular orbit with 578 m/s of dV spent, so that's a fairly consistent result. My main impression, from reading your two cases that you tried, was essentially the same as @king of nowhere's. If you try it twice, and the difference is only 10 m/s of dV, that's so close as to be a negligible difference in these two cases, given the randomness of piloting. Well, not quite. Note that @king of nowhere said he had trouble with constant-altitude ascent, not descent. And I never said that the ascent was easier at constant altitude. Quite the reverse-- a continuous burn is fairly simple, just crank it over to start the turn, set it to hold and floor it. My comment about suicide-burn landing being tricky is purely a matter of judging when to start the burn. The actual piloting is trivial, just let SAS hold and be prepared to cut thrust when needed, that's it. I'd say that a constant-altitude landing would require considerably more tweaking of steering and so forth. Less risk than a suicide-burn descent, but more interaction and, I'd say, more piloting skill needed. I think that this comment is pretty relevant: Because your approach (@camacju) and mine are, in practice, usually very similar in terms of the actual piloting. Regardless of whether one is doing a suicide burn or a constant-altitude landing, it's still the case that it's a bad idea to descend steeply to the surface. My suicide burn advice is that you only lower your Pe just barely underground, so that you're approaching the ground at a very shallow (i.e. nearly horizontal) angle before you start your burn. So, let's consider a landing, in your proposed case versus mine. In your proposed use case, you're going very fast sideways initially... ...with zero descent rate you thrust nearly horizontally, with your nose pointed up just slightly so that you can maintain altitude therefore you have a tiny cosine loss while you're burning as you slow down more, you'll have to point your nose higher and higher above horizontal, resulting in more and more cosine loss cosine loss is worst just before touchdown Whereas in my proposed use case, you're going very fast sideways initially... ...with a very low descent rate you thrust nearly horizontally, with your nose pointed perfectly therefore you have zero cosine loss, but you do have a tiny gravity loss while thrusting because you're not perfectly horizontal as you slow down more, your path will become more steeply inclined, resulting in more gravity loss. Still no cosine loss, though gravity loss is worst just before touchdown Note how very, very similar these two cases are. #1 is identical for both cases. #3 is basically identical in both cases. #4 is pretty close to identical-- a small loss in both, just of a different nature. #5 and #6 are likewise extremely similar. Now consider the fact that none of the Kerbin system's bodies are perfectly flat (except for Minmus' flats, but even those are surrounded by steep slopes that you have to clear). Which means that you're going to have to be concerned with terrain avoidance. A constant-altitude landing is generally not going to be able to slide sideways to a perfect stop on the top of a hill-- in practice, the player who wants to use this approach will pretty much always have to make that a constant-altitude that's higher than the target landing point, meaning that they're going to have to transition to a steep or vertical descent at some point in order to come in for a landing. And if they're doing that... then the shape of the curve that the ship follows is starting to look an awful lot like what a suicide-burn ship is doing, anyway.

Should it not be less efficient than a burn, because of cosine losses? Yes, there is gravity loss, but you have that regardless, no? So you can do a burn and have gravity losses, or you can do a constant-altitude burn and have both gravity losses and cosine losses. What's the rationale for the latter? It's true that sometimes you can't do a burn because you've got such a low TWR-- i.e. just barely higher than 1-- that you need to burn with your nose pointed higher than just so you don't fall down and crash while you're still trying to kill your horizontal speed. (The "landing on Tylo with nuke engines" scenario.) So, yes, sometimes that's necessary. But that's nnot the same thing as being more efficient, it's just a necessary inefficiency to deal with an extremely low TWR. And in my experience, Tylo tends to be the only place where that tends to be an issue. Other vacuum worlds tend to have fairly low gravity and therefore landers are likely to have a local TWR significantly higher than 1, so that's not an issue. If you're burning anything other than perfectly , you're incurring extra cosine losses and you're not saving gravity losses. Note that I'm not saying that a constant-altitude landing is a bad idea. There are reasons it can be appealing to people-- for example, it takes the knuckle-biting out of the landing, you don't have to worry about going splat if you misjudge timing by a fraction. You have more time to adjust, to bump your nose up a bit if you're getting uncomfortably close to terrain while accelerating, for example. There's absolutely nothing wrong with landing like that, if it works well for someone. And in very low-TWR cases, it may actually be necessary, as you point out. But it's not the most efficient. The pure suicide burn that I'm describing is riskier, that's why it's called a suicide burn. And not everyone wants that risk, and that's perfectly understandable-- it's not for everybody. But it is more efficient; that's why people do it. (Also, note that when I say "more efficient" or "less efficient", that's a relative term-- depending on the situation, the dV savings from one to the other may not be big enough for the player to care about much, in which case clearly the player should go with whatever landing technique they're comfortable with.)

One handy way to think of it is this: Let's say you're landing on the Mun, where surface gravity is 1.63 m/s2. To keep things simple for purpose of this example, assume you're heading straight down (which normally you wouldn't be, because braking to a halt in orbit and then falling down would be really inefficient). That would mean that every second until you touch down, you're accelerating downwards an additional 1.63 m/s. That's 1.63 m/s of additional dV that you'll need, to kill the accumulated pull of gravity. Basically, you're leaking dV, and the speed at which you're leaking it equals local gravity. So, the most efficient way to land is the suicide burn-- i.e. fall fast and wait until the last second to brake hard to a halt-- because that's minimizing the time you're leaking dV. That also helps give you an idea of how much of a penalty you pay if you're not quite hitting an ideal suicide burn. For example, if you start your burn too soon and as a result it takes 20 extra seconds until you touch down, then that means you would have leaked 20 * 1.63 = 32.6 m/s wasted, compared with an ideal suicide burn. Note that in the above example, I had you falling straight down, in order to simplify the math. In reality, that would be a pretty inefficient trajectory-- normally what you'd do is to do just enough of a burn in orbit to lower your Pe to ground level, so that when you're approaching the impact point, actually you're descending at a very shallow angle and mostly moving sideways. In that case, the timing of your suicide burn is a bit less critical in terms of efficiency, because most of your burn is devoted to just killing that very large sideways velocity, and a relatively small amount of it is fighting gravity. It's only the last little bit at the end that you approach the vertical, as you continuously thrust and your velocity drops.

The theoretically most efficient way is to do this: While in orbit, do just enough of a burn to get into a suborbital trajectory (i.e. lower your Pe below ground level). Note that this puts your impact trajectory on a shallow angle with the ground. Put your navball into surface mode, if it's not already. Set SAS to hold . Free-fall until you're close to the surface. At the last possible instant*, slam your throttle to maximum while still holding . Decelerate to a halt right when you arrive at ground level. Cut throttle, you're done. The catch, here-- as you've probably spotted -- is to know just when is the "last possible instant" in step 4. It's tricky and very finicky. If you start the burn too soon, you end up braking to a halt while still high over the surface, which is fuel-inefficient. If you start the burn even a little too late, like a second or two, then you get a practical demonstration of why this technique is called a "suicide burn". So, the tricky bit is judging that moment for hitting the gas. If you're amenable to mods, then my mod BetterBurnTime has some help for that, as @FruitGoose is kind enough to point out, above. If you'd prefer not to use mods, however, there's a slightly clunky way that you can use maneuver nodes to do most of the math for you. Here's a step-by-step description of the technique:

I can totally understand your concern-- I'm super paranoid about privacy, myself, and very protective of my data. However, based on the actual facts involved, I think you're probably in the clear, here. It sounds as though your concerns, as laid out above, have been addressed. I'd strongly suggest that you carefully read this statement by the KSP community manager. It's a long read with quite a few paragraphs, but details are important and I'd recommend that you read the whole thing: I can summarize it thus: Where collection & transmission of your data are concerned, there are two software packages of interest, here: Unity Analytics Red Shell Unity Analytics is, indeed, still present in KSP today. However, personally, I'm not greatly concerned about it for privacy, because: It only looks at in-game stuff (i.e. how you play KSP, what missions you run, etc.); not external stuff like what websites you visit or anything like that. It has a legitimate purpose for improving the game (by letting the developer see what people are having problems with) Most importantly, you can opt out to tell it "shut up and don't send anything". If you don't like it, you can just turn it off. Red Shell is, indeed, much creepier from a privacy standpoint, IMO. I'm with you on this one. However, Red Shell is not in KSP now, and has not been for a couple of years. They added it in KSP 1.4 After an uproar of angry users, they removed it in KSP 1.4.4 Therefore, based on the concerns that you expressed above, I think you should be fine. There's no Red Shell in there anymore, and the Unity Analytics stuff is quite a bit more benign and you can turn it off if you don't like it. I realize that you were expressing concern about KSP 2 rather than original KSP, here. And of course, until it actually comes out, nobody can say for sure exactly what they'll do. However, personally, my guess is that they won't put Red Shell in there, because they got so badly burned last time and took it out right away. It's worth noting that at the time of that kerfuffle, that was after T2 had already acquired KSP, and it was therefore T2's decision to pull Red Shell out of there. So, yes. We should stay vigilant, and we should keep our eyes on them, and if they were to add it back in for some reason, we should make our voices heard. However, it's not there now, and it seems likely to me, based on their track experience, that it won't be in there. (For myself, I also black-hole the DNS to all of Red Shell's websites, just in case any software on my system does ever try to talk to them. It's pretty straightforward to do. Details here, for anyone who's interested.)

Looks good on your forum post here, and on your SpaceDock page. However, I note that you don't appear to have updated your downloadable file with a new version-- don't you still need to replace the license file that's inside your downloadable mod?

Thank you. When I look at those two links, I see that RVE64k Kerbin Clouds for Spectra is licensed CC-BY-NC-SA, whereas you've licensed your mod as MIT. That's a license incompatibility, which is a problem-- since CC-BY-NC-SA is more restrictive than MIT, that means you can't take CC-BY-NC-SA content and re-license it as MIT, since that means you'd be erasing part of the original license. Fortunately, CC-BY-NC-SA is still a fairly permissive license-- it's just not quite as wide-open as MIT is. You could solve that by changing your license from MIT to CC-BY-NC-SA (though if you do so, you need to make sure that you change it not just here in your forum post and on your SpaceDock page, but also in the license file that you include with your download). From looking at the EVE link that you provide, it appears that it's licensed MIT, so you should be in the clear, there. (Sorry for the hassle-- I know that issues of license compatibility can be confusing. Here's a discussion of the issue, if it helps.)

Hi @Benjordy2, and welcome to the forums! A question-- when you say this, ...what exactly do you mean by that? Did you work with these people and they made content for you to include in your mod? Or did you copy content from someone else's mod to include in your own? If it's someone else's stuff that you found somewhere and included, where did you include it from? Could you provide a link?

Looks as though that option's only available when you're creating a new game-- if you have an existing game, that particular option is omitted from the difficulty settings. It may be worth manually editing the save file to see if that will do the trick. WARNING WARNING Make sure you make a backup of your persistent.sfs file for the save game BEFORE you do any tinkering. Editing a save file has the potential to corrupt it and render it unplayable if you accidentally mess anything up, so make sure you keep an unedited copy so you can go back to what you had before, in case of any problems. With that caveat: If you go into your "saves" folder and find a file called persistent.sfs, make a pristine copy of it somewhere for safekeeping, then open the original file in some text editor such as Notepad. Near the top of the file, there should be a "DIFFICULTY" section that looks something like this: DIFFICULTY { AutoHireCrews = False MissingCrewsRespawn = False RespawnTimer = 7200 BypassEntryPurchaseAfterResearch = False AllowStockVessels = False IndestructibleFacilities = False ResourceAbundance = 0.8 ReentryHeatScale = 1 EnableCommNet = True AllowOtherLaunchSites = True persistKerbalInventories = False } See that line that says AllowOtherLaunchSites = True? Well, it says "True" for me because I have 'em turned on in my own game. For your game, it will presumably say "False". So, edit that entry to say "True" instead of "False", save your changes, then start up KSP and give it a whirl. Hopefully, you'll have the other launchsites turned on, now. I should add that I haven't tried this myself and don't actually know that it works. I'm guessing that it will, but the only way to find out is to try it. Hopefully it'll do exactly what you want and cause no issues in your game. If it doesn't work, or if you notice any odd behavior after trying it, then you can go back to its previous state by exiting KSP, and copying that "safe backup copy" from wherever you put it back into your saves folder.

Some content has been removed. Let's please stick to the topic at hand and avoid personal remarks, please. Thank you.

Yes, correct, you should do this, for precisely this reason. If I'm understanding you correctly, I think you're saying "well, if I burn all the time, initially I'm thrusting slightly downwards in this picture, and later I'm thrusting slightly upwards, and those two things cancel each other out!", is that what you're saying? If so, then no, that's not how it works, that's not a thing, nothing is "canceling" anything. You're going "down" and then "up" (in that drawing" because the planet's gravity is curving your path, there's no loss. You add energy by thrusting , and only the component adds to your orbital energy. Any or component is wasted as cosine loss, so don't do that. Probably will want to narrow that down by quite a bit. When you're initially circular, this would mean you'd be futzing a lot with your Pe (since you should be thrusting ). Later, after you've given it a few kicks to raise your Ap by a lot, this means that burning for 30 degrees on either side of Pe would mean doing a lot of the burn at high altitude and losing Oberth benefit. So, best to keep your burns narrower-- 10 degrees on either side seems pretty reasonable. Yes, it raises the Pe. But as long as you only burn in a fairly narrow band on either side of Pe-- i.e. 10 degrees or less, not 30 degrees-- then it won't change your Pe very much, so the loss of Oberth effect should be minimal.

The way I normally design propeller planes and helicopters in KSP: Set torque to maximum and never touch it again. Tie the RPM to the throttle. Pick a reasonable angle for the blades, then do either the simple or the fancy: Simple: add "Toggle Deploy" for the blades to an action group. Fancy: tie the blades' deploy angle to an axis group and bind that to a key pair like I/K. ...and that's it. I use "adjust the blade pitch" the way I'd use the gear shift in a car. The "simple" approach (toggle between two positions with an action group) is like having a car that has only two gears. The "fancy" approach (where I can continuously adjust the pitch of the blades up or down by pressing I/K) is like having a car with a continuously variable transmission. I'm not saying this is the best way, or the most efficient. But I find that it works pretty well for me. I start out in "low gear" when I'm at low speed (i.e. low blade pitch), then when I max out my speed I "shift into higher gear" (apply more blade pitch).

As folks have said, "It's complicated". But it basically boils down to this: Decide what mission you're going to run. (Take a kerbal to LKO and back? Land on the Mun? Land on the Mun and return? etc.) Figure out how much dV you'll need to do that mission. Design a rocket that has that much dV (plus a reasonable amount extra as safety margin). For the parts of the mission that involve landing or taking off from the surface of a moon or planet, make sure your TWR is appropriate, given the local gravity. (Until you start visiting other planets, taking off from the launchpad at KSC is the main place you need to be concerned with this.) As to "how do you figure this stuff out": each of #2, #3, and #4 is a whole complicated topic in its own right and one could spend a lot of time explaining it. Since I don't know which bits you already know and where you need more understanding, I'll hold off on throwing great walls of text at you and let you ask more questions as you need. Broadly speaking, though: Figuring out #2 can get all mathy if you want, but there are dV maps such as what @king of nowhere posted above. For example, getting from Kerbin surface to low orbit takes about 3400 m/s. To go to the Mun from there takes about another 860 m/s, then 280 m/s to get into low Mun orbit, then 580 m/s to land on the surface. Add 'em up. "Build a rocket with a certain amount of dV" is where you hone your design skills-- that's the tricky bit. Basically you build it stage-by-stage and pick an appropriate engine and an appropriate mass of fuel for each stage. You'll have a long learning curve to climb here. One good way to learn is to just post a pic of your ship here, and we can offer suggestions about how to improve it (with explanations as to why).

"Reducing costs" really isn't a thing, for me. I design the right rocket to carry out the mission, and it just costs whatever it costs. The reason that I don't worry myself about the cost of the rocket is that the cost of the rocket is basically irrelevant. Income from contracts is much higher than the cost of missions-- I just wait until there's a lucrative contract that's reasonably quick to do, and that'll pay for scads of missions. If I just play the game, money flows in. For example, "launch a new station on a solar orbit" contracts can pay well over 500K funds, for a craft that takes about five minutes to slap together from scratch and launch to an escape trajectory. That'll pay for an awful lot of missions. By far the major financial cost of the game is upgrading buildings (especially R&D), and that's a fixed cost so there's nothing there to reduce.